> >> >But I believe Jarkko's version calculates the correct mask (below), incorporating all 18 offset bits into the 1G page. > >> >>> hex(262144 -1) > >> >'0x3ffff' > >> > >> We can get this simply by doing (page_per_hpage(level)-1), but as I mentioned above this is not what we need. > > >If we actually want the 4K page, I think we would want to use the 0x3ffff mask as Marc suggested to get to the specific 4K RMP entry, which I don't think the current code is trying to do. But maybe that *should* be what we should be doing. > > Ok, I agree to get to the specific 4K RMP entry. Thanks, Michael, for a thorough and complete reply! I have to admit, there was some nuance I missed in my earlier reply. But after reading through what you wrote, I agree, always going to the 4k-entry to get the "assigned" bit and also leveraging the implementation of snp_lookup_rmpentry() to lookup the size bit in the 2M-aligned entry seems like an elegant way to code this up. Assuming this suggestion becomes the consensus, we might consider a comment in the source code to capture this discussion. Otherwise, I think I'll forget all of this the next time I'm reading this code :-). Something like: /* * The guest-assigned bit is always propagated to the paddr's respective 4k RMP * entry -- regardless of the actual RMP page size. In contrast, the RMP page * size, handled in snp_lookup_rmpentry(), is indicated by the 2M-aligned RMP * entry. */
