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 11:34:30 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 03 Oct 2008 11:34:55 -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=cov3Ifyq5nQp3Nysew1ifuREUSV0NmxOBdmqaJNmCwg=; b=NhKBjySmfLks8uoXeWUj/ADP8+Wh1gL4Aa3bs2IkkVgJersu2Zcwgq9Y7vhZ2aq0fW Cld2sUw1m2iPj+PW41iL30Y5V2zEkqTxk7aE/LcSidNFog26l/nh6pirTAygms6lJ5Bf PbXk3KiZJXTXl1zx/ezZaxz6PBSUSnnQAJ0us=
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=cpvUl3kqkTQd5HkhCNtyIdpQpdpvNAvHSm3mkJptk13kcR/EuvjYsdo4MPcxklsDze qw/ZCa2lw7ZWWpsCDmlTwQeb2Yr6mserEoxk6UhOcsWNDL95dzM1SeZ77GqFnM5J2JoL x3G1dV1hYY1VSriS7LTU2tOTkWQFgoCxPz1BU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081003155741.GC3780@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> <e4e579070810030840r4bd0d58bobe6cea2e07a9e777@xxxxxxxxxxxxxx> <20081003155741.GC3780@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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.

Meaning that they're not marked dirty at all?  My understanding was
that qemu-dm marked them dirty and that this dirty bitmap for DMA
writes could be accessed.  It seems like that's what the live
migration code uses to check for dirtied pages from qemu dma
(init_qemu_maps(), qemu_flip_buffer()).  I can see a need for a
hypercall when qemu does the dirty marking in its code.  I may just
save myself some trouble and pre-copy those memory pages instead of
letting them be CoW.

> 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?

I'm actually not aiming for a VM fork, it's for a checkpoint.  Yup,
I'm having dom0 allocate a large enough buffer which I pass to the
hypervisor.  It's a crude approach for now, but I'll optimze it later
with some sort of circular buffer which the checkpoint agent in dom0
can ensure there's always available buffer space.

You've been tremendously helpful in clarifying things for me.  Thanks
again for the help!
Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel