Re: Some questions about x86/xen pmap

Manuel Bouyer wrote:
> On Thu, May 07, 2009 at 01:03:19AM +0200, Jean-Yves Migeon wrote:
>> Alright, then I am adding Manuel to the loop, as I would like to know  
>> why removing the APDP would be a problem comparing to temporarily  
>> switching pmaps. Is it a performance or a design issue, NetBSD-specific  
>> or anything else?
> 
> on xen/amd64 there is a separate pmap for kernel and user processes; the
> kernel never runs in the context of a user process pmap (and user process
> pmaps have no kernel mappings).

So avoiding the use of APDP under Xen/amd64 would need some re-thinking 
inside pmap (and more work to get it efficient).

>> [...]
>> The initial goal was to expand my locking to include protection for the  
>> pmap_map_ptes/pmap_unmap_ptes calls, so that APDP entries are cleared by  
>> pmap_unmap_ptes(). That way, I could avoid the pmap iterations during  
>> save, as I could guarantee that they all APDP entries are left unmapped.
> 
> note that mapping/unmapping APDP on each pmap_map_ptes/pmap_unmap_ptes call
> is extremely expensive on amd64. We want to avoid it as much as possible
> (i.e. change APDP only when another pmap needs to be mapped)

Due to the MMU hypercall?

If we ever support MP with Xen, modifying mappings found in APDP will 
require a full TLB flush on all CPUs that could use these mappings, 
which will also be very expensive.

I can iterate through pmaps and set the APDP entry to 0 if it is not, 
during suspension. But IMHO, we will have to revisit the APDP part 
sooner or later.

--

-- 
Jean-Yves Migeon
jeanyves.migeon <at> free.fr