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

[Oleksandr <olekstysh@xxxxxxxxx>]

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.

--
Regards,

Oleksandr Tyshchenko