[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKgT0Uf28XKcAiU=URR8H3xJnOdmfeKRDdVNCzrTbH_ao-mvVA@mail.gmail.com>
Date: Wed, 10 Jan 2018 16:05:44 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Maximilian Heyne <mheyne@...zon.de>, linux-pci@...r.kernel.org,
Alex Williamson <alex.williamson@...hat.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Liang-Min Wang <liang-min.wang@...el.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pci-stub: enable SR-IOV configuration through sysfs
Sorry for top-posting but I am just going to throw a recap of the
discussions as I recall them on top of this since the code itself
isn't so much the subject of review.
I would imagine this has the same issues that we were talking about
for the VFIO or UIO solutions for this. Basically the discussion all
came down to the fact that doing this potentially exposes the kernel
to a possible security issue since the PF might be managed by an
untrusted source. I believe the last discussion we had about the VFIO
based solution ended in us needing to have a way to make it so that
the auto-probe value could be changed and be restored after the
user-space managed PF driver was unloaded and/or SR-IOV was disabled.
Basically we can't risk tainting the kernel by auto-loading the VF
drivers on the kernel when the PF is managed by an unknown entity or
user space.
- Alexander
On Wed, Jan 10, 2018 at 3:35 PM, Bjorn Helgaas <helgaas@...nel.org> wrote:
> [+cc Alex, Alex, Jeff, Liang-Min, kvm, LKML]
>
> Anybody else have any thoughts on this?
>
> On Wed, Dec 13, 2017 at 02:05:33PM +0100, Maximilian Heyne wrote:
>> Currently, SR-IOV VFs can only be configured through sysfs, if a driver
>> is loaded for the device. Sometimes we don't care about the PF, but only
>> want to assign VFs to guests, which is now possible with this patch.
>>
>> Signed-off-by: Maximilian Heyne <mheyne@...zon.de>
Powered by blists - more mailing lists