Xen devel - Sep 2012 - [PATCH] arm: introduce a DTS for Xen unprivileged virtual machines

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Pawel Moll <pawel.moll@arm.com>
CC: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot     |    3 +-
 2 files changed, 117 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
new file mode 100644
index 0000000..bfb802c
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
@@ -0,0 +1,115 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "arm,vexpress";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x2c001000 0x1000>,
+		      <0x2c002000 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		reg = <0xb0000000 0x20000>;
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+		ranges = <0 0 0x08000000 0x04000000>,
+			 <1 0 0x14000000 0x04000000>,
+			 <2 0 0x18000000 0x04000000>,
+			 <3 0 0x1c000000 0x04000000>,
+			 <4 0 0x0c000000 0x04000000>,
+			 <5 0 0x10000000 0x04000000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot
b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..5c633c5 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   vexpress-xenvm-4.2.dtb
-- 
1.7.2.5

Morning,

On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini
wrote:
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
Any particular reason to include skeleton? And I think it would be
better to use #address-cells = <2> and #size-cells = <2>, to be
ready
for LPAE addresses...
> +/ {
> +	model = "XENVM-4.2";
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <0>;
> +		};
> +	};
> +
> +	memory {
Formally, it should be memory@80000000, not that I have any strong
feelings about it :-)
> +		device_type = "memory";
> +		reg = <0x80000000 0x08000000>;
> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 13 0xf08>,
> +			     <1 14 0xf08>,
> +			     <1 11 0xf08>,
> +			     <1 10 0xf08>;
> +	};
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};
Is this binding documented somewhere - I mean in
Documentation/devicetree/bindings?
> +	motherboard {
> +		arm,v2m-memory-map = "rs1";
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};
You''ve lost me here... You have ranges and interrupt map, but
don''t
include motherboard file. Is it a mistake? If not, you could remove the
ranges and interrupt-map, but where do you get your peripherals from
then?
> diff --git a/arch/arm/mach-vexpress/Makefile.boot
b/arch/arm/mach-vexpress/Makefile.boot
> index 318d308..5c633c5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
>  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
>  				   vexpress-v2p-ca9.dtb \
>  				   vexpress-v2p-ca15-tc1.dtb \
> -				   vexpress-v2p-ca15_a7.dtb
> +				   vexpress-v2p-ca15_a7.dtb \
> +				   vexpress-xenvm-4.2.dtb
Cheers!

Pawel

On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini
wrote:
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "XENVM-4.2";
Why the shouty caps?

Did you mean 4.3 here and throughout?
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
Is this second compatible thing actually true? We don''t actually
emulate
much (anything?) of what would be on a real vexpress motherboard.

"arm,vexpress" is used only in v2m.c and I don''t think we
want the
majority of that -- we don''t provide any of the peripherals which it
registers.

I think the only things we might want out of that lot are the arch timer
and perhaps the uart0 (as a debug port).

I suspect we should have our own xen machine .c.

[...]
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
Don''t we mean "arm,cortex-a15-gic" here? That''s what
we actually
provide. I''m not sure how the a9 and a15 differ.
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
Ian.

On 19/09/12 18:44, Stefano Stabellini wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
Does this make sense?  There is no fixed configuration for VMs.

Is the intention to pass a DTS to the toolstack for it to create the VM
with the appropriate amount of memory and peripheral mapped to the right
place etc?  Or is the toolstack going to create the VM and generate the
DTB from (e.g.,) an xl VM configuration file.
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};
This node needs to be generated by the toolstack as only it knows what
ABI the hypervisor has.

David

On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll
wrote:
> Morning,
> 
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> 
> Any particular reason to include skeleton? And I think it would be
> better to use #address-cells = <2> and #size-cells = <2>, to be
ready
> for LPAE addresses...
> 
> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> > +	};
Are you sure this default command line is appropriate?

I don''t normally like to see default command lines unless they really
add something which is crucial for the board to work.

None of those args looks vital to me.  They are configuration choices
and should be left up to the user.

Cheers
---Dave

On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel
wrote:
> On 19/09/12 18:44, Stefano Stabellini wrote:
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> Does this make sense?  There is no fixed configuration for VMs.
> 
> Is the intention to pass a DTS to the toolstack for it to create the VM
> with the appropriate amount of memory and peripheral mapped to the right
> place etc?  Or is the toolstack going to create the VM and generate the
> DTB from (e.g.,) an xl VM configuration file.
> 
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> This node needs to be generated by the toolstack as only it knows what
> ABI the hypervisor has.
That''s a good point: the same applies to the command line.  The
toolstack
knows where the console and root device should be etc.: the kernel itself
shouldn''t have static defaults for those.

Cheers
---Dave

On Thu, 20 Sep 2012, Pawel Moll wrote:
> Morning,
> 
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> 
> Any particular reason to include skeleton? And I think it would be
> better to use #address-cells = <2> and #size-cells = <2>, to be
ready
> for LPAE addresses...
good idea

> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> > +	};
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a15";
> > +			reg = <0>;
> > +		};
> > +	};
> > +
> > +	memory {
> 
> Formally, it should be memory@80000000, not that I have any strong
> feelings about it :-)
OK

> > +		device_type = "memory";
> > +		reg = <0x80000000 0x08000000>;
> > +	};
> > +
> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <0>;
> > +		interrupt-controller;
> > +		reg = <0x2c001000 0x1000>,
> > +		      <0x2c002000 0x100>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv7-timer";
> > +		interrupts = <1 13 0xf08>,
> > +			     <1 14 0xf08>,
> > +			     <1 11 0xf08>,
> > +			     <1 10 0xf08>;
> > +	};
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> Is this binding documented somewhere - I mean in
> Documentation/devicetree/bindings?
Yes, it is: Documentation/devicetree/bindings/arm/xen.txt
added by: http://marc.info/?l=linux-kernel&m=134790380030990&w=2

> > +	motherboard {
> > +		arm,v2m-memory-map = "rs1";
> > +		ranges = <0 0 0x08000000 0x04000000>,
> > +			 <1 0 0x14000000 0x04000000>,
> > +			 <2 0 0x18000000 0x04000000>,
> > +			 <3 0 0x1c000000 0x04000000>,
> > +			 <4 0 0x0c000000 0x04000000>,
> > +			 <5 0 0x10000000 0x04000000>;
> > +
> > +		interrupt-map-mask = <0 0 63>;
> > +		interrupt-map = <0 0  0 &gic 0  0 4>,
> > +				<0 0  1 &gic 0  1 4>,
> > +				<0 0  2 &gic 0  2 4>,
> > +				<0 0  3 &gic 0  3 4>,
> > +				<0 0  4 &gic 0  4 4>,
> > +				<0 0  5 &gic 0  5 4>,
> > +				<0 0  6 &gic 0  6 4>,
> > +				<0 0  7 &gic 0  7 4>,
> > +				<0 0  8 &gic 0  8 4>,
> > +				<0 0  9 &gic 0  9 4>,
> > +				<0 0 10 &gic 0 10 4>,
> > +				<0 0 11 &gic 0 11 4>,
> > +				<0 0 12 &gic 0 12 4>,
> > +				<0 0 13 &gic 0 13 4>,
> > +				<0 0 14 &gic 0 14 4>,
> > +				<0 0 15 &gic 0 15 4>,
> > +				<0 0 16 &gic 0 16 4>,
> > +				<0 0 17 &gic 0 17 4>,
> > +				<0 0 18 &gic 0 18 4>,
> > +				<0 0 19 &gic 0 19 4>,
> > +				<0 0 20 &gic 0 20 4>,
> > +				<0 0 21 &gic 0 21 4>,
> > +				<0 0 22 &gic 0 22 4>,
> > +				<0 0 23 &gic 0 23 4>,
> > +				<0 0 24 &gic 0 24 4>,
> > +				<0 0 25 &gic 0 25 4>,
> > +				<0 0 26 &gic 0 26 4>,
> > +				<0 0 27 &gic 0 27 4>,
> > +				<0 0 28 &gic 0 28 4>,
> > +				<0 0 29 &gic 0 29 4>,
> > +				<0 0 30 &gic 0 30 4>,
> > +				<0 0 31 &gic 0 31 4>,
> > +				<0 0 32 &gic 0 32 4>,
> > +				<0 0 33 &gic 0 33 4>,
> > +				<0 0 34 &gic 0 34 4>,
> > +				<0 0 35 &gic 0 35 4>,
> > +				<0 0 36 &gic 0 36 4>,
> > +				<0 0 37 &gic 0 37 4>,
> > +				<0 0 38 &gic 0 38 4>,
> > +				<0 0 39 &gic 0 39 4>,
> > +				<0 0 40 &gic 0 40 4>,
> > +				<0 0 41 &gic 0 41 4>,
> > +				<0 0 42 &gic 0 42 4>;
> > +	};
> > +};
> 
> You''ve lost me here... You have ranges and interrupt map, but
don''t
> include motherboard file. Is it a mistake? If not, you could remove the
> ranges and interrupt-map, but where do you get your peripherals from
> then?
There are no peripherals apart from the ones that are already described
here (timer, gic). All the peripherals that the guest sees are virtual
devices that show up on xenbus (a virtual bus). In order to initialize
xenbus, the guest only needs the hypervisor node.  So I''ll remove the
ranges and interrupt-map.

On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini
wrote:
> There are no peripherals apart from the ones that are already described
> here (timer, gic). All the peripherals that the guest sees are virtual
> devices that show up on xenbus (a virtual bus). In order to initialize
> xenbus, the guest only needs the hypervisor node.  So I''ll remove
the
> ranges and interrupt-map.
So all the peripherals are actually discoverable - awesome!

But the fact is that the only "vexpressness" of this tree is
memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
"generic A15 platform". 

