Re: [PATCH] xen/console: Handle true dom0less case when switching serial input

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.03.2023 13:34, Michal Orzel wrote:
> On 14/03/2023 16:17, Jan Beulich wrote:
>> On 14.03.2023 15:27, Michal Orzel wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -491,6 +491,14 @@ static void switch_serial_input(void)
>>>      else
>>>      {
>>>          console_rx++;
>>> +
>>> +        /*
>>> +         * Skip switching serial input to hardware domain if it does not 
>>> exist
>>> +         * (i.e. true dom0less mode).
>>> +         */
>>> +        if ( !hardware_domain && (console_rx == 1) )
>>> +            console_rx++;
>>
>> The consumers of this variable aren't really serialized with this
>> updating. That's probably okay-ish prior to your change, but now
>> there can be two updates in rapid succession. I think it would be
>> better if the variable was written only once here.
> ok, makes sense.
> 
>>
>>>          printk("*** Serial input to DOM%d", console_rx - 1);
>>
>> When invoked from console_endboot() this will now switch to Dom1,
>> i.e. that domain becomes kind of "preferred", which I think is
>> wrong. Instead I think in such a case we should direct input to
>> Xen by default.
> Switching serial input to the first usable domain is the major motivation 
> behind this patch.
> The number of times I got pinged by users with *apparent* Xen issue on true 
> dom0less
> just because input was directed to dom0 which was not there (not everyone 
> seems to read the
> boot logs) forced me to create this patch and manifests that this is not the 
> behavior user wants.
> Switching to Xen console would not help at all. Also, we already have a way 
> to set switch code to 'x'
> to default serial input to Xen.
> So I think what I did (switching to the first existing domain) should be the 
> default behavior (just like it was done for dom0).

Well, I'm not going to stand in the way, but if one of several supposedly
equal domains is to be "preferred" in some way, then I for one would
expect justification for doing so. If that's the route to go, then the
patch snippet you provided looks good to me.

Jan