Re: [PATCH] console: generalize the ability for domU access

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 3 Aug 2023, Daniel P. Smith wrote:
> On 8/2/23 19:58, Stefano Stabellini wrote:
> > On Wed, 2 Aug 2023, Jan Beulich wrote:
> > > > -    for ( ; ; )
> > > > +    if ( d == NULL )
> > > 
> > > This covers both Xen receiving input and the domain receiving input having
> > > gone away. Originally in the latter case the next sequential (in domid
> > > numbering) domain would be switched to. In the new logic you start over
> > > from the beginning of the domain list. Such a change in behavior (if
> > > deemed acceptable at all, which I'm not convinced of) needs calling out in
> > > the description.
> > 
> > I think it would be best to keep the current behavior as we already
> > have people using it unless we have strong reasons to change it.
> 
> I agree and intended to keep the order of switching but I disagree on keeping
> the complete current behavior. I mean that by the complete current behavior
> being defined, at least for Arm, as meaning only the domains created at boot.
> The is_console flag in struct domain is the DAC equivalent to granting the
> FLASK access XEN__READCONSOLE to a domain, it was just never implemented/used
> until domoless enable it. An intended consequence of this patch is to ensure
> any domain granted the privilege, either through the DAC is_console or FLASK
> XEN__READCONSOLE, is included in the rotation regardless if the domain was
> created at boot or at runtime.

I think that's fine.

Let's say that we have Xen, Dom0, and 2 Dom0less DomUs at boot.  The
console will start on Dom0 and the rotation would go:

Dom0->Dom1->Dom2->Xen->Dom0...

If a new domain comes up at runtime with is_console, it would become:

Dom0->Dom1->Dom2->Dom3->Xen->Dom0...