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

[Malcolm Crossley <malcolm.crossley@xxxxxxxxxx>]

On 10/03/16 20:48, Tamas K Lengyel wrote:
> 
> 
> On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap <george.dunlap@xxxxxxxxxx
> <mailto: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 
> <mailto: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.

I can't see any other usages of p2m_access_t without enum values either.

Malcolm



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