| 
         
xen-devel
Re: [Xen-devel] Re: Does Xen also plan to move the back-end driver	to th
 
Liang Yang wrote:
 "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?
  
 No, it means that it communicates with the native device drivers 
directly instead of going through another indirection layer (namely, the 
front and backend drivers).
Regards,
Anthony Liguori
 ----- 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
 
 |   
 
| <Prev in Thread] | 
Current Thread | 
[Next in Thread>
 |  
- Re: [Xen-devel] Questions about device/event channels in Xen., (continued)
 
- [Xen-devel] Does Xen also plan to move the back-end driver to the	stub domain for HVM?, Liang Yang
 - RE: [Xen-devel] Does Xen also plan to move the back-end driver	to the stub domain for HVM?, Petersson, Mats
 
- [Xen-devel] Re: Does Xen also plan to move the back-end driver to the stub domain for HVM?, Anthony Liguori
 - Re: [Xen-devel] Re: Does Xen also plan to move the back-end driver to	the stub domain for HVM?, Liang Yang
 - Re: [Xen-devel] Re: Does Xen also plan to move the back-end driver	to the stub domain for HVM?,
Anthony Liguori <=
 - [Xen-devel] Question about reserving one CPU for the Xen hypervisor	in case of vm exit., Liang Yang
 - RE: [Xen-devel] Question about reserving one CPU for the Xen	hypervisor in case of vm exit., Petersson, Mats
 
- RE: [Xen-devel] Re: Does Xen also plan to move the back-end	driver to the stub domain for HVM?, Petersson, Mats
 
- Re: [Xen-devel] Questions about device/event channels in Xen., Daniel Stodden
 
- [Xen-devel] RE: Questions about device/event channels in Xen., Petersson, Mats
 
- Re: [Xen-devel] More page-table questions., PUCCETTI Armand
 - RE: [Xen-devel] More page-table questions., Petersson, Mats
 - Re: [Xen-devel] More page-table questions., Mark Williamson
 
 
 |  
  
 | 
    |