From: Anthony Liguori <aliguori@us.ibm.com>
To: Liang Yang <multisyncfe991@hotmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Does Xen also plan to move the back-end driver to the stub domain for HVM?
Date: Mon, 19 Mar 2007 13:20:26 -0500 [thread overview]
Message-ID: <45FED46A.40006@us.ibm.com> (raw)
In-Reply-To: <BAY125-DAV264B6B07FBC9E6B97625093760@phx.gbl>
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
next prev parent reply other threads:[~2007-03-19 18:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1HQkNQ-0002f5-Pl@host-192-168-0-1-bcn-london>
2007-03-12 16:10 ` Xen-devel Digest, Vol 25, Issue 93 PUCCETTI Armand
2007-03-12 16:19 ` Petersson, Mats
2007-03-12 16:23 ` Keir Fraser
2007-03-12 16:26 ` More page-table questions Petersson, Mats
2007-03-12 16:32 ` Keir Fraser
2007-03-12 16:35 ` Petersson, Mats
2007-03-12 16:38 ` Keir Fraser
2007-03-15 22:15 ` Questions about device/event channels in Xen Liang Yang
2007-03-16 0:34 ` Mark Williamson
2007-03-16 6:02 ` Liang Yang
2007-03-16 6:02 ` Liang Yang
2007-03-16 8:45 ` Keir Fraser
2007-03-16 17:30 ` Does Dom0 always get interrupts first before they are delivered to other guest domains? Liang Yang
2007-03-16 17:40 ` Petersson, Mats
2007-03-16 18:48 ` Liang Yang
2007-03-21 0:37 ` Mark Williamson
2007-03-21 1:23 ` Liang Yang
2007-03-21 1:23 ` Liang Yang
2007-03-21 8:31 ` Does Dom0 always get interrupts first before they aredelivered " Tian, Kevin
2007-03-21 9:13 ` Does Dom0 always get interrupts first before they are delivered " Petersson, Mats
2007-04-07 16:59 ` Mark Williamson
2007-04-12 0:20 ` Does Dom0 always get interrupts first before theyare " Liang Yang
2007-04-12 14:00 ` Petersson, Mats
2007-04-12 20:15 ` Does Dom0 always get interrupts first beforetheyare " Liang Yang
2007-03-19 16:33 ` Does Xen also plan to move the back-end driver to the stub domain for HVM? Liang Yang
2007-03-19 16:45 ` Petersson, Mats
2007-03-19 18:20 ` Anthony Liguori [this message]
2007-03-19 19:21 ` Liang Yang
2007-03-19 20:20 ` Anthony Liguori
2007-03-19 21:56 ` Question about reserving one CPU for the Xen hypervisor in case of vm exit Liang Yang
2007-03-20 10:13 ` Petersson, Mats
2007-03-20 10:03 ` Re: Does Xen also plan to move the back-end driver to the stub domain for HVM? Petersson, Mats
2007-03-16 3:17 ` Questions about device/event channels in Xen Daniel Stodden
2007-03-16 8:38 ` Petersson, Mats
2007-03-12 17:27 ` More page-table questions PUCCETTI Armand
2007-03-12 17:42 ` Petersson, Mats
2007-03-13 16:25 ` Mark Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45FED46A.40006@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=multisyncfe991@hotmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.