On Thu, 2019-02-07 at 14:31 +0300, Nikolay Shirokovskiy wrote:
[...]
@@ -4392,6 +4393,9 @@ virDomainDefAddConsoleCompat(virDomainDefPtr
def)
switch ((virDomainChrSerialTargetType) def->serials[0]->targetType) {
case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_ISA:
+ if (def->serials[0]->targetModel ==
VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_ISA_DEBUGCON)
+ break;
This doesn't compile:
conf/domain_conf.c: In function 'virDomainDefAddConsoleCompat':
conf/domain_conf.c:4396:16: error: this statement may fall through
[-Werror=implicit-fallthrough=]
if (def->serials[0]->targetModel ==
VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_ISA_DEBUGCON)
^
conf/domain_conf.c:4399:9: note: here
case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SPAPR_VIO:
^~~~
You need to add ATTRIBUTE_FALLBACK after the break to make the
compiler happy. A short comment explaining why you're skipping
isa-debugcon would definitely be appreciated as well.
Even with that fixed, while your code prevents a <console> element
associated to the isa-debugcon to be automatically created, it
doesn't prevent something like
<console type='pty'/>
<serial type='file'>
<source path='...'/>
<target type='isa-serial'>
<model name='isa-debugcon'/>
</target>
</serial>
to result in the same problematic configuration, while the user
clearly wanted to have both a regular serial console *and* the
isa-debugcon.
I'm actually not sure we can make something very reasonable like
the above work... Perhaps we'll be forced to use <channel> after
all.
Adding Dan and Pavel so they can weigh in too.
[...]
+++ b/tests/qemuxml2argvdata/isa-serial-debugcon.xml
@@ -0,0 +1,36 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219100</memory>
+ <currentMemory unit='KiB'>219100</currentMemory>
+ <vcpu placement='static' cpuset='1-4,8-20,525'>1</vcpu>
+ <os>
+ <type arch='i686' 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-i686</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>
+ <controller type='usb' index='0'/>
+ <controller type='ide' index='0'/>
+ <controller type='pci' index='0' model='pci-root'/>
You can trim this input file significantly, and by doing so you'll
end up with something that clearly highlights what feature it's
supposed to test:
<domain type='qemu'>
<name>QEMUGuest1</name>
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
<memory unit='KiB'>219100</memory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='i686' machine='pc'>hvm</type>
</os>
<devices>
<emulator>/usr/bin/qemu-system-i686</emulator>
<controller type='usb' model='none'/>
<serial type='pipe'>
<source path='/tmp/debugcon'/>
<target type='isa-serial' port='0'>
<model name='isa-debugcon'/>
</target>
<address type='isa' iobase='0x402'/>
</serial>
<memballoon model='none'/>
</devices>
</domain>
This is all you need for the purpose of testing isa-debugcon.
+ <serial type='pipe'>
+ <source path='/tmp/debugcon'/>
+ <target type='isa-serial' port='0'>
+ <model name='isa-debugcon'/>
+ </target>
+ <address type='isa' iobase='0x402'/>
+ </serial>
So IIUC iobase=0x402 is the de-facto standard for isa-debugcon,
right?
Assuming that's indeed the case, I would expect libvirt to fill in
that value automatically unless the user has provided an iobase
explicitly themselves.
(Incidentally, and pre-existing, but shouldn't something like that
happen for isa-serial as well?)
--
Andrea Bolognani / Red Hat / Virtualization