Re: [PATCH] libxl: arm: Allow grant mappings for backends running on Dom0

[Viresh Kumar <viresh.kumar@linaro.org>]

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.

-- 
viresh