Re: [PATCH 2/2] xen/virtio: Avoid use of the dom0 backend in dom0

From: Juergen Gross
Date: Tue Jul 04 2023 - 06:40:42 EST


On 04.07.23 09:48, Roger Pau Monné wrote:
On Thu, Jun 29, 2023 at 03:44:04PM -0700, Stefano Stabellini wrote:
On Thu, 29 Jun 2023, Oleksandr Tyshchenko wrote:
On 29.06.23 04:00, Stefano Stabellini wrote:
I think we need to add a second way? It could be anything that can help
us distinguish between a non-grants-capable virtio backend and a
grants-capable virtio backend, such as:
- a string on xenstore
- a xen param
- a special PCI configuration register value
- something in the ACPI tables
- the QEMU machine type


Yes, I remember there was a discussion regarding that. The point is to
choose a solution to be functional for both PV and HVM *and* to be able
to support a hotplug. IIRC, the xenstore could be a possible candidate.

xenstore would be among the easiest to make work. The only downside is
the dependency on xenstore which otherwise virtio+grants doesn't have.

I would avoid introducing a dependency on xenstore, if nothing else we
know it's a performance bottleneck.

We would also need to map the virtio device topology into xenstore, so
that we can pass different options for each device.

This aspect (different options) is important. How do you want to pass virtio
device configuration parameters from dom0 to the virtio backend domain? You
probably need something like Xenstore (a virtio based alternative like virtiofs
would work, too) for that purpose.

Mapping the topology should be rather easy via the PCI-Id, e.g.:

/local/domain/42/device/virtio/0000:00:1c.0/backend


Vikram is working on virtio with grants support in QEMU as we speak.
Maybe we could find a way to add a flag in QEMU so that we can detect at
runtime if a given virtio device support grants or not.

Isn't there a way for the device to expose capabilities already? For
example how does a virtio-blk backend expose support for indirect
descriptors?

Those capabilities are defined in the virtio spec [1]. Adding the backend
domid would be possible, but it probably wouldn't be that easy (requires
changing the virtio spec by either expanding an existing config area or by
adding a new one). I'm not sure handling in the specific frontends is
generic enough for being able to have a central place where the backend
domid could be retrieved, without requiring any change of the frontends.


Juergen

[1]: http://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature