[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 13:20:07 +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 11:20:18 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=YwfF/bD3jqwDMfHg3Cdqpw8U9o+kN7kYK/sVfkD6P5S+19Mt6e1m+xiW8iP4H+j2unFec798dArywJEAmYwg08LeyRSR3WIkmRnyb98mwlLY42ZybjhWCZb2JIeGHCaY6HTYkZk5/Ebt+rVG2w/GJDPKgUdSJ5mw96n48sz+4bsB63hmjQunP0zJCn5Z7O1C0UffLfyKGER+IlZI7xxQWwcxZ5BprBsm60x3SDe7nMutrj9bVW2cjUJ1vd+NvfjgpQxkeUBf/07Umn/s+BT1weRpD3eHiJ2+hMbDLiZiUjxgzvuZ2nOSt0JCWFpxXBu23B/1R5rmRtMKrN28PUGbYg==; 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 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
enable/disable
* 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:
    #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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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