- 28 8月, 2018 1 次提交
-
-
由 Andrea Bolognani 提交于
The affected functions are virDeviceInfoPCIAddressWanted() virDeviceInfoPCIAddressPresent() which get renamed to virDeviceInfoPCIAddressIsWanted() virDeviceInfoPCIAddressIsPresent() to comply with the naming convention used for other predicates. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 8月, 2018 4 次提交
-
-
由 Lubomir Rintel 提交于
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Lubomir Rintel 提交于
We're going to need to assign virtio-mmio addresses to non-ARM guests soon, so let's create a generic wrapper that calls to the architecture-specific implementation. Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Lubomir Rintel 提交于
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Lubomir Rintel 提交于
They're ARM specific. Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 07 8月, 2018 1 次提交
-
-
由 Boris Fiuczynski 提交于
Add support and tests for vhost-vsock-ccw. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
-
- 31 7月, 2018 1 次提交
-
-
由 Erik Skultety 提交于
Commit d48813e8 made sure we wouldn't get one for i440fx, but not for Q35 machine type. If the primary video didn't get the assumed 0:0:1.0 PCI address, the evaluation then failed with: "Cannot automatically add a new PCI bus for a device with connect flags 00" https://bugzilla.redhat.com/show_bug.cgi?id=1609087Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 19 7月, 2018 1 次提交
-
-
由 Erik Skultety 提交于
Historically, we've always enabled an emulated video device every time we see that graphics should be supported with a guest. With the appearance of mediated devices which can support QEMU's vfio-display capability, users might want to use such a device as the only video device. Therefore introduce a new, effectively a 'disable', type for video device. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 10 7月, 2018 1 次提交
-
-
由 Erik Skultety 提交于
Since 133fb140 moved the validation of a video device into a separate function, the code handling PCI slot assignment for video devices has been the same for both the primary device and the secondary devices. Let's merge these and thus handle all the devices within the existing 'for' loop. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 7月, 2018 1 次提交
-
-
由 Anya Harter 提交于
from src/qemu/qemu_domain_address.c to src/conf/domain_addr.c and rename to virDomainCCWAddressSetCreateFromDomain (rename to have Address in full instead of Addr to follow the naming convention of other virDomainCCWAddress functions) Signed-off-by: NAnya Harter <aharter@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 29 5月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
Add a new 'vsock' element for the vsock device. The 'model' attribute is optional. A <source cid> subelement should be used to specify the guest cid, or <source auto='yes'/> should be used. https://bugzilla.redhat.com/show_bug.cgi?id=1291851Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 15 5月, 2018 2 次提交
-
-
Introduces the vfio-ccw model for mediated devices and prime vfio-ccw devices such that CCW address will be generated. Alters the qemuxml2xmltest for testing a basic mdev device using vfio-ccw. Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
Add the function virHostdevIsMdevDevice() which detects whether a hostdev is a mediated device or not. Also, replace all existing conditionals. Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 14 5月, 2018 1 次提交
-
-
Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments which identify support for ccw devices. The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7. The QEMU_CAPS_CCW capability is based on the existence of the QEMU type. Let us also add the capability QEMU_CAPS_CCW to the tests which require support for ccw devices. Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 5月, 2018 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 06 4月, 2018 3 次提交
-
-
由 Andrea Bolognani 提交于
Just like the existing areMultipleRootsSupported, this will allow us to change the results of the driver-agnostic PCI address allocation logic based on whether the QEMU binary supports certain features. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Andrea Bolognani 提交于
The new controller will not yet be used automatically by libvirt, but at this point it's already possible to configure a guest to use it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Andrea Bolognani 提交于
We're going to add a similarly-named attribute later, and we'd like to be consistent. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 3月, 2018 1 次提交
-
-
由 Farhan Ali 提交于
QEMU on S390 (since v2.11) can support the virtio-gpu-ccw device, which can be used as a video device. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
-
- 16 3月, 2018 2 次提交
-
-
由 Farhan Ali 提交于
commit 7210cef4 'qemu: build command line for virtio input devices' introduced an error, by checking if input bus type is VIR_DOMAIN_DISK_BUS_VIRTIO. Fix it by using the correct bus type for input devices. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Farhan Ali 提交于
Commit id '177db487' renamed 'qemuValidateDevicePCISlotsChipsets' to 'qemuDomainValidateDevicePCISlotsChipsets', but didn't adjust comment. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 13 3月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
Since data.count is not a pointer, but an integer, compare it against an integer value instead of using the implicit "boolean" conversion that is customarily used for pointers. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 07 3月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
If the user tries to define a domain that has <controller type='usb' model='none'/> and also some USB devices, we report an error: error: internal error: No free USB ports Which is technically still correct for a domain with no USB ports. Change it to: USB is disabled for this domain, but USB devices are present in the domain XML https://bugzilla.redhat.com/show_bug.cgi?id=1347550Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 22 2月, 2018 1 次提交
-
-
由 John Ferlan 提交于
Rather than having the caller check, if the input @addrs is NULL (e.g. priv->usbaddrs), then just return 0. This also removes the need for ATTRIBUTE_NONNULL which only really helped if someone passed a NULL as a parameter not if the passed parameter is NULL. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 20 2月, 2018 2 次提交
-
-
由 Daniel P. Berrangé 提交于
GCC 8 became more fussy about detecting switch fallthroughs. First it doesn't like it if you have a fallthrough attribute that is not before a case statement. e.g. FOO: BAR: WIZZ: ATTRIBUTE_FALLTHROUGH; Is unacceptable as there's no final case statement, so while FOO & BAR are falling through, WIZZ is not falling through. IOW, GCC wants us to write FOO: BAR: ATTRIBUTE_FALLTHROUGH; WIZZ: Second, it will report risk of fallthrough even if you have a case statement for every single enum value, but only if the switch is nested inside another switch and the outer case statement has no final break. This is is arguably valid because despite the fact that we have cast from "int" to the enum typedef, nothing guarantees that the variable we're switching on only contains values that have corresponding switch labels. e.g. int domstate = 87539319; switch ((virDomainState)domstate) { ... } will not match enum value, but also not raise any kind of compiler warning. So it is right to complain about risk of fallthrough if no default: is present. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The controller model is slightly unusual in that the default value is -1, not 0. As a result the default value is not covered by any of the existing enum cases. This in turn means that any switch() statements that think they have covered all cases, will in fact not match the default value at all. In the qemuDomainDeviceCalculatePCIConnectFlags() method this has caused a serious mistake where we fallthrough from the SCSI controller case, to the VirtioSerial controller case, and from the USB controller case to the IDE controller case. By adding explicit enum constant starting at -1, we can ensure switches remember to handle the default case. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 2月, 2018 1 次提交
-
-
由 Daniel P. Berrangé 提交于
Currently the QEMU driver will call directly into the network driver impl to modify resolve the atual type of NICs with type=network. It has todo this before it has allocated the actual NIC. This introduces a callback system to allow us to decouple the QEMU driver from the network driver. This is a short term step, as it ought to be possible to achieve the same end goal by simply querying XML via the public network API. The QEMU code in question though, has no virConnectPtr conveniently available at this time. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 01 2月, 2018 6 次提交
-
-
由 John Ferlan 提交于
Now that the controller model is updated during post parse callback, this code no longer needs to fetch the model based on the capabilities and can just return the model directly if the controller is found. Removal of @qemuCaps cascades through various callers which are now updated to not pass the capabilities.
-
由 John Ferlan 提交于
Now that post parse processing handles setting the SCSI controller model, there's no need to call qemuDomainGetSCSIControllerModel to get the "default controller" when building the command line controller string or when assigning the spaprvio address since the controller model value will already be filled in.
-
由 John Ferlan 提交于
During post parse processing, let's force setting the controller model to default value if not already set for defined controllers (e.g. the non implicit ones).
-
由 John Ferlan 提交于
Rename and rework qemuDomainSetSCSIControllerModel since we're really not setting the SCSI controller model. Instead the code is either returning the existing SCSI controller model value, the default value based on the capabilities, or -1 with the error set.
-
由 John Ferlan 提交于
Rather than repeat multiple steps in order to find the SCSI controller model, let's combine them into one helper that will return either the model from the definition or the default model based on the capabilities. This patch adds an extra check/error that the controller that's being found actually exists. This just clarifies that the error was because the controller doesn't exist rather than the more generic error that we were unable to determine the model from qemuDomainSetSCSIControllerModel when a -1 was passed in and the capabilities were unable to find one.
-
由 John Ferlan 提交于
Rather than one function serving two purposes, let's split out the else condition which is checking whether the model can be used during command line building based on the capabilities. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 21 1月, 2018 1 次提交
-
-
由 Laine Stump 提交于
Commit 10c73bf1 fixed a bug that I had introduced back in commit 70249927 - if a vhost-scsi device had no manually assigned PCI address, one wouldn't be assigned automatically. There was a slight problem with the logic of the fix though - in the case of domains with pcie-root (e.g. those with a q35 machinetype), qemuDomainDeviceCalculatePCIConnectFlags() will attempt to determine if the host-side PCI device is Express or legacy by examining sysfs based on the host-side PCI address stored in hostdev->source.subsys.u.pci.addr, but that part of the union is only valid for PCI hostdevs, *not* for SCSI hostdevs. So we end up trying to read sysfs for some probably-non-existent device, which fails, and the function virPCIDeviceIsPCIExpress() returns failure (-1). By coincidence, the return value is being examined as a boolean, and since -1 is true, we still end up assigning the vhost-scsi device to an Express slot, but that is just by chance (and could fail in the case that the gibberish in the "hostside PCI address" was the address of a real device that happened to be legacy PCI). Since (according to Paolo Bonzini) vhost-scsi devices appear just like virtio-scsi devices in the guest, they should follow the same rules as virtio devices when deciding whether they should be placed in an Express or a legacy slot. That's accomplished in this patch by returning early with virtioFlags, rather than erroneously using hostdev->source.subsys.u.pci.addr. It also adds a test case for PCIe to assure it doesn't get broken in the future.
-
- 14 12月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Commit id '70249927' neglected to cover this case because the test had taken the "shortcut" to already add the <address>; however, when the PCI address assignment code was adjusted by commit id '70249927' the vhost-scsi (VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI_HOST) wasn't covered thus returning a 0 for pciFlags. So I altered the tests too to make sure it doesn't happen again. Previously the qemuxml2xmloutdata was a softlink to the source qemuxml2argvdata, so I unlinked and recreated the output file to force generation of the adddress. Without the test changes, an address generation returns: libvirt: Domain Config error : internal error: Cannot automatically add a new PCI bus for a device with connect flags 00 if an address was supplied in the test, a restart of libvirtd or edit of a guest would display the following opaque message: warning : qemuDomainCollectPCIAddress:1237 : qemuDomainDeviceCalculatePCIConnectFlags() thinks that the device with PCI address 0000:00:09.0 should not have a PCI address where the address is related to the guest PCI address provided.
-
- 28 11月, 2017 5 次提交
-
-
由 Pino Toscano 提交于
Introduce specific a target types with two models for the console devices (sclp and sclplm) used in s390 and s390x guests, so isa-serial is no more used for them. This makes <serial> usable on s390 and s390x guests, with at most only a single sclpconsole and one sclplmconsole devices usable in a single guest (due to limitations in QEMU, which will enforce already at runtime). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449265Signed-off-by: NPino Toscano <ptoscano@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Andrea Bolognani 提交于
We can finally introduce a specific target model for the pl011 device used by mach-virt guests, which means isa-serial will no longer show up to confuse users. We make sure migration works in both directions by interpreting the isa-serial target type, or the lack of target type, appropriately when parsing the guest XML, and skipping the newly-introduced type when formatting if for migration. We also verify that pl011 is not used for non-mach-virt guests and add a bunch of test cases. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=151292Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Andrea Bolognani 提交于
The existing implementation set the address type for all serial devices to spapr-vio, which made it impossible to use other devices such as usb-serial and pci-serial; moreover, some decisions were made based on the address type rather than the device type. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1512934Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Andrea Bolognani 提交于
We can finally introduce a specific target model for the spapr-vty device used by pSeries guests, which means isa-serial will no longer show up to confuse users. We make sure migration works in both directions by interpreting the isa-serial target type, or the lack of target type, appropriately when parsing the guest XML, and skipping the newly-introduced type when formatting if for migration. We also verify that spapr-vty is not used for non-pSeries guests and add a bunch of test cases. This commit is best viewed with 'git show -w'. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511421Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Andrea Bolognani 提交于
This is the first step in getting rid of the assumption that isa-serial is the default target type for serial devices. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-