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

["Liang Yang" <multisyncfe991@xxxxxxxxxxx>]

"QEMU has direct access to hardware", does this mean the QEMU device model 
does not need to communicate with the native device driver which is also 
sitting in dom0?
----- Original Message ----- 
From: "Anthony Liguori" <aliguori@xxxxxxxxxx>
To: "Liang Yang" <multisyncfe991@xxxxxxxxxxx>
Cc: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, March 19, 2007 11:20 AM
Subject: [Xen-devel] Re: Does Xen also plan to move the back-end driver to 
the stub domain for HVM?
> Liang Yang wrote:
> > 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.
> Using a stub domain won't improve HVM performance.  It will improve 
> accountability and scalability but running a single HVM guest shouldn't 
> see any improvement.
> > 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).
> Actually, this cannot make performance better since you're technically 
> adding another layer of indirection in the picture.  Within dom0, qemu-dm 
> has direct access to the hardware.  Fortunately, the Xen BE/FE model is 
> quite good performance wise so there shouldn't be a performance regression 
> here.
> > 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?
> A lot of this is still being worked out.  From a user perspective, the 
> idea would be that creating an HVM domain would be identical to how it's 
> done today.  What happens under the covers though remains to be seen.
> Regards,
>
> Anthony Liguori
>
> > 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?
> > 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