Re: [Xen-devel] [PATCH 2/2] x86/HVM: fix preemption handling in do_hvm_op()

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-03-26 at 14:42 +0000, George Dunlap wrote:
> On Tue, Mar 25, 2014 at 4:03 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > Just like previously done for some mem-op hypercalls, undo preemption
> > using the interface structures (altering it in ways the caller may not
> > expect) and replace it by storing the continuation point in the high
> > bits of sub-operation argument.
> >
> > This also changes the "nr" fields of struct xen_hvm_track_dirty_vram
> > (operation already limited to 1Gb worth of pages) and struct
> > xen_hvm_modified_memory to be only 32 bits wide, consistent with those
> > of struct xen_set_mem{type,access}. If that's not acceptable for some
> > reason, we'd need to shrink the HVMOP_op_bits (while still enforcing
> > the [then higher] limit resulting from the need to be able to encode
> > the continuation).
> 
> So these calls are made directly by qemu -- and I thought that we were
> trying to have a stable ABI with qemu so that people could pop in any
> (recent) version of qemu and have it Just Work.

I don't think we've said that, we've always been quite explicit that
libxc is an unstable API.

AFAIK qemu contains a compat shim which allows it to compile against
multiple libxc versions. If libxc is to change again then qemu might
need updating.

To some extent we've resisted gratuitous cleanups etc to libxc if they
would impact e.g. qemu, but if a change is required then we should go
ahead with it (NB: I've not looked into the actual proposal in this
thread to know which it is).

Maybe we should make stronger guarantees about interfaces used by device
models but that process would have to start with an enumeration of
exactly what those interfaces are. *If* we were to then go ahead with
that then I would advocate moving those interfaces into a library other
than libxc so it is clear what is what.

Ian.


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