On Saturday 13 March 2010 04:35:53 Jeremy Fitzhardinge wrote:
> On 03/11/2010 06:57 PM, Sheng Yang wrote:
> > The PV extended HVM(once known as Hybrid) is started from real mode like
> > HVM guest, but also with a component based PV feature selection(e.g. PV
> > halt, PV timer, event channel, then PV drivers). So guest can takes the
> > advantages of both H/W virtualization and Para-Virtualization.
> >
> > This patch introduced the PV extension of HVM guest initialization.
> >
> > Guest would detect the capability using CPUID 0x40000002.edx, then call
> > HVMOP_enable_pv hypercall to enable pv support in hypervisor.
> >
> > Signed-off-by: Sheng Yang<sheng@xxxxxxxxxxxxxxx>
> > Signed-off-by: Yaozu (Eddie) Dong<eddie.dong@xxxxxxxxx>
> > ---
> > arch/x86/include/asm/xen/cpuid.h | 5 +
> > arch/x86/include/asm/xen/hypervisor.h | 12 +++
> > arch/x86/xen/Kconfig | 4 +
> > arch/x86/xen/Makefile | 1 +
> > arch/x86/xen/hvmpv.c | 135
> > +++++++++++++++++++++++++++++++++ include/xen/interface/hvm/hvm_op.h |
> > 8 ++
> > 6 files changed, 165 insertions(+), 0 deletions(-)
> > create mode 100644 arch/x86/xen/hvmpv.c
> >
> > diff --git a/arch/x86/include/asm/xen/cpuid.h
> > b/arch/x86/include/asm/xen/cpuid.h index 8787f03..b3a0b3a 100644
> > --- a/arch/x86/include/asm/xen/cpuid.h
> > +++ b/arch/x86/include/asm/xen/cpuid.h
> > @@ -65,4 +65,9 @@
> > #define _XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD 0
> > #define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD (1u<<0)
> >
> > +#define _XEN_CPUID_FEAT2_HVM_PV 0
> > +#define XEN_CPUID_FEAT2_HVM_PV (1u<<0)
> > +#define _XEN_CPUID_FEAT2_HVM_PV_CLOCK 1
> > +#define XEN_CPUID_FEAT2_HVM_PV_CLOCK (1u<<1)
> > +
> > #endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
> > diff --git a/arch/x86/include/asm/xen/hypervisor.h
> > b/arch/x86/include/asm/xen/hypervisor.h index d5b7e90..7569f64 100644
> > --- a/arch/x86/include/asm/xen/hypervisor.h
> > +++ b/arch/x86/include/asm/xen/hypervisor.h
> > @@ -55,6 +55,18 @@ extern enum xen_domain_type xen_domain_type;
> > #define xen_hvm_domain() (xen_domain()&& \
> > xen_domain_type == XEN_HVM_DOMAIN)
> >
> > +#ifdef CONFIG_XEN_HVM_PV
> > +
> > +#define XEN_HVM_PV_CLOCK_ENABLED (1u<< 0)
>
> Why is this flag needed? As far as I understand it, there's no real
> underlying hypervisor change needed to make HVM access to pv clock
> possible; its just a field in the shared_info's vcpu struct after all.
> Even if you enable this feature unconditionally, the user can still
> control whether the Xen clocksource is used with the "clocksource="
> kernel command-line parameter.
But we should make sure Xen have ability to support such kind of operation.
The CPUID would show if Xen have such ability, and if it does, the feature
would be enabled unconditionally. Guest kernel always enable all features it
can do unconditionally, but Xen should offer the support for them.
> Also, there's nothing about this which is 64-bit specific is there?
64 bit things are mostly evtchn/interrupt related. I think no such limit here.
But I think it's better to do it step by step, so leave it after evtchn
solution settled.
--
regards
Yang, Sheng
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home