[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1509367141.11641.51.camel@infradead.org>
Date: Mon, 30 Oct 2017 12:39:01 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Christoph Hellwig <hch@...radead.org>,
"Duyck, Alexander H" <alexander.h.duyck@...el.com>
Cc: "Wang, Liang-min" <liang-min.wang@...el.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH] Enable SR-IOV instantiation through /sys file
On Sat, 2017-10-28 at 23:16 -0700, Christoph Hellwig wrote:
> On Fri, Oct 27, 2017 at 11:20:41PM +0000, Duyck, Alexander H wrote:
> >
> > I don't see this so much as a security problem per-se. It all depends
> > on the hardware setup. If I recall correctly, there are devices where
> > the PF function doesn't really do much other than act as a bit more
> > heavy-weight VF, and the actual logic is handled by a firmware engine
> > on the device.
>
> Can you cite an example? While those surely could exist in theory,
> I can't think of a practical example.
I have them, which is why I'm patching the UIO driver to allow num_vfs
to be set. I don't even want to *use* the UIO driver for any purpose
except to make that appear in sysfs. It's all handled in the device.
(I think we might be able to just give the PF out to a guest as if it
were just another VF, but I don't think we actually *do* that right
now).
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (4938 bytes)
Powered by blists - more mailing lists