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
