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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120920125730.GE2117@linaro.org>
Date:	Thu, 20 Sep 2012 13:57:30 +0100
From:	Dave Martin <dave.martin@...aro.org>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>
Cc:	David Vrabel <david.vrabel@...rix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Ian Campbell <Ian.Campbell@...rix.com>,
	Pawel Moll <pawel.moll@....com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/