Xen devel - Sep 2009 - Xen: Hybrid extension patchset for hypervisor

Hi Keir & Jeremy

Here is the hypervisor part of hybrid extension support.

Please review, thanks!

-- 
regards
Yang, Sheng








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 16/09/2009 09:44, "Yang, Sheng" <sheng.yang@intel.com> 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? 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? What''s a hybrid gnttab, and why
does it
need an explciit reserved e820 region? And so on.

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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 16/09/2009 10:08, "Keir Fraser" <keir.fraser@eu.citrix.com>
wrote:
> 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? 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? What''s a hybrid gnttab, and
why does it
> need an explciit reserved e820 region? And so on.
> 
> 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.
By the way, if your intention is to speed up 64-bit guest performance, then
I think you should compare with running a full PV guest in a VMCS container.
That is runs in VMX non-root mode but still retains the usual full-PV
interfaces. I think that would be no more code than you are proposing here,
and would avoid scattering a bunch more code around the guest OS, to which
there is bound to be resistance.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote on Wed, 16 Sep 2009 at 07:04:10:
> On 16/09/2009 10:08, "Keir Fraser"
<keir.fraser@eu.citrix.com> wrote:
> 
>> 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? 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?
What''s a
>> hybrid gnttab, and why does it need an explciit reserved e820 region?
>> And so on.
>> 
>> 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.
>  By the way, if your intention is to speed up 64-bit guest performance,
> then I think you should compare with running a full PV guest in a VMCS
> container. That is runs in VMX non-root mode but still retains the usual
> full-PV interfaces. I think that would be no more code than you are
> proposing here, and would avoid scattering a bunch more code around the
> guest OS, to which there is bound to be resistance.
Do you mean running the existing 64-bit PV kernel binaries in a VMCS container?

Based on our data, what we would want in PV 64-bit guests are, fundamentally:
- have the kernel run in ring 0 (so that it can regain the performance
enhancements)
- use hardware-based MMU virtualization (e.g. EPT-based) if present
> 
>  -- Keir
>
Jun
___
Intel Open Source Technology Center




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/16/09 09:28, Nakajima, Jun wrote:
> Keir Fraser wrote on Wed, 16 Sep 2009 at 07:04:10:
>   
>>  By the way, if your intention is to speed up 64-bit guest performance,
>> then I think you should compare with running a full PV guest in a VMCS
>> container. That is runs in VMX non-root mode but still retains the
usual
>> full-PV interfaces. I think that would be no more code than you are
>> proposing here, and would avoid scattering a bunch more code around the
>> guest OS, to which there is bound to be resistance.
>>     
> Do you mean running the existing 64-bit PV kernel binaries in a VMCS
container?
>   
Yes.  I don''t think there''s any deep problem in doing that.
> Based on our data, what we would want in PV 64-bit guests are,
fundamentally:
> - have the kernel run in ring 0 (so that it can regain the performance
enhancements)
>   
That''s no problem.  PV kernels don''t currently assume
they''re running in
any particular ring, so they''d be happy to run in ring 0 if
that''s how
they''re started (if there are problems, I''d consider that a
bug).  We
could then check for ring 0 and enable syscall/sysenter.
> - use hardware-based MMU virtualization (e.g. EPT-based) if present
>   
We could do that with minimal API/ABI changes by:

    * Providing an identity p2m table
    * Changing the hypercall page to make pte writes simple memory
      writes (no hypercalls); xen would still keep track of pinned pages
      and trap''n''emulate on them for back-compatibility (but
fast-path
      with no validation).  We could expose the presence of HAP via
      xen_features so that guests know they can avoid marking pagetables
      RO, etc.
    * Similarly, cr3 changes can be fast-pathed within the hypercall page.
    * Whatever else I''ve overlooked.

This would be very similar to how xenner gets PV guests running under kvm.

The tricky part might be in getting IO working, since it relies on
getting real MFNs for DMA.

At any rate, the changes need only be very localized within the
Xen-specific code.  I would not want to introduce a new or significantly
different kernel<->hypervisor ABI for any new modes (we have enough
already).

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 16/09/2009 09:44, "Yang, Sheng" <sheng.yang@intel.com>
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? 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? What''s a hybrid gnttab, and
why does it
> need an explciit reserved e820 region? And so on.
>
> 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.
>
>  -- Keir
>   
I did not see the hypervisor part of these patches appear in my 
xen-devel inbox. Is this a problem on my end, or were they not sent to 
the list? If so, I''m interested in them, so it''d be great if
they could
be sent to the list.

Thanks,

- Frank


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2009-09-16 at 19:19 +0100, Jeremy Fitzhardinge wrote:
> On 09/16/09 09:28, Nakajima, Jun wrote:
> > Keir Fraser wrote on Wed, 16 Sep 2009 at 07:04:10:
> >   
> >>  By the way, if your intention is to speed up 64-bit guest
performance,
> >> then I think you should compare with running a full PV guest in a
VMCS
> >> container. That is runs in VMX non-root mode but still retains the
usual
> >> full-PV interfaces. I think that would be no more code than you
are
> >> proposing here, and would avoid scattering a bunch more code
around the
> >> guest OS, to which there is bound to be resistance.
> >>     
> > Do you mean running the existing 64-bit PV kernel binaries in a VMCS
container?
> >   
> 
> Yes.  I don''t think there''s any deep problem in doing
that.
> 
> > Based on our data, what we would want in PV 64-bit guests are,
fundamentally:
> > - have the kernel run in ring 0 (so that it can regain the performance
enhancements)
> >   
> 
> That''s no problem.  PV kernels don''t currently assume
they''re running in
> any particular ring, so they''d be happy to run in ring 0 if
that''s how
> they''re started (if there are problems, I''d consider that
a bug).  We
> could then check for ring 0 and enable syscall/sysenter.
XENFEAT_supervisor_mode_kernel is supposed to enable this behaviour,
although it hasn''t been actively used for several years and never in
the
pvops kernel so you can bet it has bit-rotted...
> 
> > - use hardware-based MMU virtualization (e.g. EPT-based) if present
> >   
> 
> We could do that with minimal API/ABI changes by:
> 
>     * Providing an identity p2m table
>     * Changing the hypercall page to make pte writes simple memory
>       writes (no hypercalls); xen would still keep track of pinned pages
>       and trap''n''emulate on them for back-compatibility
(but fast-path
>       with no validation).  We could expose the presence of HAP via
>       xen_features so that guests know they can avoid marking pagetables
>       RO, etc.
>     * Similarly, cr3 changes can be fast-pathed within the hypercall page.
>     * Whatever else I''ve overlooked.
Some combination of XENFEAT_writable_page_tables
XENFEAT_writable_descriptor_tables and XENFEAT_auto_translated_physmap
might be of interest for this bit.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/16/09 14:12, Ian Campbell wrote:
>>> Based on our data, what we would want in PV 64-bit guests are,
fundamentally:
>>> - have the kernel run in ring 0 (so that it can regain the
performance enhancements)
>>>   
>>>       
>> That''s no problem.  PV kernels don''t currently assume
they''re running in
>> any particular ring, so they''d be happy to run in ring 0 if
that''s how
>> they''re started (if there are problems, I''d consider
that a bug).  We
>> could then check for ring 0 and enable syscall/sysenter.
>>     
> XENFEAT_supervisor_mode_kernel is supposed to enable this behaviour,
> although it hasn''t been actively used for several years and never
in the
> pvops kernel so you can bet it has bit-rotted...
>   
That tends to have a slightly different meaning, viz "dom0 really *is*
privileged and can do anything it feels like".  It isn''t necessary
to
have a specific feature/mechanism for "kernel happens to be in ring
0";
it can look at its own cs ring number.
>> We could do that with minimal API/ABI changes by:
>>
>>     * Providing an identity p2m table
>>     * Changing the hypercall page to make pte writes simple memory
>>       writes (no hypercalls); xen would still keep track of pinned
pages
>>       and trap''n''emulate on them for
back-compatibility (but fast-path
>>       with no validation).  We could expose the presence of HAP via
>>       xen_features so that guests know they can avoid marking
pagetables
>>       RO, etc.
>>     * Similarly, cr3 changes can be fast-pathed within the hypercall
page.
>>     * Whatever else I''ve overlooked.
>>     
> Some combination of XENFEAT_writable_page_tables
> XENFEAT_writable_descriptor_tables and XENFEAT_auto_translated_physmap
> might be of interest for this bit.
Making use of XENFEAT_auto_translated_physmap would avoid the need for
identity p2m/m2p tables, but I''m not sure whether it still works.  I
got
close to completely removing all references to it at one point, but I
think ia64 uses it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 17 September 2009 03:11:49 Frank van der Linden
wrote:
> Keir Fraser wrote:
> > On 16/09/2009 09:44, "Yang, Sheng"
<sheng.yang@intel.com> 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? 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? What''s a
hybrid gnttab,
> > and why does it need an explciit reserved e820 region? And so on.
> >
> > 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.
> >
> >  -- Keir
>
> I did not see the hypervisor part of these patches appear in my
> xen-devel inbox. Is this a problem on my end, or were they not sent to
> the list? If so, I''m interested in them, so it''d be great
if they could
> be sent to the list.
>
> Thanks,
>
> - Frank
It''s quite strange...

