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

["Mike Sun" <msun@xxxxxxxxxx>]

> 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