| Message ID | 1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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.
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?
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.
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
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