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

[Oleksandr <olekstysh@xxxxxxxxx>]

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. Actually the virtio-mmio 
PoC is based on IOREQ/DM features and emulator (based on demu) acting as 
a virtio-mmio backend. But it may be various use-cases for that (some 
mediator for sharing specific H/W resource between Guests or custom PCI 
emulator for example). If this is valid from Xen PoV I would be happy to 
get feedback how to transform tweaks (hacks) in current patch into the 
proper support.

--
Regards,

Oleksandr Tyshchenko