Re: [PATCH v1] xenconsole: Add connected flag

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-08-07 03:00, Jürgen Groß wrote:
> On 07.08.25 03:56, Jason Andryuk wrote:
> > With hyperlaunch, a domU can start before its console ring is connected
> > by xenconsoled.  With nothing emptying the ring, it can quickly fill
> > during boot.  In domU_write_console(), __write_console() returns 0 when
> > the ring is full.  This loops spins until xenconsoled starts emptying
> > the ring:
> >
> >          while (len) {
> >                  ssize_t sent = __write_console(cons, data, len);
> >
> >                  if (sent < 0)
> >                          return sent;
> >
> >                  data += sent;
> >                  len -= sent;
> >
> >                  if (unlikely(len))
> >                          HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
> >          }
> >
> > The goal of this patch is to add a way for the frontend to know when a
> > console is connected.  This patch adds a new flag to the end of the
> > console ring structure.  It is used for the backend to indicate that it
> > has connected and started servicing the page.
> >
> > The two values are
> > XENCONSOLE_DISCONNECTED 1
> > XENCONSOLE_CONNECTED    0
> >
> > XENCONSOLE_DISCONNECTED indicates to the guest that ring is
> > disconnected, so it will not be serviced.  The guest can avoid writing
> > into it in that case.  A domU can use console hypercalls and only
> > transition to the ring when it is connected and won't fill and block.
> >
> > Once the backend (xenconsoled) maps and starts servicing the
> > console, the flag will be set to XENCONSOLE_CONNECTED (0) to indicate
> > the backend state to the frontend.
> >
> > The connected value as 0 will be match the default of a zero-ed console
> > page.  Hyperlaunch can set the flag to XENCONSOLE_DISCONNECTED and let
> > xenconsoled set to XENCONSOLE_CONNECTED.
> I think libxenguest should set XENCONSOLE_DISCONNECTED as well (see below).
>
> > Old domU hvc_xen drivers won't check the flag.
> > New domU hvc_xen running on a new xen/xenconsoled will work properly.
> > New domU hvc_xen on old xen/xenconsoled should only see a 0 for the flag
> > and behave as if connected.
> >
> > Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> Adapt the title of the patch?
With Jan's naming suggestion, it'll be "xenconsole: Add connection field"

> > ---
> > v1:
> > Remove evtchn notify call
> > Set connected later when there is no error
> >
> > RFC v3:
> > Flip flag values so 0 is connected.
> >
> > The other option would be to add:
> > uint32_t features
> > uint32_t connected
> >
> > New domUs would check features for a magic value and/or flag to know
> > they can rely on connected transitioning.
> >
> > I think making XENCONSOLE_CONNECTED == 0 side steps the need for
> > an additional features field.  As long as assuming zero-ed memory is
> > acceptable.  However, this only matters for a hyperlaunched guest -
> > xenconsoled will normally readily connect the console and set the value.
> I'd like to consider other cases as well, e.g. a console driver domain.
> So any instance creating a domain with a console ring page should set the
> flag initially to "disconnected".
Sure, that makes sense.

I don't have immediate plans for this, but I had the additional thought 
of placing the event channel inside the page like we do for xenstore. 
Today xenconsoled uses xenstore for the ring-ref and event channel, 
thought it tries the reserved console grant first.  With the reserved 
grant, and the event channel inside, that dependency would be removed. 
Xenconsoled still needs some way to know when domains come and go, and 
it depends on xenstore's @introduceDomain/@releaseDomain for that.  So 
it couldn't be completely decoupled without some other mechanism.
> > This assumes that existing frontends are not using the flag space for
> > some other use.
> >
> > Removed idea:
> > Send an event channel notification to let the domU know that xenconsoled
> > is connected.  Xenstored does similar, but for xenstore, the xenstore
> > driver owns the event channel/irq and can rebind it.  For hvc_xen, the
> > hvc subsystem owns the irq, so it isn't readily available for rebinding.
> > This is not implemented.
> >
> > I had the idea for the kernel to use a static key and switch writing
> > from the hypercall to the PV ring once connected.  It didn't actually
> > work in my short attempt - I think changing the static key from within
> > an interupt was wrong.  I fell back to just checking the flag directly
> You'd need to do the static key changing from a worker thread instead.
Thanks.  I'll investigate.

Regards,
Jason