On Tue, Aug 26, 2008 at 11:31:47AM +0100, Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 05/13] xen: groundwork for xen
> > +/*
> > + * Figure the environment we are running in.
> > + * Returns true when xen is present, false otherwise.
> > + * Also checks whenever the domain specified via -domid
> > + * exists (so we can attach) or whenever it must be created.
> > + */
> I don't think this is the right approach. The intent appears to be
> that if you run a particular qemu rune, it will do a completely
> different thing when running under Xen.
This particular check is doing two different jobs in one go. I think
they need to be dealt with separately.
- Check to see if running on Xen or not. This is a similar idea to
to pv_ops where we have one kernel binary, and probe at runtime
to decide whether to run in KVM, Xen, VMWare or bare metal mode.
This is important to QEMU too. Merging the source trees for all
projects using QEMU is just the first step. A single binary for
all is the holy grail, though may not be practical for Mini-OS
- Check to see whether the guest domain is pre-created (ie attaching
to an existing VM created by XenD), or whether QEMU is constructing
the domain from scratch.
Probing for whether a domain ID exists in the hypervisor, and if not, then
creating it, has a nasty race condition, where XenD could launch QEMU
and then (for whatever reason) decide to kill off the domain, but QEMU
then re-creates it during its startup procedure.
If we want QEMU to explicitly created Xen domains from scratch, rather than
attaching to an existing one, then there needs to be a way to reliably
specify this behaviour via the CLI.
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Xen-devel mailing list