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: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 12 Mar 2010 12:35:53 -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: Fri, 12 Mar 2010 12:36:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1268362647-5317-5-git-send-email-sheng@xxxxxxxxxxxxxxx>
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>
References: <1268362647-5317-1-git-send-email-sheng@xxxxxxxxxxxxxxx> <1268362647-5317-5-git-send-email-sheng@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
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.

Also, there's nothing about this which is 64-bit specific is there?

Thanks,
    J

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