On 06.05.2024 17:33, Roger Pau Monné wrote: > On Mon, May 06, 2024 at 12:07:33PM +0200, Jan Beulich wrote: >> On 30.04.2024 18:58, Roger Pau Monne wrote: >>> Keep track of the maximum gfn that has ever been populated into the p2m, and >>> also account for the number of foreign mappings. Such information will be >>> needed in order to remove foreign mappings during teardown for HVM guests. >> >> Is "needed" the right term? We could e.g. traverse the P2M tree (didn't look >> at patch 2 yet as to how exactly you use these two new fields there), at >> which >> point we might get away without either or both of these extra statistics, >> while at the same time also not needing to iterate over a gigantic range of >> GFNs. Going from populated page tables would roughly match "max_gfn", with >> the >> benefit of certain removals of P2M entries then also shrinking the upper >> bound. > > One note about traversing the p2m tree that I forgot to add earlier: > AFAICT we would need one implementation for EPT and one for NPT, as I > expect the different page-table format won't allow us to use the same > code against both EPT and NPT page-tables (I really need to check).
Yes, that would be pretty much unavoidable, I agree. Jan
