Hi,
At 09:46 +0100 on 26 May (1243331218), Wu Bingzheng wrote:
> Shadow-1. Its method of propagating changes from guest pagetables
> to the shadow pagetables was as follows:
>
> 1. Remove write access to any guest pagetable.
> 2. When a guest attempts to write to the guest pagetable, mark it
> out-of-sync, add the page to the out-of-sync list and give write
> permission.
> 3. On the next page fault or cr3 write, take each page from the
> out-of-sync list and:
> - resync the page: look for changes to the guest pagetable,
> propagate those entries into the shadow pagetable
> - remove write permission, and clear the out-of-sync bit.
>
> My question is that, dose step 2 trap into Xen hypervisor?
Yes, of course. It's done in the #PF handler.
> 2.
> I think there are 2 kinds of page fault. 1) normal page fault in guest,
> which should be handled by guest; 2) invoked by guest updating the page
> table, which should be handled by Xen.
>
> So, if there's a page-miss fault in guest, how many times it will trap into
> Xen?
> First, page miss, trap into Xen. Xen finds out it's the 1st kind fault,
> then it go back to guest to handle it
> Then, in guest, when it updates the page table to fix the page fault,
> it will invoke the 2nd kind fault, which will trap into Xen again.
>
> Am I right?
Yes; and in some circumstances there can be more than two faults
(e.g. if the guest's new entry hasn't got the Accessed bit set).
> 3.
> For the user space part, are the attribute bits of the entries
> in Guest page table and Shadow page table the same?
No; the only guarantee is that the shadow entry won't contain more
access rights than the guest entry. For PTEs that map MMIO space we try
to do the right thing with the caching attributes too.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home