Re: [PATCH v1] xenconsole: Add connected flag

[Jürgen Groß <jgross@xxxxxxxx>]

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?

> ---
> 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".

> 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.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature