External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-05 21:01:13 +00:00
Code Issues Packages Projects Releases Wiki Activity
1201299699
libvirt/tests/qemuxml2argvdata/usb1-usb2.xml

75 lines
2.4 KiB
XML
Raw Normal View History

Add a usb1 & usb2 qemuxml2argv test
2011-09-05 07:07:01 +00:00
<domain type='qemu'>
<name>QEMUGuest1</name>
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
xml: output memory unit for clarity Make it obvious to 'dumpxml' readers what unit we are using, since our default of KiB for memory (1024) differs from qemu's default of MiB; and differs from our use of bytes for storage. Tests were updated via: $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(memory\|currentMemory\|hard_limit\|soft_limit\|min_guarantee\|swap_hard_limit\)>/<\1 unit='"'KiB'>/" $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(capacity\|allocation\|available\)>/<\1 unit='"'bytes'>/" followed by a few fixes for the stragglers. Note that with this patch, the RNG for <memory> still forbids validation of anything except unit='KiB', since the code silently ignores the attribute; a later patch will expand <memory> to allow scaled input in the code and update the RNG to match. * docs/schemas/basictypes.rng (unit): Add 'bytes'. (scaledInteger): New define. * docs/schemas/storagevol.rng (sizing): Use it. * docs/schemas/storagepool.rng (sizing): Likewise. * docs/schemas/domaincommon.rng (memoryKBElement): New define; use for memory elements. * src/conf/storage_conf.c (virStoragePoolDefFormat) (virStorageVolDefFormat): Likewise. * src/conf/domain_conf.h (_virDomainDef): Document unit used internally. * src/conf/storage_conf.h (_virStoragePoolDef, _virStorageVolDef): Likewise. * tests/*data/*.xml: Update all tests. * tests/*out/*.xml: Likewise. * tests/define-dev-segfault: Likewise. * tests/openvzutilstest.c (testReadNetworkConf): Likewise. * tests/qemuargv2xmltest.c (blankProblemElements): Likewise.
2012-02-23 00:48:38 +00:00
<memory unit='KiB'>219136</memory>
xml: drop unenforced minimum memory limit from RNG The test domain allows <memory>0</memory>, but the RNG was stating that memory had to be at least 4096000 bytes. Hypervisors should enforce their own limits, rather than complicating the RNG. Meanwhile, some copy and paste had introduced some fishy constructs in various unit tests. * docs/schemas/domaincommon.rng (memoryKB, memoryKBElement): Drop limit that isn't enforced in code. * src/conf/domain_conf.c (virDomainDefParseXML): Require current <= maximum. * tests/qemuxml2argvdata/*.xml: Fix offenders.
2012-02-23 04:18:39 +00:00
<currentMemory unit='KiB'>219136</currentMemory>
numad: Always output 'placement' of <vcpu> <vcpu> is not an optional node. The value for its 'placement' actually always defaults to 'static' in the underlying codes. (Even no 'cpuset' and 'placement' is specified, the domain process will be pinned to all the available pCPUs).
2012-05-08 16:04:36 +00:00
<vcpu placement='static'>1</vcpu>
Add a usb1 & usb2 qemuxml2argv test
2011-09-05 07:07:01 +00:00
<os>
qemuxml2argvdata: Replace 'qemu-system-i386' by 'qemu-system-x86_64' in most test files Replace the emulator and architecture to x86_64, for all non-cpu related test cases. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-08-10 14:00:50 +00:00
<type arch='x86_64' machine='pc'>hvm</type>
Add a usb1 & usb2 qemuxml2argv test
2011-09-05 07:07:01 +00:00
<boot dev='hd'/>
</os>
<devices>
qemuxml2argvdata: Replace 'qemu-system-i386' by 'qemu-system-x86_64' in most test files Replace the emulator and architecture to x86_64, for all non-cpu related test cases. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-08-10 14:00:50 +00:00
<emulator>/usr/bin/qemu-system-x86_64</emulator>
Add a usb1 & usb2 qemuxml2argv test
2011-09-05 07:07:01 +00:00
<memballoon model='virtio'/>
<controller type='usb' index='0' model='piix3-uhci'>
<address type='pci' domain='0' bus='0' slot='1' function='2'/>
</controller>
<controller type='usb' index='1' model='ich9-ehci1'>
<address type='pci' domain='0' bus='0' slot='4' function='7'/>
</controller>
<controller type='usb' index='1' model='ich9-uhci1'>
<master startport='0'/>
qemu: make PCI multifunction support more manual When support for was added for PCI multifunction cards (in commit 9f8baf, first included in libvirt 0.9.3), it was done by always turning on the multifunction bit for all PCI devices. Since that time it has been realized that this is not an ideal solution, and that the multifunction bit must be selectively turned on. For example, see https://bugzilla.redhat.com/show_bug.cgi?id=728174 and the discussion before and after https://www.redhat.com/archives/libvir-list/2011-September/msg01036.html This patch modifies multifunction support so that the multifunction=on option is only added to the qemu commandline for a device if its PCI <address> definition has the attribute "multifunction='on'", e.g.: <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> In practice, the multifunction bit should only be turned on if function='0' AND other functions will be used in the same slot - it usually isn't needed for functions 1-7 (although there are apparently some exceptions, e.g. the Intel X53 according to the QEMU source code), and should never be set if only function 0 will be used in the slot. The test cases have been changed accordingly to illustrate. With this patch in place, if a user attempts to assign multiple functions in a slot without setting the multifunction bit for function 0, libvirt will issue an error when the domain is defined, and the define operation will fail. In the future, we may decide to detect this situation and automatically add multifunction=on to avoid the error; even then it will still be useful to have a manual method of turning on multifunction since, as stated above, there are some devices that excpect it to be turned on for all functions in a slot. A side effect of this patch is that attempts to use the same PCI address for two different devices will now log an error (previously this would cause the domain define operation to fail, but there would be no log message generated). Because the function doing this log was almost completely rewritten, I didn't think it worthwhile to make a separate patch for that fix (the entire patch would immediately be obsoleted).
2011-09-29 17:00:32 +00:00
<address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/>
Add a usb1 & usb2 qemuxml2argv test
2011-09-05 07:07:01 +00:00
</controller>
<controller type='usb' index='1' model='ich9-uhci2'>
<master startport='2'/>
<address type='pci' domain='0' bus='0' slot='4' function='1'/>
</controller>
<controller type='usb' index='1' model='ich9-uhci3'>
<master startport='4'/>
<address type='pci' domain='0' bus='0' slot='4' function='2'/>
</controller>
<controller type='usb' index='2' model='ich9-ehci1'>
<address type='pci' domain='0' bus='0' slot='5' function='7'/>
</controller>
<controller type='usb' index='2' model='ich9-uhci1'>
<master startport='0'/>
qemu: make PCI multifunction support more manual When support for was added for PCI multifunction cards (in commit 9f8baf, first included in libvirt 0.9.3), it was done by always turning on the multifunction bit for all PCI devices. Since that time it has been realized that this is not an ideal solution, and that the multifunction bit must be selectively turned on. For example, see https://bugzilla.redhat.com/show_bug.cgi?id=728174 and the discussion before and after https://www.redhat.com/archives/libvir-list/2011-September/msg01036.html This patch modifies multifunction support so that the multifunction=on option is only added to the qemu commandline for a device if its PCI <address> definition has the attribute "multifunction='on'", e.g.: <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> In practice, the multifunction bit should only be turned on if function='0' AND other functions will be used in the same slot - it usually isn't needed for functions 1-7 (although there are apparently some exceptions, e.g. the Intel X53 according to the QEMU source code), and should never be set if only function 0 will be used in the slot. The test cases have been changed accordingly to illustrate. With this patch in place, if a user attempts to assign multiple functions in a slot without setting the multifunction bit for function 0, libvirt will issue an error when the domain is defined, and the define operation will fail. In the future, we may decide to detect this situation and automatically add multifunction=on to avoid the error; even then it will still be useful to have a manual method of turning on multifunction since, as stated above, there are some devices that excpect it to be turned on for all functions in a slot. A side effect of this patch is that attempts to use the same PCI address for two different devices will now log an error (previously this would cause the domain define operation to fail, but there would be no log message generated). Because the function doing this log was almost completely rewritten, I didn't think it worthwhile to make a separate patch for that fix (the entire patch would immediately be obsoleted).
2011-09-29 17:00:32 +00:00
<address type='pci' domain='0' bus='0' slot='5' function='0' multifunction='on'/>
Add a usb1 & usb2 qemuxml2argv test
2011-09-05 07:07:01 +00:00
</controller>
<controller type='usb' index='2' model='ich9-uhci2'>
<master startport='2'/>
<address type='pci' domain='0' bus='0' slot='5' function='1'/>
</controller>
<controller type='usb' index='2' model='ich9-uhci3'>
<master startport='4'/>
<address type='pci' domain='0' bus='0' slot='5' function='2'/>
</controller>
<input type='tablet' bus='usb'>
<address type='usb' bus='0' port='2'/>
</input>
<hub type='usb'>
<address type='usb' bus='1' port='1'/>
</hub>
<hostdev mode='subsystem' type='usb'>
<source>
<address bus='14' device='6'/>
</source>
<address type='usb' bus='2' port='1'/>
</hostdev>
<hostdev mode='subsystem' type='usb'>
<source>
<address bus='14' device='7'/>
</source>
<address type='usb' bus='2' port='2'/>
</hostdev>
</devices>
</domain>
Reference in New Issue Copy Permalink