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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
