On Thu, Jun 18, 2009 at 01:05:58PM +0100, Tim Deegan wrote:
> At 13:02 +0100 on 18 Jun (1245330161), Stefano Stabellini wrote:
> > At least in theory is certainly feasible: just a matter or registering
> > another savevm function for a record called "cpu" or "vcpu", that would
> > take care of saving the guest memory using xc_domain_save.
>
> Yuck. You still need to add a bunch of metadata from xend that qemu
> doesn't know about, so you'll have to wrap the qemu output in another
> file format already.
Why? The qemu format is extensible, no? Why isn't this just an .sxp
SaveStateEntry ?
Think about it from the point of view of a save-file inspector. If they
can write the container-unwrapping code just once, and have specific
methods for Xen-particular or kvm-particular sections, that seems like a
clear win.
> just layering for its own sake. (Also, using qemu to save a PV guests
> would be pretty wierd).
Why? We already use qemu for PV guests and that's only going to become
more common. But heck, if you like, make libxc write out qemu format.
> > The qemu people are also maintaing save record compatibility now, so we
> > are safe from that perspective.
>
> Yes, but their code-defines-format model is rubbish.
Maybe now is the time to help them fix that? It's really no worse than
Xen's code-defines-format model, headers or not.
If we do need a separate container format, let's use ELF like the core
files (slightly extended as I mentioned). Just not yet another format
when there's no need.
regards
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home