Re: [Xen-devel] [Minios-devel] [PATCH v4 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-11-19 at 16:20 +0000, Stefano Stabellini wrote:
>Â
> > I think it would be reasonable to add a new library (say, 
> > libxendevicemodel, for arguments sake) with a stable ABI and to move all of 
> > the xc_hvm_* above into it. They are not used for anything else and are 
> > based on HVMOP which is a stable interface (AFAIK).
> > 
> > Within qemu xc_domain_add_to_physmap and xc_domain_pin_memory_cacheattr are
> > used in tandem solely to populate VRAM with WB memory and to remove again.
> > 
> > xc_domain_populate_physmap_exact is used only to populate RAM and
> > xc_domain_shutdown is used on shutdown.
> > 
> > I think having three or four functions in libxendevicemodel which offer
> > these exact facilities while retaining the underlying (possibly more
> > flexible) functionality in libxenctrl for other users (dombuilder, other in
> > tree tools) would be tolerable.
> > 
> > Three or four functions depends on whether the uses of
> > xc_domain_add_to_physmap+xc_domain_pin_memory_cacheattr and
> > xc_domain_populate_physmap_exact can be satisfied with a single API or not.
> > I don't know that yet.
> > 
> > The main question would then be whether libxendevicemodel should wrap
> > libxenctrl in a stable layer or whether it should actually duplicate the
> > functionality in the thin wrappers.
> 
> Couldn't we rename the existing libxc calls and make them stable?

This was what I was trying to get at a couple of paras earlier.

The current functions are far more flexible than what QEMU requires (and
that flexibility is used by other in tree components).

I'm not sure we can (or want to) declare the full breadth of the
functionality of e.g. xc_domain_add_to_physmap and
xc_domain_pin_memory_cacheattr as being stable.

It would be much easier to arrive at and agree on a suitable stable
interface for the more limited specific functionality which is actually
used by (or useful to) device models. (In the case
ofÂxc_domain_add_to_physmap and xc_domain_pin_memory_cacheattr that more
limited functionality is something like a function to populate VRAM in the
guest).

If we were to just say "xc_domain_add_to_physmap and
xc_domain_pin_memory_cacheattr are now stable" then having them in a
libxendevicemodel would be incorrect, since they are not in any way
specific to device models.

My question about wrappers vs duplicating was assuming we wanted
libxendevicemodel to provide some specific stable functionality like
"populate the VRAM" and in that case how to implement it, either by calling
xc_domain_add_to_physmap and xc_domain_pin_memory_cacheattr from libxenctrl
or by calling the domctls directly from libxendevicemodel.

> ÂÂKeep
> in mind that we already have stable wrappers in QEMU in
> include/hw/xen/xen_common.h. I don't think we need two layers of
> wrappers :-)

Indeed, but part of the purpose of Xen providing stable libraries is that
external components/users should not need wrappers.

IOW IMHO the current wrappers in QEMU should, as part of this exercise in
providing stable interfaces, be deprecated and remain only to retain
compatibility with older versions of Xen which lacked the stable
interfaces, with a view to them eventually being removed as support for
those older Xen's is removed from QEMU.

Ian.

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