[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Consult some concepts about shadow paging mechanism


  • To: Gianluca Guida <glguida@xxxxxxxxx>
  • From: Jui-Hao Chiang <windtracekimo@xxxxxxxxx>
  • Date: Fri, 24 Apr 2009 00:23:23 -0400
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 23 Apr 2009 21:23:47 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HFxDkXOUJO2HaMQHPhVuyhYK2nWWFm/2XJCz6K6sQOk1Wb0lSJQumYlIfzm92q7Edg NUldqjlFJcJsDj/V7d5ShV9Q8J4M1DvkBSHmZliwTbDjPfMmzN61Ldzg7p0QsaZ7q3ES w+GB6RAG6FWe7IOrwZZ+7lzQUf0PAIBY7X8JQ=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Thanks, Gianluca:

I have some additional doubts as the following:
(1) For normal data page, in order to propagate the Dirty or Access
bit from SPTE to GPTE, the hypervisor needs to set Read-Only in the
SPTE. When the write page fault of this data page comes, hypervisor
can propagate the Dirty or Access bit to GPTE and set it to R/W. My
question is when does the hypervisor make it Read-Only again? Is there
any place inside the source code you can point out?

(2) How many shadow pages are maintained for each guest domain? If the
hypervisor keep only one shadow page table for the active process in
each guest domain, then during the guest context-switch, it might
erase the entire shadow page table, and re-construct it for the new
process, which seems a lot of overhead. I have checked the
sh_update_cr3(), but not sure of the detailed mechanism.

Thanks for your patience,
Jui-Hao


On Thu, Apr 23, 2009 at 11:46 AM, Gianluca Guida <glguida@xxxxxxxxx> wrote:
> Hi,
>
> On Wed, Apr 22, 2009 at 3:14 PM, Jui-Hao Chiang <windtracekimo@xxxxxxxxx> 
> wrote:
>> Assume we have the following terms
>> GPT: guest page table
>> SPT: shadow page table
>>
>> (Question a) When guest OS is running, is it always using SPT for
>> address translation?
>
> Yes, the guest always run directly on shadow pagetables.
>
>> If it is the case, how does guest OS refer and
>> modify its own GPT content?
>
> The guest will map its own pagetables (GPT) in the guest page tables
> itself. It will access them trasparently, and the shadow code will
> kick in doing the various magic to keep guest and shadows in sync.
>
>> It seems that there is a page table entry
>> in SPT for the GPT page.
>
> Yes, exactly.
>
>
>> (Question b) The hypervisor is performing synchronization between GPT
>> and SPT. When guest OS increase access to some page (call it
>> Normal_Page) by marking 'read only' GPT entries as 'read write',
>> what's the read-write mode of the GPT page in the beginning?
>> (1) If it's read-only in SPT, the this modification will trigger a
>> page fault for GPT page, so that hypervisor can synchronize those two
>> tables at this moment.
>
> Yes, that's exactly what happens in general. GPT pages are always
> mapped read only in shadows. Well, there's an exception at the moment:
> level 1 pagetables (page tables, as opposed to page directories, etc.)
> can be mapped writable, but this is a much longer discussion.
>
>
> Gianluca
>
> --
> It was a type of people I did not know, I found them very strange and
> they did not inspire confidence at all. Later I learned that I had been
> introduced to electronic engineers.
>                                                  E. W. Dijkstra
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.