2011-06-08 04:34:04 +00:00
|
|
|
LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M \
|
|
|
|
|
pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults \
|
|
|
|
|
-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \
|
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
|
|
|
-device lsi,id=scsi0,bus=pci.0,multifunction=off,addr=0x3 \
|
|
|
|
|
-device lsi,id=scsi1,bus=pci.0,multifunction=on,addr=0x4 \
|
2011-06-08 04:34:04 +00:00
|
|
|
-device lsi,id=scsi2,bus=pci.0,multifunction=on,addr=0x4.0x1 \
|
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
|
|
|
-device lsi,id=scsi3,bus=pci.0,addr=0x4.0x2 \
|
|
|
|
|
-device lsi,id=scsi4,bus=pci.0,addr=0x4.0x3 \
|
|
|
|
|
-device lsi,id=scsi5,bus=pci.0,addr=0x4.0x4 \
|
|
|
|
|
-device lsi,id=scsi6,bus=pci.0,addr=0x4.0x5 \
|
|
|
|
|
-device lsi,id=scsi7,bus=pci.0,addr=0x4.0x6 \
|
|
|
|
|
-device lsi,id=scsi8,bus=pci.0,addr=0x4.0x7 \
|
2012-10-26 09:09:22 +00:00
|
|
|
-usb -drive file=/tmp/scsidisk.img,if=none,id=drive-scsi0-0-0 \
|
2011-06-08 04:34:04 +00:00
|
|
|
-device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 \
|
2012-10-26 09:09:22 +00:00
|
|
|
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
|
