Re: [PATCH vfio 10/11] vfio/virtio: Expose admin commands over virtio device

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

 



On Wed, Oct 11, 2023 at 04:10:58AM -0400, Michael S. Tsirkin wrote:
> On Wed, Oct 11, 2023 at 08:00:57AM +0000, Parav Pandit wrote:
> > Hi Christoph,
> > 
> > > From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
> > > Sent: Wednesday, October 11, 2023 12:29 PM
> > > 
> > > On Wed, Oct 11, 2023 at 02:43:37AM -0400, Michael S. Tsirkin wrote:
> > > > > Btw, what is that intel thing everyone is talking about?  And why
> > > > > would the virtio core support vendor specific behavior like that?
> > > >
> > > > It's not a thing it's Zhu Lingshan :) intel is just one of the vendors
> > > > that implemented vdpa support and so Zhu Lingshan from intel is
> > > > working on vdpa and has also proposed virtio spec extensions for migration.
> > > > intel's driver is called ifcvf.  vdpa composes all this stuff that is
> > > > added to vfio in userspace, so it's a different approach.
> > > 
> > > Well, so let's call it virtio live migration instead of intel.
> > > 
> > > And please work all together in the virtio committee that you have one way of
> > > communication between controlling and controlled functions.
> > > If one extension does it one way and the other a different way that's just
> > > creating a giant mess.
> > 
> > We in virtio committee are working on VF device migration where:
> > VF = controlled function
> > PF = controlling function
> > 
> > The second proposal is what Michael mentioned from Intel that somehow combine controlled and controlling function as single entity on VF.
> > 
> > The main reasons I find it weird are:
> > 1. it must always need to do mediation to do fake the device reset, and flr flows
> > 2. dma cannot work as you explained for complex device state
> > 3. it needs constant knowledge of each tiny things for each virtio device type
> > 
> > Such single entity appears a bit very weird to me but maybe it is just me.
> 
> Yea it appears to include everyone from nvidia. Others are used to it -
> this is exactly what happens with virtio generally. E.g. vhost
> processes fast path in the kernel and control path is in userspace.
> vdpa has been largely modeled after that, for better or worse.

As Parav says, you can't use DMA for any migration flows, and you open
a single VF scheme up to PCI P2P attacks from the VM. It is a pretty
bad design.

vfio reviewers will reject things like this that are not secure - we
just did for Intel E800, for instance.

With VDPA doing the same stuff as vfio I'm not sure who is auditing it
for security.

The simple way to be sure is to never touch the PCI function that has
DMA assigned to a VM from the hypervisor, except through config space.

Beyond that.. Well, think carefully about security.

IMHO the single-VF approach is not suitable for standardization.

Jason



[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