Here is the patches(attached). Send them again...

-- 
regards
Yang, Sheng








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 16/09/2009 20:11, "Frank van der Linden"
<Frank.Vanderlinden@Sun.COM>
wrote:
> I did not see the hypervisor part of these patches appear in my
> xen-devel inbox. Is this a problem on my end, or were they not sent to
> the list? If so, I''m interested in them, so it''d be great
if they could
> be sent to the list.
They were sent to the list with the subject heading "Xen: Hybrid extension
patchset for hypervisor".

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 17 September 2009 14:25:52 Keir Fraser
wrote:
> On 16/09/2009 20:11, "Frank van der Linden"
<Frank.Vanderlinden@Sun.COM>
>
> wrote:
> > I did not see the hypervisor part of these patches appear in my
> > xen-devel inbox. Is this a problem on my end, or were they not sent to
> > the list? If so, I''m interested in them, so it''d be
great if they could
> > be sent to the list.
>
> They were sent to the list with the subject heading "Xen: Hybrid
extension
> patchset for hypervisor".
>
>  -- Keir
I found I can''t find them(also the last one I sent, with attached
patches) in
the http://news.gmane.org/gmane.comp.emulators.xen.devel

Seems something bad happened in the mailserver? Try another mailbox... 

-- 
regards
Yang, Sheng









