Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:

On 08/03/16 15:30, Malcolm Crossley 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.
>
> Signed-off-by: Malcolm Crossley <malcolm.crossley@xxxxxxxxxx>

Looks good; but following up Jan's point, could you do a brief survey of
the places where the p2m_access values are used, and confirm that none
of them now implicitly assume that p2m_access_rwx is zero?

(Or Tamas, can you say that you're reasonably certain nothing has now
come to depend on the value of p2m_access_rwx being zero?)

Yes, from my perspective it's all fine as checks of p2m_access values are done with the enum names and not the values directly.

Tamas

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