RE: [PATCH 1/2] Drivers: hv: vmbus: add support to ignore certain PCIE devices

[Long Li]

> Subject: RE: [PATCH 1/2] Drivers: hv: vmbus: add support to ignore certain
> PCIE devices
> 
> From: longli@xxxxxxxxxxxxxxxxx <longli@xxxxxxxxxxxxxxxxx> Sent:
> Monday, June 7, 2021 6:05 PM
> >
> > When Hyper-v presents a FlexIOV device to VMBUS, this device has its
> > VMBUS channel and a PCIE channel. The PCIE channel is not used in
> > Linux and does not have a backing PCIE device on Hyper-v. For such
> > FlexIOV devices, add the code to ignore those PCIE devices so they are
> > not getting probed by the PCI subsystem.
> >
> > Cc: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
> > Cc: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> > Cc: Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>
> > Cc: Wei Liu <wei.liu@xxxxxxxxxx>
> > Cc: Dexuan Cui <decui@xxxxxxxxxxxxx>
> > Signed-off-by: Long Li <longli@xxxxxxxxxxxxx>
> > ---
> >  drivers/hv/channel_mgmt.c | 43
> > +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> > index caf6d0c..6fd7ae5 100644
> > --- a/drivers/hv/channel_mgmt.c
> > +++ b/drivers/hv/channel_mgmt.c
> > @@ -26,6 +26,20 @@
> >
> >  static void init_vp_index(struct vmbus_channel *channel);
> >
> > +/*
> > + * Hyper-v presents FlexIOV devices on the PCIE.
> > + * Those devices have no real PCI implementation in Hyper-V, and
> > +should be
> > + * ignored and not presented to the PCI layer.
> > + */
> > +static const guid_t vpci_ignore_instances[] = {
> > +	/*
> > +	 * XStore Fastpath instance ID in VPCI introduced by FlexIOV
> > +	 * {d4573da2-2caa-4711-a8f9-bbabf4ee9685}
> > +	 */
> > +	GUID_INIT(0xd4573da2, 0x2caa, 0x4711, 0xa8, 0xf9,
> > +		0xbb, 0xab, 0xf4, 0xee, 0x96, 0x85), };
> > +
> >  const struct vmbus_device vmbus_devs[] = {
> >  	/* IDE */
> >  	{ .dev_type = HV_IDE,
> > @@ -487,6 +501,16 @@ void vmbus_free_channels(void)
> >  	}
> >  }
> >
> > +static bool ignore_pcie_device(guid_t *if_instance) {
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(vpci_ignore_instances); i++)
> > +		if (guid_equal(&vpci_ignore_instances[i], if_instance))
> > +			return true;
> > +	return false;
> > +}
> > +
> >  /* Note: the function can run concurrently for primary/sub channels.
> > */  static void vmbus_add_channel_work(struct work_struct *work)  { @@
> > -958,6 +982,17 @@ static bool vmbus_is_valid_device(const guid_t *guid)
> >  	return false;
> >  }
> >
> > +static bool is_pcie_offer(struct vmbus_channel_offer_channel *offer)
> > +{
> > +	int i;
> > +
> > +	for (i = HV_IDE; i < HV_UNKNOWN; i++)
> > +		if (guid_equal(&offer->offer.if_type, &vmbus_devs[i].guid))
> > +			break;
> 
> This would be the third place in channel_mgmt.c that we have essentially the
> same code for looking through the vmbus_devs array for a matching GUID.
> See hv_get_dev_type() and vmbus_is_valid_device().
> Perhaps do some minor refactoring to have a common search function that
> return a pointer to the matching entry in the vmbus_devs array?  The code
> would have to handle the "no match"
> case by pointing to the last entry (HV_UNKNOWN).
> 
> > +
> > +	return i == HV_PCIE;
> 
> This assumes that the index in the vmbus_devs array is the same as
> the .dev_type field of the entry.  That's true at the moment, but seems a bit
> brittle in the long run.
> 
> > +}
> > +
> >  /*
> >   * vmbus_onoffer - Handler for channel offers from vmbus in parent
> partition.
> >   *
> > @@ -1051,6 +1086,14 @@ static void vmbus_onoffer(struct
> > vmbus_channel_message_header *hdr)
> >  		return;
> >  	}
> >
> > +	/* Check to see if we should ignore this PCIe channel */
> > +	if (is_pcie_offer(offer) &&
> > +	    ignore_pcie_device(&offer->offer.if_instance)) {
> > +		pr_info("Ignore instance %pUl over VPCI\n",
> > +			&offer->offer.if_instance);
> 
> I'm wondering if we really want to output this message.   As
> Hyper-V is updated to support this new blob access method, it seems like
> pretty much every VM will generate the message on boot, and I don't see
> any real value in it.  Maybe make it debug level?
> 
> > +		return;
> > +	}
> > +
> 
> Is there a reason to do this check *after* searching for the oldchannel and
> handling a match?  I'm thinking this check could go immediately after the call
> to trace_vmbus_onoffer().
> 
> >  	/* Allocate the channel object and save this offer. */
> >  	newchannel = alloc_channel();
> >  	if (!newchannel) {
> > --
> > 1.8.3.1

I'm sending v2 to address all the comments.