Re: [Xen-devel] e820_host default value and libxl (not xl)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, May 23, 2016 at 11:59:10AM +0100, Andrew Cooper wrote:
> On 23/05/16 11:47, Wei Liu wrote:
> > On Sat, May 21, 2016 at 04:42:11AM +0200, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> According to xl.cfg(5) " This option defaults to true (1) if any PCI
> >> passthrough devices are configured and false (0) otherwise."
> >> And indeed this behaviour is implemented in xl. But not in libxl, which
> >> means other libxl based toolstacks (libvirt) will not take advantage of
> >> this directly.
> >>
> >> What would be the best approach here? Duplicate that behaviour in
> >> libvirt (currently libvirt knows nothing about this option), or move
> >> that default handling to libxl? I think the later makes more sense, but
> >> maybe there is some reason against it?
> >>
> > The latter.
> >
> > I wouldn't be surprised if the boundary between xl and libxl was
> > overlooked when implementing this flag. I've done similar things to push
> > xsm label handling logic from xl to libxl.
> 
> Please don't propage this bandaid any further than it currently is.  It
> is not appropriate for libxl to set this by default.
> 
> The reason it is currently used is because libxl/libxc doesn't know how
> to lay out a guests physmap.  This is something I am working on
> resolving for some ballooning issues we are having in XenServer.
> 

This is not entirely true. It knows a version of it, but not the final
version, which is even worse than not knowing at all. :-)

> xl can get away defaulting this on, because xl is inherently a single
> host toolstack.  However, using host_e820 is wrong for any multi-host
> setup where the VM might plausibly migrate (which includes the
> passthrough case here).
> 

Libxl has to determine the value one way or another:

1. get that value from upper layer
2. derive from internal logic

#1 takes precedence. Currently the "internal logic" is "always off".
This makes life harder for toolstack other than xl, so making that
internal logic better looks acceptable to me.

On the other hand I agree this is only bandaid to bigger issue. The
objection is also quite convincing.

So living it as is is probably the safest option.

Wei.

> ~Andrew

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