On 10/03/16 20:48, Tamas K Lengyel wrote: > > > On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap <george.dun...@citrix.com > <mailto:george.dun...@citrix.com>> 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.cross...@citrix.com > <mailto:malcolm.cross...@citrix.com>> > > 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@lists.xen.org http://lists.xen.org/xen-devel
