[PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Changeset 762:a070228ac76e ("add hvc compatibility mode to xencons"
added this call just for the HVC case, without giving any reason why
HVC would be special in this regard. Use the call for all cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/console/console.c
+++ b/drivers/xen/console/console.c
@@ -214,8 +214,6 @@ static int __init xen_console_init(void)
 		strcpy(kcons_info.name, "hvc");
 		if (xc_num == -1)
 			xc_num = 0;
-		if (!is_initial_xendomain())
-			add_preferred_console(kcons_info.name, xc_num, NULL);
 		break;
 
 	case XC_SERIAL:
@@ -236,6 +234,8 @@ static int __init xen_console_init(void)
 
 	wbuf = alloc_bootmem(wbuf_size);
 
+	if (!is_initial_xendomain())
+		add_preferred_console(kcons_info.name, xc_num, NULL);
 	register_console(&kcons_info);
 
  out:




[-- Attachment #2: xen-console-add-preferred.patch --]
[-- Type: text/plain, Size: 886 bytes --]

xencons: generalize use of add_preferred_console()

Changeset 762:a070228ac76e ("add hvc compatibility mode to xencons"
added this call just for the HVC case, without giving any reason why
HVC would be special in this regard. Use the call for all cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/console/console.c
+++ b/drivers/xen/console/console.c
@@ -214,8 +214,6 @@ static int __init xen_console_init(void)
 		strcpy(kcons_info.name, "hvc");
 		if (xc_num == -1)
 			xc_num = 0;
-		if (!is_initial_xendomain())
-			add_preferred_console(kcons_info.name, xc_num, NULL);
 		break;
 
 	case XC_SERIAL:
@@ -236,6 +234,8 @@ static int __init xen_console_init(void)
 
 	wbuf = alloc_bootmem(wbuf_size);
 
+	if (!is_initial_xendomain())
+		add_preferred_console(kcons_info.name, xc_num, NULL);
 	register_console(&kcons_info);
 
  out:

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Olaf Hering]

On Fri, Dec 13, Jan Beulich wrote:

> Changeset 762:a070228ac76e ("add hvc compatibility mode to xencons"
> added this call just for the HVC case, without giving any reason why
> HVC would be special in this regard. Use the call for all cases.

> +++ b/drivers/xen/console/console.c
> @@ -236,6 +234,8 @@ static int __init xen_console_init(void)
>  
>  	wbuf = alloc_bootmem(wbuf_size);
>  
> +	if (!is_initial_xendomain())
> +		add_preferred_console(kcons_info.name, xc_num, NULL);
>  	register_console(&kcons_info);

Why is dom0 special in this case anyway? At least with SLE12, when Xen
is booted with 'console=com1 com1=115200' and the kernel is booted
without any console= or xencons=, kcons_info.index is still -1 and as a
result xvc-1 is registered as name for xvc0. This confuses systemd
because kernel name and console name do not match, so login via serial
is not possible.

When add_preferred_console is called uncondtionally the login on serial
works as expected.


Olaf

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Jan Beulich]

>>> On 06.02.14 at 23:53, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Dec 13, Jan Beulich wrote:
> 
>> Changeset 762:a070228ac76e ("add hvc compatibility mode to xencons"
>> added this call just for the HVC case, without giving any reason why
>> HVC would be special in this regard. Use the call for all cases.
> 
>> +++ b/drivers/xen/console/console.c
>> @@ -236,6 +234,8 @@ static int __init xen_console_init(void)
>>  
>>  	wbuf = alloc_bootmem(wbuf_size);
>>  
>> +	if (!is_initial_xendomain())
>> +		add_preferred_console(kcons_info.name, xc_num, NULL);
>>  	register_console(&kcons_info);
> 
> Why is dom0 special in this case anyway? At least with SLE12, when Xen
> is booted with 'console=com1 com1=115200' and the kernel is booted
> without any console= or xencons=, kcons_info.index is still -1 and as a
> result xvc-1 is registered as name for xvc0. This confuses systemd
> because kernel name and console name do not match, so login via serial
> is not possible.

I have to direct this question to Ian, who wrote the original patch
(sorry Ian, I know it's been long ago), which the patch above only
generalizes.

> When add_preferred_console is called uncondtionally the login on serial
> works as expected.

They question is what the intended behavior here is: I'd generally
expect the lack of console= on the command line for Dom0 to
behave just like for a native kernel, which I don't think would show
a login prompt on other than the screen in that case. So maybe
instead of just dropping the is_initial_xendomain() we should make
console registration conditional upon a command line option having
requested its presence in the Dom0 case. (Looking at the command
line handling code I also wonder whether it isn't a mistake to set
console_use_vt even in the xencons=off case, and to not bail
upon the right side of the = not being recognized - see
196:52f308b17bae and 153:12c399692d44 for how this evolved.)

Jan

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Olaf Hering]

On Fri, Feb 07, Jan Beulich wrote:

> They question is what the intended behavior here is: I'd generally

In my opinion dom0 is just a child of Xen, which should follow the rules
of the parent. If Xen is configured to have its console on serial then
the default of dom0 should be to follow just that. Appearently its just
a matter of correctly using xvc0.

I'm not sure what the gain would be to have Xen on serial and dom0
somewhere else, and enforcing the need of a console= cmdline option to
point dom0 also to serial. Thats just doing things twice.


Olaf

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Jan Beulich]

>>> On 07.02.14 at 09:32, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 07, Jan Beulich wrote:
> 
>> They question is what the intended behavior here is: I'd generally
> 
> In my opinion dom0 is just a child of Xen, which should follow the rules
> of the parent. If Xen is configured to have its console on serial then
> the default of dom0 should be to follow just that. Appearently its just
> a matter of correctly using xvc0.
> 
> I'm not sure what the gain would be to have Xen on serial and dom0
> somewhere else, and enforcing the need of a console= cmdline option to
> point dom0 also to serial. Thats just doing things twice.

That's a fair point, but leaves aside the case of Xen _not_ using
the serial console. Dom0 has no way to know, and hence would
still push output there, not knowing that it ends up no-where.

Also the "follow the rules of the parent" already doesn't apply for
the VGA console case, where Dom0 makes its own decision too
(and it's for that reason that Xen needs to stop sending data to
the VGA in order to not interfere). Hence I'm not sure that
argument really counts.

Jan

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Olaf Hering]

On Fri, Feb 07, Jan Beulich wrote:

> >>> On 07.02.14 at 09:32, Olaf Hering <olaf@aepfle.de> wrote:
> > On Fri, Feb 07, Jan Beulich wrote:
> > 
> >> They question is what the intended behavior here is: I'd generally
> > 
> > In my opinion dom0 is just a child of Xen, which should follow the rules
> > of the parent. If Xen is configured to have its console on serial then
> > the default of dom0 should be to follow just that. Appearently its just
> > a matter of correctly using xvc0.
> > 
> > I'm not sure what the gain would be to have Xen on serial and dom0
> > somewhere else, and enforcing the need of a console= cmdline option to
> > point dom0 also to serial. Thats just doing things twice.
> 
> That's a fair point, but leaves aside the case of Xen _not_ using
> the serial console. Dom0 has no way to know, and hence would
> still push output there, not knowing that it ends up no-where.

You mean no Xen console= option implies that dom0 writes no-where? I
would think dom0 will use the graphics card in this case to send its
output.

> Also the "follow the rules of the parent" already doesn't apply for
> the VGA console case, where Dom0 makes its own decision too
> (and it's for that reason that Xen needs to stop sending data to
> the VGA in order to not interfere). Hence I'm not sure that
> argument really counts.

The details about driving a certain hardware dont really matter. I think
the important part is "goes to the wire" vs. "goes to the monitor". 

I think the bug is that register_console("xvc") is called without a
preceeding add_prefered_console, which with current kernels means a
second entry in /proc/consoles. This in turn lets systemd spawn a login
for that.

Somehow I think the rules have changed since 2.6.18. I will have a look
at this now.

Olaf

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Jan Beulich]

>>> On 07.02.14 at 11:07, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 07, Jan Beulich wrote:
>> >>> On 07.02.14 at 09:32, Olaf Hering <olaf@aepfle.de> wrote:
>> > In my opinion dom0 is just a child of Xen, which should follow the rules
>> > of the parent. If Xen is configured to have its console on serial then
>> > the default of dom0 should be to follow just that. Appearently its just
>> > a matter of correctly using xvc0.
>> > 
>> > I'm not sure what the gain would be to have Xen on serial and dom0
>> > somewhere else, and enforcing the need of a console= cmdline option to
>> > point dom0 also to serial. Thats just doing things twice.
>> 
>> That's a fair point, but leaves aside the case of Xen _not_ using
>> the serial console. Dom0 has no way to know, and hence would
>> still push output there, not knowing that it ends up no-where.
> 
> You mean no Xen console= option implies that dom0 writes no-where? I
> would think dom0 will use the graphics card in this case to send its
> output.

"No" to the question. Dom0, without any console= and xencons=,
always writes _both_ ways (unless - under EFI only - it detects that
there's RAM at address 0xA0000), no matter whether this actually
ends up being visible anywhere.

>> Also the "follow the rules of the parent" already doesn't apply for
>> the VGA console case, where Dom0 makes its own decision too
>> (and it's for that reason that Xen needs to stop sending data to
>> the VGA in order to not interfere). Hence I'm not sure that
>> argument really counts.
> 
> The details about driving a certain hardware dont really matter. I think
> the important part is "goes to the wire" vs. "goes to the monitor". 
> 
> I think the bug is that register_console("xvc") is called without a
> preceeding add_prefered_console, which with current kernels means a
> second entry in /proc/consoles. This in turn lets systemd spawn a login
> for that.

Yes, I agree that there likely needs to be another change here.
I'm just not certain yet which way this should be done.

Jan

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Olaf Hering]

On Fri, Feb 07, Jan Beulich wrote:

> Yes, I agree that there likely needs to be another change here.
> I'm just not certain yet which way this should be done.

Jan,

before I start doing software archaeology:
How would you want it to look like?
What combinations of Xen console= and Linux xencons=/console= are useful anyway?

Olaf

Re: [PATCH] linux-2.6.18/xencons: generalize use of add_preferred_console()

[Jan Beulich]

>>> On 07.02.14 at 13:30, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 07, Jan Beulich wrote:
> 
>> Yes, I agree that there likely needs to be another change here.
>> I'm just not certain yet which way this should be done.
> 
> before I start doing software archaeology:
> How would you want it to look like?
> What combinations of Xen console= and Linux xencons=/console= are useful 
> anyway?

I'd really first see if Ian remembers why that original change was
done for DomU only.

Jan