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

[Dave Martin]

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