On 18.04.2020 13:43, Julien Grall wrote: > On 18/04/2020 12:01, Julien Grall wrote: >> On 26/03/2020 15:54, Jan Beulich wrote: >>> On 22.03.2020 17:14, jul...@xen.org wrote: >>>> From: Julien Grall <jgr...@amazon.com> >>>> >>>> Note that the code is now using cr3_to_mfn() to get the MFN. This is >>>> slightly different as the top 12-bits will now be masked. >>> >>> And here I agree with the change. Hence it is even more so important >>> that the patch introducing the new helper(s) first gets sorted. >>> Should there be further patches in this series with this same >>> interaction issue, I won't point it out again and may not respond at >>> all if I see no other issues. >> >> I will update the commit message explaining the reason of using cr3_to_mfn() >> and look at the other user. > > Looking at the code again, there are a few users that don't mask the top > 12-bits. I am trying to understand why this has never been an issue so far. > > Wouldn't it break when bit 63 (no flush) is set?
Yes; I guess those uses are case where bit 63 can't / won't be set. Just like the register, which doesn't store the bit, I think we avoid storing the bit set as well. But correctness of the non- masking variants can only be established by looking at every individual site. > If so, maybe I should split the work from typesafe. Maybe better indeed. Jan