On (Thu) 22 Sep 2011 [13:20:07], Christian Borntraeger wrote:
> On 22/09/11 12:08, Amit Shah wrote:
> >> + /* If there was an early virtio console, assume that there are no
> >> + * other consoles. We need to wait until the hvc_alloc matches the
> >> + * hvc_instantiate, otherwise tty_open will complain, resulting in
> >> + * a "Warning: unable to open an initial console" boot failure.
> >> + * Without multiport this is done in add_port above. With multiport
> >> + * this might take some host<->guest communication - thus we have to
> >> + * wait. */
> >
> > This file uses comments in the form
> > /*
> > * ...
> > */
>
> Will fix.
>
> >
> >> + if (multiport && early)
> >> + wait_for_completion(&port_added);
> >> +
> >
> > Can there be a problem to not timeout this wait? Maybe it's not a
> > real problem; just thinking out aloud.
>
> I had the same thoughts. I then asked myself, how big the timeout has to be -
> and
> the answer was it really depends on the host load. So we can certainly use
> wait_for_completion_timeout(&port_added, HZ*<x>);
> which will work in 99.9% of all cases. It might still cause spurious boot
> failures,
> if for some reasons it takes too long.
Yes; there's no deterministic way.
> So the big question is, is there a case were virtio is used as an early
> console
> but virtio_console does not register a console during probe. Ideas?
Currently only ppc and s390 use early_console. And since you're
sending this patch now, I guess you've started using multiport in the
host recently. So it's really upto you to decide :-) I think this is
benign as of now.
Amit
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
