Re: [PATCH] Enable SR-IOV instantiation through /sys file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 6, 2017 at 3:27 PM, Alex Williamson
<alex.williamson@xxxxxxxxxx> wrote:
> On Tue, 31 Oct 2017 12:55:20 +0000
> "Wang, Liang-min" <liang-min.wang@xxxxxxxxx> wrote:
>
>> > -----Original Message-----
>> > From: David Woodhouse [mailto:dwmw2@xxxxxxxxxxxxx]
>> > Sent: Monday, October 30, 2017 8:39 AM
>> > To: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Duyck, Alexander H
>> > <alexander.h.duyck@xxxxxxxxx>
>> > Cc: Wang, Liang-min <liang-min.wang@xxxxxxxxx>;
>> > alex.williamson@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Kirsher, Jeffrey T
>> > <jeffrey.t.kirsher@xxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx;
>> > linux-pci@xxxxxxxxxxxxxxx
>> > 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).
>>
>> Under UEFI secure boot environment, kernel puts restrictions on UIO and its derivatives.
>> So, user-space function/driver based upon UIO is no longer working under UEFI secure
>> boot environment. The next viable option is vfio-pci, hence this patch in parallel with
>> UIO work.
>
> If you want a PF driver that does nothing other than allow SR-IOV to be
> enabled, doesn't that scream pci-stub?  Trying to overlay it onto a
> driver that also allows userspace driver access to that device seems
> like the worst idea.  Thanks,
>
> Alex

So for the case where a user-space agent is running the actual PF how
is it you suggest we go about quarantining the interfaces? What kind
of behavior is it you are expecting to see? Should we look into a way
to clear match_driver for the VF interfaces so the drivers won't load
on them at all, or are you expecting something like vfio-pci to be
selected to auto-load on them since the PF is already running that?

Thanks.

- Alexander



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux