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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 17 Oct 2012, Ian Campbell wrote:
> 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.

-22 is EINVAL, that Xen would return only if:

- the requested parameter is out of range
this is not the case, 18 < 30

- the domain is not actually an HVM domain
can you please post your VM config file?



> 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.

Even if the toolstack didn't set HVM_PARAM_CONSOLE_EVTCHN, or if the
check for 0 is not correct, the guest shouldn't get -EINVAL. I don't
think the error is related to this issue.

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