I understand that you had to use some "compatible" value to get
initialization code and I''m flattered ;-) by your choice of
"arm,vexpress", but maybe - as suggested by others - you would be
better
off with generating this stuff in runtime, by whatever tool is used to
instantiate the guest?

Paweł

On Thu, 20 Sep 2012, Ian Campbell wrote:
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	model = "XENVM-4.2";
> 
> Why the shouty caps?
It looks like that model names are always capital, at least in the
vexpress family.

> Did you mean 4.3 here and throughout?
Nope, after all this is the fruit of the work we did on Xen 4.2, mostly
already upstream. By the time of the 4.3 release we might have a
different dts.

> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> 
> Is this second compatible thing actually true? We don''t actually
emulate
> much (anything?) of what would be on a real vexpress motherboard.
> 
> "arm,vexpress" is used only in v2m.c and I don''t think
we want the
> majority of that -- we don''t provide any of the peripherals which
it
> registers.
> 
> I think the only things we might want out of that lot are the arch timer
> and perhaps the uart0 (as a debug port).
> 
> I suspect we should have our own xen machine .c.
> 
> [...]
It is true that we are "arm,vexpress" compatible at the moment.
Also we need to be unless we want to introduce our own arch/arm/mach-xen
that I think is overkill.

Versatile Express is flexible enough to be a good base for our own
virtual machine platform, especially if the maintainers keep an eye on
getting everything through DT and not expecting devices just to be there
;-)

> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> 
> Don''t we mean "arm,cortex-a15-gic" here? That''s
what we actually
> provide. I''m not sure how the a9 and a15 differ.
The GIC that comes with vexpress is a9 compatible.

On Thu, 20 Sep 2012, David Vrabel wrote:
> On 19/09/12 18:44, Stefano Stabellini wrote:
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> Does this make sense?  There is no fixed configuration for VMs.
> 
> Is the intention to pass a DTS to the toolstack for it to create the VM
> with the appropriate amount of memory and peripheral mapped to the right
> place etc?  Or is the toolstack going to create the VM and generate the
> DTB from (e.g.,) an xl VM configuration file.
> 
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> This node needs to be generated by the toolstack as only it knows what
> ABI the hypervisor has.
 
This DTS is going to be genereted by the toolstack (or the hypervisor).
We don''t expect people to take this exact DTS and use it for Xen VMs.
However it is useful to have it in the Linux tree as a reference.

Of course the amount of memory and the position of the memory region
under the hypervisor node can change.

On Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > Morning,
> > 
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/dts-v1/;
> > > +
> > > +/include/ "skeleton.dtsi"
> > 
> > Any particular reason to include skeleton? And I think it would be
> > better to use #address-cells = <2> and #size-cells = <2>,
to be ready
> > for LPAE addresses...
> > 
> > > +/ {
> > > +	model = "XENVM-4.2";
> > > +	compatible = "xen,xenvm-4.2",
"arm,vexpress";
> > > +	interrupt-parent = <&gic>;
> > > +
> > > +	chosen {
> > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> > > +	};
> 
> Are you sure this default command line is appropriate?
> 
> I don''t normally like to see default command lines unless they
really
> add something which is crucial for the board to work.
> 
> None of those args looks vital to me.  They are configuration choices
> and should be left up to the user.
Yes, you are right. I''ll trim it down to "console=hvc0
root=/dev/xvda".

On Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> > On 19/09/12 18:44, Stefano Stabellini wrote:
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > 
> > Does this make sense?  There is no fixed configuration for VMs.
> > 
> > Is the intention to pass a DTS to the toolstack for it to create the
VM
> > with the appropriate amount of memory and peripheral mapped to the
right
> > place etc?  Or is the toolstack going to create the VM and generate
the
> > DTB from (e.g.,) an xl VM configuration file.
> > 
> > > +
> > > +	hypervisor {
> > > +		compatible = "xen,xen-4.2", "xen,xen";
> > > +		reg = <0xb0000000 0x20000>;
> > > +		interrupts = <1 15 0xf08>;
> > > +	};
> > 
> > This node needs to be generated by the toolstack as only it knows what
> > ABI the hypervisor has.
> 
> That''s a good point: the same applies to the command line.  The
toolstack
> knows where the console and root device should be etc.: the kernel itself
> shouldn''t have static defaults for those.
As I was saying in the other email, this dts is just supposed to be a
reference. The real one is going to come from the toolstack or the
hypervisor. 

But isn''t the same true for other dts as well? Aren''t they
supposed to
be passed to the kernel by the bootloader?

On Thu, 20 Sep 2012, Pawel Moll wrote:
> On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
> > There are no peripherals apart from the ones that are already
described
> > here (timer, gic). All the peripherals that the guest sees are virtual
> > devices that show up on xenbus (a virtual bus). In order to initialize
> > xenbus, the guest only needs the hypervisor node.  So I''ll
remove the
> > ranges and interrupt-map.
> 
> So all the peripherals are actually discoverable - awesome!
> 
> But the fact is that the only "vexpressness" of this tree is
> memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
> "generic A15 platform". 
> 
> I understand that you had to use some "compatible" value to get
> initialization code and I''m flattered ;-) by your choice of
> "arm,vexpress", but maybe - as suggested by others - you would be
better
> off with generating this stuff in runtime, by whatever tool is used to
> instantiate the guest?
Yes, it is certainly going to be generated at run time. Does it make
sense to keep an example under arch/arm/boot/dts? I think so. There must
be other platforms that actually pass the device tree to the kernel from
the firmware and still have a dts in the kernel tree, right?
If actually there are none, it is probably best to forget about this
patch :)

Regarding the choice of "arm,vexpress", there was a discussion at
kernel
summit about vexpress being the right choice as a base platform for
virtual machines on ARM, even though in the Xen case it means having a
vexpress with no peripherals.

On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini
wrote:
> On Thu, 20 Sep 2012, Ian Campbell wrote:
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > +	model = "XENVM-4.2";
> > 
> > Why the shouty caps?
> 
> It looks like that model names are always capital, at least in the
> vexpress family.
> 
> 
> > Did you mean 4.3 here and throughout?
> 
> Nope, after all this is the fruit of the work we did on Xen 4.2, mostly
> already upstream. By the time of the 4.3 release we might have a
> different dts.
> 
> 
> > > +	compatible = "xen,xenvm-4.2",
"arm,vexpress";
> > 
> > Is this second compatible thing actually true? We don''t
actually emulate
> > much (anything?) of what would be on a real vexpress motherboard.
> > 
> > "arm,vexpress" is used only in v2m.c and I don''t
think we want the
> > majority of that -- we don''t provide any of the peripherals
which it
> > registers.
> > 
> > I think the only things we might want out of that lot are the arch
timer
> > and perhaps the uart0 (as a debug port).
> > 
> > I suspect we should have our own xen machine .c.
> > 
> > [...]
> 
> It is true that we are "arm,vexpress" compatible at the moment.
But we aren''t, we don''t emulate 90%+ of the actual hardware
which
vexpress compatibility would actually imply.

Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
this compat value -- it''s full of stuff which we don''t (and
aren''t going
to) implement.
> Also we need to be unless we want to introduce our own arch/arm/mach-xen
> that I think is overkill.
Probably.
> Versatile Express is flexible enough to be a good base for our own
> virtual machine platform, especially if the maintainers keep an eye on
> getting everything through DT and not expecting devices just to be there
> ;-)
Perhaps what we want is a stricter subset of the stuff in mach-vexpress
then. But if so then this should be expressed both in the DT and in the
code, not just papered over by declaring things compatible when they are
not.
> > > +	gic: interrupt-controller@2c001000 {
> > > +		compatible = "arm,cortex-a9-gic";
> > 
> > Don''t we mean "arm,cortex-a15-gic" here?
That''s what we actually
> > provide. I''m not sure how the a9 and a15 differ.
> 
> The GIC that comes with vexpress is a9 compatible.
The GIC which Xen emulates is the one which matters here though, and
that is an a15.

Ian.

On 20/09/12 13:15, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Pawel Moll wrote:
>> On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
>>> There are no peripherals apart from the ones that are already
described
>>> here (timer, gic). All the peripherals that the guest sees are
virtual
>>> devices that show up on xenbus (a virtual bus). In order to
initialize
>>> xenbus, the guest only needs the hypervisor node.  So I''ll
remove the
>>> ranges and interrupt-map.
>>
>> So all the peripherals are actually discoverable - awesome!
>>
>> But the fact is that the only "vexpressness" of this tree is
>> memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
>> "generic A15 platform". 
>>
>> I understand that you had to use some "compatible" value to
get
>> initialization code and I''m flattered ;-) by your choice of
>> "arm,vexpress", but maybe - as suggested by others - you
would be better
>> off with generating this stuff in runtime, by whatever tool is used to
>> instantiate the guest?
> 
> Yes, it is certainly going to be generated at run time. Does it make
> sense to keep an example under arch/arm/boot/dts? I think so. There must
> be other platforms that actually pass the device tree to the kernel from
> the firmware and still have a dts in the kernel tree, right?
> If actually there are none, it is probably best to forget about this
> patch :)
> 
> Regarding the choice of "arm,vexpress", there was a discussion at
kernel
> summit about vexpress being the right choice as a base platform for
> virtual machines on ARM, even though in the Xen case it means having a
> vexpress with no peripherals.
I think the important thing here is that the memory map is RS1. As this
is a (very limited) subset of a vexpress A15, it seems to make some sense.

I still think it is useful at have an example of such a platform in the
tree, if only as a very minimal example.

	M.
-- 
Jazz is not dead. It just smells funny...

