linux-hyperv.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Kelley <mikelley@microsoft.com>
To: "longli@linuxonhyperv.com" <longli@linuxonhyperv.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
Cc: Long Li <longli@microsoft.com>, KY Srinivasan <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>
Subject: RE: [PATCH 1/2] Drivers: hv: vmbus: add support to ignore certain PCIE devices
Date: Mon, 21 Jun 2021 18:06:08 +0000	[thread overview]
Message-ID: <MWHPR21MB1593CD3B5D24099745AD1D21D70A9@MWHPR21MB1593.namprd21.prod.outlook.com> (raw)
In-Reply-To: <1623114276-11696-2-git-send-email-longli@linuxonhyperv.com>

From: longli@linuxonhyperv.com <longli@linuxonhyperv.com> 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@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: Dexuan Cui <decui@microsoft.com>
> Signed-off-by: Long Li <longli@microsoft.com>
> ---
>  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


  reply	other threads:[~2021-06-21 18:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08  1:04 [PATCH 0/2] Add a driver for host accelerated Microsoft Azure Blob Storage access longli
2021-06-08  1:04 ` [PATCH 1/2] Drivers: hv: vmbus: add support to ignore certain PCIE devices longli
2021-06-21 18:06   ` Michael Kelley [this message]
2021-06-23 18:05     ` Long Li
2021-06-08  1:04 ` [PATCH 2/2] Drivers: hv: add XStore Fastpath driver longli
2021-06-21 18:09   ` Michael Kelley
2021-06-23 19:21     ` Long Li
2021-06-23 22:01       ` Michael Kelley
2021-06-23 22:59         ` Long Li
2021-06-25 18:39           ` Michael Kelley
2021-06-25 19:51             ` Long Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR21MB1593CD3B5D24099745AD1D21D70A9@MWHPR21MB1593.namprd21.prod.outlook.com \
    --to=mikelley@microsoft.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longli@linuxonhyperv.com \
    --cc=longli@microsoft.com \
    --cc=sthemmin@microsoft.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).