[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.