Hi Anthony,
On 02-05-23, 15:44, Anthony PERARD wrote:
diff --git a/tools/libs/light/libxl_virtio.c b/tools/libs/light/libxl_virtio.c index faada49e184e..e1f15344ef97 100644 --- a/tools/libs/light/libxl_virtio.c +++ b/tools/libs/light/libxl_virtio.c @@ -48,11 +48,13 @@ static int libxl__set_xenstore_virtio(libxl__gc *gc, uint32_t domid, flexarray_append_pair(back, "base", GCSPRINTF("%#"PRIx64, virtio->base)); flexarray_append_pair(back, "type", GCSPRINTF("%s", virtio->type)); flexarray_append_pair(back, "transport", GCSPRINTF("%s", transport));
- flexarray_append_pair(back, "forced_grant", GCSPRINTF("%u", virtio->forced_grant));
flexarray_append_pair(front, "irq", GCSPRINTF("%u", virtio->irq)); flexarray_append_pair(front, "base", GCSPRINTF("%#"PRIx64, virtio->base)); flexarray_append_pair(front, "type", GCSPRINTF("%s", virtio->type)); flexarray_append_pair(front, "transport", GCSPRINTF("%s", transport));
- flexarray_append_pair(front, "forced_grant", GCSPRINTF("%u", virtio->forced_grant));
This "forced_grant" feels weird to me in the protocol, I feel like this use of grant or not could be handled by the backend. For example in "blkif" protocol, there's plenty of "feature-*" which allows both front-end and back-end to advertise which feature they can or want to use. But maybe the fact that the device tree needs to be modified to be able to accommodate grant mapping means that libxl needs to ask the backend to use grant or not, and the frontend needs to now if it needs to use grant.
I am not sure if I fully understand what you are suggesting here.
The eventual fronend drivers (like drivers/i2c/busses/i2c-virtio.c) aren't Xen aware and the respective virtio protocol doesn't talk about how memory is mapped for the guest. The guest kernel allows both memory mapping models and the decision is made based on the presence or absence of the iommu node in the DT.
The backends in our case are hypervisor agnostic and aren't part of Xen or any other hypervisor. I am not sure how the backend can provide the mapping information to Xen, with which the creation of the iommu DT node can be controlled.
Also, as I communicated in another email, the currently suggested option in this patch, "forced_grant", isn't enough for us. We also need a way to disable grant mappings. Right now we are creating iommu nodes by default all the time, if the backend domain isn't Dom0.
What I need probably is something like: "use_grant", where setting it to 1 will always create the iommu node and setting it to 0 will not, irrespective of the backend domain, and this overrides the current model of defaulting to create the node when not mapped by Dom0.