WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initial

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Mon, 15 Mar 2010 09:45:09 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, "Yaozu \(Eddie\) Dong" <eddie.dong@xxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Sun, 14 Mar 2010 18:46:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B9AA5A9.20609@xxxxxxxx>
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: <1268362647-5317-1-git-send-email-sheng@xxxxxxxxxxxxxxx> <1268362647-5317-5-git-send-email-sheng@xxxxxxxxxxxxxxx> <4B9AA5A9.20609@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
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