[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH] docs/sphinx: overview of serial consoles




On 1/15/25 14:27, Andrew Cooper wrote:
> On 15/01/2025 12:07 pm, Yann Dirson wrote:
>> ---
>>
>> Notes:
>>      This is a very preliminar first draft for comments:
>>
>>      - would this structuration be adequate?
>>
>>      - Is my basic understanding correct, are those first enumerations
>>      correct? (some of it come solely from console.txt, which has already
>>      proven to be seriously outdated on many aspects)
>>
>>      - is there some doc about the qemu/ioemu backend I missed?  Is it able 
>> to
>>      deal with PV consoles, or is it just for virtual UARTS?
>
> Consoles are probably one of the harder areas to get started.
>
> First, we need to distinguish between host consoles and guest consoles,
> because admin-guide/console could be either/both.

OK, so this would rather be admin-guide/guest-console or even
admin-guide/guest-serial-console.

>
> Host consoles are mostly UARTs, but we have several flavours including
> usb2 and usb3 flavours.  ARM has extensive early printk support, which
> RISC-V/PPC are borrowing too.  Xen is also capable of using
> hypervisor-provided consoles too.

Let's leave this for a later admin-guide/host-console :)

> For guest consoles, there's the plain CONSOLEIO hypercalls, and whether
> they do anything interesting depend on whether you're dom0 and/or the
> CONFIG_VERBOSE build setting.

I would see that part in something like guest-guide/serial-console.

>  ARM has the ability to mutiplex output
> from different guests onto the host console.  There's also the
> xenconsoled, things emulated by Qemu or other emulators, and even the
> in-Xen UART emulator currently on list.
>
> Then, for specific guests, they've got different console options
> available.  e.g. Linux has a dedicated earlyconsole option for Xen (uses
> CONSOLEIO) as well as an hvc driver.

Those definitely seem in the scope for the doc I was thinking about

> And ideally we want all this information documented nicely, between "how
> do I set up debugging for my guest"

Debugging is an obvious superset, would hint to a "Guest debugging"
section.  Maybe it would be enough to add admin-guide/guest-debugging as
intermediate level, but not be necessary to create an additional level
of subdir for the contents?

 > and how do I write a driver for xenconsoled.

That one does not really fit in either of admin-guide, guest-guide, and
hypervisor-guide.  Something like toolstack-implementation-guide?



Yann Dirson | Vates Platform Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.