7:33 a.m.
# 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
7:33 a.m.
New subject: [libvirt PATCH 1/2] conf: support firmware ISA debug console
Introduce support for
<console type='pty'>
<target type='isa-debug'/>
</console>
which is used as a way to receive debug messages from the
firmware on x86 platforms. The iobase port will default
to 0x402 which is what SeaBIOS/OVMF expect normally.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
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 | 1 +
5 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index acd9020830..9e4e5fd036 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -6483,7 +6483,8 @@ values for the ``type`` attribute are: ``serial`` (described below);
``virtio``
(usable for s390 and s390x QEMU guests) are supported for compatibility reasons
but should not be used for new guests: use the ``sclpconsole`` and
``sclplmconsole`` target models, respectively, with the ``serial`` element
-instead.
+instead. ``isa-debug`` provides a virtual console for receiving debug
+messages from the firmware on x86 platforms. :since:`Since: 8.1.0`.
Of the target types listed above, ``serial`` is special in that it doesn't
represents a separate device, but rather the same device as the first ``serial``
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 169b8d8dee..4ff3bcda24 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4387,6 +4387,7 @@
<value>openvz</value>
<value>sclp</value>
<value>sclplm</value>
+ <value>isa-debug</value>
</choice>
</attribute>
</define>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 393f9d9478..c73085a513 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -672,6 +672,7 @@ VIR_ENUM_IMPL(virDomainChrConsoleTarget,
"openvz",
"sclp",
"sclplm",
+ "isa-debug",
);
VIR_ENUM_IMPL(virDomainChrSerialTargetModel,
@@ -5382,7 +5383,7 @@ virDomainChrIsaSerialDefPostParse(virDomainDef *def)
}
-static void
+static int
virDomainChrDefPostParse(virDomainChrDef *chr,
const virDomainDef *def)
{
@@ -5391,9 +5392,18 @@ virDomainChrDefPostParse(virDomainChrDef *chr,
virDomainChrGetDomainPtrs(def, chr->deviceType, &arrPtr, &cnt);
- if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE &&
- chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE) {
- chr->targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL;
+ if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE) {
+ switch (chr->targetType) {
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE:
+ chr->targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL;
+ break;
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG:
+ if (!ARCH_IS_X86(def->os.arch)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("isa-debug console type only valid on x86
architecture"));
+ return -1;
+ }
+ }
}
if (chr->target.port == -1 &&
@@ -5409,6 +5419,8 @@ virDomainChrDefPostParse(virDomainChrDef *chr,
chr->target.port = maxport + 1;
}
+
+ return 0;
}
@@ -5620,8 +5632,7 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDef *dev,
switch ((virDomainDeviceType)dev->type) {
case VIR_DOMAIN_DEVICE_CHR:
- virDomainChrDefPostParse(dev->data.chr, def);
- ret = 0;
+ ret = virDomainChrDefPostParse(dev->data.chr, def);
break;
case VIR_DOMAIN_DEVICE_RNG:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e2f35fe20b..7f845b609d 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1183,6 +1183,7 @@ typedef enum {
VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_OPENVZ,
VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SCLP,
VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SCLPLM,
+ VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG,
VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST
} virDomainChrConsoleTargetType;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 60b4f96e06..030c27b963 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -10845,6 +10845,7 @@ qemuBuildConsoleChrDeviceProps(const virDomainDef *def,
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_UML:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LXC:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_OPENVZ:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("unsupported console target type %s"),
--
2.33.1
7:33 a.m.
New subject: [libvirt PATCH 2/2] qemu: wire up support for isa-debugcon
This wires up the command line generator so that it can emit the
args needed to enable the ISA debug console in QEMU. No capability
check is required since this has been around forever in QEMU and
the conf parser rejects it on non-x86 configs already.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/qemu/qemu_command.c | 36 +++++++++++++++--
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 +
6 files changed, 141 insertions(+), 6 deletions(-)
create mode 100644 tests/qemuxml2argvdata/debugcon.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/debugcon.xml
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 030c27b963..b91998a5f5 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -5634,6 +5634,27 @@ qemuBuildSclpDevProps(virDomainChrDef *dev)
}
+static virJSONValue *
+qemuBuildISADebugDevProps(const virDomainDef *def,
+ virDomainChrDef *dev)
+{
+ g_autoptr(virJSONValue) props = NULL;
+ g_autofree char *chardev = g_strdup_printf("char%s", dev->info.alias);
+
+ if (virJSONValueObjectAdd(&props,
+ "s:driver", "isa-debugcon",
+ "s:chardev", chardev,
+ "s:id", dev->info.alias,
+ NULL) < 0)
+ return NULL;
+
+ if (qemuBuildDeviceAddressProps(props, def, &dev->info) < 0)
+ return NULL;
+
+ return g_steal_pointer(&props);
+}
+
+
static int
qemuBuildRNGBackendChrdev(virCommand *cmd,
virDomainRNGDef *rng,
@@ -9317,7 +9338,6 @@ qemuBuildChrDeviceCommandLine(virCommand *cmd,
virQEMUCaps *qemuCaps)
{
g_autoptr(virJSONValue) props = NULL;
-
if (!(props = qemuBuildChrDeviceProps(def, chr, qemuCaps)))
return -1;
@@ -9500,10 +9520,11 @@ qemuBuildConsoleCommandLine(virCommand *cmd,
virDomainChrDef *console = def->consoles[i];
g_autofree char *charAlias =
qemuAliasChardevFromDevAlias(console->info.alias);
- switch (console->targetType) {
+ switch ((virDomainChrConsoleTargetType)console->targetType) {
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SCLP:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SCLPLM:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG:
if (qemuBuildChardevCommand(cmd,
console->source,
charAlias,
@@ -9517,7 +9538,12 @@ qemuBuildConsoleCommandLine(virCommand *cmd,
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL:
break;
- default:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_XEN:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_UML:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LXC:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_OPENVZ:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST:
return -1;
}
}
@@ -10839,13 +10865,15 @@ qemuBuildConsoleChrDeviceProps(const virDomainDef *def,
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO:
return qemuBuildVirtioSerialPortDevProps(def, chr);
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG:
+ return qemuBuildISADebugDevProps(def, chr);
+
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_XEN:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_UML:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LXC:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_OPENVZ:
- case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("unsupported console target type %s"),
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 18fc34d049..e97c612762 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -3174,6 +3174,28 @@ qemuDomainAssignUSBAddresses(virDomainDef *def,
}
+static int
+qemuDomainAssignISAAddresses(virDomainDef *def)
+{
+ size_t i;
+
+ for (i = 0; i < def->nconsoles; i++) {
+ virDomainChrDef *chr = def->consoles[i];
+
+ if (chr->targetType != VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG) {
+ continue;
+ }
+
+ if (chr->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
+ chr->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ISA;
+ chr->info.addr.isa.iobase = 0x402;
+ }
+ }
+
+ return 0;
+}
+
+
int
qemuDomainAssignAddresses(virDomainDef *def,
virQEMUCaps *qemuCaps,
@@ -3201,6 +3223,9 @@ qemuDomainAssignAddresses(virDomainDef *def,
if (qemuDomainAssignMemorySlots(def) < 0)
return -1;
+ if (qemuDomainAssignISAAddresses(def) < 0)
+ return -1;
+
return 0;
}
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index ae0ee4e744..fd25701fd3 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -862,7 +862,7 @@ qemuValidateDomainDefConsole(const virDomainDef *def,
for (i = 0; i < def->nconsoles; i++) {
virDomainChrDef *console = def->consoles[i];
- switch (console->targetType) {
+ switch ((virDomainChrConsoleTargetType)console->targetType) {
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SCLP:
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_SCLPCONSOLE)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -879,11 +879,25 @@ qemuValidateDomainDefConsole(const virDomainDef *def,
}
break;
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_ISA_DEBUG:
+ if (console->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ISA) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("isa-debug console target must has ISA address type
not %s"),
+
virDomainDeviceAddressTypeToString(console->info.type));
+ return -1;
+ }
+ break;
+
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL:
break;
- default:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_XEN:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_UML:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LXC:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_OPENVZ:
+ case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("unsupported console target type %s"),
NULLSTR(virDomainChrConsoleTargetTypeToString(console->targetType)));
diff --git a/tests/qemuxml2argvdata/debugcon.x86_64-latest.args
b/tests/qemuxml2argvdata/debugcon.x86_64-latest.args
new file mode 100644
index 0000000000..fa6c422329
--- /dev/null
+++ b/tests/qemuxml2argvdata/debugcon.x86_64-latest.args
@@ -0,0 +1,39 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/tmp/lib/domain--1-QEMUGuest1 \
+USER=test \
+LOGNAME=test \
+XDG_DATA_HOME=/tmp/lib/domain--1-QEMUGuest1/.local/share \
+XDG_CACHE_HOME=/tmp/lib/domain--1-QEMUGuest1/.cache \
+XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
+/usr/bin/qemu-system-x86_64 \
+-name guest=QEMUGuest1,debug-threads=on \
+-S \
+-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/tmp/lib/domain--1-QEMUGuest1/master-key.aes"}'
\
+-machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram \
+-accel tcg \
+-cpu qemu64 \
+-m 214 \
+-object
'{"qom-type":"memory-backend-ram","id":"pc.ram","size":224395264}'
\
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-no-acpi \
+-boot strict=on \
+-device
'{"driver":"piix3-usb-uhci","id":"usb","bus":"pci.0","addr":"0x1.0x2"}'
\
+-blockdev
'{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
+-blockdev
'{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}'
\
+-device
'{"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-1-format","id":"ide0-0-0","bootindex":1}'
\
+-chardev pty,id=charconsole0 \
+-device
'{"driver":"isa-debugcon","chardev":"charconsole0","id":"console0","iobase":1026}'
\
+-audiodev
'{"id":"audio1","driver":"none"}' \
+-device
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x2"}'
\
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
diff --git a/tests/qemuxml2argvdata/debugcon.xml b/tests/qemuxml2argvdata/debugcon.xml
new file mode 100644
index 0000000000..662284c79a
--- /dev/null
+++ b/tests/qemuxml2argvdata/debugcon.xml
@@ -0,0 +1,27 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219136</memory>
+ <currentMemory unit='KiB'>219136</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='x86_64' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-x86_64</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='ide'/>
+ <address type='drive' controller='0' bus='0'
target='0' unit='0'/>
+ </disk>
+ <console type='pty'>
+ <target type='isa-debug'/>
+ <address type='isa' iobase='0x402'/>
+ </console>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 9d2de2a569..7100a4d7f1 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1257,6 +1257,8 @@ mymain(void)
DO_TEST_NOCAPS("q35-noacpi-nouefi");
DO_TEST_NOCAPS("q35-acpi-nouefi");
+ DO_TEST_CAPS_LATEST("debugcon");
+
DO_TEST_NOCAPS("clock-utc");
DO_TEST_NOCAPS("clock-localtime");
DO_TEST_NOCAPS("clock-localtime-basis-localtime");
--
2.33.1
7:57 a.m.
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(a)redhat.com>
9:08 a.m.
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
12:14 p.m.
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 :|
4:12 a.m.
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-a...
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
3:09 a.m.
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
1033
days inactive
1038
days old
7 comments
4 participants
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Gerd Hoffmann -
Peter Krempa