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

[Michal Orzel <michal.orzel@xxxxxxx>]

On 15/03/2023 14:11, Jan Beulich wrote:
> 
> 
> 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.
Well, the explanation is that we are directing input to the first existing 
domain
which also is the first domain created (this is what users expect at least by 
default).
This for now creates simplest/cleanest solution that matches the current 
behavior
with dom0 and solves the users inconveniences I mentioned earlier.
There is no other real preference apart from being first domain created and to 
help keep the order simple.

In the future, we are going to allow specifying which domain to direct serial 
input to if users
want to modify the default behavior. This way, we will have all the flexibility 
needed:
-default -> first created
-conswitch=ax -> Xen
-dt property -> dom<N>

~Michal