Re: Proposal for virtual IOMMU binding b/w vIOMMU and passthrough devices

[Julien Grall <julien@xxxxxxx>]

On 28/10/2022 14:13, Bertrand Marquis wrote:
> Hi Julien,
Hi Bertrand,

> > On 28 Oct 2022, at 14:06, Julien Grall <julien@xxxxxxx> wrote:
> >
> > Hi Rahul,
> >
> > On 28/10/2022 13:54, Rahul Singh wrote:
> > > > > > > > For ACPI, I would have expected the information to be found in the IOREQ.
> > > > > > > >
> > > > > > > > So can you add more context why this is necessary for everyone?
> > > > > > > We have information for IOMMU and Master-ID but we don’t have information for 
> > > > > > > linking vMaster-ID to pMaster-ID.
> > > > > > I am confused. Below, you are making the virtual master ID optional. So 
> > > > > > shouldn't this be mandatory if you really need the mapping with the virtual ID?
> > > > > vMasterID is optional if user knows pMasterID is unique on the system. But if 
> > > > > pMasterId is not unique then user needs to provide the vMasterID.
> > > > So the expectation is the user will be able to know that the pMasterID is uniq. 
> > > > This may be easy with a couple of SMMUs, but if you have 50+ (as suggested 
> > > > above). This will become a pain on larger system.
> > > >
> > > > IHMO, it would be much better if we can detect that in libxl (see below).
> > > We can make the vMasterID compulsory to avoid complexity in libxl to solve this
> > In general, complexity in libxl is not too much of problem.
> I am a bit unsure about this strategy.
> Currently xl has one configuration file where you put all Xen parameters. The 
> device tree is only needed by some guests to have a description of the system 
> they run on.
> If we change the model and say that Xen configuration parameters are both in 
> the configuration and the device tree, we somehow enforce to have a device tree 
> even though some guests do not need it at all (for example Zephyr).
I think my approach was misunderstood because there is no change in the 
existing model.
What I am suggesting is to not introduce iommu_devid_map but instead let 
libxl allocate the virtual Master-ID and create the mapping with the 
physical Master-ID.
Libxl would then update the property "iommus" in the device-tree with 
the allocated virtual Master-ID.
Each node in the partial device-tree would need to have a property
to refer to the physical device just so we know how to update the 
"iommus". The list of device passthrough will still be specified in the 
configuration file. IOW, the partial device-tree is not directly 
involved in the configuration of the guest.
So far, I don't see a particular issue with this approach because the 
vMaster ID algorithm allocation should be generic. But please let me 
know if you think there are bits I am missing.
Cheers,

--
Julien Grall