This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] Does Xen also plan to move the back-end driver to the st

To: "Liang Yang" <multisyncfe991@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Does Xen also plan to move the back-end driver to the stub domain for HVM?
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Mon, 19 Mar 2007 17:45:00 +0100
Delivery-date: Mon, 19 Mar 2007 09:44:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <BAY125-DAV264B6B07FBC9E6B97625093760@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdqRHJ9W6JBDGiETEucooLC8ElmZwAAA9vw
Thread-topic: [Xen-devel] Does Xen also plan to move the back-end driver to the stub domain for HVM?

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

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

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>