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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien,

> On 28 Oct 2022, at 14:27, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> 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.

Ok I understand now.

> 
> 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.

But we will generate it. How would something like Zephyr guest work ? Zephyr is 
not using the device tree we pass, it has an embedded one.

> 
> 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.

I am a bit afraid of things that are “automatic”.

For everything else we let the user in control (IPA for mapping, virtual 
interrupt number) and in this case we switch to a model where we automatically 
generated a vMaster ID.
With this model, guest not using the device tree will have to guess the vMaster 
ID or somehow know how the tools are generating it to use the right one.

Cheers
Bertrand


> 
> Cheers,
> 
> -- 
> Julien Grall