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] Re: [PATCH] qemu-xen: Fix PV segfault

Ian Jackson schrieb:
> John Levon writes ("Re: [Xen-devel] Re: [PATCH] qemu-xen: Fix PV segfault"):
>> Oh, if it's just the PV bits, then it's probably part of the work to
>> drop the need for the Xen daemons altogether and move to a domain ==
>> running qemu implementation as Dan Berrange presented at the summit some
>> time ago.
> 
> I wasn't around for that summit presentation but for the record my
> personal view is that this is a bad idea.  dom0 host processes are
> much more fragile (much more vulnerable to failures induced both
> inside that process and from the rest of dom0) than a Xen domain.
> Ideally the proper functioning of guests would not depend on that kind
> of complexity.
> 
> Indeed currently even if dom0 entirely stops running user code for
> some reason, it is still possible to have PV guests keep running and
> cleanly shut themselves down (although management functions like
> migration, device hotplug, and requesting shutdown from dom0 are of
> course unavailable).
> 
> So guests should continue to be regarded as owned and parented by the
> hypervisor, not by some dom0 userland process.

They would still be owned by the hypervisor (anything else wouldn't be
Xen any more). It's just the Dom0 tools which could be accumulated in
qemu. That is, you wouldn't use xm create and xend and all that stuff,
but start qemu to get the domain set up and running.

I'm not completely sure if I really got the idea, but that's what I
understand.

Kevin

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