openkylin
/
libvirt
mirror of https://gitee.com/openkylin/libvirt.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
libvirt/tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-do...

45 lines
1.8 KiB
XML
Raw Normal View History

conf: new pcie-controller model "pcie-switch-downstream-port" This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
2015-06-18 03:27:40 +08:00
<domain type='qemu'>
<name>q35-test</name>
<uuid>11dbdcdd-4c3b-482b-8903-9bdb8c0a2774</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static' cpuset='0-1'>2</vcpu>
<os>
<type arch='x86_64' machine='q35'>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>
tests: unify qemu binary paths for all qemu related tests Our test data used a lot of different qemu binary paths and some of them were based on downstream systems. Note that there is one file where I had to add "accel=kvm" because the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm". Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-07 00:19:48 +08:00
<emulator>/usr/bin/qemu-system-x86_64</emulator>
conf: new pcie-controller model "pcie-switch-downstream-port" This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
2015-06-18 03:27:40 +08:00
<disk type='block' device='disk'>
<source dev='/dev/HostVG/QEMUGuest1'/>
<target dev='sda' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='pci' index='0' model='pcie-root'/>
tests: Reduce usage of legacy PCI controllers on PCIe machines Up until a while ago, libvirt would automatically add a legacy PCI controllers combo (dmi-to-pci-bridge + pci-bridge) to any PCIe machine type (x86_64/q35 and aarch64/virt). As a result, a number of input and output files in the test suite ended up containing the legacy PCI controllers, even though they are not needed or in any way relevant to the feature being tested. Get rid of most of the occurrences. Most of the time, this just means removing the controllers from the input file and regenerating the output files; in a few instances, some minor tweaking is performed on the input file, most notably removing the memory balloon: as memory balloon support was not the scope of the test being changed, there is no loss of test coverage from doing so. Several occurrences of the legacy PCI controllers remain in the test suite, both because removing their usage would have required even more tweaking, and because we still want to have coverage of this perfectly valid combination.
2017-02-21 21:30:39 +08:00
<controller type='pci' index='1' model='pcie-root-port'/>
<controller type='pci' index='2' model='pcie-switch-upstream-port'/>
<controller type='pci' index='3' model='pcie-switch-downstream-port'/>
<controller type='pci' index='4' model='pcie-switch-downstream-port'/>
conf: new pcie-controller model "pcie-switch-downstream-port" This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
2015-06-18 03:27:40 +08:00
<controller type='pci' index='5' model='pcie-switch-downstream-port'/>
tests: Reduce usage of legacy PCI controllers on PCIe machines Up until a while ago, libvirt would automatically add a legacy PCI controllers combo (dmi-to-pci-bridge + pci-bridge) to any PCIe machine type (x86_64/q35 and aarch64/virt). As a result, a number of input and output files in the test suite ended up containing the legacy PCI controllers, even though they are not needed or in any way relevant to the feature being tested. Get rid of most of the occurrences. Most of the time, this just means removing the controllers from the input file and regenerating the output files; in a few instances, some minor tweaking is performed on the input file, most notably removing the memory balloon: as memory balloon support was not the scope of the test being changed, there is no loss of test coverage from doing so. Several occurrences of the legacy PCI controllers remain in the test suite, both because removing their usage would have required even more tweaking, and because we still want to have coverage of this perfectly valid combination.
2017-02-21 21:30:39 +08:00
<controller type='pci' index='6' model='pcie-switch-downstream-port'>
conf: new pcie-controller model "pcie-switch-downstream-port" This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
2015-06-18 03:27:40 +08:00
<model name='xio3130-downstream'/>
<target chassis='30' port='0x27'/>
</controller>
tests: Reduce usage of legacy PCI controllers on PCIe machines Up until a while ago, libvirt would automatically add a legacy PCI controllers combo (dmi-to-pci-bridge + pci-bridge) to any PCIe machine type (x86_64/q35 and aarch64/virt). As a result, a number of input and output files in the test suite ended up containing the legacy PCI controllers, even though they are not needed or in any way relevant to the feature being tested. Get rid of most of the occurrences. Most of the time, this just means removing the controllers from the input file and regenerating the output files; in a few instances, some minor tweaking is performed on the input file, most notably removing the memory balloon: as memory balloon support was not the scope of the test being changed, there is no loss of test coverage from doing so. Several occurrences of the legacy PCI controllers remain in the test suite, both because removing their usage would have required even more tweaking, and because we still want to have coverage of this perfectly valid combination.
2017-02-21 21:30:39 +08:00
<controller type='pci' index='7' model='pcie-switch-upstream-port'/>
<controller type='pci' index='8' model='pcie-switch-downstream-port'/>
<controller type='pci' index='9' model='pcie-switch-downstream-port'/>
conf: new pcie-controller model "pcie-switch-downstream-port" This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
2015-06-18 03:27:40 +08:00
<controller type='pci' index='10' model='pcie-switch-downstream-port'/>
<controller type='sata' index='0'/>
device: cleanup input device code The current code was a little bit odd. At first we've removed all possible implicit input devices from domain definition to add them later back if there was any graphics device defined while parsing XML description. That's not all, while formating domain definition to XML description we at first ignore any input devices with bus different to USB and VIRTIO and few lines later we add implicit input devices to XML. This seems to me as a lot of code for nothing. This patch may look to be more complicated than original approach, but this is a preferred way to modify/add driver specific stuff only in those drivers and not deal with them in common parsing/formating functions. The update is to add those implicit input devices into config XML to follow the real HW configuration visible by guest OS. There was also inconsistence between our behavior and QEMU's in the way, that in QEMU there is no way how to disable those implicit input devices for x86 architecture and they are available always, even without graphics device. This applies also to XEN hypervisor. VZ driver already does its part by putting correct implicit devices into live XML. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-01-11 19:40:32 +08:00
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
conf: new pcie-controller model "pcie-switch-downstream-port" This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
2015-06-18 03:27:40 +08:00
<video>
<model type='qxl' ram='65536' vram='32768' vgamem='8192' heads='1'/>
</video>
<memballoon model='none'/>
</devices>
</domain>