On Thu, 20 Sep 2012, Ian Campbell wrote:
> > Versatile Express is flexible enough to be a good base for our own
> > virtual machine platform, especially if the maintainers keep an eye on
> > getting everything through DT and not expecting devices just to be
there
> > ;-)
> 
> Perhaps what we want is a stricter subset of the stuff in mach-vexpress
> then. But if so then this should be expressed both in the DT and in the
> code, not just papered over by declaring things compatible when they are
> not.
But it is already expressed in the DT, by removing all the device nodes
we don''t emulated. And it is already expressed in the code, by fully
discovering peripherals via DT, therefore not trying to initialize
non-present devices.

> > > > +	gic: interrupt-controller@2c001000 {
> > > > +		compatible = "arm,cortex-a9-gic";
> > > 
> > > Don''t we mean "arm,cortex-a15-gic" here?
That''s what we actually
> > > provide. I''m not sure how the a9 and a15 differ.
> > 
> > The GIC that comes with vexpress is a9 compatible.
> 
> The GIC which Xen emulates is the one which matters here though, and
> that is an a15.
The a15 gic is still a9 compatible. OK to be precise I am going to add
"arm,cortex-a15-gic", but I cannot really remove
"arm,cortex-a9-gic".

On Thu, Sep 20, 2012 at 01:04:34PM +0100, Stefano Stabellini
wrote:
> On Thu, 20 Sep 2012, Dave Martin wrote:
> > On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> > > On 19/09/12 18:44, Stefano Stabellini wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > > 
> > > Does this make sense?  There is no fixed configuration for VMs.
> > > 
> > > Is the intention to pass a DTS to the toolstack for it to create
the VM
> > > with the appropriate amount of memory and peripheral mapped to
the right
> > > place etc?  Or is the toolstack going to create the VM and
generate the
> > > DTB from (e.g.,) an xl VM configuration file.
> > > 
> > > > +
> > > > +	hypervisor {
> > > > +		compatible = "xen,xen-4.2",
"xen,xen";
> > > > +		reg = <0xb0000000 0x20000>;
> > > > +		interrupts = <1 15 0xf08>;
> > > > +	};
> > > 
> > > This node needs to be generated by the toolstack as only it knows
what
> > > ABI the hypervisor has.
> > 
> > That''s a good point: the same applies to the command line. 
The toolstack
> > knows where the console and root device should be etc.: the kernel
itself
> > shouldn''t have static defaults for those.
> 
> As I was saying in the other email, this dts is just supposed to be a
> reference. The real one is going to come from the toolstack or the
> hypervisor. 
> 
> But isn''t the same true for other dts as well? Aren''t
they supposed to
> be passed to the kernel by the bootloader?
Opinions on this may differ -- but I would say that the bootloader (or
virtualisation toolstack) should receive a dtb as configuration data for
the image, and should do the minimum appropriate customisations on it.
The rationale for that is that fixing buggy firmware is harder than
deploying a new device tree blob.

For a virtualisation toolstack, I think the expected level of
customisation might be higher: because it is the toolstack that knows
what virtualised I/O devices the guest is supposed to attach to etc. 
For example, if I want to boot a guest using a particular image file as
its disk, then the toolstack needs to set things up, and then boot the
guest OS with appropriate configuration.  Exactly _what_ configuration
may be a private protocol between the toolstack, the hypervisor/host and
the client drivers in the guest OS.

But for all the stuff which never changes in the guest VM (such as the
simulated interrupt controller topology, or whatever) the dts can be
fairly static and just provided as input to the toolstack; part of the
configuration for a particular guest image.

That means that the static parts of the config can be fixed
independently of the toolstack if necessary.  Fixing the dynamic
configuration aspects independently of the toolstack makes less sense
because the toolstack really does have to participate in those areas.

This is just my view, though.

Cheers
---Dave

On Thu, 2012-09-20 at 13:39 +0100, Stefano Stabellini
wrote:
> On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > Versatile Express is flexible enough to be a good base for our
own
> > > virtual machine platform, especially if the maintainers keep an
eye on
> > > getting everything through DT and not expecting devices just to
be there
> > > ;-)
> > 
> > Perhaps what we want is a stricter subset of the stuff in
mach-vexpress
> > then. But if so then this should be expressed both in the DT and in
the
> > code, not just papered over by declaring things compatible when they
are
> > not.
> 
> But it is already expressed in the DT, by removing all the device nodes
> we don''t emulated. And it is already expressed in the code, by
fully
> discovering peripherals via DT, therefore not trying to initialize
> non-present devices.
Sorry on second look most of the non-DT stuff is part of the non-DT
vexpress support code in the same file.

There are some exceptions though:

v2m_reset and v2m_power_off don''t refer to DT and touch system
peripherals directly.

v2m_dt_map_io falls back to v2m_io_desc if there is no rs1 node (which I
think we don''t have?) 

