From: Wei Liu <wei.liu@kernel.org>
To: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Cc: Michael Kelley <mhklinux@outlook.com>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Wei Liu <wei.liu@kernel.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Dexuan Cui <decui@microsoft.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drivers/hv: select PCI_HYPERV if PCI is enabled
Date: Tue, 28 Jan 2025 04:10:05 +0000 [thread overview]
Message-ID: <Z5hYnSW-3iKZxn0T@liuwe-devbox-debian-v2> (raw)
In-Reply-To: <Z5f94J7rzSC-TyIB@hm-sls2>
On Mon, Jan 27, 2025 at 04:42:56PM -0500, Hamza Mahfooz wrote:
> On Mon, Jan 27, 2025 at 09:02:22PM +0000, Michael Kelley wrote:
> > From: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Sent: Monday, January 27, 2025 10:10 AM
> > >
> > > We should select PCI_HYPERV here, otherwise it's possible for devices to
> > > not show up as expected, at least not in an orderly manner.
> >
> > The commit message needs more precision: What does "not show up"
> > mean, and what does "not in an orderly manner" mean? And "it's possible"
> > is vague -- can you be more specific about the conditions? Also, avoid
> > the use of personal pronouns like "we".
> >
> > But the commit message notwithstanding, I don't think this is change
> > that should be made. CONFIG_PCI_HYPERV refers to the VMBus device
> > driver for handling vPCI (a.k.a PCI pass-thru) devices. It's perfectly
> > possible and normal for a VM on Hyper-V to not have any such devices,
> > in which case the driver isn't needed and should not be forced to be
> > included. (See Documentation/virt/hyperv/vpci.rst for more on vPCI
> > devices.)
>
> Ya, we ran into an issue where CONFIG_NVME_CORE=y and
> CONFIG_PCI_HYPERV=m caused the passed-through SSDs not to show up (i.e.
> they aren't visible to userspace). I guess it's cause PCI_HYPERV has
> to load in before the nvme stuff for that workload. So, I thought it was
> reasonable to select PCI_HYPERV here to prevent someone else from
> shooting themselves in the foot. Though, I guess it really it on the
> distro guys to get that right.
Does inserting the PCI_HYPERV module trigger a (re)scanning of the
(v)PCI bus? If so, the passed-through NVMe devices should show up just
fine, I suppose.
I agree with Michael that we should not select PCI_HYPERV by default. In
some environments, it is not needed at all.
Thanks,
Wei.
next prev parent reply other threads:[~2025-01-28 4:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 18:09 [PATCH] drivers/hv: select PCI_HYPERV if PCI is enabled Hamza Mahfooz
2025-01-27 21:02 ` Michael Kelley
2025-01-27 21:42 ` Hamza Mahfooz
2025-01-27 22:14 ` Michael Kelley
2025-01-28 4:10 ` Wei Liu [this message]
2025-01-28 4:45 ` Michael Kelley
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=Z5hYnSW-3iKZxn0T@liuwe-devbox-debian-v2 \
--to=wei.liu@kernel.org \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hamzamahfooz@linux.microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=stable@vger.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