_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wednesday 16 September 2009 17:08:20 Keir Fraser
wrote:
> On 16/09/2009 09:44, "Yang, Sheng" <sheng.yang@intel.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2009-09-16 at 22:22 +0100, Jeremy Fitzhardinge
wrote:
> On 09/16/09 14:12, Ian Campbell wrote:
> >>> Based on our data, what we would want in PV 64-bit guests are,
fundamentally:
> >>> - have the kernel run in ring 0 (so that it can regain the
performance enhancements)
> >>>   
> >>>       
> >> That''s no problem.  PV kernels don''t currently
assume they''re running in
> >> any particular ring, so they''d be happy to run in ring 0
if that''s how
> >> they''re started (if there are problems, I''d
consider that a bug).  We
> >> could then check for ring 0 and enable syscall/sysenter.
> >>     
> > XENFEAT_supervisor_mode_kernel is supposed to enable this behaviour,
> > although it hasn''t been actively used for several years and
never in the
> > pvops kernel so you can bet it has bit-rotted...
> >   
> 
> That tends to have a slightly different meaning, viz "dom0 really *is*
> privileged and can do anything it feels like".  It isn''t
necessary to
> have a specific feature/mechanism for "kernel happens to be in ring
0";
> it can look at its own cs ring number.
In practise, at least for the 2.6.18-xen tree (which is the only one
where I expect it was ever completely implemented), it is only used to
set the kernel CS and DS and to gate sysenter setup (for which I think
we have a better mechanism today) but you are right that in principle it
could be more far reaching than that.
> >> We could do that with minimal API/ABI changes by:
> >>
> >>     * Providing an identity p2m table
> >>     * Changing the hypercall page to make pte writes simple memory
> >>       writes (no hypercalls); xen would still keep track of pinned
pages
> >>       and trap''n''emulate on them for
back-compatibility (but fast-path
> >>       with no validation).  We could expose the presence of HAP
via
> >>       xen_features so that guests know they can avoid marking
pagetables
> >>       RO, etc.
> >>     * Similarly, cr3 changes can be fast-pathed within the
hypercall page.
> >>     * Whatever else I''ve overlooked.
> >>     
> > Some combination of XENFEAT_writable_page_tables
> > XENFEAT_writable_descriptor_tables and XENFEAT_auto_translated_physmap
> > might be of interest for this bit.
> 
> Making use of XENFEAT_auto_translated_physmap would avoid the need for
> identity p2m/m2p tables, but I''m not sure whether it still works. 
I got
> close to completely removing all references to it at one point, but I
> think ia64 uses it?
I very much expect that it''ll need fixing/(re)implementing on both the
kernel and hypervisor side...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Campbell wrote on Thu, 17 Sep 2009 at 02:16:25:
> On Wed, 2009-09-16 at 22:22 +0100, Jeremy Fitzhardinge wrote:
>>>> We could do that with minimal API/ABI changes by:
>>>> 
>>>>     * Providing an identity p2m table
>>>>     * Changing the hypercall page to make pte writes simple
memory
>>>>       writes (no hypercalls); xen would still keep track of
pinned
>>>>       pages and trap''n''emulate on them for
back-compatibility (but
>>>>       fast- path with no validation).  We could expose the
presence
>>>>       of HAP via xen_features so that guests know they can
avoid
>>>>       marking pagetables RO, etc.
>>>>     * Similarly, cr3 changes can be fast-pathed within the
hypercall
>>>>     page. * Whatever else I''ve overlooked.
>>>> 
>>> Some combination of XENFEAT_writable_page_tables
>>> XENFEAT_writable_descriptor_tables and
XENFEAT_auto_translated_physmap
>>> might be of interest for this bit.
>>  Making use of XENFEAT_auto_translated_physmap would avoid the need for
>> identity p2m/m2p tables, but I''m not sure whether it still
works.  I
>> got close to completely removing all references to it at one point, but
>> I think ia64 uses it?
> 
> I very much expect that it''ll need fixing/(re)implementing on both
the
> kernel and hypervisor side...
To me, leveraging the native MMU code, rather than using existing API/ABI, would
simplify both the guest and hypervisor side if hardware MMU virtualization is
present. For example:
- today a 64-bit PV guest builds/switches page tables depending on the
kernel/user mode. It''s not required anymore.
- we can automatically get large page support (2MB, 1GB)

