Re: [PATCH v4 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

[Corneliu ZUZU <czuzu@bitdefender.com>]

On 2/16/2016 12:45 PM, Jan Beulich wrote:
>>>> On 16.02.16 at 09:13, <czuzu@bitdefender.com> wrote:
>> On 2/16/2016 9:08 AM, Corneliu ZUZU wrote:
>>> This patch moves monitor_domctl to common-side.
>>> Purpose: move what's common to common, prepare for implementation
>>> of such vm-events on ARM.
>>>
>>> * move get_capabilities to arch-side => arch_monitor_get_capabilities.
>>> * add arch-side monitor op handling function => arch_monitor_domctl_op.
>>>     e.g. X86-side handles XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP op
>>> * add arch-side monitor event handling function => arch_monitor_domctl_event.
>>>     e.g. X86-side handles XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR event
>> enable/disable
>>> * remove status_check
>>>
>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>>>
>>> ---
>>> Changed since v3:
>>>     * monitor_domctl @ common/monitor.c:
>>>       - remove unused requested_status
>>>       - sanity check mop->event range to avoid left-shift undefined behavior
>> Due to left-shift undefined behavior situations, shouldn't I also:
>>
>> * in X86 arch_monitor_get_capabilities: replace '1 <<' w/ '1U <<'
> There's no undefinedness there, since the right side operands of
> << are all constant. Using 1U here would be okay, but is not
> strictly needed.

I reasoned based on this ISO C99 quote:
[for an E1 << E2 operation, ]
"If E1 has a signed type and nonnegative value, and E1 × 2^E2 is 
representable in the result type, then that is the resulting value; 
otherwise, the behavior is undefined."

I inferred that this means that code such as '(1 << 31)' would render 
undefined behavior, since (1 x 2^31) is not representable on 'int'.
The standard doesn't seem to mention different behavior if the operands 
are constants.
This would render undefined behavior if bit 31 of capabilities would be 
used @ some point, i.e. if one day someone would e.g. unknowingly:
     #define XEN_DOMCTL_MONITOR_EVENT_GRAVITATIONAL_WAVE 31
Have I misinterpreted the 'representable in the result type' part?

>
>> * in X86 arch_monitor_domctl_event,
>> XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG case
>> add a sanity check of mop->u.mov_to_cr.index before:
>>       unsigned int ctrlreg_bitmask =
>> monitor_ctrlreg_bitmask(mop->u.mov_to_cr.index);
>> , which basically translates to:
>>       unsigned int ctrlreg_bitmask = (1U << mop->u.mov_to_cr.index);
>>
>> ? (especially since mop->u.mov_to_cr.index is set by the caller).
> Yes, there a range check would be needed, but preferably as a
> separate patch (as this has nothing to do with the code motion
> you perform here).
>
> Jan
>
>

Great, I'll do these changes in a separate patch then.
Let me know if you have any other comments on this.

Thanks,
Corneliu.

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