docs/formatdomain.rst | 3 +- docs/schemas/domaincommon.rng | 1 + src/conf/domain_conf.c | 23 ++++++++--- src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 35 +++++++++++++++-- src/qemu/qemu_domain_address.c | 25 ++++++++++++ src/qemu/qemu_validate.c | 18 ++++++++- .../debugcon.x86_64-latest.args | 39 +++++++++++++++++++ tests/qemuxml2argvdata/debugcon.xml | 27 +++++++++++++ tests/qemuxml2argvtest.c | 2 + 10 files changed, 162 insertions(+), 12 deletions(-) create mode 100644 tests/qemuxml2argvdata/debugcon.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/debugcon.xml
# 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> # virsh start --paused fedora34x86_64 # virsh console --devname console1 fedora34x86_64 Now in another terminal # virsh resume fedora34x86_64 And the 'virsh console' will now show the very first messages at startup.... SecCoreStartupWithStack(0xFFFCC000, 0x820000) SEC: Normal boot DecompressMemFvs: OutputBuffer@A00000+0xCE0090 ScratchBuffer@1700000+0x10000 PcdOvmfDecompressionScratchEnd=0x1710000 Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A The 0th FV start address is 0x00000820000, size is 0x000E0000, handle is 0x820000 Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389 DiscoverPeimsAndOrderWithApriori(): Found 0xD PEI FFS files in the 0th FV ...snip... Daniel P. Berrangé (2): conf: support firmware ISA debug console qemu: wire up support for isa-debugcon docs/formatdomain.rst | 3 +- docs/schemas/domaincommon.rng | 1 + src/conf/domain_conf.c | 23 ++++++++--- src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 35 +++++++++++++++-- src/qemu/qemu_domain_address.c | 25 ++++++++++++ src/qemu/qemu_validate.c | 18 ++++++++- .../debugcon.x86_64-latest.args | 39 +++++++++++++++++++ tests/qemuxml2argvdata/debugcon.xml | 27 +++++++++++++ tests/qemuxml2argvtest.c | 2 + 10 files changed, 162 insertions(+), 12 deletions(-) create mode 100644 tests/qemuxml2argvdata/debugcon.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/debugcon.xml -- 2.33.1
On Thu, Jan 20, 2022 at 13:33:01 +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> > > # virsh start --paused fedora34x86_64 > > # virsh console --devname console1 fedora34x86_64 > > Now in another terminal > > # virsh resume fedora34x86_64 > > And the 'virsh console' will now show the very first messages > at startup.... > > SecCoreStartupWithStack(0xFFFCC000, 0x820000) > SEC: Normal boot > DecompressMemFvs: OutputBuffer@A00000+0xCE0090 ScratchBuffer@1700000+0x10000 PcdOvmfDecompressionScratchEnd=0x1710000 > Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE > Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 > Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A > The 0th FV start address is 0x00000820000, size is 0x000E0000, handle is 0x820000 > Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 > Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 > Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 > Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389 > DiscoverPeimsAndOrderWithApriori(): Found 0xD PEI FFS files in the 0th FV > ...snip... > Reviewed-by: Peter Krempa <pkrempa@redhat.com>
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 -- Andrea Bolognani / Red Hat / Virtualization
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 :|
On Thu, Jan 20, 2022 at 06:14:07PM +0000, Daniel P. Berrangé wrote: > 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. This interpretation directly contradicts our documentation, specifically https://libvirt.org/formatdomain.html#console The console element is used to represent interactive serial consoles. https://libvirt.org/formatdomain.html#relationship-between-serial-ports-and-consoles Due to historical reasons, the serial and console elements have partially overlapping scopes. In general, both elements are used to configure one or more serial consoles to be used for interacting with the guest. The main difference between the two is that serial is used for emulated, usually native, serial consoles, whereas console is used for paravirtualized ones. Now, to be completely transparent: I happen to be the one who wrote the bulk of that :) But I believe that, in doing so, I have neither inaccurately described the existing practice nor contradicted what the documentation said at the time. And at this point that text has been up on our website for 4+ years without being contested. On account of isa-debugcon being neither interactive nor paravirtualized, I feel that it should be exposed as a <serial> device rather than a <console>. -- Andrea Bolognani / Red Hat / Virtualization
Hi, > > 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. > > This interpretation directly contradicts our documentation, > specifically > > https://libvirt.org/formatdomain.html#console > > The console element is used to represent interactive serial > consoles. Yep. Something where it make sense to run a getty on. Which surely isn't the case for isa-debugcon ... take care, Gerd
© 2016 - 2024 Red Hat, Inc.