v2m_clk_init is called from v2m_dt_timer_init (I think you may have
fixed this one).
> 
> 
> > > > > +	gic: interrupt-controller@2c001000 {
> > > > > +		compatible = "arm,cortex-a9-gic";
> > > > 
> > > > Don''t we mean "arm,cortex-a15-gic" here?
That''s what we actually
> > > > provide. I''m not sure how the a9 and a15 differ.
> > > 
> > > The GIC that comes with vexpress is a9 compatible.
> > 
> > The GIC which Xen emulates is the one which matters here though, and
> > that is an a15.
> 
> The a15 gic is still a9 compatible. OK to be precise I am going to add
> "arm,cortex-a15-gic", but I cannot really remove
"arm,cortex-a9-gic".
I think A9 is GIC v1 and A15 is GIC v2, with the primary difference
being the alignment of the memory mapped registers, but I''m not totally
sure of that.

A bunch of places do use "arm,cortex-a15-gic",
"arm,cortex-a9-gic" so
you are probably right that this is the proper answer.

Ian.

On Thursday 20 September 2012, Ian Campbell wrote:
> On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> > On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > > + compatible = "xen,xenvm-4.2",
"arm,vexpress";
> > > 
> > > Is this second compatible thing actually true? We don''t
actually emulate
> > > much (anything?) of what would be on a real vexpress motherboard.
> > > 
> > > "arm,vexpress" is used only in v2m.c and I
don''t think we want the
> > > majority of that -- we don''t provide any of the
peripherals which it
> > > registers.
> > > 
> > > I think the only things we might want out of that lot are the
arch timer
> > > and perhaps the uart0 (as a debug port).
> > > 
> > > I suspect we should have our own xen machine .c.
> > > 
> > > [...]
> > 
> > It is true that we are "arm,vexpress" compatible at the
moment.
> 
> But we aren''t, we don''t emulate 90%+ of the actual
hardware which
> vexpress compatibility would actually imply.
> 
> Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
> this compat value -- it''s full of stuff which we don''t
(and aren''t going
> to) implement.
It''s not much different in the end, but I think I''d rather
make the
compatible list in the device tree "xen,xenvm-4.2",
"xen,xenvm" without
listing "arm,vexpress", but then adding "xen,xenvm" to the
list of
compatible devices in the vexpress kernel code.

The main difference is that if we decide to separate out the Linux
code for Xen and vexpress later into distinct ports, we have the
option to do that. vexpress will support multiplatform configurations
in 3.7 anyway, so the idea of making all virtual platforms part of
vexpress in order to be able to boot the same kernel on them is not
all that important any more.

	Arnd

On Thu, 2012-09-20 at 13:28 +0100, Marc Zyngier wrote:
> I think the important thing here is that the memory map is RS1. As this
> is a (very limited) subset of a vexpress A15, it seems to make some sense.
Looking at arch/arm/boot/dts/vexpress-v2m-rs1.dtsi I don''t think we
provide anything which is on rs1 though.

The Xen VM environment has only a gic (via a combination of the gic
virtualisation mode for CPU regs and emulation for the distributor), the
arch timers and xenbus (which is the s/w bus which Xen uses to discover
its paravirtualised peripherals).

Currently we provide a very simple output only emulation of UART0,
simply to get the debug output from the decompresser, but we want that
to go away not get baked in.

Ian.

On 20/09/12 14:30, Ian Campbell wrote:
> On Thu, 2012-09-20 at 13:28 +0100, Marc Zyngier wrote:
>> I think the important thing here is that the memory map is RS1. As this
>> is a (very limited) subset of a vexpress A15, it seems to make some
sense.
> 
> Looking at arch/arm/boot/dts/vexpress-v2m-rs1.dtsi I don''t think
we
> provide anything which is on rs1 though.
The location of both GIC and memory are RS1 "compliant" (as in
"they are
at the expected location").

	M.
-- 
Jazz is not dead. It just smells funny...

On Thu, 20 Sep 2012, Arnd Bergmann wrote:
> On Thursday 20 September 2012, Ian Campbell wrote:
> > On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> > > On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> 
> > > > > + compatible = "xen,xenvm-4.2",
"arm,vexpress";
> > > > 
> > > > Is this second compatible thing actually true? We
don''t actually emulate
> > > > much (anything?) of what would be on a real vexpress
motherboard.
> > > > 
> > > > "arm,vexpress" is used only in v2m.c and I
don''t think we want the
> > > > majority of that -- we don''t provide any of the
peripherals which it
> > > > registers.
> > > > 
> > > > I think the only things we might want out of that lot are
the arch timer
> > > > and perhaps the uart0 (as a debug port).
> > > > 
> > > > I suspect we should have our own xen machine .c.
> > > > 
> > > > [...]
> > > 
> > > It is true that we are "arm,vexpress" compatible at the
moment.
> > 
> > But we aren''t, we don''t emulate 90%+ of the actual
hardware which
> > vexpress compatibility would actually imply.
> > 
> > Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed
off
> > this compat value -- it''s full of stuff which we
don''t (and aren''t going
> > to) implement.
> 
> It''s not much different in the end, but I think I''d
rather make the
> compatible list in the device tree "xen,xenvm-4.2",
"xen,xenvm" without
> listing "arm,vexpress", but then adding "xen,xenvm" to
the list of
> compatible devices in the vexpress kernel code.
> 
> The main difference is that if we decide to separate out the Linux
> code for Xen and vexpress later into distinct ports, we have the
> option to do that. vexpress will support multiplatform configurations
> in 3.7 anyway, so the idea of making all virtual platforms part of
> vexpress in order to be able to boot the same kernel on them is not
> all that important any more.
That''s a very good idea, I''ll do that.

On Thu, 2012-09-20 at 15:11 +0100, Stefano Stabellini
wrote:
> On Thu, 20 Sep 2012, Arnd Bergmann wrote:
> > It's not much different in the end, but I think I'd rather
make the
> > compatible list in the device tree "xen,xenvm-4.2",
"xen,xenvm" without
> > listing "arm,vexpress", but then adding
"xen,xenvm" to the list of
> > compatible devices in the vexpress kernel code.
>
> That's a very good idea, I'll do that.
Yep, this would work with me as well. And I'm sure we can make the
"arm,vexpress,memory-map" bit unnecessary as well - have a look into
it,
and I'll help you as much as I can.

And then, if your "reference" DTS is to be merged, it won't be
called
vexpress-*.dts, so I will not have to decide whether to take it in or
not :-)

Cheers!

Paweł




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On 09/19/2012 12:44 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: linux-arm-kernel@lists.infradead.org
> ---
>  arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115
++++++++++++++++++++++++++++++
>  arch/arm/mach-vexpress/Makefile.boot     |    3 +-
>  2 files changed, 117 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> new file mode 100644
> index 0000000..bfb802c
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> @@ -0,0 +1,115 @@
> +/*
> + * Xen Virtual Machine for unprivileged guests
> + *
> + * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
> + * Cortex-A15 MPCore (V2P-CA15)
> + *
> + */
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "XENVM-4.2";
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <0>;
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x08000000>;
How much guest memory can be supported here?

I would expect something like the memory size to be filled in by the
hypervisor. If so, perhaps a note on any fields hypervisor will adjust.

Rob
> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 13 0xf08>,
> +			     <1 14 0xf08>,
> +			     <1 11 0xf08>,
> +			     <1 10 0xf08>;
> +	};
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};
> +
> +	motherboard {
> +		arm,v2m-memory-map = "rs1";
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};
> diff --git a/arch/arm/mach-vexpress/Makefile.boot
b/arch/arm/mach-vexpress/Makefile.boot
> index 318d308..5c633c5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
>  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
>  				   vexpress-v2p-ca9.dtb \
>  				   vexpress-v2p-ca15-tc1.dtb \
> -				   vexpress-v2p-ca15_a7.dtb
> +				   vexpress-v2p-ca15_a7.dtb \
> +				   vexpress-xenvm-4.2.dtb
>

On Thu, Sep 20, 2012 at 12:18:15PM +0100, Dave Martin
wrote:
> On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > Morning,
> > 
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/dts-v1/;
> > > +
> > > +/include/ "skeleton.dtsi"
> > 
> > Any particular reason to include skeleton? And I think it would be
> > better to use #address-cells = <2> and #size-cells = <2>,
to be ready
> > for LPAE addresses...
> > 
> > > +/ {
> > > +	model = "XENVM-4.2";
> > > +	compatible = "xen,xenvm-4.2",
"arm,vexpress";
> > > +	interrupt-parent = <&gic>;
> > > +
> > > +	chosen {
> > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
earlyprintk=xen ?

On Thu, 20 Sep 2012, Rob Herring wrote:
> On 09/19/2012 12:44 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> > CC: Pawel Moll <pawel.moll@arm.com>
> > CC: linux-arm-kernel@lists.infradead.org
> > ---
> >  arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115
++++++++++++++++++++++++++++++
> >  arch/arm/mach-vexpress/Makefile.boot     |    3 +-
> >  2 files changed, 117 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > 
> > diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > new file mode 100644
> > index 0000000..bfb802c
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > @@ -0,0 +1,115 @@
> > +/*
> > + * Xen Virtual Machine for unprivileged guests
> > + *
> > + * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
> > + * Cortex-A15 MPCore (V2P-CA15)
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> > +	};
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a15";
> > +			reg = <0>;
> > +		};
> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x80000000 0x08000000>;
> 
> How much guest memory can be supported here?
There are no particular restrictions other than the amount of memory
present on the physical hardware and the memory already used by other
guests.

> I would expect something like the memory size to be filled in by the
> hypervisor. If so, perhaps a note on any fields hypervisor will adjust.
> 
Yes, that''s a good idea. Certainly the amount of memory would be
adjusted by the hypervisor. Also the properties of the hypervisor node
and maybe the bootargs could be adjusted too.

> > +	};
> > +
> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <0>;
> > +		interrupt-controller;
> > +		reg = <0x2c001000 0x1000>,
> > +		      <0x2c002000 0x100>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv7-timer";
> > +		interrupts = <1 13 0xf08>,
> > +			     <1 14 0xf08>,
> > +			     <1 11 0xf08>,
> > +			     <1 10 0xf08>;
> > +	};
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> > +
> > +	motherboard {
> > +		arm,v2m-memory-map = "rs1";
> > +		ranges = <0 0 0x08000000 0x04000000>,
> > +			 <1 0 0x14000000 0x04000000>,
> > +			 <2 0 0x18000000 0x04000000>,
> > +			 <3 0 0x1c000000 0x04000000>,
> > +			 <4 0 0x0c000000 0x04000000>,
> > +			 <5 0 0x10000000 0x04000000>;
> > +
> > +		interrupt-map-mask = <0 0 63>;
> > +		interrupt-map = <0 0  0 &gic 0  0 4>,
> > +				<0 0  1 &gic 0  1 4>,
> > +				<0 0  2 &gic 0  2 4>,
> > +				<0 0  3 &gic 0  3 4>,
> > +				<0 0  4 &gic 0  4 4>,
> > +				<0 0  5 &gic 0  5 4>,
> > +				<0 0  6 &gic 0  6 4>,
> > +				<0 0  7 &gic 0  7 4>,
> > +				<0 0  8 &gic 0  8 4>,
> > +				<0 0  9 &gic 0  9 4>,
> > +				<0 0 10 &gic 0 10 4>,
> > +				<0 0 11 &gic 0 11 4>,
> > +				<0 0 12 &gic 0 12 4>,
> > +				<0 0 13 &gic 0 13 4>,
> > +				<0 0 14 &gic 0 14 4>,
> > +				<0 0 15 &gic 0 15 4>,
> > +				<0 0 16 &gic 0 16 4>,
> > +				<0 0 17 &gic 0 17 4>,
> > +				<0 0 18 &gic 0 18 4>,
> > +				<0 0 19 &gic 0 19 4>,
> > +				<0 0 20 &gic 0 20 4>,
> > +				<0 0 21 &gic 0 21 4>,
> > +				<0 0 22 &gic 0 22 4>,
> > +				<0 0 23 &gic 0 23 4>,
> > +				<0 0 24 &gic 0 24 4>,
> > +				<0 0 25 &gic 0 25 4>,
> > +				<0 0 26 &gic 0 26 4>,
> > +				<0 0 27 &gic 0 27 4>,
> > +				<0 0 28 &gic 0 28 4>,
> > +				<0 0 29 &gic 0 29 4>,
> > +				<0 0 30 &gic 0 30 4>,
> > +				<0 0 31 &gic 0 31 4>,
> > +				<0 0 32 &gic 0 32 4>,
> > +				<0 0 33 &gic 0 33 4>,
> > +				<0 0 34 &gic 0 34 4>,
> > +				<0 0 35 &gic 0 35 4>,
> > +				<0 0 36 &gic 0 36 4>,
> > +				<0 0 37 &gic 0 37 4>,
> > +				<0 0 38 &gic 0 38 4>,
> > +				<0 0 39 &gic 0 39 4>,
> > +				<0 0 40 &gic 0 40 4>,
> > +				<0 0 41 &gic 0 41 4>,
> > +				<0 0 42 &gic 0 42 4>;
> > +	};
> > +};
> > diff --git a/arch/arm/mach-vexpress/Makefile.boot
b/arch/arm/mach-vexpress/Makefile.boot
> > index 318d308..5c633c5 100644
> > --- a/arch/arm/mach-vexpress/Makefile.boot
> > +++ b/arch/arm/mach-vexpress/Makefile.boot
> > @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
> >  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
> >  				   vexpress-v2p-ca9.dtb \
> >  				   vexpress-v2p-ca15-tc1.dtb \
> > -				   vexpress-v2p-ca15_a7.dtb
> > +				   vexpress-v2p-ca15_a7.dtb \
> > +				   vexpress-xenvm-4.2.dtb
> > 
>

On Thu, 20 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 12:18:15PM +0100, Dave Martin wrote:
> > On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > > Morning,
> > > 
> > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > > +/dts-v1/;
> > > > +
> > > > +/include/ "skeleton.dtsi"
> > > 
> > > Any particular reason to include skeleton? And I think it would
be
> > > better to use #address-cells = <2> and #size-cells =
<2>, to be ready
> > > for LPAE addresses...
> > > 
> > > > +/ {
> > > > +	model = "XENVM-4.2";
> > > > +	compatible = "xen,xenvm-4.2",
"arm,vexpress";
> > > > +	interrupt-parent = <&gic>;
> > > > +
> > > > +	chosen {
> > > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda
init=/sbin/init";
> 
> earlyprintk=xen ?
> 
earlyprintk is not "selectable" on ARM (that would be a nice addition
though). It just goes to the configured uart, that is the only piece of
hardware that is being emulated by Xen at the moment.

In any case I have removed anything debug related, including
earlyprintk, from the default bootargs.