|
xen-devel
[Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
|
To: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor |
|
From: |
"Yang, Sheng" <sheng.yang@xxxxxxxxx> |
|
Date: |
Thu, 17 Sep 2009 14:47:48 +0800 |
|
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> |
|
Delivery-date: |
Mon, 21 Sep 2009 04:58:39 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C6D66994.14D6A%keir.fraser@xxxxxxxxxxxxx> |
|
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Organization: |
Intel Opensource Technology Center |
|
References: |
<C6D66994.14D6A%keir.fraser@xxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; x86_64; ; ) |
On Wednesday 16 September 2009 17:08:20 Keir Fraser wrote:
> On 16/09/2009 09:44, "Yang, Sheng" <sheng.yang@xxxxxxxxx> wrote:
> > Hi Keir & Jeremy
> >
> > Here is the hypervisor part of hybrid extension support.
> >
> > Please review, thanks!
>
> The principle is okay I guess. These changes would have to be trickled in
> with a really good explanation and justification for each one.
>
> For
> example, I'm not clear why the enable-hybrid hypercall is needed. Why not
> just provide access to evtchn and timer hypercalls always, and guest sues
> them if it is capable of it?
We have purposed a component independence approach, that means user can enable
PV timer or evtchn separately. Currently we have some limit with event channel
implementation, e.g. no passthrough device support, and SMP is also not ready
at this time(but in progress). (And I think there would be some version issue
later, if we support more features).
The enable-hybrid hypercall is there because we can do adjust some hypervisor
behaviour if we know guest would be hybrid rather than hvm or pv. For example,
HVM assume TSC is start from 0, but pv timer assume TSC is no different with
native. So we need modify tsc offset to 0 to make pv timer work. And we may
also do some optimization in hypervisor if we know that guest is hybrid rather
than hvm/pv.
> I'm also not sure why PV timer events get
> routed to irq0 -- why not via an event channel as usual, now that you are
> enabling HVM guests to use the evtchn subsystem?
As stated above, we support a mode that using PV timer without event channel.
But I am thinking maybe we can let evtchn co-exist with IOAPIC/LAPIC, then pv
timer use evtchn, others goes to normal hardware way. And another feature can
replace IOAPIC/LAPIC with evtchn.
> What's a hybrid gnttab,
> and why does it need an explciit reserved e820 region? And so on.
We need some memory to map gnttab. It was provided by a QEmu emulated device
in HVM, but we think it's not elegant that a basic feature depends on a
device, so we got this e820 region...
> The general principle of these patches seems to be to create a set of
> individual, and perhaps largely independent, accelerations/enlightenments
> to the HVM interface. I can at least agree with and support that aim.
Thanks. :)
--
regards
Yang, Sheng
>
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home