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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Fri, Mar 11, 2016 at 8:53 AM, Malcolm Crossley
<malcolm.crossley@xxxxxxxxxx> wrote:
> 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.

Great, thanks:

Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

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