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

From: Gerd Hoffmann <kraxel@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
	"John G Johnson" <john.g.johnson@oracle.com>,
	"mst@redhat.com" <mtsirkin@redhat.com>,
	"Janosch Frank" <frankja@linux.vnet.ibm.com>,
	"Jason Wang" <jasowang@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Kirti Wankhede" <kwankhede@nvidia.com>,
	"Yan Vugenfirer" <yan@daynix.com>,
	"Jag Raman" <jag.raman@oracle.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Anup Patel" <anup@brainfault.org>,
	"Claudio Imbrenda" <imbrenda@linux.vnet.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Roman Kagan" <rkagan@virtuozzo.com>,
	"Felipe Franciosi" <felipe@nutanix.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Jens Freimann" <jfreimann@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Sergio Lopez" <slp@redhat.com>,
	"Kashyap Chamarthy" <kchamart@redhat.com>,
	"Darren Kenny" <darren.kenny@oracle.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Liran Alon" <liran.alon@oracle.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Thanos Makatos" <thanos.makatos@nutanix.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Halil Pasic" <pasic@linux.vnet.ibm.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"Christophe de Dinechin" <dinechin@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>, fam <fam@euphon.net>
Subject: Re: Out-of-Process Device Emulation session at KVM Forum 2020
Date: Wed, 4 Nov 2020 07:50:52 +0100	[thread overview]
Message-ID: <20201104065052.hrc2entvg7bkodb6@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAJSP0QXJd-BK60t+efhAt2d6mj9+kgieiyfKm=DSC1z+fDCesA@mail.gmail.com>

  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.

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