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