I thought pv_xxx_ps (such as pv_time, pv_cpu_ops, pv_mmu_ops, etc.) was designed
to choose the right pv_ops accordingly depending on the features available.
> 
> Ian.
Jun
___
Intel Open Source Technology Center




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/17/09 02:16, Ian Campbell wrote:
> In practise, at least for the 2.6.18-xen tree (which is the only one
> where I expect it was ever completely implemented), it is only used to
> set the kernel CS and DS and to gate sysenter setup (for which I think
> we have a better mechanism today) but you are right that in principle it
> could be more far reaching than that.
>   
Yeah.  Looks like the only other thing it allows is that the guest can
set arbitrary gdt entries.
>> Making use of XENFEAT_auto_translated_physmap would avoid the need for
>> identity p2m/m2p tables, but I''m not sure whether it still
works.  I got
>> close to completely removing all references to it at one point, but I
>> think ia64 uses it?
>>     
> I very much expect that it''ll need fixing/(re)implementing on both
the
> kernel and hypervisor side...
>   
Yeah, I think the Xen side is missing altogether on x86 now.  I don''t
think its worth recovering it unless its the ABI for making HAP
available to guests.  If IA64 is using it, then I think big parts of the
kernel are probably in OK shape (drivers, etc).

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/17/09 08:56, Nakajima, Jun wrote:
>> I very much expect that it''ll need fixing/(re)implementing on
both the
>> kernel and hypervisor side...
>>     
> To me, leveraging the native MMU code, rather than using existing API/ABI,
would simplify both the guest and hypervisor side if hardware MMU virtualization
is present. For example:
> - today a 64-bit PV guest builds/switches page tables depending on the
kernel/user mode. It''s not required anymore.
>   
The two pagetables are largely shared, so it really comes down to
maintaining an additional L4 page.  If the domain is running in a HAP
container, then then the "kernel" pagetable would have proper U/S bit
its pagetable entries (ie, Xen wouldn''t strip them off, or set global
on
user mappings) and then loading a new pagetable would just mean
reloading cr3 with the kernel pagetable.  In other words, we can still
do an efficient pagetable swap without needing to change the guest or
the ABI at all; the user pagetable would be unused and ignored, but that
isn''t a huge burden.
> - we can automatically get large page support (2MB, 1GB)
>   
Once the requirement to mark pagetable pages RO goes away, then it would
be easy to add large-page support.
> I thought pv_xxx_ps (such as pv_time, pv_cpu_ops, pv_mmu_ops, etc.) was
designed to choose the right pv_ops accordingly depending on the features
available.
>   
Sure.  It would be easy to either use new special-purpose just plain
native versions of those ops if that''s the right thing to do; but it
would be nice if a current unmodified PV guest worked within a HVM
container and got at least some benefit from doing so.  Also, pagetable
issues have repercussions beyond just the raw pagetable update functions.

Of course you can get both these features just by booting the kernel as
an hvm guest.  But if we''re talking about giving PV kernels some
benefits from hvm/hap hardware features, I think we should looking at it
from the perspective of starting with a PV kernel then adding
incremental changes.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jeremy Fitzhardinge wrote on Thu, 17 Sep 2009 at 10:34:51:
> On 09/17/09 08:56, Nakajima, Jun wrote:
>> I thought pv_xxx_ps (such as pv_time, pv_cpu_ops, pv_mmu_ops, etc.)
> was designed to choose the right pv_ops accordingly depending on the
> features available.
>> 
>  Sure.  It would be easy to either use new special-purpose just plain
> native versions of those ops if that''s the right thing to do; but
it
> would be nice if a current unmodified PV guest worked within a HVM
> container and got at least some benefit from doing so.  Also, pagetable
> issues have repercussions beyond just the raw pagetable update functions.
> 
> Of course you can get both these features just by booting the kernel as
> an hvm guest.  But if we''re talking about giving PV kernels some
> benefits from hvm/hap hardware features, I think we should looking at it
> from the perspective of starting with a PV kernel then adding
> incremental changes.
> 
Even if we start from PV kernels, I think what we should do is to implement
ability (as "incremental changes") for PV guests to stop using PV MMU
(and PV CPU) at boot time depending on the H/W features available rather than to
keep using the same ABI, because we may not need them in the near future. Then,
such PV kernels would be at par or faster/more efficient than pure HVM guests on
machines with HAP enabled because of the other PV features.

Jun
___
Intel Open Source Technology Center




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 09/18/09 17:17, Nakajima, Jun wrote:
> Even if we start from PV kernels, I think what we should do is to implement
ability (as "incremental changes") for PV guests to stop using PV MMU
(and PV CPU) at boot time depending on the H/W features available rather than to
keep using the same ABI, because we may not need them in the near future. Then,
such PV kernels would be at par or faster/more efficient than pure HVM guests on
machines with HAP enabled because of the other PV features.
>   
Sure, that''s no problem.  So long as the current ABI keeps working, we
can easily switch to something else more appropriate where possible.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel