Re: [Xen-devel] [PATCH 2 of 3] x86/mm: Teach paging to page table-based p2m

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 12:12 -0700 on 14 Mar (1331727126), Andres Lagar-Cavilla wrote:
> > Hmmm.  If we need to have this, we should probably have it in the main
> > l*_from_pfn and l*_get_pfn code rather than needing to scatter it around
> > in the callers.  And we need a check in the e820 map to make sure we
> > don't ever use MFN 0xffffffff (once CPUs start supporting it).
> >
> > The alternative would be to add another type so we don't have to store
> > INVALID_MFN in p2m_ram_paging_in entries.
> 
> A lot of callers store INVALID_MFN into p2m entries (clear_mmio_p2m_entry,
> p2m_remove_page, more). For all of them, as well as for paging eviction,
> what matters is the type stored, not the mfn.
> 
> That is why retrieving the INVALID_MFN is not the problem. The ept code
> itself clips the INVALID_MFN (typecast to bitfield in ept_entry union) and
> everything seems to work fine when returning the clipped INVALID_MFN: no
> one actually cares about that mfn.
> 
> Because of that, I believe it's neither necessary to unclip on the
> extraction path, nor to take any special precautions in the e820.

Righto.  In that case, I'd be happy with just clipping MFNs and not
trying to unpack them.  But I think it should happen in the main
pte-building macros, not scattered around the p2m code.  It should just
be a matter of using PADDR_MASK in the right place.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel