From: Yi Min Zhao <zyimin@linux.ibm.com>
This patch introduces a new attribute PCI address extension flag
to deal with the extension PCI attributes such as 'uid' and 'fid'
on the S390 platform.
Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
---
src/conf/device_conf.h | 1 +
src/conf/domain_addr.h | 5 ++
src/qemu/qemu_domain_address.c | 137 ++++++++++++++++++++++++++++++++++++++++-
3 files changed, 141 insertions(+), 2 deletions(-)
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index a31ce9c376..6f926dff1d 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -164,6 +164,7 @@ struct _virDomainDeviceInfo {
* assignment, never saved and never reported.
*/
int pciConnectFlags; /* enum virDomainPCIConnectFlags */
+ int pciAddressExtFlags; /* enum virDomainPCIAddressExtensionFlags */
char *loadparm;
/* PCI devices will only be automatically placed on a PCI bus
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index 3236b7d6de..1d1837bd23 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -29,6 +29,11 @@
# define VIR_PCI_ADDRESS_SLOT_LAST 31
# define VIR_PCI_ADDRESS_FUNCTION_LAST 7
+typedef enum {
+ VIR_PCI_ADDRESS_EXTENSION_NONE = 0, /* no extension */
+ VIR_PCI_ADDRESS_EXTENSION_ZPCI = 1 << 0, /* zpci support */
+} virDomainPCIAddressExtensionFlags;
+
typedef enum {
VIR_PCI_CONNECT_HOTPLUGGABLE = 1 << 0, /* is hotplug needed/supported */
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index b7c82cb6f1..adce399be6 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -502,6 +502,60 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
}
+static bool
+qemuDomainDeviceSupportZPCI(virQEMUCapsPtr qemuCaps,
+ virDomainDeviceDefPtr device)
+{
+ if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI))
+ return false;
+
+ switch ((virDomainDeviceType) device->type) {
+ case VIR_DOMAIN_DEVICE_CONTROLLER:
+ case VIR_DOMAIN_DEVICE_CHR:
+ return false;
+
+ case VIR_DOMAIN_DEVICE_NONE:
+ case VIR_DOMAIN_DEVICE_DISK:
+ case VIR_DOMAIN_DEVICE_LEASE:
+ case VIR_DOMAIN_DEVICE_FS:
+ case VIR_DOMAIN_DEVICE_NET:
+ case VIR_DOMAIN_DEVICE_INPUT:
+ case VIR_DOMAIN_DEVICE_SOUND:
+ case VIR_DOMAIN_DEVICE_VIDEO:
+ case VIR_DOMAIN_DEVICE_HOSTDEV:
+ case VIR_DOMAIN_DEVICE_WATCHDOG:
+ case VIR_DOMAIN_DEVICE_GRAPHICS:
+ case VIR_DOMAIN_DEVICE_HUB:
+ case VIR_DOMAIN_DEVICE_REDIRDEV:
+ case VIR_DOMAIN_DEVICE_SMARTCARD:
+ case VIR_DOMAIN_DEVICE_MEMBALLOON:
+ case VIR_DOMAIN_DEVICE_NVRAM:
+ case VIR_DOMAIN_DEVICE_RNG:
+ case VIR_DOMAIN_DEVICE_SHMEM:
+ case VIR_DOMAIN_DEVICE_TPM:
+ case VIR_DOMAIN_DEVICE_PANIC:
+ case VIR_DOMAIN_DEVICE_MEMORY:
+ case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_LAST:
+ break;
+ }
+ return true;
+}
+
+
+static virDomainPCIAddressExtensionFlags
+qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCapsPtr qemuCaps,
+ virDomainDeviceDefPtr dev)
+{
+ virDomainPCIAddressExtensionFlags extFlags = 0;
+
+ if (qemuDomainDeviceSupportZPCI(qemuCaps, dev))
+ extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
+
+ return extFlags;
+}
+
+
/**
* qemuDomainDeviceCalculatePCIConnectFlags:
*
@@ -980,6 +1034,55 @@ qemuDomainFillAllPCIConnectFlags(virDomainDefPtr def,
}
+/**
+ * qemuDomainFillDevicePCIExtensionFlagsIter:
+ *
+ * @def: the entire DomainDef
+ * @dev: The device to be checked
+ * @info: virDomainDeviceInfo within the device
+ * @opaque: qemu capabilities
+ *
+ * Sets the pciAddressExtFlags for a single device's info. Has properly
+ * formatted arguments to be called by virDomainDeviceInfoIterate().
+ *
+ * Always returns 0 - there is no failure.
+ */
+static int
+qemuDomainFillDevicePCIExtensionFlagsIter(virDomainDefPtr def ATTRIBUTE_UNUSED,
+ virDomainDeviceDefPtr dev,
+ virDomainDeviceInfoPtr info,
+ void *opaque)
+{
+ virQEMUCapsPtr qemuCaps = opaque;
+
+ info->pciAddressExtFlags
+ = qemuDomainDeviceCalculatePCIAddressExtensionFlags(qemuCaps, dev);
+ return 0;
+}
+
+
+/**
+ * qemuDomainFillAllPCIExtensionFlags:
+ *
+ * @def: the entire DomainDef
+ * @qemuCaps: as you'd expect
+ *
+ * Set the info->pciAddressExtFlags for all devices in the domain.
+ *
+ * Returns 0 on success or -1 on failure (the only possibility of
+ * failure would be some internal problem with
+ * virDomainDeviceInfoIterate())
+ */
+static int
+qemuDomainFillAllPCIExtensionFlags(virDomainDefPtr def,
+ virQEMUCapsPtr qemuCaps)
+{
+ return virDomainDeviceInfoIterate(def,
+ qemuDomainFillDevicePCIExtensionFlagsIter,
+ qemuCaps);
+}
+
+
/**
* qemuDomainFindUnusedIsolationGroupIter:
* @def: domain definition
@@ -1254,6 +1357,29 @@ qemuDomainFillDevicePCIConnectFlags(virDomainDefPtr def,
}
+/**
+ * qemuDomainFillDevicePCIExtensionFlags:
+ *
+ * @dev: The device to be checked
+ * @qemuCaps: as you'd expect
+ *
+ * Set the info->pciAddressExtFlags for a single device.
+ *
+ * No return value.
+ */
+static void
+qemuDomainFillDevicePCIExtensionFlags(virDomainDeviceDefPtr dev,
+ virQEMUCapsPtr qemuCaps)
+{
+ virDomainDeviceInfoPtr info = virDomainDeviceGetInfo(dev);
+
+ if (info) {
+ info->pciAddressExtFlags
+ = qemuDomainDeviceCalculatePCIAddressExtensionFlags(qemuCaps, dev);
+ }
+}
+
+
static int
qemuDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev)
@@ -2380,6 +2506,9 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
if (qemuDomainFillAllPCIConnectFlags(def, qemuCaps, driver) < 0)
goto cleanup;
+ if (qemuDomainFillAllPCIExtensionFlags(def, qemuCaps) < 0)
+ goto cleanup;
+
if (qemuDomainSetupIsolationGroups(def) < 0)
goto cleanup;
@@ -2415,7 +2544,8 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
*/
virDomainDeviceInfo info = {
.pciConnectFlags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
- VIR_PCI_CONNECT_TYPE_PCI_DEVICE)
+ VIR_PCI_CONNECT_TYPE_PCI_DEVICE),
+ .pciAddressExtFlags = VIR_PCI_ADDRESS_EXTENSION_NONE
};
bool buses_reserved = true;
@@ -2452,7 +2582,8 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
qemuDomainHasPCIeRoot(def)) {
virDomainDeviceInfo info = {
.pciConnectFlags = (VIR_PCI_CONNECT_HOTPLUGGABLE |
- VIR_PCI_CONNECT_TYPE_PCIE_DEVICE)
+ VIR_PCI_CONNECT_TYPE_PCIE_DEVICE),
+ .pciAddressExtFlags = VIR_PCI_ADDRESS_EXTENSION_NONE
};
/* if there isn't an empty pcie-root-port, this will
@@ -2969,6 +3100,8 @@ qemuDomainEnsurePCIAddress(virDomainObjPtr obj,
qemuDomainFillDevicePCIConnectFlags(obj->def, dev, priv->qemuCaps, driver);
+ qemuDomainFillDevicePCIExtensionFlags(dev, priv->qemuCaps);
+
return virDomainPCIAddressEnsureAddr(priv->pciaddrs, info,
info->pciConnectFlags);
}
--
2.16.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, May 24, 2018 at 02:24:28PM +0200, Xiao Feng Ren wrote:
>From: Yi Min Zhao <zyimin@linux.ibm.com>
>
>This patch introduces a new attribute PCI address extension flag
>to deal with the extension PCI attributes such as 'uid' and 'fid'
>on the S390 platform.
>
>Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
>Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
>---
> src/conf/device_conf.h | 1 +
> src/conf/domain_addr.h | 5 ++
> src/qemu/qemu_domain_address.c | 137 ++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 141 insertions(+), 2 deletions(-)
>
>diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
>index b7c82cb6f1..adce399be6 100644
>--- a/src/qemu/qemu_domain_address.c
>+++ b/src/qemu/qemu_domain_address.c
>@@ -502,6 +502,60 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
> }
>
>
>+static bool
>+qemuDomainDeviceSupportZPCI(virQEMUCapsPtr qemuCaps,
>+ virDomainDeviceDefPtr device)
>+{
>+ if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI))
>+ return false;
There's no need to propagate qemuCaps all the way here,
if we don't have QEMU_CAPS_DEVICE_ZPCI, we don't care which devices
support it.
>+
>+ switch ((virDomainDeviceType) device->type) {
>+ case VIR_DOMAIN_DEVICE_CONTROLLER:
>+ case VIR_DOMAIN_DEVICE_CHR:
>+ return false;
Are these going to support it later? How will we detect that?
Jano
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
在 2018/6/2 下午10:15, Ján Tomko 写道:
> On Thu, May 24, 2018 at 02:24:28PM +0200, Xiao Feng Ren wrote:
>> From: Yi Min Zhao <zyimin@linux.ibm.com>
>>
>> This patch introduces a new attribute PCI address extension flag
>> to deal with the extension PCI attributes such as 'uid' and 'fid'
>> on the S390 platform.
>>
>> Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
>> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
>> ---
>> src/conf/device_conf.h | 1 +
>> src/conf/domain_addr.h | 5 ++
>> src/qemu/qemu_domain_address.c | 137
>> ++++++++++++++++++++++++++++++++++++++++-
>> 3 files changed, 141 insertions(+), 2 deletions(-)
>>
>
>> diff --git a/src/qemu/qemu_domain_address.c
>> b/src/qemu/qemu_domain_address.c
>> index b7c82cb6f1..adce399be6 100644
>> --- a/src/qemu/qemu_domain_address.c
>> +++ b/src/qemu/qemu_domain_address.c
>> @@ -502,6 +502,60 @@
>> qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
>> }
>>
>>
>> +static bool
>> +qemuDomainDeviceSupportZPCI(virQEMUCapsPtr qemuCaps,
>> + virDomainDeviceDefPtr device)
>> +{
>> + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI))
>> + return false;
>
> There's no need to propagate qemuCaps all the way here,
> if we don't have QEMU_CAPS_DEVICE_ZPCI, we don't care which devices
> support it.
>
For hotplug case, qemuDomainEnsurePCIAddress() should be called.
Then if we don't have QEMU_CAPS_DEVICE_ZPCI, we should not set
zPCI extension flag. Except checking qemuCaps, I don't know there's
any other way to check zPCI support. If we don't check zPCI cap, it would
return true for those supported device types, and then zPCI device would
be generated but qemu binary doesn't support that.
>> +
>> + switch ((virDomainDeviceType) device->type) {
>> + case VIR_DOMAIN_DEVICE_CONTROLLER:
>> + case VIR_DOMAIN_DEVICE_CHR:
>> + return false;
>
> Are these going to support it later? How will we detect that?
For now though, we won't support these in future. Actually I don't
know how to detect that via qemu interface. But anyway, we could
easily switch on support if any of them is supported on S390.
>
> Jano
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Jun 04, 2018 at 03:52:31PM +0800, Yi Min Zhao wrote:
>
>
>在 2018/6/2 下午10:15, Ján Tomko 写道:
>> On Thu, May 24, 2018 at 02:24:28PM +0200, Xiao Feng Ren wrote:
>>> From: Yi Min Zhao <zyimin@linux.ibm.com>
>>>
>>> This patch introduces a new attribute PCI address extension flag
>>> to deal with the extension PCI attributes such as 'uid' and 'fid'
>>> on the S390 platform.
>>>
>>> Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
>>> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
>>> ---
>>> src/conf/device_conf.h | 1 +
>>> src/conf/domain_addr.h | 5 ++
>>> src/qemu/qemu_domain_address.c | 137
>>> ++++++++++++++++++++++++++++++++++++++++-
>>> 3 files changed, 141 insertions(+), 2 deletions(-)
>>>
>>
>>> diff --git a/src/qemu/qemu_domain_address.c
>>> b/src/qemu/qemu_domain_address.c
>>> index b7c82cb6f1..adce399be6 100644
>>> --- a/src/qemu/qemu_domain_address.c
>>> +++ b/src/qemu/qemu_domain_address.c
>>> @@ -502,6 +502,60 @@
>>> qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
>>> }
>>>
>>>
>>> +static bool
>>> +qemuDomainDeviceSupportZPCI(virQEMUCapsPtr qemuCaps,
>>> + virDomainDeviceDefPtr device)
>>> +{
>>> + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI))
>>> + return false;
>>
>> There's no need to propagate qemuCaps all the way here,
>> if we don't have QEMU_CAPS_DEVICE_ZPCI, we don't care which devices
>> support it.
>>
>For hotplug case, qemuDomainEnsurePCIAddress() should be called.
>Then if we don't have QEMU_CAPS_DEVICE_ZPCI, we should not set
>zPCI extension flag. Except checking qemuCaps, I don't know there's
>any other way to check zPCI support. If we don't check zPCI cap, it would
>return true for those supported device types, and then zPCI device would
>be generated but qemu binary doesn't support that.
>
I meant checking the capability earlier and not even calling the
qemuDomainDeviceSupportZPCI if the capability is not there.
>>> +
>>> + switch ((virDomainDeviceType) device->type) {
>>> + case VIR_DOMAIN_DEVICE_CONTROLLER:
>>> + case VIR_DOMAIN_DEVICE_CHR:
>>> + return false;
>>
>> Are these going to support it later? How will we detect that?
>For now though, we won't support these in future. Actually I don't
>know how to detect that via qemu interface. But anyway, we could
>easily switch on support if any of them is supported on S390.
The last two sentences contradict each other - if we cannot easily probe
it and the devices do not support it now, by turning on the support
later we will break the usage of libvirt with QEMUs where these devices
did not support it yet.
Jano
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
在 2018/6/4 下午10:08, Ján Tomko 写道:
> On Mon, Jun 04, 2018 at 03:52:31PM +0800, Yi Min Zhao wrote:
>>
>>
>> 在 2018/6/2 下午10:15, Ján Tomko 写道:
>>> On Thu, May 24, 2018 at 02:24:28PM +0200, Xiao Feng Ren wrote:
>>>> From: Yi Min Zhao <zyimin@linux.ibm.com>
>>>>
>>>> This patch introduces a new attribute PCI address extension flag
>>>> to deal with the extension PCI attributes such as 'uid' and 'fid'
>>>> on the S390 platform.
>>>>
>>>> Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
>>>> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
>>>> ---
>>>> src/conf/device_conf.h | 1 +
>>>> src/conf/domain_addr.h | 5 ++
>>>> src/qemu/qemu_domain_address.c | 137
>>>> ++++++++++++++++++++++++++++++++++++++++-
>>>> 3 files changed, 141 insertions(+), 2 deletions(-)
>>>>
>>>
>>>> diff --git a/src/qemu/qemu_domain_address.c
>>>> b/src/qemu/qemu_domain_address.c
>>>> index b7c82cb6f1..adce399be6 100644
>>>> --- a/src/qemu/qemu_domain_address.c
>>>> +++ b/src/qemu/qemu_domain_address.c
>>>> @@ -502,6 +502,60 @@
>>>> qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def,
>>>> }
>>>>
>>>>
>>>> +static bool
>>>> +qemuDomainDeviceSupportZPCI(virQEMUCapsPtr qemuCaps,
>>>> + virDomainDeviceDefPtr device)
>>>> +{
>>>> + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_ZPCI))
>>>> + return false;
>>>
>>> There's no need to propagate qemuCaps all the way here,
>>> if we don't have QEMU_CAPS_DEVICE_ZPCI, we don't care which devices
>>> support it.
>>>
>> For hotplug case, qemuDomainEnsurePCIAddress() should be called.
>> Then if we don't have QEMU_CAPS_DEVICE_ZPCI, we should not set
>> zPCI extension flag. Except checking qemuCaps, I don't know there's
>> any other way to check zPCI support. If we don't check zPCI cap, it
>> would
>> return true for those supported device types, and then zPCI device would
>> be generated but qemu binary doesn't support that.
>>
>
> I meant checking the capability earlier and not even calling the
> qemuDomainDeviceSupportZPCI if the capability is not there.
OK.
>>>> +
>>>> + switch ((virDomainDeviceType) device->type) {
>>>> + case VIR_DOMAIN_DEVICE_CONTROLLER:
>>>> + case VIR_DOMAIN_DEVICE_CHR:
>>>> + return false;
>>>
>>> Are these going to support it later? How will we detect that?
>> For now though, we won't support these in future. Actually I don't
>> know how to detect that via qemu interface. But anyway, we could
>> easily switch on support if any of them is supported on S390.
>
> The last two sentences contradict each other - if we cannot easily probe
> it and the devices do not support it now, by turning on the support
> later we will break the usage of libvirt with QEMUs where these devices
> did not support it yet.
Yes, that is a problem. But there's no proper way to probe which
device supports zPCI. There's a problem confusing me. To what degree
we consider it is supported. For example, a pci device could be plugged
to s390 phb but it can't be used in guest OS.
>
> Jano
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.