[libvirt PATCH 0/2] qemu: support the SeaBIOS/EDK2 debug console

[Daniel P. Berrangé]

On Thu, Jan 20, 2022 at 07:08:03AM -0800, Andrea Bolognani wrote:
> On Thu, Jan 20, 2022 at 01:33:01PM +0000, Daniel P. Berrangé wrote:
> >  # virsh dumpxml fedora34x86_64 | xmllint  -xpath '/domain/devices/console[2]' -
> >     <console type="pty">
> >       <target type="isa-debug" port="1"/>
> >       <address type="isa" iobase="0x402"/>
> >     </console>
> 
> I can't force myself to page all of the context back in right now,
> but last time we discussed adding support for isa-debugcon back in
> 2019 Gerd seemed to be pretty firmly against using <console>.
> 
> https://listman.redhat.com/archives/libvir-list/2019-January/msg01045.html

Heh, I totally forgot that we have that discussion previously.

I can totally rule out <channel> as a concept as I think that has very
specific semantics around being targetted for supporting explicit
application network protocols. This just doesn't fit into it nicely.


The choice is  <console> vs <serial>  vs <new_invented_thing>

I briefly considered <new_invented_thing/> but I didn't feel it was
justifiable to introduce a new type of element. My thought was it
could be a <debugger> element, which could support both this
firmware debug console and QEMU's GDB stub, both of which are
chardev based.

The overhead of new parsing, support in virsh console, and so on
felt uncessarily high, and the overlap with GDB wasn't clearcut.

Even though it is used for debug purposes for getting data out
of the firmware, it is a very different beast from thue GDB
debugger stub. eg GDB is for running a communication protocol
while this is just a text output stream. In fact the GDB
stub could indeed be a good fit for <channel> because it is
basically a network protocol.[

To me I think of <console> as exclusively reflecting a text I/O
channel targetting humans, while <serial> is a more general
purpose data channel that can be used for multiple purposes.
Either running app protocols or for plain text console I/O.

In terms of an low level implementation isa-debugcon could be
argued to be a general purpose (unidirectional) data channel,
that is just passing arbitrary bytes. That would push towards
<serial> as a mapping

In terms of the actual real world use cases though, isa-debugcon
is (AFAIK) only used for spewing text debugging messages aimed
at humans. That pushes towards <console> as a mapping.

On balance I felt <console> was/is the winner. Essentially every
impl of <console> can be said to be a general purpose data
channel for passing arbitrary bytes. We choose to explicitly
distinguish <console> from <serial> based on the intended use
case of the thing.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|