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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.08.2020 11:22, Oleksandr wrote:
> 
> On 05.08.20 19:40, Paul Durrant wrote:
> 
> Hi Jan, Paul
> 
>>> -----Original Message-----
>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>> Sent: 05 August 2020 17:20
>>> To: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>; Paul Durrant <paul@xxxxxxx>
>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Oleksandr Tyshchenko 
>>> <oleksandr_tyshchenko@xxxxxxxx>; Andrew
>>> Cooper <andrew.cooper3@xxxxxxxxxx>; George Dunlap 
>>> <george.dunlap@xxxxxxxxxx>; Ian Jackson
>>> <ian.jackson@xxxxxxxxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano 
>>> Stabellini
>>> <sstabellini@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Daniel De Graaf 
>>> <dgdegra@xxxxxxxxxxxxx>
>>> 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@xxxxxxxx>
>>>>
>>>> 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.

Jan