[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Out-of-Process Device Emulation session at KVM Forum 2020
From: |
Michael S. Tsirkin |
Subject: |
Re: Out-of-Process Device Emulation session at KVM Forum 2020 |
Date: |
Wed, 4 Nov 2020 02:42:56 -0500 |
On Wed, Nov 04, 2020 at 07:50:52AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > I think not. Obviously each firmware should have its own ABI no matter
> > > whether its public or proprietary. For proprietary firmware, it should
> > > be understood by the proprietary userspace counterpart.
> >
> > Userspace does not necessarily need to interpret the contents. The
> > vendor can ship a binary blob and the driver loads the file onto the
> > device without interpreting it.
>
> Exactly. Neither userspace nor kernel look at the blob, except maybe
> some headers with version, size, checksum etc. Only the device does
> something with the actual content.
>
> Doing the same make sense for migration device state. The kernel driver
> saves and restores the device state. Userspace doesn't need to look at
> it. Again, with an exception for some header fields.
>
> So requiring userspace being able to interpret the migration data
> (except header) for all devices looks rather pointless to me.
If nothing else we need a good place where vendors can publish this
data.
> Speaking of headers: Defining a common header format makes sense.
> For standard devices (virtio, nvme, ...) it makes sense to try define
> a standard, cross-vendor migration data format.
> For vendor-specific devices (gpus for example) I absolutely don't see
> the point.
>
> take care,
> Gerd
Re: Out-of-Process Device Emulation session at KVM Forum 2020, Jason Wang, 2020/11/01