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

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

  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>
  • Date: Tue, 16 Feb 2016 15:03:24 +0200
  • Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 16 Feb 2016 13:03:31 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=Ye3brYcFB931Fq52ukgHCKT/XBt2anjhLO+puW1Udx1higWh8R+M3flufx0MnPdf1FAiuf6GryD2Op/lQkdBfaxfPIc3XJ2qiNy4x7omQ4KU+A924ItssSi0S1yPj6zEY1raB/r7VJtcyyPMd0sv0Y+zxe6w7vDO7Hs1Gf7su9abiCYFEs8SyeliDaAvtW8G4e7X+PX3iBktJJJJi8KjLAJmyCGbcaSTm7GwhmbmPF6MXwSDi+tC77GJGnO2OuRdE/okM4sD9cdwOB14IJDjAt1zxu5V1nkY0uWOfculCNNXVVSRrw7P9B0/5OEHqZ4bTu9edA7IkPusrmL8KWijgA==; h=Received:Received:Received:Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 2/16/2016 2:34 PM, Jan Beulich wrote:
On 16.02.16 at 12:20, <czuzu@xxxxxxxxxxxxxxx> wrote:
On 2/16/2016 12:45 PM, Jan Beulich wrote:
On 16.02.16 at 09:13, <czuzu@xxxxxxxxxxxxxxx> 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
* remove status_check

Signed-off-by: Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>

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:
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


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....)


Xen-devel mailing list



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