[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/3] x86: don't maintain compat M2P when !PV32
On 07.08.2020 12:12, Jan Beulich wrote: > On 06.08.2020 21:16, Andrew Cooper wrote: >> On 06/08/2020 10:28, Jan Beulich wrote: >>> Note that opt_pv32's declaration / #define need to be moved due to other >>> header dependencies; in particular can asm-x86/mm.h not include >>> asm-x86/pv/domain.h. >>> >>> While touching their definitions anyway, also adjust section placement >>> of m2p_compat_vstart and compat_idle_pg_table_l2. Similarly, while >>> putting init_xen_pae_l2_slots() inside #ifdef, also move it to a PV-only >>> source file. >>> >>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >> >> So interestingly, this is done out of the order which I was expecting to >> do things. Its not a problem, but I'd like to double check that we >> aren't creating future problems. > > I've thought about this for quite some time, and didn't see how it > would cause problems. And the change here clearly is the more low > hanging fruit. > >> The goal of this suggestion was actually for PV-Shim, to have only the >> regular or compat M2P, as they're fairly large structures and adversely >> affect VM density. > > But in particular for {INVALID,SHARED}_M2P_ENTRY there'll need to > be some, well, hacks if we want to use the compat one as a > replacement for the native one. This will require some more careful > thought (at least on my side). Having looked into this some more, I'm still unsure whether this is a viable thing to do. While we do have VALID_M2P() (checking the top bit of the entry), its use is rather limited. The most noteworthy place (but by far not the only one) where it's _not_ used is perhaps the handling of MMU_MACHPHYS_UPDATE. Additionally there's no similar checking of bit 31 for 32-bit guests at all. Hence at a first approximation both (uint32_t)INVALID_P2M_ENTRY and (uint32_t)SHARED_P2M_ENTRY are to be considered valid GFNs (albeit they wouldn't have been on a 32-bit Xen, but those were similarly lacking enforcement of this restriction anyway). Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |