qemu-devel
[Top][All Lists]
Advanced

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

Re: Out-of-Process Device Emulation session at KVM Forum 2020


From: Stefan Hajnoczi
Subject: Re: Out-of-Process Device Emulation session at KVM Forum 2020
Date: Mon, 2 Nov 2020 14:59:10 +0000

On Mon, Nov 02, 2020 at 05:34:50AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 02, 2020 at 10:27:54AM +0000, Stefan Hajnoczi wrote:
> > On Mon, Nov 02, 2020 at 11:00:12AM +0800, Jason Wang wrote:
> > > 
> > > On 2020/10/30 下午7:13, Stefan Hajnoczi wrote:
> > > > > I still don't get why it must be opaque.
> > > > If the device state format needs to be in the VMM then each device
> > > > needs explicit enablement in each VMM (QEMU, cloud-hypervisor, etc).
> > > > 
> > > > Let's invert the question: why does the VMM need to understand the
> > > > device state of a_passthrough_  device?
> > > 
> > > 
> > > It's not a 100% passthrough device if you want to support live migration.
> > > E.g the device state save and restore is not under the control of drivers 
> > > in
> > > the guest.
> > 
> > VFIO devices are already not pure passthrough (even without mdev) since
> > the PCI bus is emulated and device-specific quirks may be implemented.
> 
> So since it's not a pure passthrough anyway, let's try to
> introduce some standards even if we can not always enforce
> them.

Yes, I agree. I've sent a document called "VFIO Migration" in a separate
email thread that defines how to orchestrate migration with versioning.
Maybe we can discuss the details there and figure out which guidelines
and device state representations to standardize.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]