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

[Julien Grall <julien@xxxxxxx>]

On 14/08/2020 17:30, Oleksandr wrote:
> Hello all.
>
>
> > > > > -----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.
>
> 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.
Cheers,

--
Julien Grall