linux-kernel - Re: [PATCH] drivers/hv: select PCI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z5hYnSW-3iKZxn0T@liuwe-devbox-debian-v2>
Date: Tue, 28 Jan 2025 04:10:05 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>
Cc: Michael Kelley <mhklinux@...look.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	Wei Liu <wei.liu@...nel.org>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Dexuan Cui <decui@...rosoft.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers/hv: select PCI_HYPERV if PCI is enabled

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@...ux.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.