From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Re: Does Xen also plan to move the back-end driver to the stub domain for HVM? Date: Mon, 19 Mar 2007 15:20:09 -0500 Message-ID: <45FEF079.4070906@us.ibm.com> References: <45FED46A.40006@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Liang Yang Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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" > > To: "Liang Yang" > Cc: > 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >