ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.
Changes in v3:
- improve comments.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/arm/include/asm/xen/page.h | 82 +++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/xen/page.h
@@ -246,6 +246,7 @@ endifcore-$(CONFIG_FPE_NWFPE)+=arch/arm/nwfpe/core-$(CONFIG_FPE_FASTFPE)+=$(FASTFPE_OBJ)core-$(CONFIG_VFP)+=arch/arm/vfp/+core-$(CONFIG_XEN)+=arch/arm/xen/# If we have a machine-specific directory, then include it in the build.core-y+=arch/arm/kernel/arch/arm/mm/arch/arm/common/
@@ -0,0 +1,65 @@+/******************************************************************************+*GuestOSinterfacetoARMXen.+*+*StefanoStabellini<stefano.stabellini@eu.citrix.com>,Citrix,2012+*/++#ifndef _ASM_ARM_XEN_INTERFACE_H+#define _ASM_ARM_XEN_INTERFACE_H++#include<linux/types.h>++#define __DEFINE_GUEST_HANDLE(name, type) \+typedeftype*__guest_handle_##name++#define DEFINE_GUEST_HANDLE_STRUCT(name) \+__DEFINE_GUEST_HANDLE(name,structname)+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)+#define GUEST_HANDLE(name) __guest_handle_ ## name++#define set_xen_guest_handle(hnd, val) \+do{\+if(sizeof(hnd)==8)\+*(uint64_t*)&(hnd)=0;\+(hnd)=val;\+}while(0)++#ifndef __ASSEMBLY__+/* Guest handles for primitive C types. */+__DEFINE_GUEST_HANDLE(uchar,unsignedchar);+__DEFINE_GUEST_HANDLE(uint,unsignedint);+__DEFINE_GUEST_HANDLE(ulong,unsignedlong);+DEFINE_GUEST_HANDLE(char);+DEFINE_GUEST_HANDLE(int);+DEFINE_GUEST_HANDLE(long);+DEFINE_GUEST_HANDLE(void);+DEFINE_GUEST_HANDLE(uint64_t);+DEFINE_GUEST_HANDLE(uint32_t);++/* Maximum number of virtual CPUs in multi-processor guests. */+#define MAX_VIRT_CPUS 1++structarch_vcpu_info{};+structarch_shared_info{};++/* TODO: Move pvclock definitions some place arch independent */+structpvclock_vcpu_time_info{+u32version;+u32pad0;+u64tsc_timestamp;+u64system_time;+u32tsc_to_system_mul;+s8tsc_shift;+u8flags;+u8pad[2];+}__attribute__((__packed__));/* 32 bytes */++/* It is OK to have a 12 bytes struct with no padding because it is packed */+structpvclock_wall_clock{+u32version;+u32sec;+u32nsec;+}__attribute__((__packed__));+#endif++#endif /* _ASM_ARM_XEN_INTERFACE_H */
@@ -0,0 +1,35 @@+#include<xen/xen.h>+#include<xen/interface/xen.h>+#include<xen/interface/memory.h>+#include<xen/platform_pci.h>+#include<asm/xen/hypervisor.h>+#include<asm/xen/hypercall.h>+#include<linux/module.h>++structstart_info_xen_start_info;+structstart_info*xen_start_info=&_xen_start_info;+EXPORT_SYMBOL_GPL(xen_start_info);++enumxen_domain_typexen_domain_type=XEN_NATIVE;+EXPORT_SYMBOL_GPL(xen_domain_type);++structshared_infoxen_dummy_shared_info;+structshared_info*HYPERVISOR_shared_info=(void*)&xen_dummy_shared_info;++DEFINE_PER_CPU(structvcpu_info*,xen_vcpu);++/* TODO: to be removed */+__read_mostlyintxen_have_vector_callback;+EXPORT_SYMBOL_GPL(xen_have_vector_callback);++intxen_platform_pci_unplug=XEN_UNPLUG_ALL;+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);++intxen_remap_domain_mfn_range(structvm_area_struct*vma,+unsignedlongaddr,+unsignedlongmfn,intnr,+pgprot_tprot,unsigneddomid)+{+return-ENOSYS;+}+EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.
Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.
Changes in v3:
- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.
Changes in v2:
- replace pr_info with pr_debug.
Signed-off-by: Stefano Stabellini <redacted>
---
arch/arm/xen/enlighten.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,return-ENOSYS;}EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);++/*+*seeDocumentation/devicetree/bindings/arm/xen.txtforthe+*documentationoftheXenDeviceTreeformat.+*/+staticint__initxen_guest_init(void)+{+structxen_add_to_physmapxatp;+staticstructshared_info*shared_info_page=0;+structdevice_node*node;+intlen;+constchar*s=NULL;+constchar*version=NULL;+constchar*xen_prefix="xen,xen-";++node=of_find_compatible_node(NULL,NULL,"xen,xen");+if(!node){+pr_debug("No Xen support\n");+return0;+}+s=of_get_property(node,"compatible",&len);+if(strlen(s)+strlen(xen_prefix)+1<len&&+!strncmp(xen_prefix,s+strlen(s)+1,strlen(xen_prefix)))+version=s+strlen(s)+strlen(xen_prefix)+1;+if(version==NULL){+pr_debug("Xen version not found\n");+return0;+}+xen_domain_type=XEN_HVM_DOMAIN;++if(!shared_info_page)+shared_info_page=(structshared_info*)+get_zeroed_page(GFP_KERNEL);+if(!shared_info_page){+pr_err("not enough memory\n");+return-ENOMEM;+}+xatp.domid=DOMID_SELF;+xatp.idx=0;+xatp.space=XENMAPSPACE_shared_info;+xatp.gpfn=__pa(shared_info_page)>>PAGE_SHIFT;+if(HYPERVISOR_memory_op(XENMEM_add_to_physmap,&xatp))+BUG();++HYPERVISOR_shared_info=(structshared_info*)shared_info_page;++/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info+*page,weuseitintheeventchannelupcallandinsomepvclock+*relatedfunctions.Wedon'tneedthevcpu_infoplacement+*optimizationsbecausewedon'tuseanypv_mmuorpv_irqopon+*HVM.+*Thesharedinfocontainsexactly1CPU(thebootCPU).Theguest+*isrequiredtouseVCPUOP_register_vcpu_infotoplacevcpuinfo+*forsecondaryCPUsastheyarebroughtup.*/+per_cpu(xen_vcpu,0)=&HYPERVISOR_shared_info->vcpu_info[0];+return0;+}+core_initcall(xen_guest_init);
bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
an error.
If Linux is running as an HVM domain and is running as Dom0, use
xenstored_local_init to initialize the xenstore page and event channel.
Changes in v2:
- refactor xenbus_init.
Signed-off-by: Stefano Stabellini <redacted>
---
drivers/xen/xenbus/xenbus_comms.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 62 +++++++++++++++++++++++++-----------
drivers/xen/xenbus/xenbus_xs.c | 1 +
3 files changed, 45 insertions(+), 20 deletions(-)
@@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)returnerr;}+enumxenstore_init{+UNKNOWN,+PV,+HVM,+LOCAL,+};staticint__initxenbus_init(void){interr=0;+enumxenstore_initusage=UNKNOWN;+uint64_tv=0;if(!xen_domain())return-ENODEV;xenbus_ring_ops_init();-if(xen_hvm_domain()){-uint64_tv=0;-err=hvm_get_parameter(HVM_PARAM_STORE_EVTCHN,&v);-if(err)-gotoout_error;-xen_store_evtchn=(int)v;-err=hvm_get_parameter(HVM_PARAM_STORE_PFN,&v);-if(err)-gotoout_error;-xen_store_mfn=(unsignedlong)v;-xen_store_interface=ioremap(xen_store_mfn<<PAGE_SHIFT,PAGE_SIZE);-}else{-xen_store_evtchn=xen_start_info->store_evtchn;-xen_store_mfn=xen_start_info->store_mfn;-if(xen_store_evtchn)-xenstored_ready=1;-else{+if(xen_pv_domain())+usage=PV;+if(xen_hvm_domain())+usage=HVM;+if(xen_hvm_domain()&&xen_initial_domain())+usage=LOCAL;+if(xen_pv_domain()&&!xen_start_info->store_evtchn)+usage=LOCAL;+if(xen_pv_domain()&&xen_start_info->store_evtchn)+xenstored_ready=1;++switch(usage){+caseLOCAL:err=xenstored_local_init();if(err)gotoout_error;-}-xen_store_interface=mfn_to_virt(xen_store_mfn);+xen_store_interface=mfn_to_virt(xen_store_mfn);+break;+casePV:+xen_store_evtchn=xen_start_info->store_evtchn;+xen_store_mfn=xen_start_info->store_mfn;+xen_store_interface=mfn_to_virt(xen_store_mfn);+break;+caseHVM:+err=hvm_get_parameter(HVM_PARAM_STORE_EVTCHN,&v);+if(err)+gotoout_error;+xen_store_evtchn=(int)v;+err=hvm_get_parameter(HVM_PARAM_STORE_PFN,&v);+if(err)+gotoout_error;+xen_store_mfn=(unsignedlong)v;+xen_store_interface=+ioremap(xen_store_mfn<<PAGE_SHIFT,PAGE_SIZE);+break;+default:+pr_warn("Xenstore state unknown\n");+break;}/* Initialize the interface to xenstore. */
All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.
Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.
Changes in v3:
- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.
Signed-off-by: Stefano Stabellini <redacted>
---
arch/arm/include/asm/xen/interface.h | 8 ++++++--
arch/ia64/include/asm/xen/interface.h | 1 +
arch/x86/include/asm/xen/interface.h | 1 +
include/xen/interface/memory.h | 12 ++++++------
include/xen/interface/physdev.h | 2 +-
include/xen/interface/version.h | 2 +-
6 files changed, 16 insertions(+), 10 deletions(-)
@@ -21,13 +24,14 @@do{\if(sizeof(hnd)==8)\*(uint64_t*)&(hnd)=0;\-(hnd)=val;\+(hnd).p=val;\}while(0)#ifndef __ASSEMBLY__/* Explicitly size integers that represent pfns in the interface with*XensothatwecanhaveoneABIthatworksfor32and64bitguests.*/typedefuint64_txen_pfn_t;+typedefuint64_txen_ulong_t;/* Guest handles for primitive C types. */__DEFINE_GUEST_HANDLE(uchar,unsignedchar);__DEFINE_GUEST_HANDLE(uint,unsignedint);
@@ -34,7 +34,7 @@ struct xen_memory_reservation {GUEST_HANDLE(xen_pfn_t)extent_start;/* Number of extents, and size/alignment of each (2^extent_order pages). */-unsignedlongnr_extents;+xen_ulong_tnr_extents;unsignedintextent_order;/*
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);*/#define XENMEM_machphys_mapping 12structxen_machphys_mapping{-unsignedlongv_start,v_end;/* Start and end virtual addresses. */-unsignedlongmax_mfn;/* Maximum MFN that can be looked up. */+xen_ulong_tv_start,v_end;/* Start and end virtual addresses. */+xen_ulong_tmax_mfn;/* Maximum MFN that can be looked up. */};DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
@@ -169,7 +169,7 @@ struct xen_add_to_physmap {unsignedintspace;/* Index into source mapping space. */-unsignedlongidx;+xen_ulong_tidx;/* GPFN where the source mapping page should appear. */xen_pfn_tgpfn;
@@ -186,7 +186,7 @@ struct xen_translate_gpfn_list {domid_tdomid;/* Length of list. */-unsignedlongnr_gpfns;+xen_ulong_tnr_gpfns;/* List of GPFNs to translate. */GUEST_HANDLE(ulong)gpfn_list;
All the original Xen headers have xen_pfn_t as mfn and pfn type, however
when they have been imported in Linux, xen_pfn_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_pfn_t and let each architecture define xen_pfn_t as they
see fit.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/arm/include/asm/xen/interface.h | 4 ++++
arch/ia64/include/asm/xen/interface.h | 5 ++++-
arch/x86/include/asm/xen/interface.h | 5 +++++
include/xen/interface/grant_table.h | 4 ++--
include/xen/interface/memory.h | 6 +++---
include/xen/interface/platform.h | 4 ++--
include/xen/interface/xen.h | 6 +++---
include/xen/privcmd.h | 2 --
8 files changed, 23 insertions(+), 13 deletions(-)
@@ -25,6 +25,9 @@}while(0)#ifndef __ASSEMBLY__+/* Explicitly size integers that represent pfns in the interface with+*XensothatwecanhaveoneABIthatworksfor32and64bitguests.*/+typedefuint64_txen_pfn_t;/* Guest handles for primitive C types. */__DEFINE_GUEST_HANDLE(uchar,unsignedchar);__DEFINE_GUEST_HANDLE(uint,unsignedint);
@@ -35,6 +38,7 @@ DEFINE_GUEST_HANDLE(long);DEFINE_GUEST_HANDLE(void);DEFINE_GUEST_HANDLE(uint64_t);DEFINE_GUEST_HANDLE(uint32_t);+DEFINE_GUEST_HANDLE(xen_pfn_t);/* Maximum number of virtual CPUs in multi-processor guests. */#define MAX_VIRT_CPUS 1
@@ -67,6 +67,10 @@#define set_xen_guest_handle(hnd, val) do { (hnd).p = val; } while (0)#ifndef __ASSEMBLY__+/* Explicitly size integers that represent pfns in the public interface+*withXensothatwecouldhaveoneABIthatworksfor32and64bit+*guests.*/+typedefunsignedlongxen_pfn_t;/* Guest handles for primitive C types. */__DEFINE_GUEST_HANDLE(uchar,unsignedchar);__DEFINE_GUEST_HANDLE(uint,unsignedint);
@@ -47,6 +47,10 @@#endif#ifndef __ASSEMBLY__+/* Explicitly size integers that represent pfns in the public interface+*withXensothatonARMwecanhaveoneABIthatworksfor32and64+*bitguests.*/+typedefunsignedlongxen_pfn_t;/* Guest handles for primitive C types. */__DEFINE_GUEST_HANDLE(uchar,unsignedchar);__DEFINE_GUEST_HANDLE(uint,unsignedint);
@@ -31,7 +31,7 @@ struct xen_memory_reservation {*OUT:GMFNbasesofextentsthatwereallocated*(NB.Thiscommandalsoupdatesthemach_to_phystranslationtable)*/-GUEST_HANDLE(ulong)extent_start;+GUEST_HANDLE(xen_pfn_t)extent_start;/* Number of extents, and size/alignment of each (2^extent_order pages). */unsignedlongnr_extents;
@@ -429,11 +429,11 @@ struct start_info {unsignedlongnr_pages;/* Total pages allocated to this domain. */unsignedlongshared_info;/* MACHINE address of shared info struct. */uint32_tflags;/* SIF_xxx flags. */-unsignedlongstore_mfn;/* MACHINE page number of shared page. */+xen_pfn_tstore_mfn;/* MACHINE page number of shared page. */uint32_tstore_evtchn;/* Event channel for store communication. */union{struct{-unsignedlongmfn;/* MACHINE page number of console page. */+xen_pfn_tmfn;/* MACHINE page number of console page. */uint32_tevtchn;/* Event channel for console page. */}domU;struct{
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:++- compatible:+ compatible = "xen,xen", "xen,xen-<version>";+ where <version> is the version of the Xen ABI of the platform.++- reg: specifies the base physical address and size of a region in+ memory where the grant table should be mapped to, using an+ HYPERVISOR_memory_op hypercall. ++- interrupts: the interrupt used by Xen to inject event notifications.+++Example:++hypervisor {+ compatible = "xen,xen", "xen,xen-4.3";+ reg = <0xb0000000 0x20000>;+ interrupts = <1 15 0xf08>;+};
Use r12 to pass the hypercall number to the hypervisor.
We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.
Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".
Use the ISS to pass an hypervisor specific tag.
Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.
Signed-off-by: Stefano Stabellini <redacted>
---
arch/arm/include/asm/xen/hypercall.h | 50 ++++++++++++++++
arch/arm/xen/Makefile | 2 +-
arch/arm/xen/hypercall.S | 106 ++++++++++++++++++++++++++++++++++
3 files changed, 157 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/include/asm/xen/hypercall.h
create mode 100644 arch/arm/xen/hypercall.S
sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.
We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/arm/include/asm/sync_bitops.h | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/sync_bitops.h
@@ -269,6 +269,8 @@ typedef struct xen_callback xen_callback_t;#endif /* !__ASSEMBLY__ */+#include<asm/pvclock-abi.h>+/* Size of the shared_info area (this is not related to page size). */#define XSI_SHIFT 14#define XSI_SIZE (1 << XSI_SHIFT)
Update struct xen_add_to_physmap to be in sync with Xen's version of the
structure.
The size field was introduced by:
changeset: 24164:707d27fe03e7
user: Jean Guyader [off-list ref]
date: Fri Nov 18 13:42:08 2011 +0000
summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range
According to the comment:
"This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions."
Note: this patch should be already in Konrad's tree, it is here just for
convenience.
Changes in v2:
- remove erroneous comment in the commit message.
Signed-off-by: Stefano Stabellini <redacted>
---
include/xen/interface/memory.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
@@ -163,6 +163,9 @@ struct xen_add_to_physmap {/* Which domain to change the mapping for. */domid_tdomid;+/* Number of pages to go through for gmfn_range */+uint16_tsize;+/* Source mapping space. */#define XENMAPSPACE_shared_info 0 /* shared info page */#define XENMAPSPACE_grant_table 1 /* grant table page */
Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
drivers/xen/events.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
@@ -839,6 +839,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)structirq_info*info=info_for_irq(irq);WARN_ON(info==NULL||info->type!=IRQT_EVTCHN);}+irq_clear_status_flags(irq,IRQ_NOREQUEST|IRQ_NOAUTOEN);out:mutex_unlock(&irq_mapping_update_lock);
Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).
Changes in v2:
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.
Signed-off-by: Stefano Stabellini <redacted>
---
arch/arm/xen/enlighten.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)constchar*s=NULL;constchar*version=NULL;constchar*xen_prefix="xen,xen-";+structresourceres;node=of_find_compatible_node(NULL,NULL,"xen,xen");if(!node){
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)pr_debug("Xen version not found\n");return0;}+if(of_address_to_resource(node,GRANT_TABLE_PHYSADDR,&res))+return0;+xen_hvm_resume_frames=res.start>>PAGE_SHIFT;xen_domain_type=XEN_HVM_DOMAIN;xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)*isrequiredtouseVCPUOP_register_vcpu_infotoplacevcpuinfo*forsecondaryCPUsastheyarebroughtup.*/per_cpu(xen_vcpu,0)=&HYPERVISOR_shared_info->vcpu_info[0];++gnttab_init();+if(!xen_initial_domain())+xenbus_probe(NULL);+return0;}core_initcall(xen_guest_init);
Only until we get the balloon driver to work.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/arm/xen/enlighten.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)return0;}postcore_initcall(xen_init_events);++/* XXX: only until balloon is properly working */+intalloc_xenballooned_pages(intnr_pages,structpage**pages,boolhighmem)+{+*pages=alloc_pages(highmem?GFP_HIGHUSER:GFP_KERNEL,+get_order(nr_pages));+if(*pages==NULL)+return-ENOMEM;+return0;+}+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);++voidfree_xenballooned_pages(intnr_pages,structpage**pages)+{+kfree(*pages);+*pages=NULL;+}+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
This patch removes the "return -ENOSYS" for auto_translated_physmap
guests from privcmd_mmap, thus it allows ARM guests to issue privcmd
mmap calls. However privcmd mmap calls are still going to fail for HVM
and hybrid guests on x86 because the xen_remap_domain_mfn_range
implementation is currently PV only.
Changes in v2:
- better commit message;
- return -EINVAL from xen_remap_domain_mfn_range if
auto_translated_physmap.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/x86/xen/mmu.c | 3 +++
drivers/xen/privcmd.c | 4 ----
2 files changed, 3 insertions(+), 4 deletions(-)
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);/* Determine whether to ignore this IRQ if it is passed to a guest. */intxen_test_irq_shared(intirq);+/* initialize Xen IRQ subsystem */+voidxen_init_IRQ(void);#endif /* _XEN_EVENTS_H */
Use Xen features to figure out if we are privileged.
XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/arm/xen/enlighten.c | 7 +++++++
include/xen/interface/features.h | 3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
@@ -50,6 +50,9 @@/* x86: pirq can be used by HVM guests */#define XENFEAT_hvm_pirqs 10+/* operation as Dom0 is supported */+#define XENFEAT_dom0 11+#define XENFEAT_NR_SUBMAPS 1#endif /* __XEN_PUBLIC_FEATURES_H__ */
Changes in v2:
- mark Xen guest support on ARM as EXPERIMENTAL.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
arch/arm/Kconfig | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
@@ -1855,6 +1855,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF+selectXEN_DOM0+help+SayYifyouwanttorunLinuxinaVirtualMachineonXenonARM.+endmenumenu"Boot options"
From: Ian Campbell <redacted>
Do not apply!
This is a simple, hacky implementation of xen_remap_domain_mfn_range,
using XENMAPSPACE_gmfn_foreign.
It should use same interface as hybrid x86.
Changes in v2:
- retain binary compatibility in xen_add_to_physmap: use a union.
Changes in v3:
- do not use an anonymous union.
Signed-off-by: Ian Campbell <redacted>
Signed-off-by: Stefano Stabellini <redacted>
---
arch/arm/xen/enlighten.c | 79 +++++++++++++++++++++++++++++++++++++++-
drivers/xen/privcmd.c | 16 +++++----
drivers/xen/xenfs/super.c | 7 ++++
include/xen/interface/memory.h | 15 ++++++--
4 files changed, 105 insertions(+), 12 deletions(-)
@@ -163,12 +163,19 @@ struct xen_add_to_physmap {/* Which domain to change the mapping for. */domid_tdomid;-/* Number of pages to go through for gmfn_range */-uint16_tsize;+union{+/* Number of pages to go through for gmfn_range */+uint16_tsize;+/* IFF gmfn_foreign */+domid_tforeign_domid;+}u;/* Source mapping space. */-#define XENMAPSPACE_shared_info 0 /* shared info page */-#define XENMAPSPACE_grant_table 1 /* grant table page */+#define XENMAPSPACE_shared_info 0 /* shared info page */+#define XENMAPSPACE_grant_table 1 /* grant table page */+#define XENMAPSPACE_gmfn 2 /* GMFN */+#define XENMAPSPACE_gmfn_range 3 /* GMFN range */+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */unsignedintspace;/* Index into source mapping space. */
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:++- compatible:+ compatible = "xen,xen", "xen,xen-<version>";+ where <version> is the version of the Xen ABI of the platform.++- reg: specifies the base physical address and size of a region in+ memory where the grant table should be mapped to, using an+ HYPERVISOR_memory_op hypercall. ++- interrupts: the interrupt used by Xen to inject event notifications.
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:++- compatible:+ compatible = "xen,xen", "xen,xen-<version>";+ where <version> is the version of the Xen ABI of the platform.++- reg: specifies the base physical address and size of a region in+ memory where the grant table should be mapped to, using an+ HYPERVISOR_memory_op hypercall. ++- interrupts: the interrupt used by Xen to inject event notifications.
Thanks for the link, I wasn't aware of ePAPR.
The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?
Personally I would rather avoid full compatibility with ePAPR.
Thanks for the link, I wasn't aware of ePAPR.
The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?
Personally I would rather avoid full compatibility with ePAPR.
In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:
- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).
- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.
- guest-id
we usually make a point in trying not to tell the guest its own domid
because if the VM gets migrated to a different host it acquires a new
domid, therefore it should not rely on it.
- guest-name
we could pass the guest name here, but I don't see how it could be
of any use.
On the other hand, thinking more about what Xen needs in the device
tree, I think we could improve the current spec by clarifying the
meaning of the memory region and interrupt properties we currently
require. I thought about moving them to two separate children node with
an explicit name:
---
* Xen hypervisor device tree bindings
Xen ARM virtual platforms shall have the following properties and
children nodes:
- compatible property:
compatible = "xen,xen", "xen,xen-<version>";
where <version> is the version of the Xen ABI of the platform.
- grant_table child with the following properties:
- name:
name = "grant_table";
- reg: specifies the base physical address and size of a region in
memory where the grant table should be mapped to, using an
HYPERVISOR_memory_op hypercall.
- events child with the following properties:
- name:
name = "events";
- interrupts: the interrupt used by Xen to inject event notifications.
Example:
hypervisor {
compatible = "xen,xen", "xen,xen-4.2";
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <3>;
ranges = <0xb0000000 0xb0000000 0x20000>;
grant_table {
name = "grant_table";
reg = <0xb0000000 0x20000>;
};
events {
name = "events";
interrupts = <1 15 0xf08>;
};
};
Thanks for the link, I wasn't aware of ePAPR.
The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?
Personally I would rather avoid full compatibility with ePAPR.
In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:
- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).
compatible properties are often changed. If we do deviate on the rest of
the binding, then it needs to be different.
Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
doesn't even appear in the kernel.
We also perhaps have to consider the possibility of Xen on PowerPC. Then
alignment is more important.
- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.
It's really about the parameters passed with the HVC. The ePAPR may be a
good model for defining this. Just grepping "hypervisor" under
arch/powerpc, it's pretty clear hypervisor support happened first and
the ePAPR came second. Hopefully we can avoid that for ARM.
- guest-id
we usually make a point in trying not to tell the guest its own domid
because if the VM gets migrated to a different host it acquires a new
domid, therefore it should not rely on it.
- guest-name
we could pass the guest name here, but I don't see how it could be
of any use.
I have no issue with these being optional.
On the other hand, thinking more about what Xen needs in the device
tree, I think we could improve the current spec by clarifying the
meaning of the memory region and interrupt properties we currently
require. I thought about moving them to two separate children node with
an explicit name:
---
* Xen hypervisor device tree bindings
I really think we need to define ARM hypervisor device tree bindings
first, then Xen specific bindings as an addition to that. I worry that
the KVM folks aren't paying attention and then want something different
later on.
Xen ARM virtual platforms shall have the following properties and
children nodes:
- compatible property:
compatible = "xen,xen", "xen,xen-<version>";
"xen,xen" should be last as it is less specific.
where <version> is the version of the Xen ABI of the platform.
- grant_table child with the following properties:
- name:
name = "grant_table";
What's a grant table?
- reg: specifies the base physical address and size of a region in
memory where the grant table should be mapped to, using an
HYPERVISOR_memory_op hypercall.
- events child with the following properties:
- name:
name = "events";
- interrupts: the interrupt used by Xen to inject event notifications.
Why a child node? Just an interrupts property alone should be fine. If
you have cases with different number of interrupts, the compatible
property can distinguish that.
Rob
Thanks for the link, I wasn't aware of ePAPR.
The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?
Personally I would rather avoid full compatibility with ePAPR.
In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:
- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).
- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.
Some thoughts on this:
We decided that embedding machine instructions into the DT is a fairly
awful idea when discussing how to describe low-level debug UARTs in the
DT. I don't think it's a lot better in this case (never mind issues
like ARM versus Thumb, endianness etc.)
If we are going to attempt to describe the call interface, we should
do it symbolically, allowing the hypervisor interface code in the kernel
to choose (or, if necessary, generate) the right call wrappers.
We will have this issue for descrbing power firmware interfaces for
example: we already know that this functionality might require an SMC
or HVC instruction to call it, depending on the platform.
A hypervisor with only one call ABI could leave this to be implicit,
providing there is a version number property of similar to allow future
changes to be accommodated.
Cheers
---Dave
Thanks for the link, I wasn't aware of ePAPR.
The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?
Personally I would rather avoid full compatibility with ePAPR.
In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:
- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).
compatible properties are often changed. If we do deviate on the rest of
the binding, then it needs to be different.
Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
doesn't even appear in the kernel.
We also perhaps have to consider the possibility of Xen on PowerPC. Then
alignment is more important.
quoted
- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.
It's really about the parameters passed with the HVC. The ePAPR may be a
good model for defining this. Just grepping "hypervisor" under
arch/powerpc, it's pretty clear hypervisor support happened first and
the ePAPR came second. Hopefully we can avoid that for ARM.
Do you think it's feasible to standardise on some interoperable ABI for
kvm and Xen? This sounds pretty optimistic, but I'm not aware of all
the technicalities, or what possible third-party hypervisors are out
there.
If we could do it, it would be good. But I have my doubts about the
feasibility and the benefits. If different hypervisors are significantly
imcompatible, then having a common low-level ABI doesn't help all that
much.
Cheers
---Dave
On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
quoted
On Wed, 12 Sep 2012, Stefano Stabellini wrote:
- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.
Some thoughts on this:
We decided that embedding machine instructions into the DT is a fairly
awful idea when discussing how to describe low-level debug UARTs in the
DT. I don't think it's a lot better in this case (never mind issues
like ARM versus Thumb, endianness etc.)
If we are going to attempt to describe the call interface, we should
do it symbolically, allowing the hypervisor interface code in the kernel
to choose (or, if necessary, generate) the right call wrappers.
We will have this issue for descrbing power firmware interfaces for
example: we already know that this functionality might require an SMC
or HVC instruction to call it, depending on the platform.
A hypervisor with only one call ABI could leave this to be implicit,
providing there is a version number property of similar to allow future
changes to be accommodated.
I completely agree with Dave.
I have no problems adding a symbolic property to say "we are using hvc
with parameters on registers". I just want to avoid having actual
machine instructions (and potentially dealing with executing them) into
the DT.
Maybe we could have a "calling-convention" property that can be "xen"
or something else. When a new hypervisor vendor comes along it can
change the value of "calling-convention" to "foo".
Do you think it's feasible to standardise on some interoperable ABI for
kvm and Xen? This sounds pretty optimistic, but I'm not aware of all
the technicalities, or what possible third-party hypervisors are out
there.
If we could do it, it would be good. But I have my doubts about the
feasibility and the benefits. If different hypervisors are significantly
imcompatible, then having a common low-level ABI doesn't help all that
much.
It is not really possible because each hypervisor offers a different set
of hypercalls and has a different calling convention, so there is very
little we can do to unify them.
For example many of the current Xen hypercalls are to deal with the grant
table and event channels, that are Xen specific concepts completely
missing in KVM.
Thanks for the link, I wasn't aware of ePAPR.
The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?
Personally I would rather avoid full compatibility with ePAPR.
In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:
- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).
compatible properties are often changed. If we do deviate on the rest of
the binding, then it needs to be different.
Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
doesn't even appear in the kernel.
We also perhaps have to consider the possibility of Xen on PowerPC. Then
alignment is more important.
OK. In that case I think that we can just use "xen,xen-4.2".
quoted
- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.
It's really about the parameters passed with the HVC. The ePAPR may be a
good model for defining this. Just grepping "hypervisor" under
arch/powerpc, it's pretty clear hypervisor support happened first and
the ePAPR came second. Hopefully we can avoid that for ARM.
Right. As I wrote in the other email, we could have a new property to
select the calling convention (and therefore the hypercall wrappers) to
be used with the hypervisor.
quoted
- guest-id
we usually make a point in trying not to tell the guest its own domid
because if the VM gets migrated to a different host it acquires a new
domid, therefore it should not rely on it.
- guest-name
we could pass the guest name here, but I don't see how it could be
of any use.
I have no issue with these being optional.
OK, good.
quoted
On the other hand, thinking more about what Xen needs in the device
tree, I think we could improve the current spec by clarifying the
meaning of the memory region and interrupt properties we currently
require. I thought about moving them to two separate children node with
an explicit name:
---
* Xen hypervisor device tree bindings
I really think we need to define ARM hypervisor device tree bindings
first, then Xen specific bindings as an addition to that. I worry that
the KVM folks aren't paying attention and then want something different
later on.
The problem is that there isn't much in common between Xen and KVM at
least from the DT point of view. I am not sure what would go into this
common hypervisor node.
The three key pieces of information that we are currently passing in the
DT (xen-4.2, a memory region, a PPI) are Xen specific.
If one day KVM (or another hypervisor vendor) decides to support the Xen
interface, can't they just have the Xen specific binding with a slightly
different compatible node?
For example:
compatible = "linux,kvm", "xen,xen-4.2"
wouldn't that mean "I am KVM but I can support the Xen interface"?
quoted
Xen ARM virtual platforms shall have the following properties and
children nodes:
- compatible property:
compatible = "xen,xen", "xen,xen-<version>";
"xen,xen" should be last as it is less specific.
Ah OK, thanks.
quoted
where <version> is the version of the Xen ABI of the platform.
- grant_table child with the following properties:
- name:
name = "grant_table";
What's a grant table?
A Xen specific mechanism to share pages between guests.
quoted
- reg: specifies the base physical address and size of a region in
memory where the grant table should be mapped to, using an
HYPERVISOR_memory_op hypercall.
- events child with the following properties:
- name:
name = "events";
- interrupts: the interrupt used by Xen to inject event notifications.
Why a child node? Just an interrupts property alone should be fine. If
you have cases with different number of interrupts, the compatible
property can distinguish that.
I see, that's a good point. In that case maybe it doesn't make sense to
move the memory region and the interrupt into two different children
nodes after all. I should probably leave the spec as it was.
Russell,
sorry for not CC'ing you on the entire patch series in the past, I'll do
it in the next iteration of the series (that TBH is nearly identical to
this one apart from being 3.6-rc5 based).
Are you happy with it? Given that the changes are entirely contained
within arch/arm/xen and arch/arm/include/asm/xen (apart from patch #21
that is a generic ARM fix), should this patch series go through you or
Arnd?
Thanks,
Stefano
On Thu, 16 Aug 2012, Stefano Stabellini wrote:
Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions. It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.
It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
The patch marked with [HACK] shouldn't be applied and is part of the
series only because it is needed to create domUs.
I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.
Comments are very welcome!
Changes in v3:
- move patches that have been picked up by Konrad at the end of the
series;
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.
Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
need any early call to xen_guest_init, we can rely on core_initcall
alone;
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
functions;
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
auto_translated_physmap;
- retain binary compatibility in xen_add_to_physmap: use a union to
introduce foreign_domid.
Ian Campbell (1):
[HACK] xen/arm: implement xen_remap_domain_mfn_range
Stefano Stabellini (24):
arm: initial Xen support
xen/arm: hypercalls
xen/arm: page.h definitions
xen/arm: sync_bitops
xen/arm: empty implementation of grant_table arch specific functions
docs: Xen ARM DT bindings
xen/arm: Xen detection and shared_info page mapping
xen/arm: Introduce xen_pfn_t for pfn and mfn types
xen/arm: Introduce xen_ulong_t for unsigned long
xen/arm: compile and run xenbus
xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
xen/arm: introduce CONFIG_XEN on ARM
xen/arm: get privilege status
xen/arm: initialize grant_table on ARM
xen/arm: receive Xen events on ARM
xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
xen: allow privcmd for HVM guests
xen/arm: compile blkfront and blkback
xen/arm: compile netback
arm/v2m: initialize arch_timers even if v2m_timer is not present
xen/arm: use the __HVC macro
xen: missing includes
xen: update xen_add_to_physmap interface
Documentation/devicetree/bindings/arm/xen.txt | 22 +++
arch/arm/Kconfig | 10 +
arch/arm/Makefile | 1 +
arch/arm/include/asm/hypervisor.h | 6 +
arch/arm/include/asm/sync_bitops.h | 27 +++
arch/arm/include/asm/xen/events.h | 18 ++
arch/arm/include/asm/xen/hypercall.h | 69 +++++++
arch/arm/include/asm/xen/hypervisor.h | 19 ++
arch/arm/include/asm/xen/interface.h | 73 ++++++++
arch/arm/include/asm/xen/page.h | 82 ++++++++
arch/arm/mach-vexpress/v2m.c | 11 +-
arch/arm/xen/Makefile | 1 +
arch/arm/xen/enlighten.c | 245 +++++++++++++++++++++++++
arch/arm/xen/grant-table.c | 53 ++++++
arch/arm/xen/hypercall.S | 102 ++++++++++
arch/ia64/include/asm/xen/interface.h | 8 +-
arch/x86/include/asm/xen/interface.h | 8 +
arch/x86/xen/enlighten.c | 1 +
arch/x86/xen/irq.c | 1 +
arch/x86/xen/mmu.c | 3 +
arch/x86/xen/xen-ops.h | 1 -
drivers/block/xen-blkback/blkback.c | 1 +
drivers/net/xen-netback/netback.c | 1 +
drivers/net/xen-netfront.c | 1 +
drivers/tty/hvc/hvc_xen.c | 2 +
drivers/xen/Makefile | 11 +-
drivers/xen/events.c | 18 ++-
drivers/xen/grant-table.c | 1 +
drivers/xen/privcmd.c | 20 +-
drivers/xen/xenbus/xenbus_comms.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 62 +++++--
drivers/xen/xenbus/xenbus_probe_frontend.c | 1 +
drivers/xen/xenbus/xenbus_xs.c | 1 +
drivers/xen/xenfs/super.c | 7 +
include/xen/events.h | 2 +
include/xen/interface/features.h | 3 +
include/xen/interface/grant_table.h | 4 +-
include/xen/interface/io/protocols.h | 3 +
include/xen/interface/memory.h | 32 ++-
include/xen/interface/physdev.h | 2 +-
include/xen/interface/platform.h | 4 +-
include/xen/interface/version.h | 2 +-
include/xen/interface/xen.h | 7 +-
include/xen/privcmd.h | 3 +-
include/xen/xen.h | 2 +-
45 files changed, 885 insertions(+), 68 deletions(-)
A branch based on 3.5-rc7 is available here (the __HVC patch is missing
from this branch because it depends on "ARM: opcodes: Facilitate custom
opcode injection" http://marc.info/?l=linux-arm-kernel&m=134442896128124):
git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.5-rc7-arm-3
Cheers,
Stefano