On Fri, Apr 24, 2009 at 6:33 AM, priya sehgal <priyagps@xxxxxxxxxxx> wrote:
>
>> Ok that seems, but please note that at the moment shadows
>> always set the DIRTY bit (unless we're tracking a VRAM
>> address), so you might have to set the dirty bit clean when
>> propagating the shadow, which is a bit too intrusive
>> perhaps. But yes, that would work.
>>
>
> I see one problem, which we might introduce by making the SPTE entries of
> all the pages in the group RW, but not marking their corresponding GPTE entry
> as DIRTY -- if the Guest writes to a page (marked as RW in SPTE) and makes it
> dirty, there is no way Hypervisor will know about it, and so it cannot mark
> GPTE's entry as DIRTY. This might lead to inconsistency between the shadow
> and guest page tables. Also, the OS running inside the guest will not see
> correct picture about the dirty pages, thereby not flushing the dirty pages.
Yes, that's a common problem when you "prefetch" write accesses in
shadows. You can just set dirty (as in log_dirty) pages that have
guest's ptes dirty. Of course you must be very careful in case you
have an entry coming from a splintered L1 in shadow (that is the guest
sets the PSE bit) because in that case you have to check at the guest
L2 (guest PDE level) the dirty bit.
Anyway, I think it's kind of clear that I was trying to convince you
to the idea of getting rid of shadow_blow_tables at each log dirty
cleanup, since this feature you have in mind is both intrusive and
very specific, and perhaps not worth it. Of course, you might prove my
non-proved assumption wrong. :)
Thanks,
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
|