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 2:34 PM, Jan Beulich wrote:
>>>> On 16.02.16 at 12:20, <czuzu@bitdefender.com> wrote:
>> 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?
> No, that's all correct. It's just that right now no
> XEN_DOMCTL_MONITOR_EVENT_* has value 31, and hence
> there's only a very minor latent issue here (someone blindly
> copying the existing 1 << ... without adding the necessary U at
> that point; one might hope the compiler would then point this out
> though).
>
> Jan
>

Ah, I see. Did a fast test earlier w/ GCC 5.1, unfortunately I think the 
compiler doesn't
issue any warning in this situation, would have preferred a heads-up too 
(couldn't even force it to do so).
(it would be nice if Xen shipped w/ a gravitational-waves detector 
though....)

Corneliu.

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