RE: [Xen-devel] Does Xen also plan to move the back-end driver to the stub domain for HVM?

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Liang Yang
> Sent: 19 March 2007 16:34
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Does Xen also plan to move the back-end 
> driver to the stub domain for HVM?
> 
> Hi,
> 
> Based on the roadmap on Xen summit, there is a plan to move 
> QEMU and let it 
> run on the stub domain to improve HVM performance. However, 
> comparing with 
> QEMU device model, it will be much easier to move BE driver 
> and let it run 
> in stub domain instead of dom0 as BE part is running on the 
> kernel space 
> (QEMU is running on user space).

But that wouldn't serve the same purpose. What would you solve with
doing this? 

The purpose of the stub-domain is to ensure that QEMU-DM runs on the
same CPU as the domain needing the device-model, which in turn serves
several purposes:
1. It reduces the load on Dom0. Dom0 can end up being the bottleneck
quite qucikly for a HVM system with many domains. 
2. It reduces the latency in switching (because there is no OTHER
processor to wake up, wait for qemu-dm to react, etc, etc). 

The back-end driver, on the other hand, is there to serve as a bridge
between the virtual device in the guest and the hardware owner (dom0).
Since there's no plan to let guest-domains straight onto hardware
(besides the what's currently allowed with the pci-hide and
pci-passthrough - where the guest domain OWNS that hardware
exclusively), there's still a need to communicate from DomU to Dom0 (or
whichever domain it is that owns the hardware involved). 
> 
> but I'm little bit confused about the relationship between 
> stub domain and 
> guest domain. Is the stub domain part of guest domain? Does 
> each guest 
> domain have a stub domain which is created when the guest 
> domain is created?

Yes, each guest domain will have a stub-domain, according to what I
understand. 
> 
> If the stub domain is part of guest domain, does porting 
> device model to 
> stub domain compromise the orginial design purpose of 
> isoloated devide 
> domain?

No, because the stub-domain will still communicate with Dom0 once it's
got a full packet of IO request (cf. our discussion on IDE controller
for example). 

The purpose of the stub-domain is primarily to reduce the overhead of
Dom0. There are quite a few IO requests that can be resolved almost
entirely in the qemu-dm itself, which means that the Dom0 wouldn't have
to be bothered at all. Other requests do require that Dom0 is involved.
But if 1 in 4 requests go to Dom0, that means that the stub-domain can
solve 3 in 4 requests without going through Dom0 - that's where the big
saving is. 

--
Mats
> 
> Thanks,
> 
> Liang
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel