[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged virtual machines
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |