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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 15 Mar 2023, Michal Orzel wrote:
> 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.

My two cents. Given the feedback we are getting from users, I think it
is important that the input goes to a real valid domain (not Xen, not
Dom0 that doesn't exist). "Which dom0less domain?" is a valid question,
and I don't know what would be the best answer. But any of those domains
would be better than what we have today.