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

Re: [Xen-devel] Sources of page dirtying for HVM domains in Xen 3.2.x

  • To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
  • From: "Mike Sun" <msun@xxxxxxxxxx>
  • Date: Fri, 3 Oct 2008 08:40:18 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 03 Oct 2008 08:41:00 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=JIGqsjpKAV4GKPb+Io6Sw/+IPl+q5Aj82fK1RWQ7pEXv/QpssfzcUWsrygi+dBwLp3 IF6FHVhTllYxMABa4wgZ7hi+PUoArc1jovpntjkdXfXsw7bjfvmirKsdfd/PbxazE8hc xf2YHOd57OPZXCi3rl/tiV7m12ZHZ5O1zu/d8=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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!

Xen-devel mailing list



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