On 28/10/2022 14:13, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 28 Oct 2022, at 14:06, Julien Grall <jul...@xen.org> 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
