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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.03.14 at 19:40, <aravindp@xxxxxxxxx> 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).
>>
>>Whether (and if so how) to adjust xc_hvm_track_dirty_vram(),
>>xc_hvm_modified_memory(), xc_hvm_set_mem_type(), and
>>xc_hvm_set_mem_access() to reflect the 32-bit restriction on "nr" is
>>unclear: If the APIs need to remain stable, all four functions should 
> probably
>>check that there was no truncation. Preferably their parameters would be
>>changed to uint32_t or unsigned int, though.
> 
> I am adding mem_access support to PV domains. As part of that I am adding a 
> more generic xc_set/get_mem_access() APIs and deprecating the 
> xc_hvm_set/get_mem_access() APIs. At the moment I have the 
> xc_hvm_set/get_mem_access() APIs calling the newer ones. I am also folding 
> the mem_access ops under XENMEM_access_op and deprecating the HVMOPs. Maybe 
> as part of this I can change the nr parameter to uint32_t. Please advice and 
> I will make it part of the patch which should be ready in a couple of weeks.

You'll need to think about how to handle preemption anyway there,
and I would guess that you'd want to go with the same method used
here (due to the alternatives being more complicated). Hence you'll
need to introduce an upper bound on the number of pages anyway,
and one way that could be done would be by limiting the respective
interface structure field to 32 bits.

Jan


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