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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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!

HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

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->store_domid);
    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
state->console_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
proofing.


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





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel