xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Malcolm Crossley <malcolm.crossley@citrix.com>, tamas@tklengyel.com
Cc: george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics
Date: Tue, 08 Mar 2016 08:52:17 -0700	[thread overview]
Message-ID: <56DF034102000078000DA7DB@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1457451028-3808-1-git-send-email-malcolm.crossley@citrix.com>

>>> On 08.03.16 at 16:30, <malcolm.crossley@citrix.com> wrote:
> Nested hap code assumed implict bitmask semantics of the p2m_access_t
> enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
> 
> The change to the enum ordering broke this assumption and caused functional
> problems for the nested hap code. As it may be error prone to audit and find
> all other p2m_access users assuming bitmask semantics, instead restore the
> previous enum order and make it explict that bitmask semantics are to be
> preserved for the read, write and execute access types.

Makes sense, but how certain are you that ...

> --- a/xen/include/xen/p2m-common.h
> +++ b/xen/include/xen/p2m-common.h
> @@ -15,14 +15,15 @@
>   * default.
>   */
>  typedef enum {
> -    p2m_access_rwx   = 0, /* The default access type when not used. */

... namely this has not meanwhile seen any implicit use somewhere?

Tamas, the original commit talked about this as an optimization only.
Can you confirm that there indeed was no other intention than the
one claimed in that commit's description?

Jan


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

  parent reply	other threads:[~2016-03-08 15:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 15:30 [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics Malcolm Crossley
2016-03-08 15:36 ` Andrew Cooper
2016-03-08 15:52 ` Jan Beulich [this message]
2016-03-08 15:58   ` Tamas K Lengyel
2016-03-09 16:30 ` George Dunlap
2016-03-10 20:48   ` Tamas K Lengyel
2016-03-11  8:53     ` Malcolm Crossley
2016-03-14 18:12       ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DF034102000078000DA7DB@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=malcolm.crossley@citrix.com \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).