Re: [Xen-devel] [PATCH v5 19/19] libxl: build a device tree for ARM guests

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 14 Nov 2013, Ian Campbell wrote:
> On Thu, 2013-11-14 at 12:17 +0000, Stefano Stabellini wrote:
> > On Thu, 14 Nov 2013, Ian Jackson wrote:
> > > Ian Campbell writes ("[PATCH v5 19/19] libxl: build a device tree for ARM 
> > > guests"):
> > > > Uses xc_dom_devicetree_mem which was just added. The call to this needs 
> > > > to be
> > > > carefully sequenced to be after xc_dom_parse_image (so we can tell 
> > > > which kind
> > > > of guest we are building, although we don't use this yet) and before
> > > > xc_dom_mem_init which tries to decide where to place the FDT in guest 
> > > > RAM.
> > > > 
> > > > Removes libxl_noarch which would only have been used by IA64 after this
> > > > change. Remove IA64 as part of this patch.
> > > > 
> > > > There is no attempt to expose this as a configuration setting for the 
> > > > user.
> > > > 
> > > > Includes a debug hook to dump the dtb to a file for inspection.
> > > 
> > > Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > > 
> > > > TODO:
> > > > - v7 CPU compat is hardcoded to cortex-a15 -- may need to define 
> > > > something more
> > > >   generic via mach-virt dt bindngs?
> > > 
> > > I don't have an opinion on this.  I hope someone else does :-).
> > 
> > Wouldn't it be better to use the same cpu compatibility string of the
> > platform? After all it's the physical cpu that we are time slicing for
> > the guest: if any quirks are present, it is likely that they are going
> > to affect the guest too.
> 
> That is one option, but would require us to get at that string somehow
> from userspace (perhaps a new domctl, or add it to physinfo etc).
> 
> I think we should punt on it for now and coordinate with other mach-virt
> users (e.g. KVM) so we all follow the same approach, whatever that might
> be.

I am fine with delaying it. "cortex-a15" is OK for now.

That said, given that cpu virtualization is done very differently on Xen
and KVM, I think that it would be reasonable to make our own decision
on this.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel