[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Some questions about x86/xen pmap
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.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |