Re: [RFC PATCH V1 07/12] A collection of tweaks to be able to run emulator in driver domain

[Oleksandr <olekstysh@gmail.com>]

On 16.08.20 18:36, Julien Grall wrote:

Hi Julien.

>
>
> On 14/08/2020 17:30, Oleksandr wrote:
>>
>> Hello all.
>>
>>
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: 05 August 2020 17:20
>>>>>> To: Oleksandr Tyshchenko <olekstysh@gmail.com>; Paul Durrant 
>>>>>> <paul@xen.org>
>>>>>> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko 
>>>>>> <oleksandr_tyshchenko@epam.com>; Andrew
>>>>>> Cooper <andrew.cooper3@citrix.com>; George Dunlap 
>>>>>> <george.dunlap@citrix.com>; Ian Jackson
>>>>>> <ian.jackson@eu.citrix.com>; Julien Grall <julien@xen.org>; 
>>>>>> Stefano Stabellini
>>>>>> <sstabellini@kernel.org>; Wei Liu <wl@xen.org>; Daniel De Graaf 
>>>>>> <dgdegra@tycho.nsa.gov>
>>>>>> Subject: Re: [RFC PATCH V1 07/12] A collection of tweaks to be 
>>>>>> able to run emulator in driver domain
>>>>>>
>>>>>> On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
>>>>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>>
>>>>>>> Trying to run emulator in driver domain I ran into various issues
>>>>>>> mostly policy-related. So this patch tries to resolve all them
>>>>>>> plobably in a hackish way. I would like to get feedback how
>>>>>>> to implement them properly as having an emulator in driver domain
>>>>>>> is a completely valid use-case.
>>>>>>   From going over the comments I can only derive you want to run
>>>>>> an emulator in a driver domain, which doesn't really make sense
>>>>>> to me. A driver domain has a different purpose after all. If
>>>>>> instead you mean it to be run in just some other domain (which
>>>>>> also isn't the domain controlling the target), then there may
>>>>>> be more infrastructure changes needed.
>>>>>>
>>>>>> Paul - was/is your standalone ioreq server (demu?) able to run
>>>>>> in other than the domain controlling a guest?
>>>>>>
>>>>> Not something I've done yet, but it was always part of the idea so 
>>>>> that we could e.g. pass through a device to a dedicated domain and 
>>>>> then run multiple demu instances there to virtualize it for many 
>>>>> domUs. (I'm thinking here of a device that is not SR-IOV and hence 
>>>>> would need some bespoke emulation code to share it out).That 
>>>>> dedicated domain would be termed the 'driver domain' simply 
>>>>> because it is running the device driver for the h/w that underpins 
>>>>> the emulation.
>>>> I may abuse "driver domain" terminology, but indeed in our use-case we
>>>> pass through a set of H/W devices to a dedicated domain which is 
>>>> running
>>>> the device drivers for that H/Ws. Our target system comprises a thin
>>>> Dom0 (without H/W devices at all), DomD (which owns most of the H/W
>>>> devices) and DomU which runs on virtual devices. This patch tries to
>>>> make changes at Xen side to be able run standalone ioreq server
>>>> (emulator) in that dedicated (driver?) domain.
>>> Okay, in which case I'm fine with the term. I simply wasn't aware of 
>>> the
>>> targeted scenario, sorry.
>>
>>
>> May I kindly ask to suggest me the pointers how to *properly* resolve 
>> various policy related issues described in that patch? Without having 
>> them resolved it wouldn't be able to run standalone IOREQ server in 
>> driver domain.
>
> You could already do that by writing your own XSM policy. Did you 
> explore it? If so, may I ask why this wouldn't be suitable?
>
> Also, I would like to emphasis that because of XSA-295 (Unlimited Arm 
> Atomics Operations), you can only run emulators in trusted domain on Arm.
>
> There would be more work to do if you wanted to run them in 
> non-trusted environment.

Thank you for the explanation. Yes, we consider driver domain as a 
trusted domain, there is no plan to run emulator in non-trusted domains. 
Indeed, it worth trying to write our own policy which will cover our use 
case (with emulator in driver domain) rather than tweak Xen's default one.


-- 
Regards,

Oleksandr Tyshchenko