libvirt/tests/qemuxml2argvdata/serial-unix-missing-source.xml

<domain type='qemu'>
  <name>guest</name>
  <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
  <memory unit='KiB'>1048576</memory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <serial type='unix'>
      <target type='pci-serial'/>
    </serial>
  </devices>
</domain>
conf: Fix check for chardev source path Attempting to use a chardev definition like <serial type='unix'> <target type='isa-serial'/> </serial> correctly results in an error being reported, since the source path - a required piece of information - is missing; however, the very similar <serial type='unix'> <target type='pci-serial'/> </serial> was happily accepted by libvirt, only to result in libvirtd crashing as soon as the guest was started. The issue was caused by checking the chardev's targetType against whitelisted values from virDomainChrChannelTargetType without first checking the chardev's deviceType to make sure it is actually a channel, for which the check makes sense, rather than a different type of chardev. The only reason this wasn't spotted earlier is that the whitelisted values just so happen to correspond to USB and PCI serial devices and Xen and UML consoles respectively, all of which are fairly uncommon. https://bugzilla.redhat.com/show_bug.cgi?id=1609720 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2018-09-06 15:51:10 +00:00			`<domain type='qemu'>`
			`<name>guest</name>`
			`<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>`
			`<memory unit='KiB'>1048576</memory>`
			`<vcpu placement='static'>1</vcpu>`
			`<os>`
qemuxml2argvtest: Fix serial-unix-missing-source case Use x86_64 emulator and machine and remove the nocaps version of the test. Fixes: 80a37e96a95 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2023-03-02 16:50:07 +00:00			`<type arch='x86_64' machine='pc'>hvm</type>`
conf: Fix check for chardev source path Attempting to use a chardev definition like <serial type='unix'> <target type='isa-serial'/> </serial> correctly results in an error being reported, since the source path - a required piece of information - is missing; however, the very similar <serial type='unix'> <target type='pci-serial'/> </serial> was happily accepted by libvirt, only to result in libvirtd crashing as soon as the guest was started. The issue was caused by checking the chardev's targetType against whitelisted values from virDomainChrChannelTargetType without first checking the chardev's deviceType to make sure it is actually a channel, for which the check makes sense, rather than a different type of chardev. The only reason this wasn't spotted earlier is that the whitelisted values just so happen to correspond to USB and PCI serial devices and Xen and UML consoles respectively, all of which are fairly uncommon. https://bugzilla.redhat.com/show_bug.cgi?id=1609720 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2018-09-06 15:51:10 +00:00			`</os>`
			`<devices>`
qemuxml2argvtest: Fix serial-unix-missing-source case Use x86_64 emulator and machine and remove the nocaps version of the test. Fixes: 80a37e96a95 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2023-03-02 16:50:07 +00:00			`<emulator>/usr/bin/qemu-system-x86_64</emulator>`
conf: Fix check for chardev source path Attempting to use a chardev definition like <serial type='unix'> <target type='isa-serial'/> </serial> correctly results in an error being reported, since the source path - a required piece of information - is missing; however, the very similar <serial type='unix'> <target type='pci-serial'/> </serial> was happily accepted by libvirt, only to result in libvirtd crashing as soon as the guest was started. The issue was caused by checking the chardev's targetType against whitelisted values from virDomainChrChannelTargetType without first checking the chardev's deviceType to make sure it is actually a channel, for which the check makes sense, rather than a different type of chardev. The only reason this wasn't spotted earlier is that the whitelisted values just so happen to correspond to USB and PCI serial devices and Xen and UML consoles respectively, all of which are fairly uncommon. https://bugzilla.redhat.com/show_bug.cgi?id=1609720 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2018-09-06 15:51:10 +00:00			`<serial type='unix'>`
			`<target type='pci-serial'/>`
			`</serial>`
			`</devices>`
			`</domain>`