WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Sources of page dirtying for HVM domains in Xen 3.2.x
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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; bh=f8kK3L1yUtPQC8aVyyPrBihc8YAp8OV9kST5YabSuQo=; b=XuIXLJUjSXv+VxMDhecyZJKLp3PMqvu0uDLnZ8lvpXpKbJh+OFPfWqgC+iRy/Tpj30 TQFK6AYDkyipQezexhj2B6vMsqtDHQiGvr7X1TnxSV8ZuhLVYKxSbj3npYMP1O7RS8Iu Ecs83shgw8FxdYSXjBTFANF1QfcCua+uMx2Us=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081003132634.GB3780@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <e4e579070810021219g66054099of3eb45c082146e30@xxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D36F1B5FE@xxxxxxxxxxxxxxxxxxxxxx> <e4e579070810030606k49f0c281pd4aec636cec2cfb6@xxxxxxxxxxxxxx> <20081003132634.GB3780@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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