- 26 4月, 2016 2 次提交
-
-
由 Cole Robinson 提交于
Currently we only allow /dev/random and /dev/hwrng as host input for <rng><backend model='random'/> device. This was added after various upstream discussions in commit 4932ef45 However this restriction has generated quite a few complaints over the years, so a new discussion was initiated: http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html Several people suggested removing the restriction, and nobody really spoke up to defend it. So this patch drops the path restriction entirely https://bugzilla.redhat.com/show_bug.cgi?id=1074464
-
由 Cole Robinson 提交于
The hex range already tried to allow for it, but it wasn't using the correct XML hex syntax. Fix it, and test it
-
- 19 4月, 2016 1 次提交
-
-
由 John Ferlan 提交于
While working on the tests for the secret initialization vector, I found that the existing iSCSI tests were lacking in how they defined the IQN. Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using 'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess how they were copied/generated). Typically (and documented this way), IQN's would include be of the form 'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for naming authority specific string and "/1" for the iSCSI LUN. So modify the input XML's to use the more proper format - this of course has a ripple effect on the output XML and the args. Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri to represent the colon. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 15 4月, 2016 5 次提交
-
-
由 Laine Stump 提交于
This is backed by the qemu device pxb-pcie, which will be available in qemu 2.6.0. As with pci-expander-bus (which uses qemu's pxb device), the busNr attribute and <node> subelement of <target> are used to set the bus_nr and numa_node options. During post-parse we validate that the domain's machinetype is q35-based (since the device shows up for 440fx-based machinetypes, but is unusable), as well as checking that <node> specifies a node that is actually configured on the guest.
-
由 Laine Stump 提交于
This controller provides a single PCIe port on a new root. It is similar to pci-expander-bus, intended to provide a bus that can be associated with a guest-identifiable NUMA node, but is for machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes). Aside from PCIe vs. PCI, the other main difference is that a pci-expander-bus has a companion pci-bridge that is automatically attached along with it, but pcie-expander-bus has only a single port, and that port will only connect to a pcie-root-port, or to a pcie-switch-upstream-port. In order for the bus to be of any use in the guest, it must have either a pcie-root-port or a pcie-switch-upstream-port attached (and one or more pcie-switch-downstream-ports attached to the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
This is backed by the qemu device "pxb". The pxb device always includes a pci-bridge that is at the bus number of the pxb + 1. busNr and <node> from the <target> subelement are used to set the bus_nr and numa_node options for pxb. During post-parse we validate that the domain's machinetype is 440fx-based (since the pxb device only works on 440fx-based machines), and <node> also gets a sanity check to assure that the NUMA node specified for the pxb (if any - it's optional) actually exists on the guest.
-
由 Laine Stump 提交于
This is a standard PCI root bus (not a bridge) that can be added to a 440fx-based domain. Although it uses a PCI slot, this is *not* how it is connected into the PCI bus hierarchy, but is only used for control. Each pci-expander-bus provides 32 slots (0-31) that can accept hotplug of standard PCI devices. The usefulness of pci-expander-bus relative to a pci-bridge is that the NUMA node of the bus can be specified with the <node> subelement of <target>. This gives guest-side visibility to the NUMA node of attached devices (presuming that management apps only assign a device to a bus that has a NUMA node number matching the node number of the device on the host). Each pci-expander-bus also has a "busNr" attribute. The expander-bus itself will take the busNr specified, and all buses that are connected to this bus (including the pci-bridge that is automatically added to any expander bus of model "pxb" (see the next commit)) will use busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next lower busNr) will use bus numbers lower than busNr.
-
由 Laine Stump 提交于
When support for dmi-to-pci-bridge was added, it was assumed that, just as with the pci-root bus, slot 0 was reserved. This is not the case - it can be used to connect a device just like any other slot, so remove the restriction and update the test cases that auto-assign an address on a dmi-to-pci-bridge.
-
- 11 4月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Commit dc98a5bc refactored the code a lot and forget about checking if listen attribute is specified. This ensures that listen attribute and first listen element are compared only if both exist. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 08 4月, 2016 2 次提交
-
-
由 Pavel Hrdina 提交于
After the test and qemu_process refactor now we can benefit from default listen address for spice and vnc in tests. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Ján Tomko 提交于
Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
-
- 07 4月, 2016 1 次提交
-
-
由 John Ferlan 提交于
If the -object secret capability exists, then get the path to the masterKey file and provide that to qemu. Checking for the existence of the file before passing to qemu could be done, but causes issues in mock test environment. Since the qemuDomainObjPrivate is not available when building the command line, the qemuBuildHasMasterKey API will have to suffice as the primary arbiter for whether the capability exists in order to find/return the path to the master key for usage. Created the qemuDomainGetMasterKeyAlias API which will be used by later patches to define the 'keyid' (eg, masterKey) to be used by other secrets to provide the id to qemu for the master key.
-
- 29 3月, 2016 1 次提交
-
-
由 Maxim Nestratov 提交于
This patch adds support for "vpindex", "runtime", "synic", "stimer", and "vendor_id" features available in qemu 2.5+. - When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX to get virtual processor ID. - Hyper-V "runtime" enlightement feature allows to use MSR HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes running guest code, as well as the time the hypervisor spends running code on behalf of that guest. - Hyper-V "synic" stands for Synthetic Interrupt Controller, which is lapic extension controlled via MSRs. - Hyper-V "stimer" switches on Hyper-V SynIC timers MSR's support. Guest can setup and use fired by host events (SynIC interrupt and appropriate timer expiration message) as guest clock events - Hyper-V "reset" allows guest to reset VM. - Hyper-V "vendor_id" exposes hypervisor vendor id to guest. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 3月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
After 9c17d665 the tap device for ethernet network type is automatically precreated before spawning qemu. Problem is, the qemuxml2argvtest wasn't updated and thus is failing. Because of all the APIs that new code is calling, I had to mock a lot. Also, since the tap FDs are labeled separately from the rest of the devices/files I had to enable NOP security driver for the test too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 22 3月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Update testutilsqemu to overwrite libDir and channelTargetDir and set private paths using domain's privateData. This changes is required for following patch. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 21 3月, 2016 2 次提交
-
-
由 Christophe Fergeau 提交于
If a <graphics type='spice'> has no port nor tlsPort set, the generated QEMU command line will contain -spice port=0. This is later going to be ignored by spice-server, but it's better not to add it at all in this situation. As an empty -spice is not allowed, we still need to append port=0 if we did not add any other argument.
-
由 Christophe Fergeau 提交于
Currently -spice addr=127.0.0.1 is generated, but spice-server is going to ignore this as no port is specified.
-
- 11 3月, 2016 2 次提交
-
-
由 Marc-André Lureau 提交于
When debug-threads is enabled, individual threads are given a separate name (on Linux) Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1140121Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 10 3月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
Honour the <log file='...'/> element in chardevs to output data to a file. This requires QEMU >= 2.6 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 01 3月, 2016 5 次提交
-
-
由 Alexander Burluka 提交于
Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>
-
由 Pavel Hrdina 提交于
This attribute is used to extend secondary PCI bar and expose it to the guest as 64bit memory. It works like this: attribute vram is there to set size of secondary PCI bar and guest sees it as 32bit memory, attribute vram64 can extend this secondary PCI bar. If both attributes are used, guest sees two memory bars, both address the same memory, with the difference that the 32bit bar can address only the first part of the whole memory. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260749Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
We always place primary video device at first place, to make it easier to create a qemu command or format an xml, but we should also set the primary boolean for primary video device to 'true'. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Marc-André Lureau 提交于
Add Spice graphics gl attribute. qemu 2.6 should have -spice gl=on argument to enable opengl rendering context (patches on the ML). This is necessary to actually enable virgl rendering. Add a qemuxml2argv test for virtio-gpu + spice with virgl. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Martin Kletzander 提交于
Per-domain directories were introduced in order to be able to completely separate security labels for each domain (commit f1f68ca3). However when the domain name is long (let's say a ridiculous 110 characters), we cannot connect to the monitor socket because on length of UNIX socket address is limited. In order to get around this, let's shorten it in similar fashion and in order to avoid conflicts, throw in an ID there as well. Also save that into the status XML and load the old status XMLs properly (to clean up after older domains). That way we can change it in the future. The shortening can be seen in qemuxml2argv tests, for example in the hugepages-pages2 case. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 26 2月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Commit f1a89a8b allowed parsing configs from /etc/libvirt without validating the emulator capabilities. Check for the presence of a machine type in the qemu driver's post parse function instead of crashing. https://bugzilla.redhat.com/show_bug.cgi?id=1267256
-
- 22 2月, 2016 1 次提交
-
-
由 Paolo Bonzini 提交于
This does nothing more than adding the new device and capability. The device is present since QEMU 2.6.0. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 16 2月, 2016 3 次提交
-
-
由 Andrea Bolognani 提交于
Test all kinds of scenarios, including guests asking for GIC but failing to specify a version, guests specifying an invalid version and guests trying to use GIC with non-virt or even non-ARM machines.
-
由 Andrea Bolognani 提交于
Unify the naming to prepare for new test cases that will be added later on. Convert a couple of output XML files for the qemuxml2xml test to symlinks while at it, since they were identical to the corresponding input XML files anyways. Moreover, since we're only interested in testing GIC support here, simplify XML files by getting rid of the unrelevant bits.
-
由 Andrea Bolognani 提交于
GIC is always available to ARM virt machines, and the domain XML should reflect this fact.
-
- 10 2月, 2016 3 次提交
-
-
由 Cole Robinson 提交于
Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
-
由 Cole Robinson 提交于
QEMU_CAPS_DEVICE is always enabled for qemu binaries we support. Sync qemuxml2* to match, and regenerate all test output.
-
由 Cole Robinson 提交于
When we unconditionally enable QEMU_CAPS_DEVICE, these tests need some massaging, so do it ahead of time to not mix it in with the big test refresh. - minimal-s390 is not a real world working config, so drop it - disk-usb was testing for an old code path that will be removed. instead use it to test lack of USB disk support, and rename it to disk-usb-nosupport. Switch xml2xml to use disk-usb-device for input. - cputune-numatune was needlessly using q35, switch it to an older machine type
-
- 27 1月, 2016 2 次提交
-
-
由 Pavel Hrdina 提交于
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: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Those tests are in qemuargv2xmltest and it makes sense to include them also in qemuxml2xmltest and qemuxml2argvtest. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 26 1月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
A future patch will refactor the storage of the pinning information in a way where the ordering will be lost. Order them numerically to avoid changing the tests later.
-
- 12 1月, 2016 3 次提交
-
-
由 Dmitry Andreev 提交于
Autodeflate can be enabled/disabled for memballon device of model 'virtio'. xml: <devices> <memballoon model='virtio' autodeflate='on'/> </devices> qemu: qemu -device virtio-balloon-pci,...,deflate-on-oom=on Autodeflate cannot be enabled/disabled for running domain.
-
由 Laine Stump 提交于
Use virDomainDefAddUSBController() to add an EHCI1+UHCI1+UHCI2+UHCI3 controller set to newly defined Q35 domains that don't have any USB controllers defined.
-
由 Laine Stump 提交于
The real Q35 machine puts the first USB controller set (EHCI+(UHCIx4)) on bus 0 slot 0x1D, and the 2nd USB controller set on bus 0 slot 0x1A, so let's attempt to make the virtual machine match that for controllers with auto-assigned addresses when possible. Three test cases were added to assure that the proper addresses are assigned - one with a single set of unaddressed USB controllers, one with 3 (to grab both preferred slots plus one more), and one with the order of the controller definitions reordered, to assure that the auto-assignment isn't mixed up by order.
-
- 11 1月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
If the q35 specific disable s3/s4 setting isn't supported, fallback to specifying the PIIX setting, which is the previous behavior. It doesn't have any effect, but qemu will just warn about it rather than error: qemu-system-x86_64: Warning: global PIIX4_PM.disable_s3=1 not used qemu-system-x86_64: Warning: global PIIX4_PM.disable_s4=1 not used Since it doesn't error, I don't think we should either, since there may be configs in the wild that already have q35 + disable_s3/4 (via virt-manager)
-