From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH] xen: Restore p2m_access_t enum order to
	allow bitmask semantics
Date: Tue, 8 Mar 2016 16:58:41 +0100
Message-ID: <CABfawhnRqSLxkS3XE_BPnT8CwG4H=t6Fs8CP0Mb90e-ims+VnA@mail.gmail.com>
References: <1457451028-3808-1-git-send-email-malcolm.crossley@citrix.com>
 <56DF034102000078000DA7DB@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0787620963066639178=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <56DF034102000078000DA7DB@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Malcolm Crossley <malcolm.crossley@citrix.com>, Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

--===============0787620963066639178==
Content-Type: multipart/alternative; boundary=001a11490deec306f4052d8ba730

--001a11490deec306f4052d8ba730
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 8, 2016 at 4:52 PM, Jan Beulich <JBeulich@suse.com> wrote:

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

That's the only reason I recall as well, so from my perspective it's fine
to be reverted.

Tamas

--001a11490deec306f4052d8ba730
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Mar 8, 2016 at 4:52 PM, Jan Beulich <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt;&gt;&=
gt; On 08.03.16 at 16:30, &lt;<a href=3D"mailto:malcolm.crossley@citrix.com=
">malcolm.crossley@citrix.com</a>&gt; wrote:<br>
&gt; Nested hap code assumed implict bitmask semantics of the p2m_access_t<=
br>
&gt; enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c<br>
&gt;<br>
&gt; The change to the enum ordering broke this assumption and caused funct=
ional<br>
&gt; problems for the nested hap code. As it may be error prone to audit an=
d find<br>
&gt; all other p2m_access users assuming bitmask semantics, instead restore=
 the<br>
&gt; previous enum order and make it explict that bitmask semantics are to =
be<br>
&gt; preserved for the read, write and execute access types.<br>
<br>
</span>Makes sense, but how certain are you that ...<br>
<span class=3D""><br>
&gt; --- a/xen/include/xen/p2m-common.h<br>
&gt; +++ b/xen/include/xen/p2m-common.h<br>
&gt; @@ -15,14 +15,15 @@<br>
&gt;=C2=A0 =C2=A0* default.<br>
&gt;=C2=A0 =C2=A0*/<br>
&gt;=C2=A0 typedef enum {<br>
&gt; -=C2=A0 =C2=A0 p2m_access_rwx=C2=A0 =C2=A0=3D 0, /* The default access=
 type when not used. */<br>
<br>
</span>... namely this has not meanwhile seen any implicit use somewhere?<b=
r>
<br>
Tamas, the original commit talked about this as an optimization only.<br>
Can you confirm that there indeed was no other intention than the<br>
one claimed in that commit&#39;s description?<span class=3D"HOEnZb"><font c=
olor=3D"#888888"><br></font></span></blockquote><div><br></div><div>That&#3=
9;s the only reason I recall as well, so from my perspective it&#39;s fine =
to be reverted.<br><br></div><div>Tamas <br></div></div><br></div></div>

--001a11490deec306f4052d8ba730--


--===============0787620963066639178==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

--===============0787620963066639178==--