At 08:40 -0700 on 03 Oct (1223023218), Mike Sun wrote:
> 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?
Yes, it will. Sorry, I had misremembered the code. I though that the
check (just below that) for this being a pagetable would cause the
mark-dirty not to happen, but I was wrong. I think that would be the
correct behaviour, since this mark-dirty is intended to mean "we have
given the guest direct write access to the page".
> 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?
That mark is to say that we've actually changed the contents of the
page. As it happens, you're correct and only one of the two is needed,
but I think it's good practise to mark the page at the time that xen
actually changes it.
> > 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.
Yep. :( At least most of the places in Xen are easy to find by the
calls to paging_mark_dirty(). And probably for most of them it will be
safe to do the marking before the write, since both of them will happen
before returning from Xen, and the bitmap operations are done with the
domain paused.
If your guest has PV drivers, then it might grant access to other
guests, who don't have to be so picky (their writes are picked up by
calling paging_mark_dirty() when the grant is destroyed). But
special-casing the grant tables should be OK.
And in Xen 3.2 DMA accesses from qemu were completely un-marked (which I
believe has either been fixed in xen-unstable or else there's a patch on
the way). Since qemu already has a wrapper function for its writes to
guest RAM it's easy to add a hypercall at the top of it.
Here's a harder question: What do you do if you hit a copy-on-write
fault and don't have any memory available to copy into? Or are you
planning to allocate a full domain of memory up-front for VM fork?
> 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?
It's also done when more or less anything else wants to access the
guest's memory. But I'm not sure it's any better than your current
approach (and actually there have been more changes to that areas since
3.2 than to log-dirty so it might be storing up pain in the future.)
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