Re: Some questions about x86/xen pmap

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, May 07, 2009 at 01:03:19AM +0200, Jean-Yves Migeon wrote:
>>> Just to set the background, to make Xen save/restore/migrate work 
>>> under a NetBSD domU, I have to do some slight modifications to the 
>>> pmap, for two reasons:
>>> - Xen (and xentools) do not handle alternative recursive mappings 
>>> (the APDP entries in our PD).
>>
>> I' planning to elminate these for native x86. Instead of using the alternate
>> space, native x86 will temporarily switch the pmap onto the CPU. I discussed
>> this briefly with Manuel and he suggested that there may be problems with
>> this approach for xen. My patch leaves it unchanged for xen.
>
> 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).

>[...]
> 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)

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--