[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.