[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.