- 17 10月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
The code is entirely correct, but it still managed to trip me up when I first ran into it because I did not realize right away that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVICE and VIR_PCI_CONNECT_TYPE_PCIE_DEVICE. In order to save the next distracted traveler in PCI Address Land some time, document this fact with a comment. Add a test case for the behavior as well.
-
- 15 10月, 2016 1 次提交
-
-
由 Laine Stump 提交于
A pci-bridge has *almost* the same rules as a legacy PCI endpoint device for where it can be automatically connected, and until now both had been considered identical. There is one pairing that is okay when specifically requested by the user (i.e. manual assignment), but we want to avoid it when auto-assigning addresses - plugging a pci-bridge directly into pcie-root (it is cleaner to plug in a dmi-to-pci-bridge, then plug the pci-bridge into that). In order to allow that difference, this patch makes a separate CONNECT_TYPE for pci-bridge, and uses it to restrict auto-assigned addresses for pci-bridges to be only on pci-root, pci-expander-bus, dmi-to-pci-bridge, or on another pci-bridge. NB: As with other discouraged-but-seem-to-work configurations (e.g. plugging a legacy PCI device into a pcie-root-port) if someone *really* wants to, they can still force a pci-bridge to be plugged into pcie-root (by manually specifying its PCI address.)
-
- 14 10月, 2016 21 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1357416 Rather than return a 0 or -1 and the *result string, return just the result string to the caller. Alter all the callers to handle the different return. As a side effect or result of this, it's much clearer that we cannot just assign the returned string into the scsi_host wwnn, wwpn, and fabric_wwn fields - rather we should fetch a temporary string, then as long as our fetch was good, VIR_FREE what may have been there, and STEAL what we just got. This fixes a memory leak in the virNodeDeviceCreateXML code path through find_new_device and nodeDeviceLookupSCSIHostByWWN which will continually call nodeDeviceSysfsGetSCSIHostCaps until the expected wwnn/wwpn is found in the device object capabilities. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Without them we're keeping <alias/> even for inactive XML. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
As with all other devices, it's not part of 'address'. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1366108 There are couple of things that needs to be done in order to allow vhost-user hotplug. Firstly, vhost-user requires a chardev which is connected to vhost-user bridge and through which qemu communicates with the bridge (no acutal guest traffic is sent through there, just some metadata). In order to generate proper chardev alias, we must assign device alias way sooner. Then, because we are plugging the chardev first, we need to do the proper undo if something fails - that is remove netdev too. We don't want anything to be left over in case attach fails at some point. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1366505 So far, this function lacked support for VIR_DOMAIN_NET_TYPE_VHOSTUSER leaving callers to hack around the problem by constructing the command line on their own. This is not ideal as it blocks hot plug support. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Currently, what we do for vhost-user network is generate the following part of command line: -netdev type=vhost-user,id=hostnet0,chardev=charnet0 There's no need for 'type=' it is the default. Drop it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There's no need to reinvent the wheel here. We already have a function to format virDomainChrSourceDefPtr. It's called qemuBuildChrChardevStr(). Use that instead of some dummy virBufferAsprintf(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This alone makes not much sense. But the aim is to reuse this function in qemuBuildVhostuserCommandLine() where 'nowait' is not supported for vhost-user devices. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We tend to prevent using 'default' in switches. And it is for a good reason - control may end up in paths we wouldn't want for new values. In this specific case, if qemuBuildHostNetStr is called over VIR_DOMAIN_NET_TYPE_VHOSTUSER it would produce meaningless output. Fortunately, there no such call yet. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Instead of blindly claim support for hot-plugging of every interface type out there we should copy approach we have for device types: white listing supported types and explicitly error out on unsupported ones. For instance, trying to hotplug vhostuser interface results in nothing usable from guest currently. vhostuser typed interfaces require additional work on our side. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The idea is to have function that does some checking at its beginning and then have one big switch for all the interface types it supports. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The idea is to have function that does some checking of the arguments at its beginning and then have one big switch for all the interface types it supports. Each one of them generating the corresponding part of the command line. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The idea is to have function that does some checking of the arguments at its beginning and then have one big switch for all the interface types it supports. Each one of them generating the corresponding part of the command line. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This function for some weird reason returns integer instead of virDomainNetType type. It is important to return the correct type so that we know what values we can expect. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There are couple of formatting issues. No functional change though. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Not every system out there has syslog, that's why we check for it in our configure script. However, in 640b58ab while fixing another issue, some variables and functions are called that are defined only when syslog.h is present. But these function calls/variables were not guarded by #ifdef-s. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The smbios docs allow any string to be passed and libvirt does not really do any validation on them. Allow passing any string. Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373535
-
由 Peter Krempa 提交于
We pass free-form strings from the users to qemu, thus we need escape commas since they are passed to qemu monitor. Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373535
-
由 Peter Krempa 提交于
qemuBuildSmbiosBiosStr and qemuBuildSmbiosSystemStr return NULL if there's nothing to format on the commandline. Reporting errors from buffer creation doesn't make sense since it would be ignored.
-
由 Peter Krempa 提交于
-
- 13 10月, 2016 6 次提交
-
-
由 Michal Privoznik 提交于
This initially started as a fix of some debug printing in virCgroupDetect. However it turned out that other places suffer from the similar problem. While dealing with pids, esp. in cases where we cannot use pid_t for ABI stability reasons, we often chose an unsigned integer type. This makes no sense as pid_t is signed. Also, new syntax-check rule is introduced so we won't repeat this mistake. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ivan Baldo 提交于
It is stated in the manual already, so let's mention the same thing in the description to avoid causing problems. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
Consider the following scenario: virsh # freecell --all 0: 2048 KiB 1: 4096 KiB -------------------- Total: 6144 KiB virsh # freecell 0 0: 2048 KiB virsh # freecell 1 1: 4096 KiB And now before this change: virsh # freecell 2 After this change: virsh # freecell 2 error: invalid argument: Range exceeds available cells Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We have inclination to calling our loop variables i, j, k, not u. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 12 10月, 2016 11 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1369633Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
There are two video devices with models without VGA compatibility mode. They are primary used as secondary video devices, but in some cases it is required to use them also as primary video devices. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
This improves commit 706b5b62 in a way that we check qemu capabilities instead of what architecture we are running on to detect whether we can use *virtio-vga* model or not. This is not a case only for arm/aarch64. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Commit 21373feb added support for primary virtio-vga device but it was checking for virtio-gpu. Let's check for existence of virtio-vga if we want to use it. Virtio video device is currently represented by three different models *virtio-gpu-device*, *virtio-gpu-pci* and *virtio-vga*. The first two models are tied together and if virtio video devices is compiled in they both exist. However, the *virtio-vga* model doesn't have to exist on some architectures even if the first two models exist. So we cannot group all three together. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Before this patch we've checked qemu capabilities for video devices only while constructing qemu command line using "-device" option. Since we support qemu only if "-device" option is present we can use the same capabilities to check also video devices while using "-vga" option to construct qemu command line. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Runtime validation that depend on qemu capabilities should be moved into qemuProcessStartValidateXML. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
All definition validation that doesn't depend on qemu capabilities and was allowed previously as valid definition should be placed into qemuDomainDefValidate. The check whether video type is supported or not was based on an enum that translates type into model. Use switch to ensure that if new video type is added, it will be properly handled. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-