Keir Fraser, le Thu 31 Jul 2008 14:41:01 +0100, a écrit :
> On 31/7/08 14:27, "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx> wrote:
> >> Really too big for Xen 3.3 at this point, unfortunately.
> >
> > Ok, then I guess I should document that for stub domains to work one
> > shouldn't use the ballooner. Or a quick&dirty fix would be to add the
> > 8MB extra ballooning for PV guests as well.
>
> I think documenting the mutual incompatibility is fine for 3.3. But it's up
> to you.
The sad thing is that although it would fix HVM+ioemu-dom boot, this
quick&dirty fix of course fixes the underlying race only for one HVM
domain lagging behind. If there are several, 8MB won't be enough, etc.
I guess it's simpler to just document.
Samuel
stubdom: update documentation
stubdom/ is now compiled and installed by default
HVM+IOEMU-stubdom can not boot if dom0 has to be ballooned.
diff -r e75cd1659ea1 stubdom/README
--- a/stubdom/README Thu Jul 31 16:48:11 2008 +0100
+++ b/stubdom/README Thu Jul 31 17:24:07 2008 +0100
@@ -1,13 +1,3 @@ To compile
-To compile
-==========
-
-Just run make -j 4, that will download / patch / compile
-Then make install to install the result.
-
-Also, run make and make install in $XEN_ROOT/tools/fs-back
-
-
-
IOEMU stubdom
=============
@@ -15,6 +5,11 @@ Also, run make and make install in $XEN_
General Configuration
=====================
+
+Due to a race between the creation of the IOEMU stubdomain itself and
allocation
+of video memory for the HVM domain, you need to avoid the need for ballooning,
+by using the hypervisor dom0_mem= option for instance.
+
In your HVM config "hvmconfig",
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home