Date:	Wed, 02 Apr 2008 19:01:55 +0200
From:	Markus Armbruster <armbru@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org, mingo@...hat.com
Subject: Re: xen: Make hvc0 the preferred console in domU

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Markus Armbruster wrote:
>> This turns out to a thornier problem than one might think.
>>
>> Consoles tty, hvc and ttyS register in this order.
>>
>> Unless the kernel command line dictates otherwise, the first one to
>> register becomes the preferred console (the one behind /dev/console).
>> This is tty.  Except we patched things so that hvc wins over tty in
>> domU.  That's what we want there; tty is the dummy console there.
>>
>> Enter PV framebuffer.  It turns tty into a useful console, which we
>> want to use.  But the PVFB is created only if it's enabled for this
>> domain, and we learn that from xenstore.
>>
>> Problem: when tty registers, we can't yet know whether the PVFB is
>> enabled.  By the time we can know, the console setup game is over.
>>   
>
> Why's that?  Is it because xenbus setup is too late?  Could we do an
> earlier query?

Yes, xs_init() runs after consoles register.  I don't know whether
that could be changed.

>> The non-pvops PVFB has the same problem.  Jeremy Katz solved it there
>> with a fairly gross hack: right after the Xen console is up, at the
>> end of xencons_init(), we forcefully make the Xen console the
>> preferred console if the PVFB is disabled:
>>
>>         /* Check about framebuffer messing up the console */
>>         if (!is_initial_xendomain() &&
>> 	    !xenbus_exists(XBT_NIL, "device", "vfb")) {
>> 		/* FIXME: this is ugly */
>> 		unregister_console(&kcons_info);
>> 		kcons_info.flags |= CON_CONSDEV;
>> 		register_console(&kcons_info);
>> 	}
>>
>> Aside: we tried to get that into linux-2.6.18-xen.hg a couple of times
>> before we gave up.  If you use that tree unmodified, you simply get no
>> working console when you diable the PVFB.
>>
>> I append the straight pvops port of this hack.
>>
>> Instead of putting hvc_force_consdev() into hvc_console.c, we could
>> also have a force_console() in kernel/printk.c, like this:
>>
>> void
>> force_console(char *name, int index)
>> {
>> 	struct console *c, *cc;
>>
>> 	acquire_console_sem();
>> 	for (c = console_drivers; c->next; c = c->next) {
>> 		cc = c->next;
>> 		if (!strcmp(cc->name, name) && cc->index == index) {
>> 			c->next = c->next->next;
>> 			cc->next = console_drivers;
>> 			console_drivers->flags &= ~CON_CONSDEV;
>> 			console_drivers = cc;
>> 			cc->flags |= CON_CONSDEV;
>> 			break;
>> 		}
>> 	}
>> 	release_console_sem();
>> }
>>
>> If one of these two hacks is acceptable, I'll prepare a proper patch.
>> If not, I'd appreciate advice on how to solve this better.
>>   
>
> The console system supports multiple concurrent consoles, doesn't it?
> With the limitation that only one of them can be the source of
> keyboard input.  Can we support that, so that even if the user gets
> the config wrong they can still see some output (and we can printk a
> helpful message so they can work out how to get it working).  Ideally
> we could take input from all the consoles too, so there's no reason to
> exclusively choose one over any other...

The kernel routes printk output to all enabled console drivers, but
/dev/console can be connected to only one of them.  That's the
preferred console.

Getting the preferred console right is important for user space.  For
instance, if /dev/console is hvc, anaconda does a text install.  Not
good when the user is looking at a fully functional PVFB, wondering
why the installer doesn't come up.

My hack makes sure that both tty (PVFB if enabled, else dummy) and hvc
are enabled by default.  That's the easy part.  The hackish part makes
sure that the right one ends up as the preferred console.

> But aside from that, it doesn't seem like our problem is particularly
> strange.  One can imagine many circumstances in which we come up using
> whatever's currently available as a console, but then a better console
> device appears during device probing.   In other words, this kind of
> console device switching seems like something that the console
> subsystem should support.

That could be an argument for preferring the force_console() solution
over the hvc_force_consdev() solution.

> But in the meantime, pragmatics should win, and I don't have any
> strong objections to this patch.
>
>    J

Thanks!  I'll try to post a proper patch tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists