Re: [PATCH 1/1] i386 Encapsulate copying of pgd entries

[Zachary Amsden <zach@vmware.com>]

Pavel Machek wrote:

>Hi!
>
>  
>
>>This helps complete the encapsulation of updates to page tables (or pages
>>about to become page tables) into accessor functions rather than using
>>memcpy() to duplicate them.  This is both generally good for consistency
>>and also necessary for running in a hypervisor which requires explicit
>>updates to page table entries.
>>    
>>
>
>Hmm, I'm not sure if this kind of hypervisor can reasonably work with swsusp;
>swsusp is just copying memory, it does not know which part of memory are page tables.
>				Pavel
>  
>

There are good and bad things about this.  Everything with swap suspend 
should be fine for the suspend portion of things; it is when resuming 
back up that one must take care to call the hypervisor functions for 
reloading control registers and updating page tables.

I'm not sure that Xen can cope with that scenario - it would have to go 
into shadowed mode first, then after resume, go back from shadow mode 
into direct page table mode.  Otherwise, as you say, making swap suspend 
aware of what pages are page tables would be quite difficult and 
needlessly complicate the code.

Since most hypervisors will likely provide a suspend/resume mechanism 
that is external to the guest, most of this is a moot point anyways.  
But I wondered if you thought the pgd_clone() accessor would make this 
cleaner or if it is just most confusing:

#ifdef CONFIG_SOFTWARE_SUSPEND
/*
 * Swap suspend & friends need this for resume because things like the 
intel-agp
 * driver might have split up a kernel 4MB mapping.
 */
char __nosavedata swsusp_pg_dir[PAGE_SIZE]
        __attribute__ ((aligned (PAGE_SIZE)));

static inline void save_pg_dir(void)
{
        memcpy(swsusp_pg_dir, swapper_pg_dir, PAGE_SIZE);  <--- could be 
clone_pgd_range()
}

Zach