Re: [RFC PATCH] vfio: Update/Clarify migration uAPI, add NDMA state

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

 



On Wed, Jan 05, 2022 at 01:59:31AM +0000, Tian, Kevin wrote:

> > This will block the hypervisor from ever migrating the VM in a very
> > poor way - it will just hang in the middle of a migration request.
> 
> it's poor but 'hang' won't happen. PCI spec defines completion timeout
> for ATS translation request. If timeout the device will abort the in-fly
> request and report error back to software. 

The PRI time outs have to be long enough to handle swap back from
disk, so 'hang' will be a fair amount of time..
 
> > Regardless of the complaints of the IP designers, this is a very poor
> > direction.
> > 
> > Progress in the hypervisor should never be contingent on a guest VM.
> > 
> 
> Whether the said DOS is a real concern and how severe it is are usage 
> specific things. Why would we want to hardcode such restriction on
> an uAPI? Just give the choice to the admin (as long as this restriction is
> clearly communicated to userspace clearly)...

IMHO it is not just DOS, PRI can become dependent on IO which requires
DMA to complete.

You could quickly get yourself into a deadlock situation where the
hypervisor has disabled DMA activities of other devices and the vPRI
simply cannot be completed.

I just don't see how this scheme is generally workable without a lot
of limitations.

While I do agree we should support the HW that exists, we should
recognize this is not a long term workable design and treat it as
such.

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