[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Fedora 17 Dom-U booting issue

Adding xen-devel and the relevant maintainers.

On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> Hi Folks,
> I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> to boot fine and getting the below error on console,
> --------
> Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> Loading Fedora (3.6.1-1.fc17.x86_64)
> Loading initial ramdisk ...
> [   0.000000] Cannot get hvm parameter 18: -22!


I'm not sure it's related but commit 5842f5768599 "xen/hvc: Check
HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness." looks a bit dogy to me,
in particular:
+       /*
+        * If the toolstack (or the hypervisor) hasn't set these values, the
+        * default value is 0. Even though mfn = 0 and evtchn = 0 are
+        * theoretically correct values, in practice they never are and they
+        * mean that a legacy toolstack hasn't initialized the pv console correc
+        */

The only reason 0 isn't used is pure coincidence because libxl (and
presumably xend) do:
    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 

so the store happens to become port 0 and the console port 1, but I
think relying on this never changing is pretty fragile.

If this is being relied on then I suggest that a patch to the hypervisor
to reject port 0 as a console port would be wise in case someone decides
to refactor this code and inadvertently changes the order of the
allocation. At the same time perhaps making the default be some invalid
port number on the hypervisor side would be a good idea for future

> ---------
> The dom0 is running with Xen 3.4.3.
> Any help much appreciated!

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.