|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Sources of page dirtying for HVM domains in Xen 3.2.x
Thanks Tim. This is becoming a bit more involved than I had initially
hoped--not as simple as CoW on a normal OS kernel :).
> For emulated writes to pagetables, the _sh_propagate() call doesn't make
> a writeable mapping (since the target is a pagetable) so it shouldn't
> call page_dirty().
Not quite sure what you mean by not "making a writeable mapping".
Could you explain? When I look at the code for sh_page_fault(), the
_sh_propagate() would be called before the code starts on the emulate
path; If log-dirty mode is on, wouldn't this trigger the
paging_mark_dirty() that occurs when ft == WRITE for the faulting gva?
What I then see is that in the emulation code (in the
emulate_unmap_page()), a page_dirty() is called again for an mfn (or
two) given in the cpu context. Maybe I don't understand what the
emulate write actually does?
> The log-dirty mode seems like a good candidate, but there are a
> number of places where log-dirty marks a page dirty _after_ writing to
> it; in particular qemu DMA. It might be possible to reshuffle so that
> that the marking happens before the write in all cases, but it needs
> some thought about race conditions like:
Yeah, that's part of the fear I have. Ideally, I wanted a single
point where I could trigger a fault on any attempted write, such as
making all the guest's memory pages read only and having CR0.WP turned
on. But it seems like there are a bunch of other things that Xen does
that modifies/dirties pages without causing a protection fault.
> Another option is to hook everything from the p2m table lookup
> operation, though you'd then need to plumb through a "read/write"
> argument to lookups so you don't trigger on reads too.
p2m table lookup? Sorry, I'm really realizing I probably don't
understand what's really going on fully. Isn't that p2m lookup only
done when the shadows are created? Could that really be a
intervention point for any writes?
Thanks for all your help Tim!
Mike
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|