- 13 5月, 2013 1 次提交
-
-
由 Han Cheng 提交于
Adding two cap flags for scsi-generic: QEMU_CAPS_SCSI_GENERIC QEMU_CAPS_SCSI_GENERIC_BOOTINDEX Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: NOsier Yang <jyang@redhat.com>
-
- 25 3月, 2013 1 次提交
-
-
由 Eric Blake 提交于
This reverts commit 5ac846e4. After further discussions with Alon Levy, I learned the following: The use of '-vga qxl' vs. '-device qxl-vga' is completely orthogonal to whether ram_size can be exposed. Downstream distros are interested in backporting support for multi-head qxl, but this can be done in one of two ways: 1. Support one head per PCI device. If you do this, then it makes sense to have full control over the PCI address of each device. For full control, you need '-device qxl-vga' instead of '-vga qxl'. 2. Support multiple heads through a single PCI device. If you do this, then you need to allocate more RAM to that PCI device (enough ram to cover the multiple screens). Here, the device is hard-coded to 0:0:2.0, both in qemu and libvirt code. Apparently, backporting ram_size changes to allow multiple heads in a single device is much easier than backporting multiple device support. Furthermore, the presence or absence of qxl-vga.surfaces is no different than the presence or absence of qxl-vga.ram_size; both properties can be applied regardless of whether you have one PCI device (-vga qxl) or multiple (-device qxl-vga), so this property is NOT a good witness of whether '-device qxl-vga' support has been backported. Downstream RHEL will NOT be using this patch; and worse, leaving this patch in risks doing the wrong thing if compiling upstream libvirt on RHEL, so the best course of action is to revert it. That means that libvirt will go back to only using '-device qxl-vga' for qemu >= 1.2, but this is just fine because we know of no distros that plan on backporting multiple PCI address support to any older version of qemu. Meanwhile, downstream can still use ram_size to pack multiple heads through a single PCI device.
-
- 14 3月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Multi-head QXL support is so useful that distros have started to backport it to qemu earlier than 1.2. After discussion with Alon Levy, we determined that the existence of the qxl-vga.surfaces property is a reliable indicator of whether '-device qxl-vga' works, or whether we have to stick to the older '-vga qxl'. I'm leaving in the existing check for QEMU_CAPS_DEVICE_VIDEO_PRIMARY tied to qemu 1.2 and newer (in case qemu is built without qxl support), but for those distros that backport qxl, this additional capability check will allow the correct command line for both RHEL 6.3 (which lacks the feature) and RHEL 6.4 (where qemu still claims to be version 0.12.2.x, but has backported multi-head qxl). * src/qemu/qemu_capabilities.c (virQEMUCapsObjectPropsQxlVga): New property test. (virQEMUCapsExtractDeviceStr): Probe for backport of new capability to qemu earlier than 1.2. * tests/qemuhelpdata/qemu-kvm-1.2.0-device: Update test. * tests/qemuhelpdata/qemu-1.2.0-device: Likewise. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta-device: Likewise.
-
- 23 11月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
I was convicted that space at EOL should no be there even for qemu help data. Hence, I've removed one in commit bb2f6216. However, it turns out we want it exactly the way qemu produces it. So I should undo my premature fix. A patch against qemu has been posted as well.
-
- 22 11月, 2012 1 次提交
-
-
由 Ján Tomko 提交于
Both generated with qemu-system-x86_64 --help > qemu-1.2.0 qemu-system-x86_64 \ -device ? \ -device pci-assign,? \ -device virtio-blk-pci,? \ -device virtio-net-pci,? \ -device scsi-disk,? \ -device PIIX4_PM,? \ -device usb-redir,? \ -device ide-drive,? \ -device usb-host,? 2> qemu-1.2.0-device It seems I missed a few -device flags when doing this last time and I mixed up qemu and qemu-kvm.
-
- 18 9月, 2012 1 次提交
-
-
由 Ján Tomko 提交于
Generated with: qemu-system-x86_64 -help >tests/qemuhelpdata/qemu-1.2.0 qemu-system-x86_64 \ -device ? \ -device pci-assign,? \ -device virtio-blk-pci,? \ -device virtio-net-pci,? \ -device scsi-disk,? 2>tests/qemuhelpdata/qemu-1.2.0-device
-
- 05 6月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
QEMU 1.1.0 has been officially released. With 1.1.0 QEMU went back to three-digits version even for the initial release and I renamed the data files to match this fact. They were generated with qemu-system-x86_64 -help >tests/qemuhelpdata/qemu-1.1.0 qemu-system-x86_64 \ -device ? \ -device pci-assign,? \ -device virtio-blk-pci,? \ -device virtio-net-pci,? \ -device scsi-disk,? 2>tests/qemuhelpdata/qemu-1.1.0-device
-
- 16 5月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
Thanks to this new option we are now able to use modern CPU models (such as Westmere) defined in external configuration file. The qemu-1.1{,-device} data files for qemuhelptest are filled in with qemu-1.1-rc2 output for now. I will update those files with real qemu-1.1 output once it is released.
-
- 05 12月, 2011 1 次提交
-
-
由 Jiri Denemark 提交于
-
- 07 10月, 2011 1 次提交
-
-
由 Eric Blake 提交于
Now that RHEL 6.2 Beta is out, it would be nice to test multifunction devices on that platform. This changes things so that the multifunction cap bit can be set in two different ways: by version comparison (needed for qemu 0.13 which lacked a -device query), and by -device query (provided by qemu.git and backported to the RHEL beta build of qemu-kvm which still claims to be a modified 0.12, and therefore needed for RHEL). * src/qemu/qemu_capabilities.c (qemuCapsParseDeviceStr): Allow second method of setting multifunction cap bit. * tests/qemuhelptest.c (mymain): Test it. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta: New file. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta-device: Likewise.
-
- 18 2月, 2011 1 次提交
-
-
由 Laine Stump 提交于
This is in response to: https://bugzilla.redhat.com/show_bug.cgi?id=629662 Explanation qemu's virtio-net-pci driver allows setting the algorithm used for tx packets to either "bh" or "timer". This is done by adding ",tx=bh" or ",tx=timer" to the "-device virtio-net-pci" commandline option. 'bh' stands for 'bottom half'; when this is set, packet tx is all done in an iothread in the bottom half of the driver. (In libvirt, this option is called the more descriptive "iothread".) 'timer' means that tx work is done in qemu, and if there is more tx data than can be sent at the present time, a timer is set before qemu moves on to do other things; when the timer fires, another attempt is made to send more data. (libvirt retains the name "timer" for this option.) The resulting difference, according to the qemu developer who added the option is: bh makes tx more asynchronous and reduces latency, but potentially causes more processor bandwidth contention since the cpu doing the tx isn't necessarily the cpu where the guest generated the packets. Solution This patch provides a libvirt domain xml knob to change the option on the qemu commandline, by adding a new attribute "txmode" to the <driver> element that can be placed inside any <interface> element in a domain definition. It's use would be something like this: <interface ...> ... <model type='virtio'/> <driver txmode='iothread'/> ... </interface> I chose to put this setting as an attribute to <driver> rather than as a sub-element to <tune> because it is specific to the virtio-net driver, not something that is generally usable by all network drivers. (note that this is the same placement as the "driver name=..." attribute used to choose kernel vs. userland backend for the virtio-net driver.) Actually adding the tx=xxx option to the qemu commandline is only done if the version of qemu being used advertises it in the output of qemu -device virtio-net-pci,? If a particular txmode is requested in the XML, and the option isn't listed in that help output, an UNSUPPORTED_CONFIG error is logged, and the domain fails to start.
-
- 04 2月, 2011 1 次提交
-
-
由 Eric Blake 提交于
Qemu smartcard/spicevmc support exists on branches (such as http://cgit.freedesktop.org/~alon/qemu/commit/?h=usb_ccid.v15&id=024a37b) but is not yet upstream. The added -help output matches a scratch build that will be close to the RHEL 6.1 qemu-kvm. * src/qemu/qemu_capabilities.h (QEMUD_CMD_FLAG_CCID_EMULATED) (QEMUD_CMD_FLAG_CCID_PASSTHRU, QEMUD_CMD_FLAG_CHARDEV_SPICEVMC): New flags. * src/qemu/qemu_capabilities.c (qemuCapsComputeCmdFlags) (qemuCapsParseDeviceStr): Check for smartcard capabilities. (qemuCapsExtractVersionInfo): Tweak comment. * tests/qemuhelptest.c (mymain): New test. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61: New file. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61-device: Likewise.
-
- 14 1月, 2011 1 次提交
-
-
由 Eric Blake 提交于
* src/qemu/qemu_capabilities.h (qemuCapsParseDeviceStr): New prototype. * src/qemu/qemu_capabilities.c (qemuCapsParsePCIDeviceStrs) Rename and split... (qemuCapsExtractDeviceStr, qemuCapsParseDeviceStr): ...to make it easier to add and test device-specific checks. (qemuCapsExtractVersionInfo): Update caller. * tests/qemuhelptest.c (testHelpStrParsing): Also test parsing of device-related flags. (mymain): Update expected flags. * tests/qemuhelpdata/qemu-0.12.1-device: New file. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel60-device: New file. * tests/qemuhelpdata/qemu-kvm-0.12.3-device: New file. * tests/qemuhelpdata/qemu-kvm-0.13.0-device: New file.
-
- 14 12月, 2010 2 次提交
-
-
由 Eric Blake 提交于
* tests/qemuhelpdata/qemu-kvm-0.13.0: New file. * tests/qemuhelptest.c (mymain): New test from Fedora 14 qemu-kvm, which covers some options (like -fstype passthrough) not tested elsewhere.
-
由 Eric Blake 提交于
* tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel60: New file. * tests/qemuhelptest.c (mymain): New test from RHEL 6.0 qemu-kvm, which covers some options (like -vga=qxl) not tested elsewhere. * .x-sc_prohibit_empty_lines_at_EOF: Exempt qemu help output.
-
- 26 10月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
So far, readonly=on option is used when qemu supports -device. However, there are qemu versions which support readonly option with -drive although they don't have support for -device.
-
- 18 5月, 2010 1 次提交
-
-
由 Eric Blake 提交于
(gdb) p/x QEMUD_CMD_FLAG_VNET_HOST $7 = 0xffffffff80000000 Oops - that meant we were incorrectly setting QEMU_CMD_FLAG_RTC_TD_HACK for qemu-kvm-0.12.3 (and probably botching a few other settings as well). Fixes Red Hat BZ#592070 * src/qemu/qemu_conf.h (QEMUD_CMD_FLAG_VNET_HOST): Avoid sign extension. * tests/qemuhelpdata/qemu-kvm-0.12.3: New file. * tests/qemuhelptest.c (mymain): Add another case.
-
- 18 1月, 2010 1 次提交
-
-
由 Daniel P. Berrange 提交于
Probe for the new -device flag and if available set the -nodefaults flag, instead of using -net none, -serial none or -parallel none. Other device types will be converted to use -device in later patches. The -nodefaults flag will help avoid unwelcome surprises from future QEMU releases * src/qemu/qemu_conf.c: Probe for -device. Add -nodefaults flag. Remove -net none, -serial none or -parallel none * src/qemu/qemu_conf.h: Define QEMU_CMD_FLAG_DEVICE * tests/qemuhelpdata/qemu-0.12.1: New data file for 0.12.1 QEMU * tests/qemuhelptest.c: Test feature extraction from 0.12.1 QEMU
-
- 10 9月, 2009 1 次提交
-
-
由 Mark McLoughlin 提交于
* tests/qemuhelpdata/qemu-kvm-0.11.0-rc2: add data * tests/qemuhelptest.c: add expected output
-
- 11 6月, 2009 1 次提交
-
-
由 Mark McLoughlin 提交于
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
-