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
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
@@ -251,6 +251,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);
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <redacted>
CC: devicetree-discuss at lists.ozlabs.org
CC: David Vrabel <redacted>
CC: Rob Herring <redacted>
CC: Dave Martin <redacted>
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:++- compatible:+ compatible = "xen,xen-<version>", "xen,xen";+ 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-4.3", "xen,xen";+ reg = <0 0xb0000000 0 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
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 v4:
- do not xs_reset_watches on dom0.
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 | 3 +-
3 files changed, 46 insertions(+), 21 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_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;
@@ -430,11 +430,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{
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;
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 v4:
- simpler parsing of Xen version in the compatible DT node.
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(xen_prefix)+3<len&&+!strncmp(xen_prefix,s,strlen(xen_prefix)))+version=s+strlen(xen_prefix);+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);
Changes in v4:
- compile pcpu only on x86;
- use "+=" instead of ":=" for dom0- targets.
Changes in v2:
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
---
drivers/xen/Makefile | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
@@ -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)
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);
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(-)
@@ -836,6 +836,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);
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 */
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__ */
@@ -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 */
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(-)
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(-)
@@ -1897,6 +1897,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"
Fair point. The alias is going to disappear anyway (I'm working on a VE
platform rework right now), but in case I won't get it on time for 3.7,
I'll make sure this one is merged instead.
Cheers!
Pawe?
Fair point. The alias is going to disappear anyway (I'm working on a VE
platform rework right now), but in case I won't get it on time for 3.7,
I'll make sure this one is merged instead.
Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?
Fair point. The alias is going to disappear anyway (I'm working on a VE
platform rework right now), but in case I won't get it on time for 3.7,
I'll make sure this one is merged instead.
Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?
Em, I think so - it would conflict with my changes if they go in. Either
way you'll have the problem sorted in 3.7.
Pawe?
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:08:42
On Fri, Sep 14, 2012 at 12:13:04PM +0100, Stefano Stabellini wrote:
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>
Reviewed-by: Konrad Rzeszutek Wilk <redacted>
.. since this is all in non-x86 and non-Xen generic parts so cannot
provide you with an Ack :-)
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:13:12
On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
quoted hunk
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <redacted>
CC: devicetree-discuss at lists.ozlabs.org
CC: David Vrabel <redacted>
CC: Rob Herring <redacted>
CC: Dave Martin <redacted>
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:++- compatible:+ compatible = "xen,xen-<version>", "xen,xen";+ 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.
Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?
So two grant tables?
Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:14:16
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
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.
Let me stick it in my tree and see how it works overnight with HVM and PV guests.
quoted hunk
Changes in v4:
- do not xs_reset_watches on dom0.
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 | 3 +-
3 files changed, 46 insertions(+), 21 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. */
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:16:01
On Fri, Sep 14, 2012 at 12:13:11PM +0100, Stefano Stabellini wrote:
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>
Acked-by: Konrad Rzeszutek Wilk <redacted>
for the generic parts; all other:
Reviewed-by: Konrad Rzeszutek Wilk <redacted>
@@ -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;
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:19:10
On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
quoted hunk
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 v4:
- simpler parsing of Xen version in the compatible DT node.
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(xen_prefix)+3<len&&+!strncmp(xen_prefix,s,strlen(xen_prefix)))
If we have version '4.3.1' won't this trip us over?
Or if we only have 'major' and 'minor', then won't '4.11' trip us
over too?
+ version = s + strlen(xen_prefix);
+ if (version == NULL) {
+ pr_debug("Xen version not found\n");
+ return 0;
+ }
+ xen_domain_type = XEN_HVM_DOMAIN;
+
+ if (!shared_info_page)
+ shared_info_page = (struct shared_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 = (struct shared_info *)shared_info_page;
+
+ /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+ * page, we use it in the event channel upcall and in some pvclock
+ * related functions. We don't need the vcpu_info placement
+ * optimizations because we don't use any pv_mmu or pv_irq op on
+ * HVM.
+ * The shared info contains exactly 1 CPU (the boot CPU). The guest
+ * is required to use VCPUOP_register_vcpu_info to place vcpu info
+ * for secondary CPUs as they are brought up. */
+ per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+ return 0;
+}
+core_initcall(xen_guest_init);
--
1.7.2.5
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:21:33
On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
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).
So we don't really care about the grant's size then? The DT xen.txt
talks about it..
@@ -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);
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:23:52
On Fri, Sep 14, 2012 at 12:13:21PM +0100, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
So this should go through Jen's tree or at least get his Ack.
But doing all of these patches seperatly is painfull - and remembering
where they go is a bit of logistical nightmare.
Jen, are you OK with this patch?
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:25:10
On Fri, Sep 14, 2012 at 12:13:25PM +0100, Stefano Stabellini wrote:
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>
Acked-by: Konrad Rzeszutek Wilk <redacted>
.. and I already have this queued for 3.7.
@@ -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 */
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:25:58
On Fri, Sep 14, 2012 at 12:13:17PM +0100, Stefano Stabellini wrote:
Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").
Signed-off-by: Stefano Stabellini <redacted>
@@ -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 */
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-14 13:32:17
On Fri, Sep 14, 2012 at 12:12:59PM +0100, 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] has been dropped from this series, however
you can find it here:
http://marc.info/?l=linux-kernel&m=134513277823527&w=2.
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!
I already put in these
1) xen/events: fix unmask_evtchn for PV on HVM guests
2) xen: missing includes
3) xen: update xen_add_to_physmap interface
4) xen: Introduce xen_pfn_t for pfn and mfn types
5) xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
6) xen: allow privcmd for HVM guests
in my tree as they also impact/help the PVH domains which works for
x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
and also in #linux-next.
If it would make reviewing easier, I would recommend you rebase
your tree on top of the stable/for-linus-3.7 and just post them
as it would make the number of patches smaller.
Or alternatively, if the ARM maintainer wishes - just give you
the OK and we can figure out how/who is going to do the git-fu.
Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not
present" touches generic ARM code and still needs to be acked/reviewed.
Arnd, Russell, what do you think about this series? If you are OK with
it, to whom should I submit it?
Changes in v4:
- rebase on 3.6-rc5;
- devicetree: "xen,xen" should be last as it is less specific;
- devicetree: use 2 address-cells and 2 size-cells in the reg property;
- do not xs_reset_watches on dom0;
- compile drivers/xen/pcpu.c only on x86;
- use "+=" instead of ":=" for dom0- targets;
- add a patch to update the MAINTAINERS file.
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.
Shortlog and diffstat:
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, pcpu 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: missing includes
xen: update xen_add_to_physmap interface
MAINTAINERS: add myself as Xen ARM maintainer
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++
MAINTAINERS | 7 +
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 | 168 +++++++++++++++++++++++++
arch/arm/xen/grant-table.c | 53 ++++++++
arch/arm/xen/hypercall.S | 106 ++++++++++++++++
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 | 13 ++-
drivers/xen/events.c | 18 +++-
drivers/xen/grant-table.c | 1 +
drivers/xen/privcmd.c | 4 -
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 | 3 +-
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 | 21 ++--
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, 796 insertions(+), 61 deletions(-)
A branch based on 3.6-rc5 is available here:
git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4
Cheers,
Stefano
/*
* ARM Ltd. Versatile Express
*
* Motherboard Express uATX
* V2M-P1
*
* HBI-0190D
*
* RS1 memory map ("ARM Cortex-A Series memory map" in the board's
* Technical Reference Manual)
*
* WARNING! The hardware described in this file is independent from the
* original variant (vexpress-v2m.dtsi), but there is a strong
* correspondence between the two configurations.
*
* TAKE CARE WHEN MAINTAINING THIS FILE TO PROPAGATE ANY RELEVANT
* CHANGES TO vexpress-v2m.dtsi!
*/
/ {
aliases {
arm,v2m_timer = &v2m_timer01;
};
motherboard {
compatible = "simple-bus";
arm,v2m-memory-map = "rs1";
#address-cells = <2>; /* SMB chipselect number and offset */
#size-cells = <1>;
#interrupt-cells = <1>;
flash at 0,00000000 {
compatible = "arm,vexpress-flash", "cfi-flash";
reg = <0 0x00000000 0x04000000>,
<4 0x00000000 0x04000000>;
bank-width = <4>;
};
psram at 1,00000000 {
compatible = "arm,vexpress-psram", "mtd-ram";
reg = <1 0x00000000 0x02000000>;
bank-width = <4>;
};
vram at 2,00000000 {
compatible = "arm,vexpress-vram";
reg = <2 0x00000000 0x00800000>;
};
ethernet at 2,02000000 {
compatible = "smsc,lan91c111";
reg = <2 0x02000000 0x10000>;
interrupts = <15>;
};
usb at 2,03000000 {
compatible = "nxp,usb-isp1761";
reg = <2 0x03000000 0x20000>;
interrupts = <16>;
port1-otg;
};
iofpga at 3,00000000 {
compatible = "arm,amba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 3 0 0x200000>;
sysreg at 010000 {
compatible = "arm,vexpress-sysreg";
reg = <0x010000 0x1000>;
};
sysctl at 020000 {
compatible = "arm,sp810", "arm,primecell";
reg = <0x020000 0x1000>;
};
/* PCI-E I2C bus */
v2m_i2c_pcie: i2c at 030000 {
compatible = "arm,versatile-i2c";
reg = <0x030000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
pcie-switch at 60 {
compatible = "idt,89hpes32h8";
reg = <0x60>;
};
};
aaci at 040000 {
compatible = "arm,pl041", "arm,primecell";
reg = <0x040000 0x1000>;
interrupts = <11>;
};
mmci at 050000 {
compatible = "arm,pl180", "arm,primecell";
reg = <0x050000 0x1000>;
interrupts = <9 10>;
};
kmi at 060000 {
compatible = "arm,pl050", "arm,primecell";
reg = <0x060000 0x1000>;
interrupts = <12>;
};
kmi at 070000 {
compatible = "arm,pl050", "arm,primecell";
reg = <0x070000 0x1000>;
interrupts = <13>;
};
v2m_serial0: uart at 090000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x090000 0x1000>;
interrupts = <5>;
};
v2m_serial1: uart at 0a0000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0a0000 0x1000>;
interrupts = <6>;
};
v2m_serial2: uart at 0b0000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0b0000 0x1000>;
interrupts = <7>;
};
v2m_serial3: uart at 0c0000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0c0000 0x1000>;
interrupts = <8>;
};
wdt at 0f0000 {
compatible = "arm,sp805", "arm,primecell";
reg = <0x0f0000 0x1000>;
interrupts = <0>;
};
v2m_timer01: timer at 110000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x110000 0x1000>;
interrupts = <2>;
};
v2m_timer23: timer at 120000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x120000 0x1000>;
interrupts = <3>;
};
/* DVI I2C bus */
v2m_i2c_dvi: i2c at 160000 {
compatible = "arm,versatile-i2c";
reg = <0x160000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
dvi-transmitter at 39 {
compatible = "sil,sii9022-tpi", "sil,sii9022";
reg = <0x39>;
};
dvi-transmitter at 60 {
compatible = "sil,sii9022-cpi", "sil,sii9022";
reg = <0x60>;
};
};
rtc at 170000 {
compatible = "arm,pl031", "arm,primecell";
reg = <0x170000 0x1000>;
interrupts = <4>;
};
compact-flash at 1a0000 {
compatible = "arm,vexpress-cf", "ata-generic";
reg = <0x1a0000 0x100
0x1a0100 0xf00>;
reg-shift = <2>;
};
clcd at 1f0000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f0000 0x1000>;
interrupts = <14>;
};
};
v2m_fixed_3v3: fixedregulator at 0 {
compatible = "regulator-fixed";
regulator-name = "3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
};
From: Marc Zyngier <hidden> Date: 2012-09-14 13:45:50
On 14/09/12 12:13, Stefano Stabellini wrote:
quoted hunk
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
You should consider using Dave Martin's opcode injection series for
that. The patches are already in Russell's for-next branch.
M.
--
Jazz is not dead. It just smells funny...
I already put in these
1) xen/events: fix unmask_evtchn for PV on HVM guests
2) xen: missing includes
3) xen: update xen_add_to_physmap interface
4) xen: Introduce xen_pfn_t for pfn and mfn types
5) xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
6) xen: allow privcmd for HVM guests
in my tree as they also impact/help the PVH domains which works for
x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
and also in #linux-next.
If it would make reviewing easier, I would recommend you rebase
your tree on top of the stable/for-linus-3.7 and just post them
as it would make the number of patches smaller.
I have done that and it went quite smoothly. The patch series is now 5
patches smaller.
Thanks!
From: Marc Zyngier <hidden> Date: 2012-09-14 14:02:21
On 14/09/12 12:13, Stefano Stabellini wrote:
quoted hunk
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(-)
@@ -836,6 +836,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);
This one just sent a shiver down my spine. Are you doing this for a PPI?
M.
--
Jazz is not dead. It just smells funny...
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
You should consider using Dave Martin's opcode injection series for
that. The patches are already in Russell's for-next branch.
I am all for using Dave's patches and I have even already sent a patch
to change the wrappers to use __HVC:
http://marc.info/?l=linux-kernel&m=134513261623427&w=2
I have only temporarely dropped it, only to reduce the amount of
external dependencies of this series. It already depends on Konrad's
stable/for-linus-3.7, so I would rather send this patch out later on its
own...
You should consider using Dave Martin's opcode injection series for
that. The patches are already in Russell's for-next branch.
I am all for using Dave's patches and I have even already sent a patch
to change the wrappers to use __HVC:
http://marc.info/?l=linux-kernel&m=134513261623427&w=2
I have only temporarely dropped it, only to reduce the amount of
external dependencies of this series. It already depends on Konrad's
stable/for-linus-3.7, so I would rather send this patch out later on its
own...
Fair enough. As long as there's a plan to fix this soon enough, it
should be alright.
M.
--
Jazz is not dead. It just smells funny...
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(-)
@@ -836,6 +836,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);
This one just sent a shiver down my spine. Are you doing this for a PPI?
Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).
So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.
From: Marc Zyngier <hidden> Date: 2012-09-14 14:21:05
On 14/09/12 15:13, Stefano Stabellini wrote:
On Fri, 14 Sep 2012, Marc Zyngier wrote:
quoted
On 14/09/12 12:13, Stefano Stabellini wrote:
quoted
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(-)
@@ -836,6 +836,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);
This one just sent a shiver down my spine. Are you doing this for a PPI?
Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).
So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.
So this is some sort of secondary interrupt controller, cascaded into
your GIC emulation, and this patch only affects the xen_dynamic_chip?
M.
--
Jazz is not dead. It just smells funny...
On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
quoted
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <redacted>
CC: devicetree-discuss at lists.ozlabs.org
CC: David Vrabel <redacted>
CC: Rob Herring <redacted>
CC: Dave Martin <redacted>
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:++- compatible:+ compatible = "xen,xen-<version>", "xen,xen";+ 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.
Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?
The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.
From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.
Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:
"""
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
"""
So <1 15 0xf08> means the last PPI.
So two grant tables?
Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?
from http://devicetree.org/Device_Tree_Usage:
"Each addressable device gets a reg which is a list of tuples in the
form reg = <address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty."
In this case the address is: [0 0xb0000000], that means
0x00000000b0000000, and the length is [0 0x20000], that means
0x0000000000020000.
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(-)
@@ -836,6 +836,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);
This one just sent a shiver down my spine. Are you doing this for a PPI?
Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).
So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.
So this is some sort of secondary interrupt controller, cascaded into
your GIC emulation,
I guess it could be seen as a secondary interrupt controller
From: Marc Zyngier <hidden> Date: 2012-09-14 14:31:50
On 14/09/12 15:28, Stefano Stabellini wrote:
On Fri, 14 Sep 2012, Marc Zyngier wrote:
quoted
On 14/09/12 15:13, Stefano Stabellini wrote:
quoted
On Fri, 14 Sep 2012, Marc Zyngier wrote:
quoted
On 14/09/12 12:13, Stefano Stabellini wrote:
quoted
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(-)
@@ -836,6 +836,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);
This one just sent a shiver down my spine. Are you doing this for a PPI?
Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).
So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.
So this is some sort of secondary interrupt controller, cascaded into
your GIC emulation,
I guess it could be seen as a secondary interrupt controller
quoted
and this patch only affects the xen_dynamic_chip?
Yep
Thanks. I feel relieved... ;-)
M.
--
Jazz is not dead. It just smells funny...
On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
quoted
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 v4:
- simpler parsing of Xen version in the compatible DT node.
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(xen_prefix)+3<len&&+!strncmp(xen_prefix,s,strlen(xen_prefix)))
If we have version '4.3.1' won't this trip us over?
This isn't an issue:
if (8 + 3 < 14 &&
!strncmp("xen,xen-", "xen,xen-4.3.1", 8)
would return true
and version is set to "4.3.1".
Or if we only have 'major' and 'minor', then won't '4.11' trip us
over too?
For the same reason this shouldn't be an issue either:
if (8 + 3 < 13 &&
!strncmp("xen,xen-", "xen,xen-4.11", 8)
would return true
and version would be set to "4.11".
BTW I have just tried both out of paranoia and it works as expected.
quoted
+ version = s + strlen(xen_prefix);
+ if (version == NULL) {
+ pr_debug("Xen version not found\n");
+ return 0;
+ }
+ xen_domain_type = XEN_HVM_DOMAIN;
+
+ if (!shared_info_page)
+ shared_info_page = (struct shared_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 = (struct shared_info *)shared_info_page;
+
+ /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+ * page, we use it in the event channel upcall and in some pvclock
+ * related functions. We don't need the vcpu_info placement
+ * optimizations because we don't use any pv_mmu or pv_irq op on
+ * HVM.
+ * The shared info contains exactly 1 CPU (the boot CPU). The guest
+ * is required to use VCPUOP_register_vcpu_info to place vcpu info
+ * for secondary CPUs as they are brought up. */
+ per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+ return 0;
+}
+core_initcall(xen_guest_init);
--
1.7.2.5
On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
quoted
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).
So we don't really care about the grant's size then? The DT xen.txt
talks about it..
I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.
The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.
@@ -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);
From: Ian Campbell <hidden> Date: 2012-09-14 15:08:49
On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
quoted
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).
So we don't really care about the grant's size then? The DT xen.txt
talks about it..
I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.
Actually, the grant table can grow dynamically under the control of the
guest, I think you just pass GNTTABOP_setup_table with some more frames.
See drivers/xen/grant_table.c:gnttab_expand().
The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.
This size is the size of the physical address space where the guest
could chose map grant table frames. It could be either larger or smaller
than the actual grant table. (smaller because the guest could use
physical addresses not within this region, if it wanted to for some
reason).
Ian.
On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
quoted
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
quoted
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).
So we don't really care about the grant's size then? The DT xen.txt
talks about it..
I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.
Actually, the grant table can grow dynamically under the control of the
guest, I think you just pass GNTTABOP_setup_table with some more frames.
See drivers/xen/grant_table.c:gnttab_expand().
gnttab_expand can return error if the new size exceeds
gnttab_max_grant_frames(), that is implemented using
GNTTABOP_query_size.
quoted
The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.
This size is the size of the physical address space where the guest
could chose map grant table frames. It could be either larger or smaller
than the actual grant table. (smaller because the guest could use
physical addresses not within this region, if it wanted to for some
reason).
Right.
What I am saying is that I assume that the memory region specified in
the device tree is greater or equal than gnttab_max_grant_frames().
Maybe I should add this to the device tree doc.
From: Ian Campbell <hidden> Date: 2012-09-14 15:34:57
On Fri, 2012-09-14 at 16:29 +0100, Stefano Stabellini wrote:
On Fri, 14 Sep 2012, Ian Campbell wrote:
quoted
On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
quoted
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
quoted
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).
So we don't really care about the grant's size then? The DT xen.txt
talks about it..
I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.
Actually, the grant table can grow dynamically under the control of the
guest, I think you just pass GNTTABOP_setup_table with some more frames.
See drivers/xen/grant_table.c:gnttab_expand().
gnttab_expand can return error if the new size exceeds
gnttab_max_grant_frames(), that is implemented using
GNTTABOP_query_size.
I hadn't spotted / wasn't aware that this gives you the max too.
quoted
quoted
The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.
This size is the size of the physical address space where the guest
could chose map grant table frames. It could be either larger or smaller
than the actual grant table. (smaller because the guest could use
physical addresses not within this region, if it wanted to for some
reason).
Right.
What I am saying is that I assume that the memory region specified in
the device tree is greater or equal than gnttab_max_grant_frames().
Makes sense.
(note that gnttab_max_grant_frames can be set on the hypervisor command
line though)
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF+selectXEN_DOM0
What's the point of selecting it if it's always "y"?
WBR, Sergei
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF+selectXEN_DOM0
What's the point of selecting it if it's always "y"?
That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
quoted
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.
Let me stick it in my tree and see how it works overnight with HVM and PV guests.
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF+selectXEN_DOM0
quoted
What's the point of selecting it if it's always "y"?
That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.
But we're not on x86. On ARM this select is pointless.
WBR, Sergei
From: Rob Herring <hidden> Date: 2012-09-17 13:33:13
On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
quoted
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <redacted>
CC: devicetree-discuss at lists.ozlabs.org
CC: David Vrabel <redacted>
CC: Rob Herring <redacted>
CC: Dave Martin <redacted>
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:+
State that they are part of top-level "hypervisor" node.
quoted
quoted
+- compatible:
+ compatible = "xen,xen-<version>", "xen,xen";
+ 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.
Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?
The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.
From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.
Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:
"""
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
"""
So <1 15 0xf08> means the last PPI.
Since it is a PPI, it is handled differently than a normal interrupt.
That is fine, but you should somehow state that a GIC node is also required.
So two grant tables?
Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?
from http://devicetree.org/Device_Tree_Usage:
"Each addressable device gets a reg which is a list of tuples in the
form reg = <address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty."
In this case the address is: [0 0xb0000000], that means
0x00000000b0000000, and the length is [0 0x20000], that means
0x0000000000020000.
But the size depends on #size-cells and #address-cells. I would expect
those to be 1 for a 32-bit guest.
Rob
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-17 13:41:16
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
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 v4:
- do not xs_reset_watches on dom0.
Changes in v2:
- refactor xenbus_init.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
If you would like I can also carry this in my tree.
@@ -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. */
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
quoted
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 v4:
- do not xs_reset_watches on dom0.
Changes in v2:
- refactor xenbus_init.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
If you would like I can also carry this in my tree.
OK, let's do that. I'll rebase again on your tree with this patch.
@@ -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. */
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF+selectXEN_DOM0
quoted
quoted
What's the point of selecting it if it's always "y"?
quoted
That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.
But we're not on x86. On ARM this select is pointless.
We need some common code (under drivers/xen) that compiles only if
XEN_DOM0 is selected, so it is not pointless after all.
XEN_DOM0 is not the only symbol that is conditionally compiled on one
architectuire and always "y" on another...
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-17 14:07:46
On Mon, Sep 17, 2012 at 12:05:59PM +0100, Stefano Stabellini wrote:
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
quoted
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.
Let me stick it in my tree and see how it works overnight with HVM and PV guests.
On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
quoted
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <redacted>
CC: devicetree-discuss at lists.ozlabs.org
CC: David Vrabel <redacted>
CC: Rob Herring <redacted>
CC: Dave Martin <redacted>
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:+
State that they are part of top-level "hypervisor" node.
OK
quoted
quoted
quoted
+- compatible:
+ compatible = "xen,xen-<version>", "xen,xen";
+ 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.
Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?
The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.
From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.
Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:
"""
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
"""
So <1 15 0xf08> means the last PPI.
Since it is a PPI, it is handled differently than a normal interrupt.
That is fine, but you should somehow state that a GIC node is also required.
So two grant tables?
Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?
from http://devicetree.org/Device_Tree_Usage:
"Each addressable device gets a reg which is a list of tuples in the
form reg = <address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty."
In this case the address is: [0 0xb0000000], that means
0x00000000b0000000, and the length is [0 0x20000], that means
0x0000000000020000.
But the size depends on #size-cells and #address-cells. I would expect
those to be 1 for a 32-bit guest.
I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
that on Linux v3.6-rc5 has:
#address-cells = <2>;
#size-cells = <2>;
What should I use for the example in this doc?
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF
I think the CONFIG_EXPERIMENTAL is going away. Or it has already
gone away?
quoted
quoted
quoted
+ select XEN_DOM0
quoted
quoted
What's the point of selecting it if it's always "y"?
quoted
That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.
But we're not on x86. On ARM this select is pointless.
Sure, but parts of the generic Xen (drivers/xen) code functionality has checks
for that (CONFIG_DOM0) to use some functionality that is not neccessarily
considered "dom0" specific for ARM.
The right way is to seperate those to be more of a 'backend' config and
'frontend' config. But those CONFIG options are a maze and I figured I
will fix this Gordon knot once this is all accepted/compiled/works, and then
slowly untangle the CONFIG-mess.
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF
I think the CONFIG_EXPERIMENTAL is going away. Or it has already
gone away?
I would like to keep it for Linux v3.6, because the Xen ABI offered by
Xen 4.2 hasn't been declared stable yet.
From: Konrad Rzeszutek Wilk <hidden> Date: 2012-09-17 14:18:09
On Mon, Sep 17, 2012 at 02:45:00PM +0100, Stefano Stabellini wrote:
On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
quoted
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 v4:
- do not xs_reset_watches on dom0.
Changes in v2:
- refactor xenbus_init.
Signed-off-by: Stefano Stabellini <redacted>
Acked-by: Konrad Rzeszutek Wilk <redacted>
If you would like I can also carry this in my tree.
OK, let's do that. I'll rebase again on your tree with this patch.
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCTThiswasdeprecatedin2001andannouncedtoliveonfor5years.Someoldbootloadersstillusethisway.+configXEN_DOM0+def_booly++configXEN+bool"Xen guest support on ARM (EXPERIMENTAL)"+depends onEXPERIMENTAL&&ARM&&OF+selectXEN_DOM0
quoted
quoted
What's the point of selecting it if it's always "y"?
quoted
That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.
But we're not on x86. On ARM this select is pointless.
We need some common code (under drivers/xen) that compiles only if
XEN_DOM0 is selected, so it is not pointless after all.
XEN_DOM0 is not the only symbol that is conditionally compiled on one
architectuire and always "y" on another...
Wait a sec, I have just realized that written this way XEN_DOM0 is
always "y", even if XEN is not!
The right way of doing this is:
config XEN_DOM0
def_bool y
depends on XEN
config XEN
bool "Xen guest support on ARM (EXPERIMENTAL)"
depends on EXPERIMENTAL && ARM && OF
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
I am not sure if this is what you meant, but thanks for making me
realize this mistake anyway! :)
From: Dave Martin <hidden> Date: 2012-09-18 14:50:29
On Mon, Sep 17, 2012 at 03:12:11PM +0100, Stefano Stabellini wrote:
On Mon, 17 Sep 2012, Rob Herring wrote:
quoted
On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
quoted
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
quoted
Add a doc to describe the Xen ARM device tree bindings
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <redacted>
CC: devicetree-discuss at lists.ozlabs.org
CC: David Vrabel <redacted>
CC: Rob Herring <redacted>
CC: Dave Martin <redacted>
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@+* Xen hypervisor device tree bindings++Xen ARM virtual platforms shall have the following properties:+
State that they are part of top-level "hypervisor" node.
OK
quoted
quoted
quoted
quoted
+- compatible:
+ compatible = "xen,xen-<version>", "xen,xen";
+ 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.
Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?
The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.
From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.
Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:
"""
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
"""
So <1 15 0xf08> means the last PPI.
Since it is a PPI, it is handled differently than a normal interrupt.
That is fine, but you should somehow state that a GIC node is also required.
So two grant tables?
Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?
from http://devicetree.org/Device_Tree_Usage:
"Each addressable device gets a reg which is a list of tuples in the
form reg = <address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty."
In this case the address is: [0 0xb0000000], that means
0x00000000b0000000, and the length is [0 0x20000], that means
0x0000000000020000.
But the size depends on #size-cells and #address-cells. I would expect
those to be 1 for a 32-bit guest.
I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
that on Linux v3.6-rc5 has:
#address-cells = <2>;
#size-cells = <2>;
Some core tiles on vexpress use physical addresses beyond 4G. But many
32-bit platforms (including some supporting the virtualization extensions)
may not. There's no reason for such platforms to set these properties to
<2>.
What should I use for the example in this doc?
Looking at other files in Documentation/device-tree/bindings/, it looks
like the common example configuration is for #address-cells and
#size-cells to be 1.
So, assuming that those are 1 is probably best for examples.
You could state this explicitly for good measure, but the need to
expand reg properties (and other related properties) to match the parent
bus #address-cells and #size-cells is a standard device-tree concept, so
I think it doesn't make sense to describe the implications in detail on
a per-binding basis.
Cheers
---Dave
Fair point. The alias is going to disappear anyway (I'm working on a VE
platform rework right now), but in case I won't get it on time for 3.7,
I'll make sure this one is merged instead.
Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?
I have just noticed that this patch hasn't been merged yet, but still we
need it to boot Linux on Xen.
Do you want me to rebase and resent?
Fair point. The alias is going to disappear anyway (I'm working on a VE
platform rework right now), but in case I won't get it on time for 3.7,
I'll make sure this one is merged instead.
Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?
I have just noticed that this patch hasn't been merged yet, but still we
need it to boot Linux on Xen.
Do you want me to rebase and resent?
I'm looking at v3.8-rc2, and the code have changed significantly (see
433683a66401adb0150792e725cc4f631c94de46).
If you don't have an "arm,sp804" device in your DT, it shouldn't get
registered and carry on registering the per-cpu timers. Can you check
that it fixes your issue?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Fair point. The alias is going to disappear anyway (I'm working on a VE
platform rework right now), but in case I won't get it on time for 3.7,
I'll make sure this one is merged instead.
Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?
I have just noticed that this patch hasn't been merged yet, but still we
need it to boot Linux on Xen.
Do you want me to rebase and resent?
I'm looking at v3.8-rc2, and the code have changed significantly (see
433683a66401adb0150792e725cc4f631c94de46).
If you don't have an "arm,sp804" device in your DT, it shouldn't get
registered and carry on registering the per-cpu timers. Can you check
that it fixes your issue?
Yes, sorry, my Linux tree wasn't up to date enough, thanks!