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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 8/3/23 15:30, Stefano Stabellini wrote:
> 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...
Correct, that is the sequence I was attempting to achieve, but then I 
ran into the dom0less CI configuration of booting a system with Xen and 
a DomU. The above rotation will stay the same less dom0/hwdom, but it 
did quickly point out that I made an assumption about the hardware 
domain always being present.
v/r,
dps