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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

Would this have an impact on that?  It seems like if qemu is
dynamically linked to libxc, and libxc is matched to an appropriate
hypervisor, that shouldn't be an issue.

However, at the moment libxc exposes "nr" as uint64_t; leaving it that
way would be very misleading.

Is there a real problem with "altering [interface structures] in a way
the caller may not expect"?  Can't we just document that Xen may
change some of the structures?

 -George

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