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

[Oleksandr <olekstysh@xxxxxxxxx>]

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