Re: [RFC PATCH 00/21] Add SMMUv3 Stage 1 Support for XEN guests

[Rahul Singh <Rahul.Singh@xxxxxxx>]

Hi Stefano,Julien

> On 5 Dec 2022, at 9:43 pm, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Sat, 3 Dec 2022, Julien Grall wrote:
>> On 01/12/2022 16:02, Rahul Singh wrote:
>>> This patch series is sent as RFC to get the initial feedback from the
>>> community. This patch series consists of 21 patches which is a big number
>>> for
>>> the reviewer to review the patches but to understand the feature end-to-end
>>> we
>>> thought of sending this as a big series. Once we will get initial feedback,
>>> we
>>> will divide the series into a small number of patches for review.
>> 
>> From the cover letter, it is not clear to me what sort of input you are
>> expecting for the RFC. Is this about the design itself?
>> 
>> If so, I think it would be more helpful to write an high level document on 
>> how
>> you plan to emulate the vIOMMU in Xen. So there is one place to
>> read/agree/verify rather than trying to collate all the information from the
>> 20+ patches.
>> 
>> Briefly skimming through I think the main things that need to be addressed in
>> order of priority:
>>  - How to secure the vIOMMU
>>  - 1 vs multiple vIOMMU
>> 
>> The questions are very similar to the vITS because the SMMUv3 is based on a
>> queue. And given you are selling this feature as a security one, I don't 
>> think
>> we can go forward with the review without any understanding/agreement on what
>> needs to be implemented in order to have a safe/secure vIOMMU.
> 
> I think we are all aligned here, but let me try to clarify further.
> 
> As the vIOMMU is exposed to the guest, and exposing a queue-based
> interface to the guest is not simple, it would be good to clarify in a
> document the following points:
> 
> - how is the queue exposed to the guest
> - how are guest-inputs sanitized
> - how do the virtual queue resources map to the physical queue
>  resources
> - lifecycle of the resource mappings
> - any memory allocations triggered by guest actions and their lifecycle
> 
> It is difficult to extrapole these details from 21 patches. Having these
> key detailed written down in the 0/21 email would greatly help with the
> review. It would make the review go a lot faster.

Ack. I will send the design docs by next week that will include all the 
requested
information.

Regards.
Rahul