* [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
The patch set "Enable virtio_net to act as a standby for a passthru
device" [1] deals with live migration of guests that use passthrough
devices. However, that scheme uses the MAC address for pairing
the virtio device and the passthrough device. The thread "netvsc:
refactor notifier/event handling code to use the failover framework"
[2] discusses an alternate mechanism, such as using an UUID, for pairing
the devices. Based on that discussion, proposals "Add "Group Identifier"
to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
store pairing information..." [4] were made.
The current patch set includes all the feedback received for proposals [3]
and [4]. For the sake of completeness, patch for the virtio specification
is also included here. Following is the updated proposal.
1. Extend the virtio specification to include a new virtio PCI capability
"VIRTIO_PCI_CAP_GROUP_ID_CFG".
2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
The "uuid" is a string in UUID format.
3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
The "uuid" is a string in UUID format. Currently, PCIe bridge for
the Q35 model is supported.
4. The operator creates a unique identifier string using 'uuidgen'.
5. When the virtio device is created, the operator uses the "uuid" option
(for example, '-device virtio-net-pci,uuid="string"') and specifies
the UUID created in step 4.
QEMU stores the UUID in the virtio device's configuration space
in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
6. When assigning a PCI device to the guest in passthrough mode, the
operator first creates a bridge using the "uuid" option (for example,
'-device pcie-downstream,uuid="string"') to specify the UUID created
in step 4, and then attaches the passthrough device to the bridge.
QEMU stores the UUID in the configuration space of the bridge as
Vendor-Specific capability (0x09). The "Vendor" here is not to be
confused with a specific organization. Instead, the vendor of the
bridge is QEMU. To avoid mixing up with other bridges, the bridge
will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
option is specified. Otherwise, current defaults are used.
7. Patch 4 in patch series "Enable virtio_net to act as a standby for
a passthru device" [1] needs to be modified to use the UUID values
present in the bridge's configuration space and the virtio device's
configuration space instead of the MAC address for pairing the devices.
Thanks!
Venu
[1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
[2] https://www.spinics.net/lists/netdev/msg499011.html
[3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
[4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
Changes in v2:
- As Michael Tsirkin suggested, changed the virtio specification
to restrict the group identifier to be a 16-byte field, presented
entirely in the virtio device's configuration space.
- As Michael Tsirkin suggested, instead of tweaking the ioh3420
device with Red Hat vendor ID, create a new PCIe bridge device
named "pcie-downstream" with Red Hat Vendor ID, and include the
group identifier in this device.
- Added a new patch to enhance the "pci-bridge" device to support
the group identifier (for the i440FX model).
Venu Busireddy (4):
Add a true or false option to the DEFINE_PROP_UUID macro.
Add "Group Identifier" support to virtio devices.
Add "Group Identifier" support to Red Hat PCI bridge.
Add "Group Identifier" support to Red Hat PCI Express bridge.
default-configs/arm-softmmu.mak | 1 +
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/vmgenid.c | 2 +-
hw/pci-bridge/Makefile.objs | 1 +
hw/pci-bridge/pci_bridge_dev.c | 8 +
hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
hw/pci-bridge/pcie_downstream.h | 10 +
hw/pci/pci_bridge.c | 26 +++
hw/virtio/virtio-pci.c | 15 ++
hw/virtio/virtio-pci.h | 3 +-
include/hw/pci/pci.h | 3 +
include/hw/pci/pcie.h | 1 +
include/hw/qdev-properties.h | 4 +-
include/standard-headers/linux/virtio_pci.h | 8 +
15 files changed, 295 insertions(+), 4 deletions(-)
create mode 100644 hw/pci-bridge/pcie_downstream.c
create mode 100644 hw/pci-bridge/pcie_downstream.h
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
The patch set "Enable virtio_net to act as a standby for a passthru
device" [1] deals with live migration of guests that use passthrough
devices. However, that scheme uses the MAC address for pairing
the virtio device and the passthrough device. The thread "netvsc:
refactor notifier/event handling code to use the failover framework"
[2] discusses an alternate mechanism, such as using an UUID, for pairing
the devices. Based on that discussion, proposals "Add "Group Identifier"
to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
store pairing information..." [4] were made.
The current patch set includes all the feedback received for proposals [3]
and [4]. For the sake of completeness, patch for the virtio specification
is also included here. Following is the updated proposal.
1. Extend the virtio specification to include a new virtio PCI capability
"VIRTIO_PCI_CAP_GROUP_ID_CFG".
2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
The "uuid" is a string in UUID format.
3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
The "uuid" is a string in UUID format. Currently, PCIe bridge for
the Q35 model is supported.
4. The operator creates a unique identifier string using 'uuidgen'.
5. When the virtio device is created, the operator uses the "uuid" option
(for example, '-device virtio-net-pci,uuid="string"') and specifies
the UUID created in step 4.
QEMU stores the UUID in the virtio device's configuration space
in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
6. When assigning a PCI device to the guest in passthrough mode, the
operator first creates a bridge using the "uuid" option (for example,
'-device pcie-downstream,uuid="string"') to specify the UUID created
in step 4, and then attaches the passthrough device to the bridge.
QEMU stores the UUID in the configuration space of the bridge as
Vendor-Specific capability (0x09). The "Vendor" here is not to be
confused with a specific organization. Instead, the vendor of the
bridge is QEMU. To avoid mixing up with other bridges, the bridge
will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
option is specified. Otherwise, current defaults are used.
7. Patch 4 in patch series "Enable virtio_net to act as a standby for
a passthru device" [1] needs to be modified to use the UUID values
present in the bridge's configuration space and the virtio device's
configuration space instead of the MAC address for pairing the devices.
Thanks!
Venu
[1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
[2] https://www.spinics.net/lists/netdev/msg499011.html
[3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
[4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
Changes in v2:
- As Michael Tsirkin suggested, changed the virtio specification
to restrict the group identifier to be a 16-byte field, presented
entirely in the virtio device's configuration space.
- As Michael Tsirkin suggested, instead of tweaking the ioh3420
device with Red Hat vendor ID, create a new PCIe bridge device
named "pcie-downstream" with Red Hat Vendor ID, and include the
group identifier in this device.
- Added a new patch to enhance the "pci-bridge" device to support
the group identifier (for the i440FX model).
Venu Busireddy (4):
Add a true or false option to the DEFINE_PROP_UUID macro.
Add "Group Identifier" support to virtio devices.
Add "Group Identifier" support to Red Hat PCI bridge.
Add "Group Identifier" support to Red Hat PCI Express bridge.
default-configs/arm-softmmu.mak | 1 +
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/vmgenid.c | 2 +-
hw/pci-bridge/Makefile.objs | 1 +
hw/pci-bridge/pci_bridge_dev.c | 8 +
hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
hw/pci-bridge/pcie_downstream.h | 10 +
hw/pci/pci_bridge.c | 26 +++
hw/virtio/virtio-pci.c | 15 ++
hw/virtio/virtio-pci.h | 3 +-
include/hw/pci/pci.h | 3 +
include/hw/pci/pcie.h | 1 +
include/hw/qdev-properties.h | 4 +-
include/standard-headers/linux/virtio_pci.h | 8 +
15 files changed, 295 insertions(+), 4 deletions(-)
create mode 100644 hw/pci-bridge/pcie_downstream.c
create mode 100644 hw/pci-bridge/pcie_downstream.h
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* [Qemu-devel] [PATCH v2 1/4] Add a true or false option to the DEFINE_PROP_UUID macro.
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 3:49 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
It may not always be desirable to have a random UUID stuffed into the
'_field' member. Add a new boolean option '_default' that will allow
the caller to specify if a random UUID needs be generated or not.
Also modified the instance where this macro is used.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
hw/acpi/vmgenid.c | 2 +-
include/hw/qdev-properties.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
index d78b579a20..6d53757ee5 100644
--- a/hw/acpi/vmgenid.c
+++ b/hw/acpi/vmgenid.c
@@ -215,7 +215,7 @@ static void vmgenid_realize(DeviceState *dev, Error **errp)
}
static Property vmgenid_device_properties[] = {
- DEFINE_PROP_UUID(VMGENID_GUID, VmGenIdState, guid),
+ DEFINE_PROP_UUID(VMGENID_GUID, VmGenIdState, guid, true),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 4f60cc88f3..7d39a4bdcd 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -218,12 +218,12 @@ extern const PropertyInfo qdev_prop_off_auto_pcibar;
DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_off_auto_pcibar, \
OffAutoPCIBAR)
-#define DEFINE_PROP_UUID(_name, _state, _field) { \
+#define DEFINE_PROP_UUID(_name, _state, _field, _default) { \
.name = (_name), \
.info = &qdev_prop_uuid, \
.offset = offsetof(_state, _field) \
+ type_check(QemuUUID, typeof_field(_state, _field)), \
- .set_default = true, \
+ .set_default = _default, \
}
#define DEFINE_PROP_END_OF_LIST() \
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [virtio-dev] [PATCH v2 1/4] Add a true or false option to the DEFINE_PROP_UUID macro.
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
It may not always be desirable to have a random UUID stuffed into the
'_field' member. Add a new boolean option '_default' that will allow
the caller to specify if a random UUID needs be generated or not.
Also modified the instance where this macro is used.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
hw/acpi/vmgenid.c | 2 +-
include/hw/qdev-properties.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
index d78b579a20..6d53757ee5 100644
--- a/hw/acpi/vmgenid.c
+++ b/hw/acpi/vmgenid.c
@@ -215,7 +215,7 @@ static void vmgenid_realize(DeviceState *dev, Error **errp)
}
static Property vmgenid_device_properties[] = {
- DEFINE_PROP_UUID(VMGENID_GUID, VmGenIdState, guid),
+ DEFINE_PROP_UUID(VMGENID_GUID, VmGenIdState, guid, true),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 4f60cc88f3..7d39a4bdcd 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -218,12 +218,12 @@ extern const PropertyInfo qdev_prop_off_auto_pcibar;
DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_off_auto_pcibar, \
OffAutoPCIBAR)
-#define DEFINE_PROP_UUID(_name, _state, _field) { \
+#define DEFINE_PROP_UUID(_name, _state, _field, _default) { \
.name = (_name), \
.info = &qdev_prop_uuid, \
.offset = offsetof(_state, _field) \
+ type_check(QemuUUID, typeof_field(_state, _field)), \
- .set_default = true, \
+ .set_default = _default, \
}
#define DEFINE_PROP_END_OF_LIST() \
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [Qemu-devel] [PATCH v2 2/4] Add "Group Identifier" support to virtio devices.
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 3:49 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Use the virtio PCI capability "VIRTIO_PCI_CAP_GROUP_ID_CFG" to store the
"Group Identifier" (UUID) specified via the command line option "uuid"
for the virtio device. The capability will be present in the virtio
device's configuration space iff the "uuid" option is specified.
Group Identifier is used to pair a virtio device with a passthrough
device.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
hw/virtio/virtio-pci.c | 15 +++++++++++++++
hw/virtio/virtio-pci.h | 3 ++-
include/hw/pci/pci.h | 2 ++
include/standard-headers/linux/virtio_pci.h | 8 ++++++++
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 3a01fe90f0..42703a5567 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -36,6 +36,7 @@
#include "qemu/range.h"
#include "hw/virtio/virtio-bus.h"
#include "qapi/visitor.h"
+#include "qemu/uuid.h"
#define VIRTIO_PCI_REGION_SIZE(dev) VIRTIO_PCI_CONFIG_OFF(msix_present(dev))
@@ -1638,6 +1639,10 @@ static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
.cap.cap_len = sizeof cfg,
.cap.cfg_type = VIRTIO_PCI_CAP_PCI_CFG,
};
+ struct virtio_pci_group_id_cap group = {
+ .cap.cap_len = sizeof group,
+ .cap.cfg_type = VIRTIO_PCI_CAP_GROUP_ID_CFG,
+ };
struct virtio_pci_notify_cap notify_pio = {
.cap.cap_len = sizeof notify,
.notify_off_multiplier = cpu_to_le32(0x0),
@@ -1647,6 +1652,11 @@ static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
virtio_pci_modern_regions_init(proxy);
+ if (!qemu_uuid_is_null(&proxy->pci_dev.uuid)) {
+ memcpy(group.uuid, &proxy->pci_dev.uuid, sizeof(QemuUUID));
+ virtio_pci_modern_mem_region_map(proxy, &proxy->group, &group.cap);
+ }
+
virtio_pci_modern_mem_region_map(proxy, &proxy->common, &cap);
virtio_pci_modern_mem_region_map(proxy, &proxy->isr, &cap);
virtio_pci_modern_mem_region_map(proxy, &proxy->device, &cap);
@@ -1763,6 +1773,10 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error **errp)
proxy->device.size = 0x1000;
proxy->device.type = VIRTIO_PCI_CAP_DEVICE_CFG;
+ proxy->group.offset = 0;
+ proxy->group.size = 0;
+ proxy->group.type = VIRTIO_PCI_CAP_GROUP_ID_CFG;
+
proxy->notify.offset = 0x3000;
proxy->notify.size = virtio_pci_queue_mem_mult(proxy) * VIRTIO_QUEUE_MAX;
proxy->notify.type = VIRTIO_PCI_CAP_NOTIFY_CFG;
@@ -1898,6 +1912,7 @@ static Property virtio_pci_properties[] = {
VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
+ DEFINE_PROP_UUID("uuid", PCIDevice, uuid, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 813082b0d7..e4592e90bf 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -164,10 +164,11 @@ struct VirtIOPCIProxy {
VirtIOPCIRegion common;
VirtIOPCIRegion isr;
VirtIOPCIRegion device;
+ VirtIOPCIRegion group;
VirtIOPCIRegion notify;
VirtIOPCIRegion notify_pio;
};
- VirtIOPCIRegion regs[5];
+ VirtIOPCIRegion regs[6];
};
MemoryRegion modern_bar;
MemoryRegion io_bar;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 990d6fcbde..ee234c5a6f 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -4,6 +4,7 @@
#include "hw/qdev.h"
#include "exec/memory.h"
#include "sysemu/dma.h"
+#include "qemu/uuid.h"
/* PCI includes legacy ISA access. */
#include "hw/isa/isa.h"
@@ -343,6 +344,7 @@ struct PCIDevice {
bool has_rom;
MemoryRegion rom;
uint32_t rom_bar;
+ QemuUUID uuid;
/* INTx routing notifier */
PCIINTxRoutingNotifier intx_routing_notifier;
diff --git a/include/standard-headers/linux/virtio_pci.h b/include/standard-headers/linux/virtio_pci.h
index 9262acd130..f6de333f1d 100644
--- a/include/standard-headers/linux/virtio_pci.h
+++ b/include/standard-headers/linux/virtio_pci.h
@@ -113,6 +113,8 @@
#define VIRTIO_PCI_CAP_DEVICE_CFG 4
/* PCI configuration access */
#define VIRTIO_PCI_CAP_PCI_CFG 5
+/* Group Identifier */
+#define VIRTIO_PCI_CAP_GROUP_ID_CFG 6
/* This is the PCI capability header: */
struct virtio_pci_cap {
@@ -163,6 +165,12 @@ struct virtio_pci_cfg_cap {
uint8_t pci_cfg_data[4]; /* Data for BAR access. */
};
+/* Fields in VIRTIO_PCI_CAP_GROUP_ID_CFG: */
+struct virtio_pci_group_id_cap {
+ struct virtio_pci_cap cap;
+ uint8_t uuid[16];
+};
+
/* Macro versions of offsets for the Old Timers! */
#define VIRTIO_PCI_CAP_VNDR 0
#define VIRTIO_PCI_CAP_NEXT 1
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [virtio-dev] [PATCH v2 2/4] Add "Group Identifier" support to virtio devices.
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Use the virtio PCI capability "VIRTIO_PCI_CAP_GROUP_ID_CFG" to store the
"Group Identifier" (UUID) specified via the command line option "uuid"
for the virtio device. The capability will be present in the virtio
device's configuration space iff the "uuid" option is specified.
Group Identifier is used to pair a virtio device with a passthrough
device.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
hw/virtio/virtio-pci.c | 15 +++++++++++++++
hw/virtio/virtio-pci.h | 3 ++-
include/hw/pci/pci.h | 2 ++
include/standard-headers/linux/virtio_pci.h | 8 ++++++++
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 3a01fe90f0..42703a5567 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -36,6 +36,7 @@
#include "qemu/range.h"
#include "hw/virtio/virtio-bus.h"
#include "qapi/visitor.h"
+#include "qemu/uuid.h"
#define VIRTIO_PCI_REGION_SIZE(dev) VIRTIO_PCI_CONFIG_OFF(msix_present(dev))
@@ -1638,6 +1639,10 @@ static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
.cap.cap_len = sizeof cfg,
.cap.cfg_type = VIRTIO_PCI_CAP_PCI_CFG,
};
+ struct virtio_pci_group_id_cap group = {
+ .cap.cap_len = sizeof group,
+ .cap.cfg_type = VIRTIO_PCI_CAP_GROUP_ID_CFG,
+ };
struct virtio_pci_notify_cap notify_pio = {
.cap.cap_len = sizeof notify,
.notify_off_multiplier = cpu_to_le32(0x0),
@@ -1647,6 +1652,11 @@ static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
virtio_pci_modern_regions_init(proxy);
+ if (!qemu_uuid_is_null(&proxy->pci_dev.uuid)) {
+ memcpy(group.uuid, &proxy->pci_dev.uuid, sizeof(QemuUUID));
+ virtio_pci_modern_mem_region_map(proxy, &proxy->group, &group.cap);
+ }
+
virtio_pci_modern_mem_region_map(proxy, &proxy->common, &cap);
virtio_pci_modern_mem_region_map(proxy, &proxy->isr, &cap);
virtio_pci_modern_mem_region_map(proxy, &proxy->device, &cap);
@@ -1763,6 +1773,10 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error **errp)
proxy->device.size = 0x1000;
proxy->device.type = VIRTIO_PCI_CAP_DEVICE_CFG;
+ proxy->group.offset = 0;
+ proxy->group.size = 0;
+ proxy->group.type = VIRTIO_PCI_CAP_GROUP_ID_CFG;
+
proxy->notify.offset = 0x3000;
proxy->notify.size = virtio_pci_queue_mem_mult(proxy) * VIRTIO_QUEUE_MAX;
proxy->notify.type = VIRTIO_PCI_CAP_NOTIFY_CFG;
@@ -1898,6 +1912,7 @@ static Property virtio_pci_properties[] = {
VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
+ DEFINE_PROP_UUID("uuid", PCIDevice, uuid, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 813082b0d7..e4592e90bf 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -164,10 +164,11 @@ struct VirtIOPCIProxy {
VirtIOPCIRegion common;
VirtIOPCIRegion isr;
VirtIOPCIRegion device;
+ VirtIOPCIRegion group;
VirtIOPCIRegion notify;
VirtIOPCIRegion notify_pio;
};
- VirtIOPCIRegion regs[5];
+ VirtIOPCIRegion regs[6];
};
MemoryRegion modern_bar;
MemoryRegion io_bar;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 990d6fcbde..ee234c5a6f 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -4,6 +4,7 @@
#include "hw/qdev.h"
#include "exec/memory.h"
#include "sysemu/dma.h"
+#include "qemu/uuid.h"
/* PCI includes legacy ISA access. */
#include "hw/isa/isa.h"
@@ -343,6 +344,7 @@ struct PCIDevice {
bool has_rom;
MemoryRegion rom;
uint32_t rom_bar;
+ QemuUUID uuid;
/* INTx routing notifier */
PCIINTxRoutingNotifier intx_routing_notifier;
diff --git a/include/standard-headers/linux/virtio_pci.h b/include/standard-headers/linux/virtio_pci.h
index 9262acd130..f6de333f1d 100644
--- a/include/standard-headers/linux/virtio_pci.h
+++ b/include/standard-headers/linux/virtio_pci.h
@@ -113,6 +113,8 @@
#define VIRTIO_PCI_CAP_DEVICE_CFG 4
/* PCI configuration access */
#define VIRTIO_PCI_CAP_PCI_CFG 5
+/* Group Identifier */
+#define VIRTIO_PCI_CAP_GROUP_ID_CFG 6
/* This is the PCI capability header: */
struct virtio_pci_cap {
@@ -163,6 +165,12 @@ struct virtio_pci_cfg_cap {
uint8_t pci_cfg_data[4]; /* Data for BAR access. */
};
+/* Fields in VIRTIO_PCI_CAP_GROUP_ID_CFG: */
+struct virtio_pci_group_id_cap {
+ struct virtio_pci_cap cap;
+ uint8_t uuid[16];
+};
+
/* Macro versions of offsets for the Old Timers! */
#define VIRTIO_PCI_CAP_VNDR 0
#define VIRTIO_PCI_CAP_NEXT 1
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [Qemu-devel] [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 3:49 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
"pci-bridge", to contain the "Group Identifier" (UUID) that will be
used to pair a virtio device with the passthrough device attached to
that bridge.
This capability is added to the bridge iff the "uuid" option is specified
for the bridge.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
include/hw/pci/pcie.h | 1 +
3 files changed, 35 insertions(+)
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
index b2d861d216..bbbc6fa1c6 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
bridge_dev->msi = ON_OFF_AUTO_OFF;
}
+ err = pci_bridge_vendor_init(dev, 0, errp);
+ if (err < 0) {
+ error_append_hint(errp, "Can't init group ID, error %d\n", err);
+ goto vendor_cap_err;
+ }
+
err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
if (err) {
goto slotid_error;
@@ -109,6 +115,7 @@ slotid_error:
if (shpc_present(dev)) {
shpc_cleanup(dev, &bridge_dev->bar);
}
+vendor_cap_err:
shpc_error:
pci_bridge_exitfn(dev);
}
@@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
ON_OFF_AUTO_AUTO),
DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
PCI_BRIDGE_DEV_F_SHPC_REQ, true),
+ DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 40a39f57cb..cb8b3dad2a 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -34,12 +34,17 @@
#include "hw/pci/pci_bus.h"
#include "qemu/range.h"
#include "qapi/error.h"
+#include "qemu/uuid.h"
/* PCI bridge subsystem vendor ID helper functions */
#define PCI_SSVID_SIZEOF 8
#define PCI_SSVID_SVID 4
#define PCI_SSVID_SSID 6
+#define PCI_VENDOR_SIZEOF 20
+#define PCI_VENDOR_CAP_LEN_OFFSET 2
+#define PCI_VENDOR_GROUP_ID_OFFSET 4
+
int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
uint16_t svid, uint16_t ssid,
Error **errp)
@@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
return pos;
}
+int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
+{
+ int pos;
+
+ if (qemu_uuid_is_null(&d->uuid)) {
+ return 0;
+ }
+
+ pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
+ errp);
+ if (pos < 0) {
+ return pos;
+ }
+
+ pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
+ PCI_VENDOR_SIZEOF);
+ memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
+ sizeof(QemuUUID));
+ return pos;
+}
+
/* Accessor function to get parent bridge device from pci bus. */
PCIDevice *pci_bridge_get_device(PCIBus *bus)
{
diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
index b71e369703..b4189d0ce3 100644
--- a/include/hw/pci/pcie.h
+++ b/include/hw/pci/pcie.h
@@ -82,6 +82,7 @@ struct PCIExpressDevice {
};
#define COMPAT_PROP_PCP "power_controller_present"
+#define COMPAT_PROP_UUID "uuid"
/* PCI express capability helper functions */
int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [virtio-dev] [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
"pci-bridge", to contain the "Group Identifier" (UUID) that will be
used to pair a virtio device with the passthrough device attached to
that bridge.
This capability is added to the bridge iff the "uuid" option is specified
for the bridge.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
include/hw/pci/pcie.h | 1 +
3 files changed, 35 insertions(+)
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
index b2d861d216..bbbc6fa1c6 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
bridge_dev->msi = ON_OFF_AUTO_OFF;
}
+ err = pci_bridge_vendor_init(dev, 0, errp);
+ if (err < 0) {
+ error_append_hint(errp, "Can't init group ID, error %d\n", err);
+ goto vendor_cap_err;
+ }
+
err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
if (err) {
goto slotid_error;
@@ -109,6 +115,7 @@ slotid_error:
if (shpc_present(dev)) {
shpc_cleanup(dev, &bridge_dev->bar);
}
+vendor_cap_err:
shpc_error:
pci_bridge_exitfn(dev);
}
@@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
ON_OFF_AUTO_AUTO),
DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
PCI_BRIDGE_DEV_F_SHPC_REQ, true),
+ DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 40a39f57cb..cb8b3dad2a 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -34,12 +34,17 @@
#include "hw/pci/pci_bus.h"
#include "qemu/range.h"
#include "qapi/error.h"
+#include "qemu/uuid.h"
/* PCI bridge subsystem vendor ID helper functions */
#define PCI_SSVID_SIZEOF 8
#define PCI_SSVID_SVID 4
#define PCI_SSVID_SSID 6
+#define PCI_VENDOR_SIZEOF 20
+#define PCI_VENDOR_CAP_LEN_OFFSET 2
+#define PCI_VENDOR_GROUP_ID_OFFSET 4
+
int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
uint16_t svid, uint16_t ssid,
Error **errp)
@@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
return pos;
}
+int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
+{
+ int pos;
+
+ if (qemu_uuid_is_null(&d->uuid)) {
+ return 0;
+ }
+
+ pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
+ errp);
+ if (pos < 0) {
+ return pos;
+ }
+
+ pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
+ PCI_VENDOR_SIZEOF);
+ memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
+ sizeof(QemuUUID));
+ return pos;
+}
+
/* Accessor function to get parent bridge device from pci bus. */
PCIDevice *pci_bridge_get_device(PCIBus *bus)
{
diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
index b71e369703..b4189d0ce3 100644
--- a/include/hw/pci/pcie.h
+++ b/include/hw/pci/pcie.h
@@ -82,6 +82,7 @@ struct PCIExpressDevice {
};
#define COMPAT_PROP_PCP "power_controller_present"
+#define COMPAT_PROP_UUID "uuid"
/* PCI express capability helper functions */
int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [Qemu-devel] [PATCH v2 4/4] Add "Group Identifier" support to Red Hat PCI Express bridge.
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 3:49 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Add a new bridge device "pcie-downstream" with a Vendor ID of
PCI_VENDOR_ID_REDHAT and Device ID of PCI_DEVICE_ID_REDHAT_DOWNSTREAM.
Also add the "Vendor-Specific" capability to the bridge to contain the
"Group Identifier" (UUID) that will be used to pair a virtio device with
the passthrough device attached to that bridge.
This capability is added to the bridge iff the "uuid" option is specified
for the bridge.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
default-configs/arm-softmmu.mak | 1 +
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/pci-bridge/Makefile.objs | 1 +
hw/pci-bridge/pcie_downstream.c | 215 +++++++++++++++++++++++++++++
hw/pci-bridge/pcie_downstream.h | 10 ++
include/hw/pci/pci.h | 1 +
7 files changed, 230 insertions(+)
create mode 100644 hw/pci-bridge/pcie_downstream.c
create mode 100644 hw/pci-bridge/pcie_downstream.h
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 834d45cfaf..b86c6fb122 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -139,6 +139,7 @@ CONFIG_IMX_I2C=y
CONFIG_PCIE_PORT=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
+CONFIG_PCIE_DOWNSTREAM=y
CONFIG_I82801B11=y
CONFIG_ACPI=y
CONFIG_SMBIOS=y
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8c7d4a0fa0..a900c8f052 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -56,6 +56,7 @@ CONFIG_ACPI_NVDIMM=y
CONFIG_PCIE_PORT=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
+CONFIG_PCIE_DOWNSTREAM=y
CONFIG_I82801B11=y
CONFIG_SMBIOS=y
CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
diff --git a/default-configs/x86_64-softmmu.mak b/default-configs/x86_64-softmmu.mak
index 0390b4303c..481e4764be 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -56,6 +56,7 @@ CONFIG_ACPI_NVDIMM=y
CONFIG_PCIE_PORT=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
+CONFIG_PCIE_DOWNSTREAM=y
CONFIG_I82801B11=y
CONFIG_SMBIOS=y
CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
diff --git a/hw/pci-bridge/Makefile.objs b/hw/pci-bridge/Makefile.objs
index 47065f87d9..5b42212edc 100644
--- a/hw/pci-bridge/Makefile.objs
+++ b/hw/pci-bridge/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-$(CONFIG_PCIE_PORT) += pcie_root_port.o gen_pcie_root_port.o pcie_pci
common-obj-$(CONFIG_PXB) += pci_expander_bridge.o
common-obj-$(CONFIG_XIO3130) += xio3130_upstream.o xio3130_downstream.o
common-obj-$(CONFIG_IOH3420) += ioh3420.o
+common-obj-$(CONFIG_PCIE_DOWNSTREAM) += pcie_downstream.o
common-obj-$(CONFIG_I82801B11) += i82801b11.o
# NewWorld PowerMac
common-obj-$(CONFIG_DEC_PCI) += dec.o
diff --git a/hw/pci-bridge/pcie_downstream.c b/hw/pci-bridge/pcie_downstream.c
new file mode 100644
index 0000000000..78604504ea
--- /dev/null
+++ b/hw/pci-bridge/pcie_downstream.c
@@ -0,0 +1,215 @@
+/*
+ * Red Hat PCI Express downstream port.
+ *
+ * pcie_downstream.c
+ * Most of this code is copied from xio3130_downstream.c
+ *
+ * Copyright (c) 2018 Oracle and/or its affiliates.
+ * Author: Venu Busireddy <venu.busireddy@oracle.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/pci/pci_ids.h"
+#include "hw/pci/msi.h"
+#include "hw/pci/pcie.h"
+#include "pcie_downstream.h"
+#include "qapi/error.h"
+
+#define REDHAT_PCIE_DS_REVISION 0x1
+#define REDHAT_PCIE_DS_MSI_OFFSET 0x70
+#define REDHAT_PCIE_DS_MSI_SUPPORTED_FLAGS PCI_MSI_FLAGS_64BIT
+#define REDHAT_PCIE_DS_MSI_NR_VECTOR 1
+#define REDHAT_PCIE_DS_SSVID_OFFSET 0x80
+#define REDHAT_PCIE_DS_SSVID_SVID 0
+#define REDHAT_PCIE_DS_SSVID_SSID 0
+#define REDHAT_PCIE_DS_EXP_OFFSET 0x90
+#define REDHAT_PCIE_DS_VENDOR_OFFSET 0xCC
+#define REDHAT_PCIE_DS_AER_OFFSET 0x100
+
+static void pcie_ds_write_config(PCIDevice *d, uint32_t address,
+ uint32_t val, int len)
+{
+ pci_bridge_write_config(d, address, val, len);
+ pcie_cap_flr_write_config(d, address, val, len);
+ pcie_cap_slot_write_config(d, address, val, len);
+ pcie_aer_write_config(d, address, val, len);
+}
+
+static void pcie_ds_reset(DeviceState *qdev)
+{
+ PCIDevice *d = PCI_DEVICE(qdev);
+
+ pcie_cap_deverr_reset(d);
+ pcie_cap_slot_reset(d);
+ pcie_cap_arifwd_reset(d);
+ pci_bridge_reset(qdev);
+}
+
+static void pcie_ds_realize(PCIDevice *d, Error **errp)
+{
+ PCIEPort *p = PCIE_PORT(d);
+ PCIESlot *s = PCIE_SLOT(d);
+ int rc;
+
+ pci_bridge_initfn(d, TYPE_PCIE_BUS);
+ pcie_port_init_reg(d);
+
+ rc = pci_bridge_vendor_init(d, REDHAT_PCIE_DS_VENDOR_OFFSET, errp);
+ if (rc < 0) {
+ error_append_hint(errp, "Can't init group ID, error %d\n", rc);
+ goto err_bridge;
+ }
+
+ rc = msi_init(d, REDHAT_PCIE_DS_MSI_OFFSET, REDHAT_PCIE_DS_MSI_NR_VECTOR,
+ REDHAT_PCIE_DS_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_64BIT,
+ REDHAT_PCIE_DS_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_MASKBIT, errp);
+ if (rc < 0) {
+ assert(rc == -ENOTSUP);
+ goto err_bridge;
+ }
+
+ rc = pci_bridge_ssvid_init(d, REDHAT_PCIE_DS_SSVID_OFFSET,
+ REDHAT_PCIE_DS_SSVID_SVID, REDHAT_PCIE_DS_SSVID_SSID, errp);
+ if (rc < 0) {
+ goto err_bridge;
+ }
+
+ rc = pcie_cap_init(d, REDHAT_PCIE_DS_EXP_OFFSET, PCI_EXP_TYPE_DOWNSTREAM,
+ p->port, errp);
+ if (rc < 0) {
+ goto err_msi;
+ }
+ pcie_cap_flr_init(d);
+ pcie_cap_deverr_init(d);
+ pcie_cap_slot_init(d, s->slot);
+ pcie_cap_arifwd_init(d);
+
+ pcie_chassis_create(s->chassis);
+ rc = pcie_chassis_add_slot(s);
+ if (rc < 0) {
+ error_setg(errp, "Can't add chassis slot, error %d", rc);
+ goto err_pcie_cap;
+ }
+
+ rc = pcie_aer_init(d, PCI_ERR_VER, REDHAT_PCIE_DS_AER_OFFSET,
+ PCI_ERR_SIZEOF, errp);
+ if (rc < 0) {
+ goto err;
+ }
+
+ return;
+
+err:
+ pcie_chassis_del_slot(s);
+err_pcie_cap:
+ pcie_cap_exit(d);
+err_msi:
+ msi_uninit(d);
+err_bridge:
+ pci_bridge_exitfn(d);
+}
+
+static void pcie_ds_exitfn(PCIDevice *d)
+{
+ PCIESlot *s = PCIE_SLOT(d);
+
+ pcie_aer_exit(d);
+ pcie_chassis_del_slot(s);
+ pcie_cap_exit(d);
+ msi_uninit(d);
+ pci_bridge_exitfn(d);
+}
+
+PCIESlot *pcie_ds_init(PCIBus *bus, int devfn, bool multifunction,
+ const char *bus_name, pci_map_irq_fn map_irq,
+ uint8_t port, uint8_t chassis, uint16_t slot)
+{
+ PCIDevice *d;
+ PCIBridge *br;
+ DeviceState *qdev;
+
+ d = pci_create_multifunction(bus, devfn, multifunction, "pcie-downstream");
+ if (!d) {
+ return NULL;
+ }
+ br = PCI_BRIDGE(d);
+
+ qdev = DEVICE(d);
+ pci_bridge_map_irq(br, bus_name, map_irq);
+ qdev_prop_set_uint8(qdev, "port", port);
+ qdev_prop_set_uint8(qdev, "chassis", chassis);
+ qdev_prop_set_uint16(qdev, "slot", slot);
+ qdev_init_nofail(qdev);
+
+ return PCIE_SLOT(d);
+}
+
+static Property pcie_ds_props[] = {
+ DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
+ QEMU_PCIE_SLTCAP_PCP_BITNR, true),
+ DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
+ DEFINE_PROP_END_OF_LIST()
+};
+
+static const VMStateDescription vmstate_pcie_ds = {
+ .name = "pci-express-downstream-port",
+ .priority = MIG_PRI_PCI_BUS,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .post_load = pcie_cap_slot_post_load,
+ .fields = (VMStateField[]) {
+ VMSTATE_PCI_DEVICE(parent_obj.parent_obj.parent_obj, PCIESlot),
+ VMSTATE_STRUCT(parent_obj.parent_obj.parent_obj.exp.aer_log,
+ PCIESlot, 0, vmstate_pcie_aer_log, PCIEAERLog),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static void pcie_ds_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+ k->is_bridge = 1;
+ k->config_write = pcie_ds_write_config;
+ k->realize = pcie_ds_realize;
+ k->exit = pcie_ds_exitfn;
+ k->vendor_id = PCI_VENDOR_ID_REDHAT;
+ k->device_id = PCI_DEVICE_ID_REDHAT_DOWNSTREAM;
+ k->revision = REDHAT_PCIE_DS_REVISION;
+ set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+ dc->desc = "Red Hat PCIe Downstream Port";
+ dc->reset = pcie_ds_reset;
+ dc->vmsd = &vmstate_pcie_ds;
+ dc->props = pcie_ds_props;
+}
+
+static const TypeInfo pcie_ds_info = {
+ .name = "pcie-downstream",
+ .parent = TYPE_PCIE_SLOT,
+ .class_init = pcie_ds_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
+};
+
+static void pcie_ds_register_types(void)
+{
+ type_register_static(&pcie_ds_info);
+}
+
+type_init(pcie_ds_register_types)
diff --git a/hw/pci-bridge/pcie_downstream.h b/hw/pci-bridge/pcie_downstream.h
new file mode 100644
index 0000000000..54f18be285
--- /dev/null
+++ b/hw/pci-bridge/pcie_downstream.h
@@ -0,0 +1,10 @@
+#ifndef QEMU_PCIE_DOWNSTREAM_H
+#define QEMU_PCIE_DOWNSTREAM_H
+
+#include "hw/pci/pcie_port.h"
+
+PCIESlot *pcie_downstream_init(PCIBus *bus, int devfn, bool multifunction,
+ const char *bus_name, pci_map_irq_fn map_irq,
+ uint8_t port, uint8_t chassis, uint16_t slot);
+
+#endif /* QEMU_PCIE_DOWNSTREAM_H */
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index ee234c5a6f..5c61a5b496 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -103,6 +103,7 @@ extern bool pci_available;
#define PCI_DEVICE_ID_REDHAT_XHCI 0x000d
#define PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE 0x000e
#define PCI_DEVICE_ID_REDHAT_MDPY 0x000f
+#define PCI_DEVICE_ID_REDHAT_DOWNSTREAM 0x0010
#define PCI_DEVICE_ID_REDHAT_QXL 0x0100
#define FMT_PCIBUS PRIx64
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [virtio-dev] [PATCH v2 4/4] Add "Group Identifier" support to Red Hat PCI Express bridge.
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Add a new bridge device "pcie-downstream" with a Vendor ID of
PCI_VENDOR_ID_REDHAT and Device ID of PCI_DEVICE_ID_REDHAT_DOWNSTREAM.
Also add the "Vendor-Specific" capability to the bridge to contain the
"Group Identifier" (UUID) that will be used to pair a virtio device with
the passthrough device attached to that bridge.
This capability is added to the bridge iff the "uuid" option is specified
for the bridge.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
default-configs/arm-softmmu.mak | 1 +
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/pci-bridge/Makefile.objs | 1 +
hw/pci-bridge/pcie_downstream.c | 215 +++++++++++++++++++++++++++++
hw/pci-bridge/pcie_downstream.h | 10 ++
include/hw/pci/pci.h | 1 +
7 files changed, 230 insertions(+)
create mode 100644 hw/pci-bridge/pcie_downstream.c
create mode 100644 hw/pci-bridge/pcie_downstream.h
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 834d45cfaf..b86c6fb122 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -139,6 +139,7 @@ CONFIG_IMX_I2C=y
CONFIG_PCIE_PORT=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
+CONFIG_PCIE_DOWNSTREAM=y
CONFIG_I82801B11=y
CONFIG_ACPI=y
CONFIG_SMBIOS=y
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8c7d4a0fa0..a900c8f052 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -56,6 +56,7 @@ CONFIG_ACPI_NVDIMM=y
CONFIG_PCIE_PORT=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
+CONFIG_PCIE_DOWNSTREAM=y
CONFIG_I82801B11=y
CONFIG_SMBIOS=y
CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
diff --git a/default-configs/x86_64-softmmu.mak b/default-configs/x86_64-softmmu.mak
index 0390b4303c..481e4764be 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -56,6 +56,7 @@ CONFIG_ACPI_NVDIMM=y
CONFIG_PCIE_PORT=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
+CONFIG_PCIE_DOWNSTREAM=y
CONFIG_I82801B11=y
CONFIG_SMBIOS=y
CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
diff --git a/hw/pci-bridge/Makefile.objs b/hw/pci-bridge/Makefile.objs
index 47065f87d9..5b42212edc 100644
--- a/hw/pci-bridge/Makefile.objs
+++ b/hw/pci-bridge/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-$(CONFIG_PCIE_PORT) += pcie_root_port.o gen_pcie_root_port.o pcie_pci
common-obj-$(CONFIG_PXB) += pci_expander_bridge.o
common-obj-$(CONFIG_XIO3130) += xio3130_upstream.o xio3130_downstream.o
common-obj-$(CONFIG_IOH3420) += ioh3420.o
+common-obj-$(CONFIG_PCIE_DOWNSTREAM) += pcie_downstream.o
common-obj-$(CONFIG_I82801B11) += i82801b11.o
# NewWorld PowerMac
common-obj-$(CONFIG_DEC_PCI) += dec.o
diff --git a/hw/pci-bridge/pcie_downstream.c b/hw/pci-bridge/pcie_downstream.c
new file mode 100644
index 0000000000..78604504ea
--- /dev/null
+++ b/hw/pci-bridge/pcie_downstream.c
@@ -0,0 +1,215 @@
+/*
+ * Red Hat PCI Express downstream port.
+ *
+ * pcie_downstream.c
+ * Most of this code is copied from xio3130_downstream.c
+ *
+ * Copyright (c) 2018 Oracle and/or its affiliates.
+ * Author: Venu Busireddy <venu.busireddy@oracle.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/pci/pci_ids.h"
+#include "hw/pci/msi.h"
+#include "hw/pci/pcie.h"
+#include "pcie_downstream.h"
+#include "qapi/error.h"
+
+#define REDHAT_PCIE_DS_REVISION 0x1
+#define REDHAT_PCIE_DS_MSI_OFFSET 0x70
+#define REDHAT_PCIE_DS_MSI_SUPPORTED_FLAGS PCI_MSI_FLAGS_64BIT
+#define REDHAT_PCIE_DS_MSI_NR_VECTOR 1
+#define REDHAT_PCIE_DS_SSVID_OFFSET 0x80
+#define REDHAT_PCIE_DS_SSVID_SVID 0
+#define REDHAT_PCIE_DS_SSVID_SSID 0
+#define REDHAT_PCIE_DS_EXP_OFFSET 0x90
+#define REDHAT_PCIE_DS_VENDOR_OFFSET 0xCC
+#define REDHAT_PCIE_DS_AER_OFFSET 0x100
+
+static void pcie_ds_write_config(PCIDevice *d, uint32_t address,
+ uint32_t val, int len)
+{
+ pci_bridge_write_config(d, address, val, len);
+ pcie_cap_flr_write_config(d, address, val, len);
+ pcie_cap_slot_write_config(d, address, val, len);
+ pcie_aer_write_config(d, address, val, len);
+}
+
+static void pcie_ds_reset(DeviceState *qdev)
+{
+ PCIDevice *d = PCI_DEVICE(qdev);
+
+ pcie_cap_deverr_reset(d);
+ pcie_cap_slot_reset(d);
+ pcie_cap_arifwd_reset(d);
+ pci_bridge_reset(qdev);
+}
+
+static void pcie_ds_realize(PCIDevice *d, Error **errp)
+{
+ PCIEPort *p = PCIE_PORT(d);
+ PCIESlot *s = PCIE_SLOT(d);
+ int rc;
+
+ pci_bridge_initfn(d, TYPE_PCIE_BUS);
+ pcie_port_init_reg(d);
+
+ rc = pci_bridge_vendor_init(d, REDHAT_PCIE_DS_VENDOR_OFFSET, errp);
+ if (rc < 0) {
+ error_append_hint(errp, "Can't init group ID, error %d\n", rc);
+ goto err_bridge;
+ }
+
+ rc = msi_init(d, REDHAT_PCIE_DS_MSI_OFFSET, REDHAT_PCIE_DS_MSI_NR_VECTOR,
+ REDHAT_PCIE_DS_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_64BIT,
+ REDHAT_PCIE_DS_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_MASKBIT, errp);
+ if (rc < 0) {
+ assert(rc == -ENOTSUP);
+ goto err_bridge;
+ }
+
+ rc = pci_bridge_ssvid_init(d, REDHAT_PCIE_DS_SSVID_OFFSET,
+ REDHAT_PCIE_DS_SSVID_SVID, REDHAT_PCIE_DS_SSVID_SSID, errp);
+ if (rc < 0) {
+ goto err_bridge;
+ }
+
+ rc = pcie_cap_init(d, REDHAT_PCIE_DS_EXP_OFFSET, PCI_EXP_TYPE_DOWNSTREAM,
+ p->port, errp);
+ if (rc < 0) {
+ goto err_msi;
+ }
+ pcie_cap_flr_init(d);
+ pcie_cap_deverr_init(d);
+ pcie_cap_slot_init(d, s->slot);
+ pcie_cap_arifwd_init(d);
+
+ pcie_chassis_create(s->chassis);
+ rc = pcie_chassis_add_slot(s);
+ if (rc < 0) {
+ error_setg(errp, "Can't add chassis slot, error %d", rc);
+ goto err_pcie_cap;
+ }
+
+ rc = pcie_aer_init(d, PCI_ERR_VER, REDHAT_PCIE_DS_AER_OFFSET,
+ PCI_ERR_SIZEOF, errp);
+ if (rc < 0) {
+ goto err;
+ }
+
+ return;
+
+err:
+ pcie_chassis_del_slot(s);
+err_pcie_cap:
+ pcie_cap_exit(d);
+err_msi:
+ msi_uninit(d);
+err_bridge:
+ pci_bridge_exitfn(d);
+}
+
+static void pcie_ds_exitfn(PCIDevice *d)
+{
+ PCIESlot *s = PCIE_SLOT(d);
+
+ pcie_aer_exit(d);
+ pcie_chassis_del_slot(s);
+ pcie_cap_exit(d);
+ msi_uninit(d);
+ pci_bridge_exitfn(d);
+}
+
+PCIESlot *pcie_ds_init(PCIBus *bus, int devfn, bool multifunction,
+ const char *bus_name, pci_map_irq_fn map_irq,
+ uint8_t port, uint8_t chassis, uint16_t slot)
+{
+ PCIDevice *d;
+ PCIBridge *br;
+ DeviceState *qdev;
+
+ d = pci_create_multifunction(bus, devfn, multifunction, "pcie-downstream");
+ if (!d) {
+ return NULL;
+ }
+ br = PCI_BRIDGE(d);
+
+ qdev = DEVICE(d);
+ pci_bridge_map_irq(br, bus_name, map_irq);
+ qdev_prop_set_uint8(qdev, "port", port);
+ qdev_prop_set_uint8(qdev, "chassis", chassis);
+ qdev_prop_set_uint16(qdev, "slot", slot);
+ qdev_init_nofail(qdev);
+
+ return PCIE_SLOT(d);
+}
+
+static Property pcie_ds_props[] = {
+ DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
+ QEMU_PCIE_SLTCAP_PCP_BITNR, true),
+ DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
+ DEFINE_PROP_END_OF_LIST()
+};
+
+static const VMStateDescription vmstate_pcie_ds = {
+ .name = "pci-express-downstream-port",
+ .priority = MIG_PRI_PCI_BUS,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .post_load = pcie_cap_slot_post_load,
+ .fields = (VMStateField[]) {
+ VMSTATE_PCI_DEVICE(parent_obj.parent_obj.parent_obj, PCIESlot),
+ VMSTATE_STRUCT(parent_obj.parent_obj.parent_obj.exp.aer_log,
+ PCIESlot, 0, vmstate_pcie_aer_log, PCIEAERLog),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static void pcie_ds_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+ k->is_bridge = 1;
+ k->config_write = pcie_ds_write_config;
+ k->realize = pcie_ds_realize;
+ k->exit = pcie_ds_exitfn;
+ k->vendor_id = PCI_VENDOR_ID_REDHAT;
+ k->device_id = PCI_DEVICE_ID_REDHAT_DOWNSTREAM;
+ k->revision = REDHAT_PCIE_DS_REVISION;
+ set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+ dc->desc = "Red Hat PCIe Downstream Port";
+ dc->reset = pcie_ds_reset;
+ dc->vmsd = &vmstate_pcie_ds;
+ dc->props = pcie_ds_props;
+}
+
+static const TypeInfo pcie_ds_info = {
+ .name = "pcie-downstream",
+ .parent = TYPE_PCIE_SLOT,
+ .class_init = pcie_ds_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
+};
+
+static void pcie_ds_register_types(void)
+{
+ type_register_static(&pcie_ds_info);
+}
+
+type_init(pcie_ds_register_types)
diff --git a/hw/pci-bridge/pcie_downstream.h b/hw/pci-bridge/pcie_downstream.h
new file mode 100644
index 0000000000..54f18be285
--- /dev/null
+++ b/hw/pci-bridge/pcie_downstream.h
@@ -0,0 +1,10 @@
+#ifndef QEMU_PCIE_DOWNSTREAM_H
+#define QEMU_PCIE_DOWNSTREAM_H
+
+#include "hw/pci/pcie_port.h"
+
+PCIESlot *pcie_downstream_init(PCIBus *bus, int devfn, bool multifunction,
+ const char *bus_name, pci_map_irq_fn map_irq,
+ uint8_t port, uint8_t chassis, uint16_t slot);
+
+#endif /* QEMU_PCIE_DOWNSTREAM_H */
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index ee234c5a6f..5c61a5b496 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -103,6 +103,7 @@ extern bool pci_available;
#define PCI_DEVICE_ID_REDHAT_XHCI 0x000d
#define PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE 0x000e
#define PCI_DEVICE_ID_REDHAT_MDPY 0x000f
+#define PCI_DEVICE_ID_REDHAT_DOWNSTREAM 0x0010
#define PCI_DEVICE_ID_REDHAT_QXL 0x0100
#define FMT_PCIBUS PRIx64
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [Qemu-devel] [PATCH v2 virtio 1/1] Add "Group Identifier" to virtio PCI capabilities.
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 3:49 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Add VIRTIO_PCI_CAP_GROUP_ID_CFG (Group Identifier) capability to the
virtio PCI capabilities to allow for the grouping of devices.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
content.tex | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/content.tex b/content.tex
index be18234..27581c1 100644
--- a/content.tex
+++ b/content.tex
@@ -599,6 +599,8 @@ The fields are interpreted as follows:
#define VIRTIO_PCI_CAP_DEVICE_CFG 4
/* PCI configuration access */
#define VIRTIO_PCI_CAP_PCI_CFG 5
+/* Group Identifier */
+#define VIRTIO_PCI_CAP_GROUP_ID_CFG 6
\end{lstlisting}
Any other value is reserved for future use.
@@ -997,6 +999,40 @@ address \field{cap.length} bytes within a BAR range
specified by some other Virtio Structure PCI Capability
of type other than \field{VIRTIO_PCI_CAP_PCI_CFG}.
+\subsubsection{Group Identifier capability}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
+
+The VIRTIO_PCI_CAP_GROUP_ID_CFG capability provides means for grouping devices together.
+
+The capability is immediately followed by an identifier of arbitrary size as below:
+
+\begin{lstlisting}
+struct virtio_pci_group_id_cap {
+ struct virtio_pci_cap cap;
+ u8 group_id[]; /* Group Identifier */
+};
+\end{lstlisting}
+
+The fields \field{cap.bar}, \field{cap.length}, \field{cap.offset}
+and \field{group_id} are read-only for the driver.
+
+The specification does not impose any restrictions on the structure
+or size of group_id[], except that the size must be a multiple of 4.
+Devices are free to declare this array as large as needed, as long as
+the combined size of all capabilities can be accommodated within the
+PCI configuration space.
+
+The field \field{cap.cap_len} indicates the length of the group identifier
+\field{group_id}. The fields \field{cap.bar}, \field{cap.offset} and
+\field{cap.length} should be set to 0.
+
+\devicenormative{\paragraph}{Group Identifier capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
+
+The device MAY present the VIRTIO_PCI_CAP_GROUP_ID_CFG capability.
+
+\drivernormative{\paragraph}{Group Identifier capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
+
+The driver MUST NOT write to group_id[] area.
+
\subsubsection{Legacy Interfaces: A Note on PCI Device Layout}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
Transitional devices MUST present part of configuration
^ permalink raw reply related [flat|nested] 55+ messages in thread
* [virtio-dev] [PATCH v2 virtio 1/1] Add "Group Identifier" to virtio PCI capabilities.
@ 2018-06-27 3:49 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 3:49 UTC (permalink / raw)
To: venu.busireddy, Michael S . Tsirkin, Marcel Apfelbaum
Cc: virtio-dev, qemu-devel
Add VIRTIO_PCI_CAP_GROUP_ID_CFG (Group Identifier) capability to the
virtio PCI capabilities to allow for the grouping of devices.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
---
content.tex | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/content.tex b/content.tex
index be18234..27581c1 100644
--- a/content.tex
+++ b/content.tex
@@ -599,6 +599,8 @@ The fields are interpreted as follows:
#define VIRTIO_PCI_CAP_DEVICE_CFG 4
/* PCI configuration access */
#define VIRTIO_PCI_CAP_PCI_CFG 5
+/* Group Identifier */
+#define VIRTIO_PCI_CAP_GROUP_ID_CFG 6
\end{lstlisting}
Any other value is reserved for future use.
@@ -997,6 +999,40 @@ address \field{cap.length} bytes within a BAR range
specified by some other Virtio Structure PCI Capability
of type other than \field{VIRTIO_PCI_CAP_PCI_CFG}.
+\subsubsection{Group Identifier capability}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
+
+The VIRTIO_PCI_CAP_GROUP_ID_CFG capability provides means for grouping devices together.
+
+The capability is immediately followed by an identifier of arbitrary size as below:
+
+\begin{lstlisting}
+struct virtio_pci_group_id_cap {
+ struct virtio_pci_cap cap;
+ u8 group_id[]; /* Group Identifier */
+};
+\end{lstlisting}
+
+The fields \field{cap.bar}, \field{cap.length}, \field{cap.offset}
+and \field{group_id} are read-only for the driver.
+
+The specification does not impose any restrictions on the structure
+or size of group_id[], except that the size must be a multiple of 4.
+Devices are free to declare this array as large as needed, as long as
+the combined size of all capabilities can be accommodated within the
+PCI configuration space.
+
+The field \field{cap.cap_len} indicates the length of the group identifier
+\field{group_id}. The fields \field{cap.bar}, \field{cap.offset} and
+\field{cap.length} should be set to 0.
+
+\devicenormative{\paragraph}{Group Identifier capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
+
+The device MAY present the VIRTIO_PCI_CAP_GROUP_ID_CFG capability.
+
+\drivernormative{\paragraph}{Group Identifier capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Group Identifier capability}
+
+The driver MUST NOT write to group_id[] area.
+
\subsubsection{Legacy Interfaces: A Note on PCI Device Layout}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Legacy Interfaces: A Note on PCI Device Layout}
Transitional devices MUST present part of configuration
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 4:02 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 4:02 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> used to pair a virtio device with the passthrough device attached to
> that bridge.
>
> This capability is added to the bridge iff the "uuid" option is specified
> for the bridge.
I think the name should be more explicit. How about "failover-group-id"?
>
> Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
I'd like to also tweak the device id in this case,
to make it easier for guests to know it's a grouping bridge.
> ---
> hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> include/hw/pci/pcie.h | 1 +
> 3 files changed, 35 insertions(+)
>
> diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> index b2d861d216..bbbc6fa1c6 100644
> --- a/hw/pci-bridge/pci_bridge_dev.c
> +++ b/hw/pci-bridge/pci_bridge_dev.c
> @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> bridge_dev->msi = ON_OFF_AUTO_OFF;
> }
>
> + err = pci_bridge_vendor_init(dev, 0, errp);
> + if (err < 0) {
> + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> + goto vendor_cap_err;
> + }
> +
> err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> if (err) {
> goto slotid_error;
> @@ -109,6 +115,7 @@ slotid_error:
> if (shpc_present(dev)) {
> shpc_cleanup(dev, &bridge_dev->bar);
> }
> +vendor_cap_err:
> shpc_error:
> pci_bridge_exitfn(dev);
> }
> @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> ON_OFF_AUTO_AUTO),
> DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> index 40a39f57cb..cb8b3dad2a 100644
> --- a/hw/pci/pci_bridge.c
> +++ b/hw/pci/pci_bridge.c
> @@ -34,12 +34,17 @@
> #include "hw/pci/pci_bus.h"
> #include "qemu/range.h"
> #include "qapi/error.h"
> +#include "qemu/uuid.h"
>
> /* PCI bridge subsystem vendor ID helper functions */
> #define PCI_SSVID_SIZEOF 8
> #define PCI_SSVID_SVID 4
> #define PCI_SSVID_SSID 6
>
> +#define PCI_VENDOR_SIZEOF 20
> +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> +
> int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> uint16_t svid, uint16_t ssid,
> Error **errp)
> @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> return pos;
> }
>
> +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> +{
> + int pos;
> +
> + if (qemu_uuid_is_null(&d->uuid)) {
> + return 0;
> + }
> +
> + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> + errp);
> + if (pos < 0) {
> + return pos;
> + }
> +
> + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> + PCI_VENDOR_SIZEOF);
> + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> + sizeof(QemuUUID));
> + return pos;
> +}
> +
> /* Accessor function to get parent bridge device from pci bus. */
> PCIDevice *pci_bridge_get_device(PCIBus *bus)
> {
> diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> index b71e369703..b4189d0ce3 100644
> --- a/include/hw/pci/pcie.h
> +++ b/include/hw/pci/pcie.h
> @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> };
>
> #define COMPAT_PROP_PCP "power_controller_present"
> +#define COMPAT_PROP_UUID "uuid"
>
> /* PCI express capability helper functions */
> int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-27 4:02 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 4:02 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> used to pair a virtio device with the passthrough device attached to
> that bridge.
>
> This capability is added to the bridge iff the "uuid" option is specified
> for the bridge.
I think the name should be more explicit. How about "failover-group-id"?
>
> Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
I'd like to also tweak the device id in this case,
to make it easier for guests to know it's a grouping bridge.
> ---
> hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> include/hw/pci/pcie.h | 1 +
> 3 files changed, 35 insertions(+)
>
> diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> index b2d861d216..bbbc6fa1c6 100644
> --- a/hw/pci-bridge/pci_bridge_dev.c
> +++ b/hw/pci-bridge/pci_bridge_dev.c
> @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> bridge_dev->msi = ON_OFF_AUTO_OFF;
> }
>
> + err = pci_bridge_vendor_init(dev, 0, errp);
> + if (err < 0) {
> + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> + goto vendor_cap_err;
> + }
> +
> err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> if (err) {
> goto slotid_error;
> @@ -109,6 +115,7 @@ slotid_error:
> if (shpc_present(dev)) {
> shpc_cleanup(dev, &bridge_dev->bar);
> }
> +vendor_cap_err:
> shpc_error:
> pci_bridge_exitfn(dev);
> }
> @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> ON_OFF_AUTO_AUTO),
> DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> index 40a39f57cb..cb8b3dad2a 100644
> --- a/hw/pci/pci_bridge.c
> +++ b/hw/pci/pci_bridge.c
> @@ -34,12 +34,17 @@
> #include "hw/pci/pci_bus.h"
> #include "qemu/range.h"
> #include "qapi/error.h"
> +#include "qemu/uuid.h"
>
> /* PCI bridge subsystem vendor ID helper functions */
> #define PCI_SSVID_SIZEOF 8
> #define PCI_SSVID_SVID 4
> #define PCI_SSVID_SSID 6
>
> +#define PCI_VENDOR_SIZEOF 20
> +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> +
> int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> uint16_t svid, uint16_t ssid,
> Error **errp)
> @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> return pos;
> }
>
> +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> +{
> + int pos;
> +
> + if (qemu_uuid_is_null(&d->uuid)) {
> + return 0;
> + }
> +
> + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> + errp);
> + if (pos < 0) {
> + return pos;
> + }
> +
> + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> + PCI_VENDOR_SIZEOF);
> + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> + sizeof(QemuUUID));
> + return pos;
> +}
> +
> /* Accessor function to get parent bridge device from pci bus. */
> PCIDevice *pci_bridge_get_device(PCIBus *bus)
> {
> diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> index b71e369703..b4189d0ce3 100644
> --- a/include/hw/pci/pcie.h
> +++ b/include/hw/pci/pcie.h
> @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> };
>
> #define COMPAT_PROP_PCP "power_controller_present"
> +#define COMPAT_PROP_UUID "uuid"
>
> /* PCI express capability helper functions */
> int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 4:06 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 4:06 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> The patch set "Enable virtio_net to act as a standby for a passthru
> device" [1] deals with live migration of guests that use passthrough
> devices. However, that scheme uses the MAC address for pairing
> the virtio device and the passthrough device. The thread "netvsc:
> refactor notifier/event handling code to use the failover framework"
> [2] discusses an alternate mechanism, such as using an UUID, for pairing
> the devices. Based on that discussion, proposals "Add "Group Identifier"
> to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> store pairing information..." [4] were made.
>
> The current patch set includes all the feedback received for proposals [3]
> and [4]. For the sake of completeness, patch for the virtio specification
> is also included here. Following is the updated proposal.
>
> 1. Extend the virtio specification to include a new virtio PCI capability
> "VIRTIO_PCI_CAP_GROUP_ID_CFG".
There's still discussion around whether it should be
a virtio pci capability, a virtio net config field or
a new kind of capability.
> 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> The "uuid" is a string in UUID format.
>
> 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> The "uuid" is a string in UUID format. Currently, PCIe bridge for
> the Q35 model is supported.
>
> 4. The operator creates a unique identifier string using 'uuidgen'.
>
> 5. When the virtio device is created, the operator uses the "uuid" option
> (for example, '-device virtio-net-pci,uuid="string"') and specifies
> the UUID created in step 4.
>
> QEMU stores the UUID in the virtio device's configuration space
> in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> 6. When assigning a PCI device to the guest in passthrough mode, the
> operator first creates a bridge using the "uuid" option (for example,
> '-device pcie-downstream,uuid="string"') to specify the UUID created
> in step 4, and then attaches the passthrough device to the bridge.
>
> QEMU stores the UUID in the configuration space of the bridge as
> Vendor-Specific capability (0x09). The "Vendor" here is not to be
> confused with a specific organization. Instead, the vendor of the
> bridge is QEMU. To avoid mixing up with other bridges, the bridge
> will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> option is specified. Otherwise, current defaults are used.
>
> 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
> a passthru device" [1] needs to be modified to use the UUID values
> present in the bridge's configuration space and the virtio device's
> configuration space instead of the MAC address for pairing the devices.
>
> Thanks!
>
> Venu
The part where the visibility of a vfio device is controlled by the
virtio driver acknowledging the backup feature is missing here.
> [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
> [2] https://www.spinics.net/lists/netdev/msg499011.html
> [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
> [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
>
> Changes in v2:
> - As Michael Tsirkin suggested, changed the virtio specification
> to restrict the group identifier to be a 16-byte field, presented
> entirely in the virtio device's configuration space.
> - As Michael Tsirkin suggested, instead of tweaking the ioh3420
> device with Red Hat vendor ID, create a new PCIe bridge device
> named "pcie-downstream" with Red Hat Vendor ID, and include the
> group identifier in this device.
> - Added a new patch to enhance the "pci-bridge" device to support
> the group identifier (for the i440FX model).
>
> Venu Busireddy (4):
> Add a true or false option to the DEFINE_PROP_UUID macro.
> Add "Group Identifier" support to virtio devices.
> Add "Group Identifier" support to Red Hat PCI bridge.
> Add "Group Identifier" support to Red Hat PCI Express bridge.
>
> default-configs/arm-softmmu.mak | 1 +
> default-configs/i386-softmmu.mak | 1 +
> default-configs/x86_64-softmmu.mak | 1 +
> hw/acpi/vmgenid.c | 2 +-
> hw/pci-bridge/Makefile.objs | 1 +
> hw/pci-bridge/pci_bridge_dev.c | 8 +
> hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
> hw/pci-bridge/pcie_downstream.h | 10 +
> hw/pci/pci_bridge.c | 26 +++
> hw/virtio/virtio-pci.c | 15 ++
> hw/virtio/virtio-pci.h | 3 +-
> include/hw/pci/pci.h | 3 +
> include/hw/pci/pcie.h | 1 +
> include/hw/qdev-properties.h | 4 +-
> include/standard-headers/linux/virtio_pci.h | 8 +
> 15 files changed, 295 insertions(+), 4 deletions(-)
> create mode 100644 hw/pci-bridge/pcie_downstream.c
> create mode 100644 hw/pci-bridge/pcie_downstream.h
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 4:06 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 4:06 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> The patch set "Enable virtio_net to act as a standby for a passthru
> device" [1] deals with live migration of guests that use passthrough
> devices. However, that scheme uses the MAC address for pairing
> the virtio device and the passthrough device. The thread "netvsc:
> refactor notifier/event handling code to use the failover framework"
> [2] discusses an alternate mechanism, such as using an UUID, for pairing
> the devices. Based on that discussion, proposals "Add "Group Identifier"
> to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> store pairing information..." [4] were made.
>
> The current patch set includes all the feedback received for proposals [3]
> and [4]. For the sake of completeness, patch for the virtio specification
> is also included here. Following is the updated proposal.
>
> 1. Extend the virtio specification to include a new virtio PCI capability
> "VIRTIO_PCI_CAP_GROUP_ID_CFG".
There's still discussion around whether it should be
a virtio pci capability, a virtio net config field or
a new kind of capability.
> 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> The "uuid" is a string in UUID format.
>
> 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> The "uuid" is a string in UUID format. Currently, PCIe bridge for
> the Q35 model is supported.
>
> 4. The operator creates a unique identifier string using 'uuidgen'.
>
> 5. When the virtio device is created, the operator uses the "uuid" option
> (for example, '-device virtio-net-pci,uuid="string"') and specifies
> the UUID created in step 4.
>
> QEMU stores the UUID in the virtio device's configuration space
> in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> 6. When assigning a PCI device to the guest in passthrough mode, the
> operator first creates a bridge using the "uuid" option (for example,
> '-device pcie-downstream,uuid="string"') to specify the UUID created
> in step 4, and then attaches the passthrough device to the bridge.
>
> QEMU stores the UUID in the configuration space of the bridge as
> Vendor-Specific capability (0x09). The "Vendor" here is not to be
> confused with a specific organization. Instead, the vendor of the
> bridge is QEMU. To avoid mixing up with other bridges, the bridge
> will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> option is specified. Otherwise, current defaults are used.
>
> 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
> a passthru device" [1] needs to be modified to use the UUID values
> present in the bridge's configuration space and the virtio device's
> configuration space instead of the MAC address for pairing the devices.
>
> Thanks!
>
> Venu
The part where the visibility of a vfio device is controlled by the
virtio driver acknowledging the backup feature is missing here.
> [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
> [2] https://www.spinics.net/lists/netdev/msg499011.html
> [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
> [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
>
> Changes in v2:
> - As Michael Tsirkin suggested, changed the virtio specification
> to restrict the group identifier to be a 16-byte field, presented
> entirely in the virtio device's configuration space.
> - As Michael Tsirkin suggested, instead of tweaking the ioh3420
> device with Red Hat vendor ID, create a new PCIe bridge device
> named "pcie-downstream" with Red Hat Vendor ID, and include the
> group identifier in this device.
> - Added a new patch to enhance the "pci-bridge" device to support
> the group identifier (for the i440FX model).
>
> Venu Busireddy (4):
> Add a true or false option to the DEFINE_PROP_UUID macro.
> Add "Group Identifier" support to virtio devices.
> Add "Group Identifier" support to Red Hat PCI bridge.
> Add "Group Identifier" support to Red Hat PCI Express bridge.
>
> default-configs/arm-softmmu.mak | 1 +
> default-configs/i386-softmmu.mak | 1 +
> default-configs/x86_64-softmmu.mak | 1 +
> hw/acpi/vmgenid.c | 2 +-
> hw/pci-bridge/Makefile.objs | 1 +
> hw/pci-bridge/pci_bridge_dev.c | 8 +
> hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
> hw/pci-bridge/pcie_downstream.h | 10 +
> hw/pci/pci_bridge.c | 26 +++
> hw/virtio/virtio-pci.c | 15 ++
> hw/virtio/virtio-pci.h | 3 +-
> include/hw/pci/pci.h | 3 +
> include/hw/pci/pcie.h | 1 +
> include/hw/qdev-properties.h | 4 +-
> include/standard-headers/linux/virtio_pci.h | 8 +
> 15 files changed, 295 insertions(+), 4 deletions(-)
> create mode 100644 hw/pci-bridge/pcie_downstream.c
> create mode 100644 hw/pci-bridge/pcie_downstream.h
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-27 4:02 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-27 4:08 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 4:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > used to pair a virtio device with the passthrough device attached to
> > that bridge.
> >
> > This capability is added to the bridge iff the "uuid" option is specified
> > for the bridge.
>
> I think the name should be more explicit. How about "failover-group-id"?
I can change it. But don't you think it is bit long?
> >
> > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
>
> I'd like to also tweak the device id in this case,
> to make it easier for guests to know it's a grouping bridge.
Could you please recommend a name for the new ID'd definition? Something
in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
Thanks,
Venu
>
> > ---
> > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > include/hw/pci/pcie.h | 1 +
> > 3 files changed, 35 insertions(+)
> >
> > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > index b2d861d216..bbbc6fa1c6 100644
> > --- a/hw/pci-bridge/pci_bridge_dev.c
> > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > }
> >
> > + err = pci_bridge_vendor_init(dev, 0, errp);
> > + if (err < 0) {
> > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > + goto vendor_cap_err;
> > + }
> > +
> > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > if (err) {
> > goto slotid_error;
> > @@ -109,6 +115,7 @@ slotid_error:
> > if (shpc_present(dev)) {
> > shpc_cleanup(dev, &bridge_dev->bar);
> > }
> > +vendor_cap_err:
> > shpc_error:
> > pci_bridge_exitfn(dev);
> > }
> > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > ON_OFF_AUTO_AUTO),
> > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
> > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > index 40a39f57cb..cb8b3dad2a 100644
> > --- a/hw/pci/pci_bridge.c
> > +++ b/hw/pci/pci_bridge.c
> > @@ -34,12 +34,17 @@
> > #include "hw/pci/pci_bus.h"
> > #include "qemu/range.h"
> > #include "qapi/error.h"
> > +#include "qemu/uuid.h"
> >
> > /* PCI bridge subsystem vendor ID helper functions */
> > #define PCI_SSVID_SIZEOF 8
> > #define PCI_SSVID_SVID 4
> > #define PCI_SSVID_SSID 6
> >
> > +#define PCI_VENDOR_SIZEOF 20
> > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > +
> > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > uint16_t svid, uint16_t ssid,
> > Error **errp)
> > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > return pos;
> > }
> >
> > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > +{
> > + int pos;
> > +
> > + if (qemu_uuid_is_null(&d->uuid)) {
> > + return 0;
> > + }
> > +
> > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > + errp);
> > + if (pos < 0) {
> > + return pos;
> > + }
> > +
> > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > + PCI_VENDOR_SIZEOF);
> > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > + sizeof(QemuUUID));
> > + return pos;
> > +}
> > +
> > /* Accessor function to get parent bridge device from pci bus. */
> > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > {
> > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > index b71e369703..b4189d0ce3 100644
> > --- a/include/hw/pci/pcie.h
> > +++ b/include/hw/pci/pcie.h
> > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > };
> >
> > #define COMPAT_PROP_PCP "power_controller_present"
> > +#define COMPAT_PROP_UUID "uuid"
> >
> > /* PCI express capability helper functions */
> > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-27 4:08 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 4:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > used to pair a virtio device with the passthrough device attached to
> > that bridge.
> >
> > This capability is added to the bridge iff the "uuid" option is specified
> > for the bridge.
>
> I think the name should be more explicit. How about "failover-group-id"?
I can change it. But don't you think it is bit long?
> >
> > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
>
> I'd like to also tweak the device id in this case,
> to make it easier for guests to know it's a grouping bridge.
Could you please recommend a name for the new ID'd definition? Something
in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
Thanks,
Venu
>
> > ---
> > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > include/hw/pci/pcie.h | 1 +
> > 3 files changed, 35 insertions(+)
> >
> > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > index b2d861d216..bbbc6fa1c6 100644
> > --- a/hw/pci-bridge/pci_bridge_dev.c
> > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > }
> >
> > + err = pci_bridge_vendor_init(dev, 0, errp);
> > + if (err < 0) {
> > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > + goto vendor_cap_err;
> > + }
> > +
> > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > if (err) {
> > goto slotid_error;
> > @@ -109,6 +115,7 @@ slotid_error:
> > if (shpc_present(dev)) {
> > shpc_cleanup(dev, &bridge_dev->bar);
> > }
> > +vendor_cap_err:
> > shpc_error:
> > pci_bridge_exitfn(dev);
> > }
> > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > ON_OFF_AUTO_AUTO),
> > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
> > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > index 40a39f57cb..cb8b3dad2a 100644
> > --- a/hw/pci/pci_bridge.c
> > +++ b/hw/pci/pci_bridge.c
> > @@ -34,12 +34,17 @@
> > #include "hw/pci/pci_bus.h"
> > #include "qemu/range.h"
> > #include "qapi/error.h"
> > +#include "qemu/uuid.h"
> >
> > /* PCI bridge subsystem vendor ID helper functions */
> > #define PCI_SSVID_SIZEOF 8
> > #define PCI_SSVID_SVID 4
> > #define PCI_SSVID_SSID 6
> >
> > +#define PCI_VENDOR_SIZEOF 20
> > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > +
> > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > uint16_t svid, uint16_t ssid,
> > Error **errp)
> > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > return pos;
> > }
> >
> > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > +{
> > + int pos;
> > +
> > + if (qemu_uuid_is_null(&d->uuid)) {
> > + return 0;
> > + }
> > +
> > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > + errp);
> > + if (pos < 0) {
> > + return pos;
> > + }
> > +
> > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > + PCI_VENDOR_SIZEOF);
> > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > + sizeof(QemuUUID));
> > + return pos;
> > +}
> > +
> > /* Accessor function to get parent bridge device from pci bus. */
> > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > {
> > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > index b71e369703..b4189d0ce3 100644
> > --- a/include/hw/pci/pcie.h
> > +++ b/include/hw/pci/pcie.h
> > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > };
> >
> > #define COMPAT_PROP_PCP "power_controller_present"
> > +#define COMPAT_PROP_UUID "uuid"
> >
> > /* PCI express capability helper functions */
> > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 4:06 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-27 4:12 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 4:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 07:06:42 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, that scheme uses the MAC address for pairing
> > the virtio device and the passthrough device. The thread "netvsc:
> > refactor notifier/event handling code to use the failover framework"
> > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > store pairing information..." [4] were made.
> >
> > The current patch set includes all the feedback received for proposals [3]
> > and [4]. For the sake of completeness, patch for the virtio specification
> > is also included here. Following is the updated proposal.
> >
> > 1. Extend the virtio specification to include a new virtio PCI capability
> > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> There's still discussion around whether it should be
> a virtio pci capability, a virtio net config field or
> a new kind of capability.
>
> > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > The "uuid" is a string in UUID format.
> >
> > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > the Q35 model is supported.
> >
> > 4. The operator creates a unique identifier string using 'uuidgen'.
> >
> > 5. When the virtio device is created, the operator uses the "uuid" option
> > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > the UUID created in step 4.
> >
> > QEMU stores the UUID in the virtio device's configuration space
> > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 6. When assigning a PCI device to the guest in passthrough mode, the
> > operator first creates a bridge using the "uuid" option (for example,
> > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > in step 4, and then attaches the passthrough device to the bridge.
> >
> > QEMU stores the UUID in the configuration space of the bridge as
> > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > confused with a specific organization. Instead, the vendor of the
> > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > option is specified. Otherwise, current defaults are used.
> >
> > 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
> > a passthru device" [1] needs to be modified to use the UUID values
> > present in the bridge's configuration space and the virtio device's
> > configuration space instead of the MAC address for pairing the devices.
> >
> > Thanks!
> >
> > Venu
>
> The part where the visibility of a vfio device is controlled by the
> virtio driver acknowledging the backup feature is missing here.
Could you please elaborate?
Thanks,
Venu
>
>
> > [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
> > [2] https://www.spinics.net/lists/netdev/msg499011.html
> > [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
> > [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
> >
> > Changes in v2:
> > - As Michael Tsirkin suggested, changed the virtio specification
> > to restrict the group identifier to be a 16-byte field, presented
> > entirely in the virtio device's configuration space.
> > - As Michael Tsirkin suggested, instead of tweaking the ioh3420
> > device with Red Hat vendor ID, create a new PCIe bridge device
> > named "pcie-downstream" with Red Hat Vendor ID, and include the
> > group identifier in this device.
> > - Added a new patch to enhance the "pci-bridge" device to support
> > the group identifier (for the i440FX model).
> >
> > Venu Busireddy (4):
> > Add a true or false option to the DEFINE_PROP_UUID macro.
> > Add "Group Identifier" support to virtio devices.
> > Add "Group Identifier" support to Red Hat PCI bridge.
> > Add "Group Identifier" support to Red Hat PCI Express bridge.
> >
> > default-configs/arm-softmmu.mak | 1 +
> > default-configs/i386-softmmu.mak | 1 +
> > default-configs/x86_64-softmmu.mak | 1 +
> > hw/acpi/vmgenid.c | 2 +-
> > hw/pci-bridge/Makefile.objs | 1 +
> > hw/pci-bridge/pci_bridge_dev.c | 8 +
> > hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
> > hw/pci-bridge/pcie_downstream.h | 10 +
> > hw/pci/pci_bridge.c | 26 +++
> > hw/virtio/virtio-pci.c | 15 ++
> > hw/virtio/virtio-pci.h | 3 +-
> > include/hw/pci/pci.h | 3 +
> > include/hw/pci/pcie.h | 1 +
> > include/hw/qdev-properties.h | 4 +-
> > include/standard-headers/linux/virtio_pci.h | 8 +
> > 15 files changed, 295 insertions(+), 4 deletions(-)
> > create mode 100644 hw/pci-bridge/pcie_downstream.c
> > create mode 100644 hw/pci-bridge/pcie_downstream.h
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 4:12 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 4:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 07:06:42 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, that scheme uses the MAC address for pairing
> > the virtio device and the passthrough device. The thread "netvsc:
> > refactor notifier/event handling code to use the failover framework"
> > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > store pairing information..." [4] were made.
> >
> > The current patch set includes all the feedback received for proposals [3]
> > and [4]. For the sake of completeness, patch for the virtio specification
> > is also included here. Following is the updated proposal.
> >
> > 1. Extend the virtio specification to include a new virtio PCI capability
> > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> There's still discussion around whether it should be
> a virtio pci capability, a virtio net config field or
> a new kind of capability.
>
> > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > The "uuid" is a string in UUID format.
> >
> > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > the Q35 model is supported.
> >
> > 4. The operator creates a unique identifier string using 'uuidgen'.
> >
> > 5. When the virtio device is created, the operator uses the "uuid" option
> > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > the UUID created in step 4.
> >
> > QEMU stores the UUID in the virtio device's configuration space
> > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 6. When assigning a PCI device to the guest in passthrough mode, the
> > operator first creates a bridge using the "uuid" option (for example,
> > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > in step 4, and then attaches the passthrough device to the bridge.
> >
> > QEMU stores the UUID in the configuration space of the bridge as
> > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > confused with a specific organization. Instead, the vendor of the
> > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > option is specified. Otherwise, current defaults are used.
> >
> > 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
> > a passthru device" [1] needs to be modified to use the UUID values
> > present in the bridge's configuration space and the virtio device's
> > configuration space instead of the MAC address for pairing the devices.
> >
> > Thanks!
> >
> > Venu
>
> The part where the visibility of a vfio device is controlled by the
> virtio driver acknowledging the backup feature is missing here.
Could you please elaborate?
Thanks,
Venu
>
>
> > [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
> > [2] https://www.spinics.net/lists/netdev/msg499011.html
> > [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
> > [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
> >
> > Changes in v2:
> > - As Michael Tsirkin suggested, changed the virtio specification
> > to restrict the group identifier to be a 16-byte field, presented
> > entirely in the virtio device's configuration space.
> > - As Michael Tsirkin suggested, instead of tweaking the ioh3420
> > device with Red Hat vendor ID, create a new PCIe bridge device
> > named "pcie-downstream" with Red Hat Vendor ID, and include the
> > group identifier in this device.
> > - Added a new patch to enhance the "pci-bridge" device to support
> > the group identifier (for the i440FX model).
> >
> > Venu Busireddy (4):
> > Add a true or false option to the DEFINE_PROP_UUID macro.
> > Add "Group Identifier" support to virtio devices.
> > Add "Group Identifier" support to Red Hat PCI bridge.
> > Add "Group Identifier" support to Red Hat PCI Express bridge.
> >
> > default-configs/arm-softmmu.mak | 1 +
> > default-configs/i386-softmmu.mak | 1 +
> > default-configs/x86_64-softmmu.mak | 1 +
> > hw/acpi/vmgenid.c | 2 +-
> > hw/pci-bridge/Makefile.objs | 1 +
> > hw/pci-bridge/pci_bridge_dev.c | 8 +
> > hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
> > hw/pci-bridge/pcie_downstream.h | 10 +
> > hw/pci/pci_bridge.c | 26 +++
> > hw/virtio/virtio-pci.c | 15 ++
> > hw/virtio/virtio-pci.h | 3 +-
> > include/hw/pci/pci.h | 3 +
> > include/hw/pci/pcie.h | 1 +
> > include/hw/qdev-properties.h | 4 +-
> > include/standard-headers/linux/virtio_pci.h | 8 +
> > 15 files changed, 295 insertions(+), 4 deletions(-)
> > create mode 100644 hw/pci-bridge/pcie_downstream.c
> > create mode 100644 hw/pci-bridge/pcie_downstream.h
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 4:06 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-27 7:21 ` Siwei Liu
-1 siblings, 0 replies; 55+ messages in thread
From: Siwei Liu @ 2018-06-27 7:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 9:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
>> The patch set "Enable virtio_net to act as a standby for a passthru
>> device" [1] deals with live migration of guests that use passthrough
>> devices. However, that scheme uses the MAC address for pairing
>> the virtio device and the passthrough device. The thread "netvsc:
>> refactor notifier/event handling code to use the failover framework"
>> [2] discusses an alternate mechanism, such as using an UUID, for pairing
>> the devices. Based on that discussion, proposals "Add "Group Identifier"
>> to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
>> store pairing information..." [4] were made.
>>
>> The current patch set includes all the feedback received for proposals [3]
>> and [4]. For the sake of completeness, patch for the virtio specification
>> is also included here. Following is the updated proposal.
>>
>> 1. Extend the virtio specification to include a new virtio PCI capability
>> "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> There's still discussion around whether it should be
> a virtio pci capability, a virtio net config field or
> a new kind of capability.
>
>> 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
>> The "uuid" is a string in UUID format.
>>
>> 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
>> The "uuid" is a string in UUID format. Currently, PCIe bridge for
>> the Q35 model is supported.
>>
>> 4. The operator creates a unique identifier string using 'uuidgen'.
>>
>> 5. When the virtio device is created, the operator uses the "uuid" option
>> (for example, '-device virtio-net-pci,uuid="string"') and specifies
>> the UUID created in step 4.
>>
>> QEMU stores the UUID in the virtio device's configuration space
>> in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>>
>> 6. When assigning a PCI device to the guest in passthrough mode, the
>> operator first creates a bridge using the "uuid" option (for example,
>> '-device pcie-downstream,uuid="string"') to specify the UUID created
>> in step 4, and then attaches the passthrough device to the bridge.
>>
>> QEMU stores the UUID in the configuration space of the bridge as
>> Vendor-Specific capability (0x09). The "Vendor" here is not to be
>> confused with a specific organization. Instead, the vendor of the
>> bridge is QEMU. To avoid mixing up with other bridges, the bridge
>> will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
>> device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
>> option is specified. Otherwise, current defaults are used.
>>
>> 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
>> a passthru device" [1] needs to be modified to use the UUID values
>> present in the bridge's configuration space and the virtio device's
>> configuration space instead of the MAC address for pairing the devices.
>>
>> Thanks!
>>
>> Venu
>
> The part where the visibility of a vfio device is controlled by the
> virtio driver acknowledging the backup feature is missing here.
While it is still being discussed, I tend to put that effort into a
seperate set of patches, and this patch series comes first just for
enabling guest to use the UUID feature (I've some code pending). Does
this division makes sense? I realize that the vfio's visibility work
would need to take a while.
-Siwei
>
>
>> [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
>> [2] https://www.spinics.net/lists/netdev/msg499011.html
>> [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
>> [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
>>
>> Changes in v2:
>> - As Michael Tsirkin suggested, changed the virtio specification
>> to restrict the group identifier to be a 16-byte field, presented
>> entirely in the virtio device's configuration space.
>> - As Michael Tsirkin suggested, instead of tweaking the ioh3420
>> device with Red Hat vendor ID, create a new PCIe bridge device
>> named "pcie-downstream" with Red Hat Vendor ID, and include the
>> group identifier in this device.
>> - Added a new patch to enhance the "pci-bridge" device to support
>> the group identifier (for the i440FX model).
>>
>> Venu Busireddy (4):
>> Add a true or false option to the DEFINE_PROP_UUID macro.
>> Add "Group Identifier" support to virtio devices.
>> Add "Group Identifier" support to Red Hat PCI bridge.
>> Add "Group Identifier" support to Red Hat PCI Express bridge.
>>
>> default-configs/arm-softmmu.mak | 1 +
>> default-configs/i386-softmmu.mak | 1 +
>> default-configs/x86_64-softmmu.mak | 1 +
>> hw/acpi/vmgenid.c | 2 +-
>> hw/pci-bridge/Makefile.objs | 1 +
>> hw/pci-bridge/pci_bridge_dev.c | 8 +
>> hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
>> hw/pci-bridge/pcie_downstream.h | 10 +
>> hw/pci/pci_bridge.c | 26 +++
>> hw/virtio/virtio-pci.c | 15 ++
>> hw/virtio/virtio-pci.h | 3 +-
>> include/hw/pci/pci.h | 3 +
>> include/hw/pci/pcie.h | 1 +
>> include/hw/qdev-properties.h | 4 +-
>> include/standard-headers/linux/virtio_pci.h | 8 +
>> 15 files changed, 295 insertions(+), 4 deletions(-)
>> create mode 100644 hw/pci-bridge/pcie_downstream.c
>> create mode 100644 hw/pci-bridge/pcie_downstream.h
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 7:21 ` Siwei Liu
0 siblings, 0 replies; 55+ messages in thread
From: Siwei Liu @ 2018-06-27 7:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 9:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
>> The patch set "Enable virtio_net to act as a standby for a passthru
>> device" [1] deals with live migration of guests that use passthrough
>> devices. However, that scheme uses the MAC address for pairing
>> the virtio device and the passthrough device. The thread "netvsc:
>> refactor notifier/event handling code to use the failover framework"
>> [2] discusses an alternate mechanism, such as using an UUID, for pairing
>> the devices. Based on that discussion, proposals "Add "Group Identifier"
>> to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
>> store pairing information..." [4] were made.
>>
>> The current patch set includes all the feedback received for proposals [3]
>> and [4]. For the sake of completeness, patch for the virtio specification
>> is also included here. Following is the updated proposal.
>>
>> 1. Extend the virtio specification to include a new virtio PCI capability
>> "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> There's still discussion around whether it should be
> a virtio pci capability, a virtio net config field or
> a new kind of capability.
>
>> 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
>> The "uuid" is a string in UUID format.
>>
>> 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
>> The "uuid" is a string in UUID format. Currently, PCIe bridge for
>> the Q35 model is supported.
>>
>> 4. The operator creates a unique identifier string using 'uuidgen'.
>>
>> 5. When the virtio device is created, the operator uses the "uuid" option
>> (for example, '-device virtio-net-pci,uuid="string"') and specifies
>> the UUID created in step 4.
>>
>> QEMU stores the UUID in the virtio device's configuration space
>> in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>>
>> 6. When assigning a PCI device to the guest in passthrough mode, the
>> operator first creates a bridge using the "uuid" option (for example,
>> '-device pcie-downstream,uuid="string"') to specify the UUID created
>> in step 4, and then attaches the passthrough device to the bridge.
>>
>> QEMU stores the UUID in the configuration space of the bridge as
>> Vendor-Specific capability (0x09). The "Vendor" here is not to be
>> confused with a specific organization. Instead, the vendor of the
>> bridge is QEMU. To avoid mixing up with other bridges, the bridge
>> will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
>> device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
>> option is specified. Otherwise, current defaults are used.
>>
>> 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
>> a passthru device" [1] needs to be modified to use the UUID values
>> present in the bridge's configuration space and the virtio device's
>> configuration space instead of the MAC address for pairing the devices.
>>
>> Thanks!
>>
>> Venu
>
> The part where the visibility of a vfio device is controlled by the
> virtio driver acknowledging the backup feature is missing here.
While it is still being discussed, I tend to put that effort into a
seperate set of patches, and this patch series comes first just for
enabling guest to use the UUID feature (I've some code pending). Does
this division makes sense? I realize that the vfio's visibility work
would need to take a while.
-Siwei
>
>
>> [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
>> [2] https://www.spinics.net/lists/netdev/msg499011.html
>> [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
>> [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
>>
>> Changes in v2:
>> - As Michael Tsirkin suggested, changed the virtio specification
>> to restrict the group identifier to be a 16-byte field, presented
>> entirely in the virtio device's configuration space.
>> - As Michael Tsirkin suggested, instead of tweaking the ioh3420
>> device with Red Hat vendor ID, create a new PCIe bridge device
>> named "pcie-downstream" with Red Hat Vendor ID, and include the
>> group identifier in this device.
>> - Added a new patch to enhance the "pci-bridge" device to support
>> the group identifier (for the i440FX model).
>>
>> Venu Busireddy (4):
>> Add a true or false option to the DEFINE_PROP_UUID macro.
>> Add "Group Identifier" support to virtio devices.
>> Add "Group Identifier" support to Red Hat PCI bridge.
>> Add "Group Identifier" support to Red Hat PCI Express bridge.
>>
>> default-configs/arm-softmmu.mak | 1 +
>> default-configs/i386-softmmu.mak | 1 +
>> default-configs/x86_64-softmmu.mak | 1 +
>> hw/acpi/vmgenid.c | 2 +-
>> hw/pci-bridge/Makefile.objs | 1 +
>> hw/pci-bridge/pci_bridge_dev.c | 8 +
>> hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
>> hw/pci-bridge/pcie_downstream.h | 10 +
>> hw/pci/pci_bridge.c | 26 +++
>> hw/virtio/virtio-pci.c | 15 ++
>> hw/virtio/virtio-pci.h | 3 +-
>> include/hw/pci/pci.h | 3 +
>> include/hw/pci/pcie.h | 1 +
>> include/hw/qdev-properties.h | 4 +-
>> include/standard-headers/linux/virtio_pci.h | 8 +
>> 15 files changed, 295 insertions(+), 4 deletions(-)
>> create mode 100644 hw/pci-bridge/pcie_downstream.c
>> create mode 100644 hw/pci-bridge/pcie_downstream.h
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 4:06 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-27 8:17 ` Cornelia Huck
-1 siblings, 0 replies; 55+ messages in thread
From: Cornelia Huck @ 2018-06-27 8:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel,
Yi Min Zhao, Pierre Morel
On Wed, 27 Jun 2018 07:06:42 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, that scheme uses the MAC address for pairing
> > the virtio device and the passthrough device. The thread "netvsc:
> > refactor notifier/event handling code to use the failover framework"
> > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > store pairing information..." [4] were made.
> >
> > The current patch set includes all the feedback received for proposals [3]
> > and [4]. For the sake of completeness, patch for the virtio specification
> > is also included here. Following is the updated proposal.
> >
> > 1. Extend the virtio specification to include a new virtio PCI capability
> > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> There's still discussion around whether it should be
> a virtio pci capability, a virtio net config field or
> a new kind of capability.
Moreover, I hate to be that person again, but...
>
> > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > The "uuid" is a string in UUID format.
> >
> > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > the Q35 model is supported.
> >
> > 4. The operator creates a unique identifier string using 'uuidgen'.
> >
> > 5. When the virtio device is created, the operator uses the "uuid" option
> > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > the UUID created in step 4.
> >
> > QEMU stores the UUID in the virtio device's configuration space
> > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 6. When assigning a PCI device to the guest in passthrough mode, the
> > operator first creates a bridge using the "uuid" option (for example,
> > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > in step 4, and then attaches the passthrough device to the bridge.
> >
> > QEMU stores the UUID in the configuration space of the bridge as
> > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > confused with a specific organization. Instead, the vendor of the
> > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > option is specified. Otherwise, current defaults are used.
...if the bridge is the means of getting the uuid to the guest for the
passthrough device, I don't see how this can work on s390. Unless I'm
mistaken, we don't see the pci bridge created in QEMU from the guest
(zPCI uses instructions to list functions, and does not have any
topology view). Adding some folks who have worked on zPCI for their
comments.
> >
> > 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
> > a passthru device" [1] needs to be modified to use the UUID values
> > present in the bridge's configuration space and the virtio device's
> > configuration space instead of the MAC address for pairing the devices.
> >
> > Thanks!
> >
> > Venu
>
> The part where the visibility of a vfio device is controlled by the
> virtio driver acknowledging the backup feature is missing here.
Also, shouldn't libvirt be involved at some point in time?
>
>
> > [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
> > [2] https://www.spinics.net/lists/netdev/msg499011.html
> > [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
> > [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
> >
> > Changes in v2:
> > - As Michael Tsirkin suggested, changed the virtio specification
> > to restrict the group identifier to be a 16-byte field, presented
> > entirely in the virtio device's configuration space.
> > - As Michael Tsirkin suggested, instead of tweaking the ioh3420
> > device with Red Hat vendor ID, create a new PCIe bridge device
> > named "pcie-downstream" with Red Hat Vendor ID, and include the
> > group identifier in this device.
> > - Added a new patch to enhance the "pci-bridge" device to support
> > the group identifier (for the i440FX model).
> >
> > Venu Busireddy (4):
> > Add a true or false option to the DEFINE_PROP_UUID macro.
> > Add "Group Identifier" support to virtio devices.
> > Add "Group Identifier" support to Red Hat PCI bridge.
> > Add "Group Identifier" support to Red Hat PCI Express bridge.
> >
> > default-configs/arm-softmmu.mak | 1 +
> > default-configs/i386-softmmu.mak | 1 +
> > default-configs/x86_64-softmmu.mak | 1 +
> > hw/acpi/vmgenid.c | 2 +-
> > hw/pci-bridge/Makefile.objs | 1 +
> > hw/pci-bridge/pci_bridge_dev.c | 8 +
> > hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
> > hw/pci-bridge/pcie_downstream.h | 10 +
> > hw/pci/pci_bridge.c | 26 +++
> > hw/virtio/virtio-pci.c | 15 ++
> > hw/virtio/virtio-pci.h | 3 +-
> > include/hw/pci/pci.h | 3 +
> > include/hw/pci/pcie.h | 1 +
> > include/hw/qdev-properties.h | 4 +-
> > include/standard-headers/linux/virtio_pci.h | 8 +
> > 15 files changed, 295 insertions(+), 4 deletions(-)
> > create mode 100644 hw/pci-bridge/pcie_downstream.c
> > create mode 100644 hw/pci-bridge/pcie_downstream.h
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 8:17 ` Cornelia Huck
0 siblings, 0 replies; 55+ messages in thread
From: Cornelia Huck @ 2018-06-27 8:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel,
Yi Min Zhao, Pierre Morel
On Wed, 27 Jun 2018 07:06:42 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, that scheme uses the MAC address for pairing
> > the virtio device and the passthrough device. The thread "netvsc:
> > refactor notifier/event handling code to use the failover framework"
> > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > store pairing information..." [4] were made.
> >
> > The current patch set includes all the feedback received for proposals [3]
> > and [4]. For the sake of completeness, patch for the virtio specification
> > is also included here. Following is the updated proposal.
> >
> > 1. Extend the virtio specification to include a new virtio PCI capability
> > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> There's still discussion around whether it should be
> a virtio pci capability, a virtio net config field or
> a new kind of capability.
Moreover, I hate to be that person again, but...
>
> > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > The "uuid" is a string in UUID format.
> >
> > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > the Q35 model is supported.
> >
> > 4. The operator creates a unique identifier string using 'uuidgen'.
> >
> > 5. When the virtio device is created, the operator uses the "uuid" option
> > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > the UUID created in step 4.
> >
> > QEMU stores the UUID in the virtio device's configuration space
> > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 6. When assigning a PCI device to the guest in passthrough mode, the
> > operator first creates a bridge using the "uuid" option (for example,
> > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > in step 4, and then attaches the passthrough device to the bridge.
> >
> > QEMU stores the UUID in the configuration space of the bridge as
> > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > confused with a specific organization. Instead, the vendor of the
> > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > option is specified. Otherwise, current defaults are used.
...if the bridge is the means of getting the uuid to the guest for the
passthrough device, I don't see how this can work on s390. Unless I'm
mistaken, we don't see the pci bridge created in QEMU from the guest
(zPCI uses instructions to list functions, and does not have any
topology view). Adding some folks who have worked on zPCI for their
comments.
> >
> > 7. Patch 4 in patch series "Enable virtio_net to act as a standby for
> > a passthru device" [1] needs to be modified to use the UUID values
> > present in the bridge's configuration space and the virtio device's
> > configuration space instead of the MAC address for pairing the devices.
> >
> > Thanks!
> >
> > Venu
>
> The part where the visibility of a vfio device is controlled by the
> virtio driver acknowledging the backup feature is missing here.
Also, shouldn't libvirt be involved at some point in time?
>
>
> > [1] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00156.html
> > [2] https://www.spinics.net/lists/netdev/msg499011.html
> > [3] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html
> > [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00204.html
> >
> > Changes in v2:
> > - As Michael Tsirkin suggested, changed the virtio specification
> > to restrict the group identifier to be a 16-byte field, presented
> > entirely in the virtio device's configuration space.
> > - As Michael Tsirkin suggested, instead of tweaking the ioh3420
> > device with Red Hat vendor ID, create a new PCIe bridge device
> > named "pcie-downstream" with Red Hat Vendor ID, and include the
> > group identifier in this device.
> > - Added a new patch to enhance the "pci-bridge" device to support
> > the group identifier (for the i440FX model).
> >
> > Venu Busireddy (4):
> > Add a true or false option to the DEFINE_PROP_UUID macro.
> > Add "Group Identifier" support to virtio devices.
> > Add "Group Identifier" support to Red Hat PCI bridge.
> > Add "Group Identifier" support to Red Hat PCI Express bridge.
> >
> > default-configs/arm-softmmu.mak | 1 +
> > default-configs/i386-softmmu.mak | 1 +
> > default-configs/x86_64-softmmu.mak | 1 +
> > hw/acpi/vmgenid.c | 2 +-
> > hw/pci-bridge/Makefile.objs | 1 +
> > hw/pci-bridge/pci_bridge_dev.c | 8 +
> > hw/pci-bridge/pcie_downstream.c | 215 ++++++++++++++++++++
> > hw/pci-bridge/pcie_downstream.h | 10 +
> > hw/pci/pci_bridge.c | 26 +++
> > hw/virtio/virtio-pci.c | 15 ++
> > hw/virtio/virtio-pci.h | 3 +-
> > include/hw/pci/pci.h | 3 +
> > include/hw/pci/pcie.h | 1 +
> > include/hw/qdev-properties.h | 4 +-
> > include/standard-headers/linux/virtio_pci.h | 8 +
> > 15 files changed, 295 insertions(+), 4 deletions(-)
> > create mode 100644 hw/pci-bridge/pcie_downstream.c
> > create mode 100644 hw/pci-bridge/pcie_downstream.h
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
` (6 preceding siblings ...)
(?)
@ 2018-06-27 12:24 ` Roman Kagan
2018-06-27 19:29 ` [virtio-dev] " Venu Busireddy
-1 siblings, 1 reply; 55+ messages in thread
From: Roman Kagan @ 2018-06-27 12:24 UTC (permalink / raw)
To: Venu Busireddy
Cc: Michael S . Tsirkin, Marcel Apfelbaum, virtio-dev, qemu-devel
On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> The patch set "Enable virtio_net to act as a standby for a passthru
> device" [1] deals with live migration of guests that use passthrough
> devices. However, that scheme uses the MAC address for pairing
> the virtio device and the passthrough device. The thread "netvsc:
> refactor notifier/event handling code to use the failover framework"
> [2] discusses an alternate mechanism, such as using an UUID, for pairing
> the devices. Based on that discussion, proposals "Add "Group Identifier"
> to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> store pairing information..." [4] were made.
I must have missed something in those threads, but where does this UUID
thing come about? AFAICS this identifier doesn't need to be
"universally" unique, nor persistent; it only has to be unique across
the VM and stable throughout the VM lifetime.
FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
to be implied in the thread you refer to.
> The current patch set includes all the feedback received for proposals [3]
> and [4]. For the sake of completeness, patch for the virtio specification
> is also included here. Following is the updated proposal.
>
> 1. Extend the virtio specification to include a new virtio PCI capability
> "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> The "uuid" is a string in UUID format.
>
> 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> The "uuid" is a string in UUID format. Currently, PCIe bridge for
> the Q35 model is supported.
>
> 4. The operator creates a unique identifier string using 'uuidgen'.
>
> 5. When the virtio device is created, the operator uses the "uuid" option
> (for example, '-device virtio-net-pci,uuid="string"') and specifies
> the UUID created in step 4.
>
> QEMU stores the UUID in the virtio device's configuration space
> in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
>
> 6. When assigning a PCI device to the guest in passthrough mode, the
> operator first creates a bridge using the "uuid" option (for example,
> '-device pcie-downstream,uuid="string"') to specify the UUID created
> in step 4, and then attaches the passthrough device to the bridge.
>
> QEMU stores the UUID in the configuration space of the bridge as
> Vendor-Specific capability (0x09). The "Vendor" here is not to be
> confused with a specific organization. Instead, the vendor of the
> bridge is QEMU. To avoid mixing up with other bridges, the bridge
> will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> option is specified. Otherwise, current defaults are used.
I wonder if it makes more sense to drop the concept of failover groups,
and just refer to the standby device by device-id, like
-device virtio-net-pci,id=foo \
-device pcie-downstream,failover=foo
The bridge device will then lookup the failover device, figure out the
common identifier to expose to the guest, and defer the visibility of
the PT device behind the bridge until the guest acknowledged the support
for failover on the PV device.
Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 12:24 ` [Qemu-devel] " Roman Kagan
@ 2018-06-27 19:29 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 19:29 UTC (permalink / raw)
To: Roman Kagan, Michael S . Tsirkin, Marcel Apfelbaum, virtio-dev,
qemu-devel
On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, that scheme uses the MAC address for pairing
> > the virtio device and the passthrough device. The thread "netvsc:
> > refactor notifier/event handling code to use the failover framework"
> > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > store pairing information..." [4] were made.
>
> I must have missed something in those threads, but where does this UUID
> thing come about? AFAICS this identifier doesn't need to be
> "universally" unique, nor persistent; it only has to be unique across
> the VM and stable throughout the VM lifetime.
The notion of using UUID came up in the thread
https://www.spinics.net/lists/netdev/msg499011.html
> FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> to be implied in the thread you refer to.
Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
However, what we are doing is similar to that. Instead of 32 bits,
we are using 128 bits.
> > The current patch set includes all the feedback received for proposals [3]
> > and [4]. For the sake of completeness, patch for the virtio specification
> > is also included here. Following is the updated proposal.
> >
> > 1. Extend the virtio specification to include a new virtio PCI capability
> > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > The "uuid" is a string in UUID format.
> >
> > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > the Q35 model is supported.
> >
> > 4. The operator creates a unique identifier string using 'uuidgen'.
> >
> > 5. When the virtio device is created, the operator uses the "uuid" option
> > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > the UUID created in step 4.
> >
> > QEMU stores the UUID in the virtio device's configuration space
> > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 6. When assigning a PCI device to the guest in passthrough mode, the
> > operator first creates a bridge using the "uuid" option (for example,
> > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > in step 4, and then attaches the passthrough device to the bridge.
> >
> > QEMU stores the UUID in the configuration space of the bridge as
> > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > confused with a specific organization. Instead, the vendor of the
> > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > option is specified. Otherwise, current defaults are used.
>
> I wonder if it makes more sense to drop the concept of failover groups,
> and just refer to the standby device by device-id, like
>
> -device virtio-net-pci,id=foo \
> -device pcie-downstream,failover=foo
Isn't this the same as what this patch series proposes? In your
suggestion, "foo" is the entity that connects the passthrough device
and the failover device. In this patch set, that "foo" is the UUID,
and the options "id" and "failover" are replaced by "uuid". Do you agree?
Regards,
Venu
> The bridge device will then lookup the failover device, figure out the
> common identifier to expose to the guest, and defer the visibility of
> the PT device behind the bridge until the guest acknowledged the support
> for failover on the PV device.
>
> Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 19:29 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 19:29 UTC (permalink / raw)
To: Roman Kagan, Michael S . Tsirkin, Marcel Apfelbaum, virtio-dev,
qemu-devel
On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > The patch set "Enable virtio_net to act as a standby for a passthru
> > device" [1] deals with live migration of guests that use passthrough
> > devices. However, that scheme uses the MAC address for pairing
> > the virtio device and the passthrough device. The thread "netvsc:
> > refactor notifier/event handling code to use the failover framework"
> > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > store pairing information..." [4] were made.
>
> I must have missed something in those threads, but where does this UUID
> thing come about? AFAICS this identifier doesn't need to be
> "universally" unique, nor persistent; it only has to be unique across
> the VM and stable throughout the VM lifetime.
The notion of using UUID came up in the thread
https://www.spinics.net/lists/netdev/msg499011.html
> FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> to be implied in the thread you refer to.
Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
However, what we are doing is similar to that. Instead of 32 bits,
we are using 128 bits.
> > The current patch set includes all the feedback received for proposals [3]
> > and [4]. For the sake of completeness, patch for the virtio specification
> > is also included here. Following is the updated proposal.
> >
> > 1. Extend the virtio specification to include a new virtio PCI capability
> > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > The "uuid" is a string in UUID format.
> >
> > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > the Q35 model is supported.
> >
> > 4. The operator creates a unique identifier string using 'uuidgen'.
> >
> > 5. When the virtio device is created, the operator uses the "uuid" option
> > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > the UUID created in step 4.
> >
> > QEMU stores the UUID in the virtio device's configuration space
> > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> >
> > 6. When assigning a PCI device to the guest in passthrough mode, the
> > operator first creates a bridge using the "uuid" option (for example,
> > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > in step 4, and then attaches the passthrough device to the bridge.
> >
> > QEMU stores the UUID in the configuration space of the bridge as
> > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > confused with a specific organization. Instead, the vendor of the
> > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > option is specified. Otherwise, current defaults are used.
>
> I wonder if it makes more sense to drop the concept of failover groups,
> and just refer to the standby device by device-id, like
>
> -device virtio-net-pci,id=foo \
> -device pcie-downstream,failover=foo
Isn't this the same as what this patch series proposes? In your
suggestion, "foo" is the entity that connects the passthrough device
and the failover device. In this patch set, that "foo" is the UUID,
and the options "id" and "failover" are replaced by "uuid". Do you agree?
Regards,
Venu
> The bridge device will then lookup the failover device, figure out the
> common identifier to expose to the guest, and defer the visibility of
> the PT device behind the bridge until the guest acknowledged the support
> for failover on the PV device.
>
> Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 19:29 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 19:47 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 19:47 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > device" [1] deals with live migration of guests that use passthrough
> > > devices. However, that scheme uses the MAC address for pairing
> > > the virtio device and the passthrough device. The thread "netvsc:
> > > refactor notifier/event handling code to use the failover framework"
> > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > store pairing information..." [4] were made.
> >
> > I must have missed something in those threads, but where does this UUID
> > thing come about? AFAICS this identifier doesn't need to be
> > "universally" unique, nor persistent; it only has to be unique across
> > the VM and stable throughout the VM lifetime.
>
> The notion of using UUID came up in the thread
>
> https://www.spinics.net/lists/netdev/msg499011.html
That's probably because it was expected one of standard serial number capabilities
(VPD or PCI Express serial #) will be used, which are expected to be unique.
If you are rolling your own vendor specific one, it's just an ID and
does not have to be unique.
> > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > to be implied in the thread you refer to.
>
> Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> However, what we are doing is similar to that. Instead of 32 bits,
> we are using 128 bits.
That's OK. The name is confusing though. It's a failover group id,
not a UUID.
> > > The current patch set includes all the feedback received for proposals [3]
> > > and [4]. For the sake of completeness, patch for the virtio specification
> > > is also included here. Following is the updated proposal.
> > >
> > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > >
> > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > The "uuid" is a string in UUID format.
> > >
> > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > the Q35 model is supported.
> > >
> > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > >
> > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > the UUID created in step 4.
> > >
> > > QEMU stores the UUID in the virtio device's configuration space
> > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > >
> > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > operator first creates a bridge using the "uuid" option (for example,
> > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > in step 4, and then attaches the passthrough device to the bridge.
> > >
> > > QEMU stores the UUID in the configuration space of the bridge as
> > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > confused with a specific organization. Instead, the vendor of the
> > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > option is specified. Otherwise, current defaults are used.
> >
> > I wonder if it makes more sense to drop the concept of failover groups,
> > and just refer to the standby device by device-id, like
> >
> > -device virtio-net-pci,id=foo \
> > -device pcie-downstream,failover=foo
>
> Isn't this the same as what this patch series proposes? In your
> suggestion, "foo" is the entity that connects the passthrough device
> and the failover device. In this patch set, that "foo" is the UUID,
> and the options "id" and "failover" are replaced by "uuid". Do you agree?
>
> Regards,
>
> Venu
>
> > The bridge device will then lookup the failover device, figure out the
> > common identifier to expose to the guest, and defer the visibility of
> > the PT device behind the bridge until the guest acknowledged the support
> > for failover on the PV device.
> >
> > Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 19:47 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 19:47 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > device" [1] deals with live migration of guests that use passthrough
> > > devices. However, that scheme uses the MAC address for pairing
> > > the virtio device and the passthrough device. The thread "netvsc:
> > > refactor notifier/event handling code to use the failover framework"
> > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > store pairing information..." [4] were made.
> >
> > I must have missed something in those threads, but where does this UUID
> > thing come about? AFAICS this identifier doesn't need to be
> > "universally" unique, nor persistent; it only has to be unique across
> > the VM and stable throughout the VM lifetime.
>
> The notion of using UUID came up in the thread
>
> https://www.spinics.net/lists/netdev/msg499011.html
That's probably because it was expected one of standard serial number capabilities
(VPD or PCI Express serial #) will be used, which are expected to be unique.
If you are rolling your own vendor specific one, it's just an ID and
does not have to be unique.
> > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > to be implied in the thread you refer to.
>
> Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> However, what we are doing is similar to that. Instead of 32 bits,
> we are using 128 bits.
That's OK. The name is confusing though. It's a failover group id,
not a UUID.
> > > The current patch set includes all the feedback received for proposals [3]
> > > and [4]. For the sake of completeness, patch for the virtio specification
> > > is also included here. Following is the updated proposal.
> > >
> > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > >
> > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > The "uuid" is a string in UUID format.
> > >
> > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > the Q35 model is supported.
> > >
> > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > >
> > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > the UUID created in step 4.
> > >
> > > QEMU stores the UUID in the virtio device's configuration space
> > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > >
> > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > operator first creates a bridge using the "uuid" option (for example,
> > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > in step 4, and then attaches the passthrough device to the bridge.
> > >
> > > QEMU stores the UUID in the configuration space of the bridge as
> > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > confused with a specific organization. Instead, the vendor of the
> > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > option is specified. Otherwise, current defaults are used.
> >
> > I wonder if it makes more sense to drop the concept of failover groups,
> > and just refer to the standby device by device-id, like
> >
> > -device virtio-net-pci,id=foo \
> > -device pcie-downstream,failover=foo
>
> Isn't this the same as what this patch series proposes? In your
> suggestion, "foo" is the entity that connects the passthrough device
> and the failover device. In this patch set, that "foo" is the UUID,
> and the options "id" and "failover" are replaced by "uuid". Do you agree?
>
> Regards,
>
> Venu
>
> > The bridge device will then lookup the failover device, figure out the
> > common identifier to expose to the guest, and defer the visibility of
> > the PT device behind the bridge until the guest acknowledged the support
> > for failover on the PV device.
> >
> > Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 19:47 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-27 19:59 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 19:59 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > device" [1] deals with live migration of guests that use passthrough
> > > > devices. However, that scheme uses the MAC address for pairing
> > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > refactor notifier/event handling code to use the failover framework"
> > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > store pairing information..." [4] were made.
> > >
> > > I must have missed something in those threads, but where does this UUID
> > > thing come about? AFAICS this identifier doesn't need to be
> > > "universally" unique, nor persistent; it only has to be unique across
> > > the VM and stable throughout the VM lifetime.
> >
> > The notion of using UUID came up in the thread
> >
> > https://www.spinics.net/lists/netdev/msg499011.html
>
> That's probably because it was expected one of standard serial number capabilities
> (VPD or PCI Express serial #) will be used, which are expected to be unique.
>
> If you are rolling your own vendor specific one, it's just an ID and
> does not have to be unique.
>
> > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > to be implied in the thread you refer to.
> >
> > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > However, what we are doing is similar to that. Instead of 32 bits,
> > we are using 128 bits.
>
> That's OK. The name is confusing though. It's a failover group id,
> not a UUID.
Sure, we can name it whatever we want. I can change it to
"failover-group-id", if that is what we want to call it.
But what is more important is, what is represented by that name? I thought
we were going to use UUID. The QEMU command line changes in this patch
set expect the user to specify an UUID as the value for this option
(whatever we name it). Are we still in agreement about that, or do you
propose something else to be used? If so, what is it? A 32-bit number, a
64-bit number, or an arbitrary string?
Regards,
Venu
>
> > > > The current patch set includes all the feedback received for proposals [3]
> > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > is also included here. Following is the updated proposal.
> > > >
> > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > >
> > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > The "uuid" is a string in UUID format.
> > > >
> > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > the Q35 model is supported.
> > > >
> > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > >
> > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > the UUID created in step 4.
> > > >
> > > > QEMU stores the UUID in the virtio device's configuration space
> > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > >
> > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > operator first creates a bridge using the "uuid" option (for example,
> > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > in step 4, and then attaches the passthrough device to the bridge.
> > > >
> > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > confused with a specific organization. Instead, the vendor of the
> > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > option is specified. Otherwise, current defaults are used.
> > >
> > > I wonder if it makes more sense to drop the concept of failover groups,
> > > and just refer to the standby device by device-id, like
> > >
> > > -device virtio-net-pci,id=foo \
> > > -device pcie-downstream,failover=foo
> >
> > Isn't this the same as what this patch series proposes? In your
> > suggestion, "foo" is the entity that connects the passthrough device
> > and the failover device. In this patch set, that "foo" is the UUID,
> > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> >
> > Regards,
> >
> > Venu
> >
> > > The bridge device will then lookup the failover device, figure out the
> > > common identifier to expose to the guest, and defer the visibility of
> > > the PT device behind the bridge until the guest acknowledged the support
> > > for failover on the PV device.
> > >
> > > Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 19:59 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 19:59 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > device" [1] deals with live migration of guests that use passthrough
> > > > devices. However, that scheme uses the MAC address for pairing
> > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > refactor notifier/event handling code to use the failover framework"
> > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > store pairing information..." [4] were made.
> > >
> > > I must have missed something in those threads, but where does this UUID
> > > thing come about? AFAICS this identifier doesn't need to be
> > > "universally" unique, nor persistent; it only has to be unique across
> > > the VM and stable throughout the VM lifetime.
> >
> > The notion of using UUID came up in the thread
> >
> > https://www.spinics.net/lists/netdev/msg499011.html
>
> That's probably because it was expected one of standard serial number capabilities
> (VPD or PCI Express serial #) will be used, which are expected to be unique.
>
> If you are rolling your own vendor specific one, it's just an ID and
> does not have to be unique.
>
> > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > to be implied in the thread you refer to.
> >
> > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > However, what we are doing is similar to that. Instead of 32 bits,
> > we are using 128 bits.
>
> That's OK. The name is confusing though. It's a failover group id,
> not a UUID.
Sure, we can name it whatever we want. I can change it to
"failover-group-id", if that is what we want to call it.
But what is more important is, what is represented by that name? I thought
we were going to use UUID. The QEMU command line changes in this patch
set expect the user to specify an UUID as the value for this option
(whatever we name it). Are we still in agreement about that, or do you
propose something else to be used? If so, what is it? A 32-bit number, a
64-bit number, or an arbitrary string?
Regards,
Venu
>
> > > > The current patch set includes all the feedback received for proposals [3]
> > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > is also included here. Following is the updated proposal.
> > > >
> > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > >
> > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > The "uuid" is a string in UUID format.
> > > >
> > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > the Q35 model is supported.
> > > >
> > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > >
> > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > the UUID created in step 4.
> > > >
> > > > QEMU stores the UUID in the virtio device's configuration space
> > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > >
> > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > operator first creates a bridge using the "uuid" option (for example,
> > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > in step 4, and then attaches the passthrough device to the bridge.
> > > >
> > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > confused with a specific organization. Instead, the vendor of the
> > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > option is specified. Otherwise, current defaults are used.
> > >
> > > I wonder if it makes more sense to drop the concept of failover groups,
> > > and just refer to the standby device by device-id, like
> > >
> > > -device virtio-net-pci,id=foo \
> > > -device pcie-downstream,failover=foo
> >
> > Isn't this the same as what this patch series proposes? In your
> > suggestion, "foo" is the entity that connects the passthrough device
> > and the failover device. In this patch set, that "foo" is the UUID,
> > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> >
> > Regards,
> >
> > Venu
> >
> > > The bridge device will then lookup the failover device, figure out the
> > > common identifier to expose to the guest, and defer the visibility of
> > > the PT device behind the bridge until the guest acknowledged the support
> > > for failover on the PV device.
> > >
> > > Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 19:59 ` [virtio-dev] " Venu Busireddy
@ 2018-06-27 20:12 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 20:12 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > refactor notifier/event handling code to use the failover framework"
> > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > store pairing information..." [4] were made.
> > > >
> > > > I must have missed something in those threads, but where does this UUID
> > > > thing come about? AFAICS this identifier doesn't need to be
> > > > "universally" unique, nor persistent; it only has to be unique across
> > > > the VM and stable throughout the VM lifetime.
> > >
> > > The notion of using UUID came up in the thread
> > >
> > > https://www.spinics.net/lists/netdev/msg499011.html
> >
> > That's probably because it was expected one of standard serial number capabilities
> > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> >
> > If you are rolling your own vendor specific one, it's just an ID and
> > does not have to be unique.
> >
> > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > to be implied in the thread you refer to.
> > >
> > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > However, what we are doing is similar to that. Instead of 32 bits,
> > > we are using 128 bits.
> >
> > That's OK. The name is confusing though. It's a failover group id,
> > not a UUID.
>
> Sure, we can name it whatever we want. I can change it to
> "failover-group-id", if that is what we want to call it.
>
> But what is more important is, what is represented by that name? I thought
> we were going to use UUID. The QEMU command line changes in this patch
> set expect the user to specify an UUID as the value for this option
> (whatever we name it). Are we still in agreement about that, or do you
> propose something else to be used? If so, what is it? A 32-bit number, a
> 64-bit number, or an arbitrary string?
>
> Regards,
>
> Venu
If we don't really need a UUID, I'd avoid that requirement.
> >
> > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > is also included here. Following is the updated proposal.
> > > > >
> > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > >
> > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > The "uuid" is a string in UUID format.
> > > > >
> > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > the Q35 model is supported.
> > > > >
> > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > >
> > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > the UUID created in step 4.
> > > > >
> > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > >
> > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > >
> > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > confused with a specific organization. Instead, the vendor of the
> > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > option is specified. Otherwise, current defaults are used.
> > > >
> > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > and just refer to the standby device by device-id, like
> > > >
> > > > -device virtio-net-pci,id=foo \
> > > > -device pcie-downstream,failover=foo
> > >
> > > Isn't this the same as what this patch series proposes? In your
> > > suggestion, "foo" is the entity that connects the passthrough device
> > > and the failover device. In this patch set, that "foo" is the UUID,
> > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > >
> > > Regards,
> > >
> > > Venu
> > >
> > > > The bridge device will then lookup the failover device, figure out the
> > > > common identifier to expose to the guest, and defer the visibility of
> > > > the PT device behind the bridge until the guest acknowledged the support
> > > > for failover on the PV device.
> > > >
> > > > Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 20:12 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-27 20:12 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > refactor notifier/event handling code to use the failover framework"
> > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > store pairing information..." [4] were made.
> > > >
> > > > I must have missed something in those threads, but where does this UUID
> > > > thing come about? AFAICS this identifier doesn't need to be
> > > > "universally" unique, nor persistent; it only has to be unique across
> > > > the VM and stable throughout the VM lifetime.
> > >
> > > The notion of using UUID came up in the thread
> > >
> > > https://www.spinics.net/lists/netdev/msg499011.html
> >
> > That's probably because it was expected one of standard serial number capabilities
> > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> >
> > If you are rolling your own vendor specific one, it's just an ID and
> > does not have to be unique.
> >
> > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > to be implied in the thread you refer to.
> > >
> > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > However, what we are doing is similar to that. Instead of 32 bits,
> > > we are using 128 bits.
> >
> > That's OK. The name is confusing though. It's a failover group id,
> > not a UUID.
>
> Sure, we can name it whatever we want. I can change it to
> "failover-group-id", if that is what we want to call it.
>
> But what is more important is, what is represented by that name? I thought
> we were going to use UUID. The QEMU command line changes in this patch
> set expect the user to specify an UUID as the value for this option
> (whatever we name it). Are we still in agreement about that, or do you
> propose something else to be used? If so, what is it? A 32-bit number, a
> 64-bit number, or an arbitrary string?
>
> Regards,
>
> Venu
If we don't really need a UUID, I'd avoid that requirement.
> >
> > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > is also included here. Following is the updated proposal.
> > > > >
> > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > >
> > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > The "uuid" is a string in UUID format.
> > > > >
> > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > the Q35 model is supported.
> > > > >
> > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > >
> > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > the UUID created in step 4.
> > > > >
> > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > >
> > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > >
> > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > confused with a specific organization. Instead, the vendor of the
> > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > option is specified. Otherwise, current defaults are used.
> > > >
> > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > and just refer to the standby device by device-id, like
> > > >
> > > > -device virtio-net-pci,id=foo \
> > > > -device pcie-downstream,failover=foo
> > >
> > > Isn't this the same as what this patch series proposes? In your
> > > suggestion, "foo" is the entity that connects the passthrough device
> > > and the failover device. In this patch set, that "foo" is the UUID,
> > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > >
> > > Regards,
> > >
> > > Venu
> > >
> > > > The bridge device will then lookup the failover device, figure out the
> > > > common identifier to expose to the guest, and defer the visibility of
> > > > the PT device behind the bridge until the guest acknowledged the support
> > > > for failover on the PV device.
> > > >
> > > > Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 20:12 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-27 22:34 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 22:34 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > store pairing information..." [4] were made.
> > > > >
> > > > > I must have missed something in those threads, but where does this UUID
> > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > the VM and stable throughout the VM lifetime.
> > > >
> > > > The notion of using UUID came up in the thread
> > > >
> > > > https://www.spinics.net/lists/netdev/msg499011.html
> > >
> > > That's probably because it was expected one of standard serial number capabilities
> > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > >
> > > If you are rolling your own vendor specific one, it's just an ID and
> > > does not have to be unique.
> > >
> > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > to be implied in the thread you refer to.
> > > >
> > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > we are using 128 bits.
> > >
> > > That's OK. The name is confusing though. It's a failover group id,
> > > not a UUID.
> >
> > Sure, we can name it whatever we want. I can change it to
> > "failover-group-id", if that is what we want to call it.
> >
> > But what is more important is, what is represented by that name? I thought
> > we were going to use UUID. The QEMU command line changes in this patch
> > set expect the user to specify an UUID as the value for this option
> > (whatever we name it). Are we still in agreement about that, or do you
> > propose something else to be used? If so, what is it? A 32-bit number, a
> > 64-bit number, or an arbitrary string?
> >
> > Regards,
> >
> > Venu
>
> If we don't really need a UUID, I'd avoid that requirement.
I don't see the need for a 128-bit UUID. I just took that approach because
UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
Since it is unlikely to have more than 4 billion devices in the system,
a 32-bit value would be more than enough to uniquely identify devices!
I am looking for direction from you :-). Roman already opined that UUID
may be an overkill. It appears that you too are leaning that way. Would
it be acceptable if I change the group identifier ("failover-group-id")
to a 32-bit value? If you concur, I will start reworking my patch. Could
you please confirm?
Thanks,
Venu
>
>
> > >
> > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > is also included here. Following is the updated proposal.
> > > > > >
> > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > >
> > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > The "uuid" is a string in UUID format.
> > > > > >
> > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > the Q35 model is supported.
> > > > > >
> > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > >
> > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > the UUID created in step 4.
> > > > > >
> > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > >
> > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > >
> > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > option is specified. Otherwise, current defaults are used.
> > > > >
> > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > and just refer to the standby device by device-id, like
> > > > >
> > > > > -device virtio-net-pci,id=foo \
> > > > > -device pcie-downstream,failover=foo
> > > >
> > > > Isn't this the same as what this patch series proposes? In your
> > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > >
> > > > Regards,
> > > >
> > > > Venu
> > > >
> > > > > The bridge device will then lookup the failover device, figure out the
> > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > for failover on the PV device.
> > > > >
> > > > > Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-27 22:34 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 22:34 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > store pairing information..." [4] were made.
> > > > >
> > > > > I must have missed something in those threads, but where does this UUID
> > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > the VM and stable throughout the VM lifetime.
> > > >
> > > > The notion of using UUID came up in the thread
> > > >
> > > > https://www.spinics.net/lists/netdev/msg499011.html
> > >
> > > That's probably because it was expected one of standard serial number capabilities
> > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > >
> > > If you are rolling your own vendor specific one, it's just an ID and
> > > does not have to be unique.
> > >
> > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > to be implied in the thread you refer to.
> > > >
> > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > we are using 128 bits.
> > >
> > > That's OK. The name is confusing though. It's a failover group id,
> > > not a UUID.
> >
> > Sure, we can name it whatever we want. I can change it to
> > "failover-group-id", if that is what we want to call it.
> >
> > But what is more important is, what is represented by that name? I thought
> > we were going to use UUID. The QEMU command line changes in this patch
> > set expect the user to specify an UUID as the value for this option
> > (whatever we name it). Are we still in agreement about that, or do you
> > propose something else to be used? If so, what is it? A 32-bit number, a
> > 64-bit number, or an arbitrary string?
> >
> > Regards,
> >
> > Venu
>
> If we don't really need a UUID, I'd avoid that requirement.
I don't see the need for a 128-bit UUID. I just took that approach because
UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
Since it is unlikely to have more than 4 billion devices in the system,
a 32-bit value would be more than enough to uniquely identify devices!
I am looking for direction from you :-). Roman already opined that UUID
may be an overkill. It appears that you too are leaning that way. Would
it be acceptable if I change the group identifier ("failover-group-id")
to a 32-bit value? If you concur, I will start reworking my patch. Could
you please confirm?
Thanks,
Venu
>
>
> > >
> > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > is also included here. Following is the updated proposal.
> > > > > >
> > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > >
> > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > The "uuid" is a string in UUID format.
> > > > > >
> > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > the Q35 model is supported.
> > > > > >
> > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > >
> > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > the UUID created in step 4.
> > > > > >
> > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > >
> > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > >
> > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > option is specified. Otherwise, current defaults are used.
> > > > >
> > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > and just refer to the standby device by device-id, like
> > > > >
> > > > > -device virtio-net-pci,id=foo \
> > > > > -device pcie-downstream,failover=foo
> > > >
> > > > Isn't this the same as what this patch series proposes? In your
> > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > >
> > > > Regards,
> > > >
> > > > Venu
> > > >
> > > > > The bridge device will then lookup the failover device, figure out the
> > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > for failover on the PV device.
> > > > >
> > > > > Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-27 4:08 ` Venu Busireddy
@ 2018-06-27 23:07 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 23:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
> On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > used to pair a virtio device with the passthrough device attached to
> > > that bridge.
> > >
> > > This capability is added to the bridge iff the "uuid" option is specified
> > > for the bridge.
> >
> > I think the name should be more explicit. How about "failover-group-id"?
>
> I can change it. But don't you think it is bit long?
>
> > >
> > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> >
> > I'd like to also tweak the device id in this case,
> > to make it easier for guests to know it's a grouping bridge.
>
> Could you please recommend a name for the new ID'd definition? Something
> in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
How about these names and values for the device IDs?
PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
Thanks,
Venu
> > > ---
> > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > > include/hw/pci/pcie.h | 1 +
> > > 3 files changed, 35 insertions(+)
> > >
> > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > > index b2d861d216..bbbc6fa1c6 100644
> > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > > }
> > >
> > > + err = pci_bridge_vendor_init(dev, 0, errp);
> > > + if (err < 0) {
> > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > > + goto vendor_cap_err;
> > > + }
> > > +
> > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > > if (err) {
> > > goto slotid_error;
> > > @@ -109,6 +115,7 @@ slotid_error:
> > > if (shpc_present(dev)) {
> > > shpc_cleanup(dev, &bridge_dev->bar);
> > > }
> > > +vendor_cap_err:
> > > shpc_error:
> > > pci_bridge_exitfn(dev);
> > > }
> > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > > ON_OFF_AUTO_AUTO),
> > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > > DEFINE_PROP_END_OF_LIST(),
> > > };
> > >
> > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > > index 40a39f57cb..cb8b3dad2a 100644
> > > --- a/hw/pci/pci_bridge.c
> > > +++ b/hw/pci/pci_bridge.c
> > > @@ -34,12 +34,17 @@
> > > #include "hw/pci/pci_bus.h"
> > > #include "qemu/range.h"
> > > #include "qapi/error.h"
> > > +#include "qemu/uuid.h"
> > >
> > > /* PCI bridge subsystem vendor ID helper functions */
> > > #define PCI_SSVID_SIZEOF 8
> > > #define PCI_SSVID_SVID 4
> > > #define PCI_SSVID_SSID 6
> > >
> > > +#define PCI_VENDOR_SIZEOF 20
> > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > > +
> > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > uint16_t svid, uint16_t ssid,
> > > Error **errp)
> > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > return pos;
> > > }
> > >
> > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > > +{
> > > + int pos;
> > > +
> > > + if (qemu_uuid_is_null(&d->uuid)) {
> > > + return 0;
> > > + }
> > > +
> > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > > + errp);
> > > + if (pos < 0) {
> > > + return pos;
> > > + }
> > > +
> > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > > + PCI_VENDOR_SIZEOF);
> > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > > + sizeof(QemuUUID));
> > > + return pos;
> > > +}
> > > +
> > > /* Accessor function to get parent bridge device from pci bus. */
> > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > > {
> > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > > index b71e369703..b4189d0ce3 100644
> > > --- a/include/hw/pci/pcie.h
> > > +++ b/include/hw/pci/pcie.h
> > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > > };
> > >
> > > #define COMPAT_PROP_PCP "power_controller_present"
> > > +#define COMPAT_PROP_UUID "uuid"
> > >
> > > /* PCI express capability helper functions */
> > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-27 23:07 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-27 23:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
> On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > used to pair a virtio device with the passthrough device attached to
> > > that bridge.
> > >
> > > This capability is added to the bridge iff the "uuid" option is specified
> > > for the bridge.
> >
> > I think the name should be more explicit. How about "failover-group-id"?
>
> I can change it. But don't you think it is bit long?
>
> > >
> > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> >
> > I'd like to also tweak the device id in this case,
> > to make it easier for guests to know it's a grouping bridge.
>
> Could you please recommend a name for the new ID'd definition? Something
> in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
How about these names and values for the device IDs?
PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
Thanks,
Venu
> > > ---
> > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > > include/hw/pci/pcie.h | 1 +
> > > 3 files changed, 35 insertions(+)
> > >
> > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > > index b2d861d216..bbbc6fa1c6 100644
> > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > > }
> > >
> > > + err = pci_bridge_vendor_init(dev, 0, errp);
> > > + if (err < 0) {
> > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > > + goto vendor_cap_err;
> > > + }
> > > +
> > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > > if (err) {
> > > goto slotid_error;
> > > @@ -109,6 +115,7 @@ slotid_error:
> > > if (shpc_present(dev)) {
> > > shpc_cleanup(dev, &bridge_dev->bar);
> > > }
> > > +vendor_cap_err:
> > > shpc_error:
> > > pci_bridge_exitfn(dev);
> > > }
> > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > > ON_OFF_AUTO_AUTO),
> > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > > DEFINE_PROP_END_OF_LIST(),
> > > };
> > >
> > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > > index 40a39f57cb..cb8b3dad2a 100644
> > > --- a/hw/pci/pci_bridge.c
> > > +++ b/hw/pci/pci_bridge.c
> > > @@ -34,12 +34,17 @@
> > > #include "hw/pci/pci_bus.h"
> > > #include "qemu/range.h"
> > > #include "qapi/error.h"
> > > +#include "qemu/uuid.h"
> > >
> > > /* PCI bridge subsystem vendor ID helper functions */
> > > #define PCI_SSVID_SIZEOF 8
> > > #define PCI_SSVID_SVID 4
> > > #define PCI_SSVID_SSID 6
> > >
> > > +#define PCI_VENDOR_SIZEOF 20
> > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > > +
> > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > uint16_t svid, uint16_t ssid,
> > > Error **errp)
> > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > return pos;
> > > }
> > >
> > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > > +{
> > > + int pos;
> > > +
> > > + if (qemu_uuid_is_null(&d->uuid)) {
> > > + return 0;
> > > + }
> > > +
> > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > > + errp);
> > > + if (pos < 0) {
> > > + return pos;
> > > + }
> > > +
> > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > > + PCI_VENDOR_SIZEOF);
> > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > > + sizeof(QemuUUID));
> > > + return pos;
> > > +}
> > > +
> > > /* Accessor function to get parent bridge device from pci bus. */
> > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > > {
> > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > > index b71e369703..b4189d0ce3 100644
> > > --- a/include/hw/pci/pcie.h
> > > +++ b/include/hw/pci/pcie.h
> > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > > };
> > >
> > > #define COMPAT_PROP_PCP "power_controller_present"
> > > +#define COMPAT_PROP_UUID "uuid"
> > >
> > > /* PCI express capability helper functions */
> > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 22:34 ` [virtio-dev] " Venu Busireddy
@ 2018-06-28 1:54 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-28 1:54 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > store pairing information..." [4] were made.
> > > > > >
> > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > the VM and stable throughout the VM lifetime.
> > > > >
> > > > > The notion of using UUID came up in the thread
> > > > >
> > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > >
> > > > That's probably because it was expected one of standard serial number capabilities
> > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > >
> > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > does not have to be unique.
> > > >
> > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > to be implied in the thread you refer to.
> > > > >
> > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > we are using 128 bits.
> > > >
> > > > That's OK. The name is confusing though. It's a failover group id,
> > > > not a UUID.
> > >
> > > Sure, we can name it whatever we want. I can change it to
> > > "failover-group-id", if that is what we want to call it.
> > >
> > > But what is more important is, what is represented by that name? I thought
> > > we were going to use UUID. The QEMU command line changes in this patch
> > > set expect the user to specify an UUID as the value for this option
> > > (whatever we name it). Are we still in agreement about that, or do you
> > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > 64-bit number, or an arbitrary string?
> > >
> > > Regards,
> > >
> > > Venu
> >
> > If we don't really need a UUID, I'd avoid that requirement.
>
> I don't see the need for a 128-bit UUID. I just took that approach because
> UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> Since it is unlikely to have more than 4 billion devices in the system,
> a 32-bit value would be more than enough to uniquely identify devices!
>
> I am looking for direction from you :-). Roman already opined that UUID
> may be an overkill. It appears that you too are leaning that way. Would
> it be acceptable if I change the group identifier ("failover-group-id")
> to a 32-bit value? If you concur, I will start reworking my patch. Could
> you please confirm?
>
> Thanks,
>
> Venu
I would do a 64 bit one, just in case we want to use PCI Express Device
Serial Number down the road.
> >
> >
> > > >
> > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > is also included here. Following is the updated proposal.
> > > > > > >
> > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > >
> > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > The "uuid" is a string in UUID format.
> > > > > > >
> > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > the Q35 model is supported.
> > > > > > >
> > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > >
> > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > the UUID created in step 4.
> > > > > > >
> > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > >
> > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > >
> > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > >
> > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > and just refer to the standby device by device-id, like
> > > > > >
> > > > > > -device virtio-net-pci,id=foo \
> > > > > > -device pcie-downstream,failover=foo
> > > > >
> > > > > Isn't this the same as what this patch series proposes? In your
> > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Venu
> > > > >
> > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > for failover on the PV device.
> > > > > >
> > > > > > Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-28 1:54 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-28 1:54 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > store pairing information..." [4] were made.
> > > > > >
> > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > the VM and stable throughout the VM lifetime.
> > > > >
> > > > > The notion of using UUID came up in the thread
> > > > >
> > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > >
> > > > That's probably because it was expected one of standard serial number capabilities
> > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > >
> > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > does not have to be unique.
> > > >
> > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > to be implied in the thread you refer to.
> > > > >
> > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > we are using 128 bits.
> > > >
> > > > That's OK. The name is confusing though. It's a failover group id,
> > > > not a UUID.
> > >
> > > Sure, we can name it whatever we want. I can change it to
> > > "failover-group-id", if that is what we want to call it.
> > >
> > > But what is more important is, what is represented by that name? I thought
> > > we were going to use UUID. The QEMU command line changes in this patch
> > > set expect the user to specify an UUID as the value for this option
> > > (whatever we name it). Are we still in agreement about that, or do you
> > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > 64-bit number, or an arbitrary string?
> > >
> > > Regards,
> > >
> > > Venu
> >
> > If we don't really need a UUID, I'd avoid that requirement.
>
> I don't see the need for a 128-bit UUID. I just took that approach because
> UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> Since it is unlikely to have more than 4 billion devices in the system,
> a 32-bit value would be more than enough to uniquely identify devices!
>
> I am looking for direction from you :-). Roman already opined that UUID
> may be an overkill. It appears that you too are leaning that way. Would
> it be acceptable if I change the group identifier ("failover-group-id")
> to a 32-bit value? If you concur, I will start reworking my patch. Could
> you please confirm?
>
> Thanks,
>
> Venu
I would do a 64 bit one, just in case we want to use PCI Express Device
Serial Number down the road.
> >
> >
> > > >
> > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > is also included here. Following is the updated proposal.
> > > > > > >
> > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > >
> > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > The "uuid" is a string in UUID format.
> > > > > > >
> > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > the Q35 model is supported.
> > > > > > >
> > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > >
> > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > the UUID created in step 4.
> > > > > > >
> > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > >
> > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > >
> > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > >
> > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > and just refer to the standby device by device-id, like
> > > > > >
> > > > > > -device virtio-net-pci,id=foo \
> > > > > > -device pcie-downstream,failover=foo
> > > > >
> > > > > Isn't this the same as what this patch series proposes? In your
> > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Venu
> > > > >
> > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > for failover on the PV device.
> > > > > >
> > > > > > Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-27 23:07 ` Venu Busireddy
@ 2018-06-28 2:14 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-28 2:14 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 06:07:59PM -0500, Venu Busireddy wrote:
> On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
> > On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > > used to pair a virtio device with the passthrough device attached to
> > > > that bridge.
> > > >
> > > > This capability is added to the bridge iff the "uuid" option is specified
> > > > for the bridge.
> > >
> > > I think the name should be more explicit. How about "failover-group-id"?
> >
> > I can change it. But don't you think it is bit long?
> >
> > > >
> > > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> > >
> > > I'd like to also tweak the device id in this case,
> > > to make it easier for guests to know it's a grouping bridge.
> >
> > Could you please recommend a name for the new ID'd definition? Something
> > in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
>
> How about these names and values for the device IDs?
>
> PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
You do not need the second PCI, and group is one of the
functions of bridge anyway.
PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER?
> PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
>
> Thanks,
>
> Venu
PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER?
It's becoming annoying though - we'll need one for each type :(
Ideas/options:
- use revision ID to distinguish from regular bridge
- use device serial # cap for the bridge when it's an express device
> > > > ---
> > > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > > > include/hw/pci/pcie.h | 1 +
> > > > 3 files changed, 35 insertions(+)
> > > >
> > > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > > > index b2d861d216..bbbc6fa1c6 100644
> > > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > > > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > > > }
> > > >
> > > > + err = pci_bridge_vendor_init(dev, 0, errp);
> > > > + if (err < 0) {
> > > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > > > + goto vendor_cap_err;
> > > > + }
> > > > +
> > > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > > > if (err) {
> > > > goto slotid_error;
> > > > @@ -109,6 +115,7 @@ slotid_error:
> > > > if (shpc_present(dev)) {
> > > > shpc_cleanup(dev, &bridge_dev->bar);
> > > > }
> > > > +vendor_cap_err:
> > > > shpc_error:
> > > > pci_bridge_exitfn(dev);
> > > > }
> > > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > > > ON_OFF_AUTO_AUTO),
> > > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > > > DEFINE_PROP_END_OF_LIST(),
> > > > };
> > > >
> > > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > > > index 40a39f57cb..cb8b3dad2a 100644
> > > > --- a/hw/pci/pci_bridge.c
> > > > +++ b/hw/pci/pci_bridge.c
> > > > @@ -34,12 +34,17 @@
> > > > #include "hw/pci/pci_bus.h"
> > > > #include "qemu/range.h"
> > > > #include "qapi/error.h"
> > > > +#include "qemu/uuid.h"
> > > >
> > > > /* PCI bridge subsystem vendor ID helper functions */
> > > > #define PCI_SSVID_SIZEOF 8
> > > > #define PCI_SSVID_SVID 4
> > > > #define PCI_SSVID_SSID 6
> > > >
> > > > +#define PCI_VENDOR_SIZEOF 20
> > > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > > > +
> > > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > uint16_t svid, uint16_t ssid,
> > > > Error **errp)
> > > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > return pos;
> > > > }
> > > >
> > > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > > > +{
> > > > + int pos;
> > > > +
> > > > + if (qemu_uuid_is_null(&d->uuid)) {
> > > > + return 0;
> > > > + }
> > > > +
> > > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > > > + errp);
> > > > + if (pos < 0) {
> > > > + return pos;
> > > > + }
> > > > +
> > > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > > > + PCI_VENDOR_SIZEOF);
> > > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > > > + sizeof(QemuUUID));
> > > > + return pos;
> > > > +}
> > > > +
> > > > /* Accessor function to get parent bridge device from pci bus. */
> > > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > > > {
> > > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > > > index b71e369703..b4189d0ce3 100644
> > > > --- a/include/hw/pci/pcie.h
> > > > +++ b/include/hw/pci/pcie.h
> > > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > > > };
> > > >
> > > > #define COMPAT_PROP_PCP "power_controller_present"
> > > > +#define COMPAT_PROP_UUID "uuid"
> > > >
> > > > /* PCI express capability helper functions */
> > > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-28 2:14 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-28 2:14 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 06:07:59PM -0500, Venu Busireddy wrote:
> On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
> > On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > > used to pair a virtio device with the passthrough device attached to
> > > > that bridge.
> > > >
> > > > This capability is added to the bridge iff the "uuid" option is specified
> > > > for the bridge.
> > >
> > > I think the name should be more explicit. How about "failover-group-id"?
> >
> > I can change it. But don't you think it is bit long?
> >
> > > >
> > > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> > >
> > > I'd like to also tweak the device id in this case,
> > > to make it easier for guests to know it's a grouping bridge.
> >
> > Could you please recommend a name for the new ID'd definition? Something
> > in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
>
> How about these names and values for the device IDs?
>
> PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
You do not need the second PCI, and group is one of the
functions of bridge anyway.
PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER?
> PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
>
> Thanks,
>
> Venu
PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER?
It's becoming annoying though - we'll need one for each type :(
Ideas/options:
- use revision ID to distinguish from regular bridge
- use device serial # cap for the bridge when it's an express device
> > > > ---
> > > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > > > include/hw/pci/pcie.h | 1 +
> > > > 3 files changed, 35 insertions(+)
> > > >
> > > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > > > index b2d861d216..bbbc6fa1c6 100644
> > > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > > > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > > > }
> > > >
> > > > + err = pci_bridge_vendor_init(dev, 0, errp);
> > > > + if (err < 0) {
> > > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > > > + goto vendor_cap_err;
> > > > + }
> > > > +
> > > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > > > if (err) {
> > > > goto slotid_error;
> > > > @@ -109,6 +115,7 @@ slotid_error:
> > > > if (shpc_present(dev)) {
> > > > shpc_cleanup(dev, &bridge_dev->bar);
> > > > }
> > > > +vendor_cap_err:
> > > > shpc_error:
> > > > pci_bridge_exitfn(dev);
> > > > }
> > > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > > > ON_OFF_AUTO_AUTO),
> > > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > > > DEFINE_PROP_END_OF_LIST(),
> > > > };
> > > >
> > > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > > > index 40a39f57cb..cb8b3dad2a 100644
> > > > --- a/hw/pci/pci_bridge.c
> > > > +++ b/hw/pci/pci_bridge.c
> > > > @@ -34,12 +34,17 @@
> > > > #include "hw/pci/pci_bus.h"
> > > > #include "qemu/range.h"
> > > > #include "qapi/error.h"
> > > > +#include "qemu/uuid.h"
> > > >
> > > > /* PCI bridge subsystem vendor ID helper functions */
> > > > #define PCI_SSVID_SIZEOF 8
> > > > #define PCI_SSVID_SVID 4
> > > > #define PCI_SSVID_SSID 6
> > > >
> > > > +#define PCI_VENDOR_SIZEOF 20
> > > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > > > +
> > > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > uint16_t svid, uint16_t ssid,
> > > > Error **errp)
> > > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > return pos;
> > > > }
> > > >
> > > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > > > +{
> > > > + int pos;
> > > > +
> > > > + if (qemu_uuid_is_null(&d->uuid)) {
> > > > + return 0;
> > > > + }
> > > > +
> > > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > > > + errp);
> > > > + if (pos < 0) {
> > > > + return pos;
> > > > + }
> > > > +
> > > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > > > + PCI_VENDOR_SIZEOF);
> > > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > > > + sizeof(QemuUUID));
> > > > + return pos;
> > > > +}
> > > > +
> > > > /* Accessor function to get parent bridge device from pci bus. */
> > > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > > > {
> > > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > > > index b71e369703..b4189d0ce3 100644
> > > > --- a/include/hw/pci/pcie.h
> > > > +++ b/include/hw/pci/pcie.h
> > > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > > > };
> > > >
> > > > #define COMPAT_PROP_PCP "power_controller_present"
> > > > +#define COMPAT_PROP_UUID "uuid"
> > > >
> > > > /* PCI express capability helper functions */
> > > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-28 1:54 ` [virtio-dev] " Michael S. Tsirkin
@ 2018-06-28 3:27 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-28 3:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-28 04:54:16 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> > On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > > store pairing information..." [4] were made.
> > > > > > >
> > > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > > the VM and stable throughout the VM lifetime.
> > > > > >
> > > > > > The notion of using UUID came up in the thread
> > > > > >
> > > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > > >
> > > > > That's probably because it was expected one of standard serial number capabilities
> > > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > > >
> > > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > > does not have to be unique.
> > > > >
> > > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > > to be implied in the thread you refer to.
> > > > > >
> > > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > > we are using 128 bits.
> > > > >
> > > > > That's OK. The name is confusing though. It's a failover group id,
> > > > > not a UUID.
> > > >
> > > > Sure, we can name it whatever we want. I can change it to
> > > > "failover-group-id", if that is what we want to call it.
> > > >
> > > > But what is more important is, what is represented by that name? I thought
> > > > we were going to use UUID. The QEMU command line changes in this patch
> > > > set expect the user to specify an UUID as the value for this option
> > > > (whatever we name it). Are we still in agreement about that, or do you
> > > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > > 64-bit number, or an arbitrary string?
> > > >
> > > > Regards,
> > > >
> > > > Venu
> > >
> > > If we don't really need a UUID, I'd avoid that requirement.
> >
> > I don't see the need for a 128-bit UUID. I just took that approach because
> > UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> > Since it is unlikely to have more than 4 billion devices in the system,
> > a 32-bit value would be more than enough to uniquely identify devices!
> >
> > I am looking for direction from you :-). Roman already opined that UUID
> > may be an overkill. It appears that you too are leaning that way. Would
> > it be acceptable if I change the group identifier ("failover-group-id")
> > to a 32-bit value? If you concur, I will start reworking my patch. Could
> > you please confirm?
> >
> > Thanks,
> >
> > Venu
>
> I would do a 64 bit one, just in case we want to use PCI Express Device
> Serial Number down the road.
Will do.
Venu
> > >
> > >
> > > > >
> > > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > > is also included here. Following is the updated proposal.
> > > > > > > >
> > > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > >
> > > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > > The "uuid" is a string in UUID format.
> > > > > > > >
> > > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > > the Q35 model is supported.
> > > > > > > >
> > > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > > >
> > > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > > the UUID created in step 4.
> > > > > > > >
> > > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > >
> > > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > > >
> > > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > > >
> > > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > > and just refer to the standby device by device-id, like
> > > > > > >
> > > > > > > -device virtio-net-pci,id=foo \
> > > > > > > -device pcie-downstream,failover=foo
> > > > > >
> > > > > > Isn't this the same as what this patch series proposes? In your
> > > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Venu
> > > > > >
> > > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > > for failover on the PV device.
> > > > > > >
> > > > > > > Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-28 3:27 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-28 3:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-28 04:54:16 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> > On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > > store pairing information..." [4] were made.
> > > > > > >
> > > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > > the VM and stable throughout the VM lifetime.
> > > > > >
> > > > > > The notion of using UUID came up in the thread
> > > > > >
> > > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > > >
> > > > > That's probably because it was expected one of standard serial number capabilities
> > > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > > >
> > > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > > does not have to be unique.
> > > > >
> > > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > > to be implied in the thread you refer to.
> > > > > >
> > > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > > we are using 128 bits.
> > > > >
> > > > > That's OK. The name is confusing though. It's a failover group id,
> > > > > not a UUID.
> > > >
> > > > Sure, we can name it whatever we want. I can change it to
> > > > "failover-group-id", if that is what we want to call it.
> > > >
> > > > But what is more important is, what is represented by that name? I thought
> > > > we were going to use UUID. The QEMU command line changes in this patch
> > > > set expect the user to specify an UUID as the value for this option
> > > > (whatever we name it). Are we still in agreement about that, or do you
> > > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > > 64-bit number, or an arbitrary string?
> > > >
> > > > Regards,
> > > >
> > > > Venu
> > >
> > > If we don't really need a UUID, I'd avoid that requirement.
> >
> > I don't see the need for a 128-bit UUID. I just took that approach because
> > UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> > Since it is unlikely to have more than 4 billion devices in the system,
> > a 32-bit value would be more than enough to uniquely identify devices!
> >
> > I am looking for direction from you :-). Roman already opined that UUID
> > may be an overkill. It appears that you too are leaning that way. Would
> > it be acceptable if I change the group identifier ("failover-group-id")
> > to a 32-bit value? If you concur, I will start reworking my patch. Could
> > you please confirm?
> >
> > Thanks,
> >
> > Venu
>
> I would do a 64 bit one, just in case we want to use PCI Express Device
> Serial Number down the road.
Will do.
Venu
> > >
> > >
> > > > >
> > > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > > is also included here. Following is the updated proposal.
> > > > > > > >
> > > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > >
> > > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > > The "uuid" is a string in UUID format.
> > > > > > > >
> > > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > > the Q35 model is supported.
> > > > > > > >
> > > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > > >
> > > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > > the UUID created in step 4.
> > > > > > > >
> > > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > >
> > > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > > >
> > > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > > >
> > > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > > and just refer to the standby device by device-id, like
> > > > > > >
> > > > > > > -device virtio-net-pci,id=foo \
> > > > > > > -device pcie-downstream,failover=foo
> > > > > >
> > > > > > Isn't this the same as what this patch series proposes? In your
> > > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Venu
> > > > > >
> > > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > > for failover on the PV device.
> > > > > > >
> > > > > > > Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-28 2:14 ` Michael S. Tsirkin
@ 2018-06-28 3:46 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-28 3:46 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-28 05:14:50 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 06:07:59PM -0500, Venu Busireddy wrote:
> > On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
> > > On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > > > used to pair a virtio device with the passthrough device attached to
> > > > > that bridge.
> > > > >
> > > > > This capability is added to the bridge iff the "uuid" option is specified
> > > > > for the bridge.
> > > >
> > > > I think the name should be more explicit. How about "failover-group-id"?
> > >
> > > I can change it. But don't you think it is bit long?
> > >
> > > > >
> > > > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> > > >
> > > > I'd like to also tweak the device id in this case,
> > > > to make it easier for guests to know it's a grouping bridge.
> > >
> > > Could you please recommend a name for the new ID'd definition? Something
> > > in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
> >
> > How about these names and values for the device IDs?
> >
> > PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
>
> You do not need the second PCI, and group is one of the
> functions of bridge anyway.
>
> PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER?
Sounds good.
> > PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
> >
> > Thanks,
> >
> > Venu
>
> PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER?
Sounds good.
> It's becoming annoying though - we'll need one for each type :(
>
> Ideas/options:
> - use revision ID to distinguish from regular bridge
What would we use for the revision? For example, "pci-bridge" (default
one) currently uses revision 0. Should we use revision 1 for the group
bridge? If we do that, what if in the future we need to up the revision
for the default bridge?
> - use device serial # cap for the bridge when it's an express device
We could do that. But if we are defining a new Device ID for the PCI
case, we might as well do so for the PCIe case too, and be consistent?
The other advantage in defining a new ID is, 'lspci' could right away
tell what type of bridge it is (if we update PCI IDs). No need to map
the revision to a bridge type!
Unless you have strong reservations against, I think the notion of
different Device ID for the grouping bridge sounds cleaner. Do you agree?
Venu
>
> > > > > ---
> > > > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > > > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > > > > include/hw/pci/pcie.h | 1 +
> > > > > 3 files changed, 35 insertions(+)
> > > > >
> > > > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > > > > index b2d861d216..bbbc6fa1c6 100644
> > > > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > > > > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > > > > }
> > > > >
> > > > > + err = pci_bridge_vendor_init(dev, 0, errp);
> > > > > + if (err < 0) {
> > > > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > > > > + goto vendor_cap_err;
> > > > > + }
> > > > > +
> > > > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > > > > if (err) {
> > > > > goto slotid_error;
> > > > > @@ -109,6 +115,7 @@ slotid_error:
> > > > > if (shpc_present(dev)) {
> > > > > shpc_cleanup(dev, &bridge_dev->bar);
> > > > > }
> > > > > +vendor_cap_err:
> > > > > shpc_error:
> > > > > pci_bridge_exitfn(dev);
> > > > > }
> > > > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > > > > ON_OFF_AUTO_AUTO),
> > > > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > > > > DEFINE_PROP_END_OF_LIST(),
> > > > > };
> > > > >
> > > > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > > > > index 40a39f57cb..cb8b3dad2a 100644
> > > > > --- a/hw/pci/pci_bridge.c
> > > > > +++ b/hw/pci/pci_bridge.c
> > > > > @@ -34,12 +34,17 @@
> > > > > #include "hw/pci/pci_bus.h"
> > > > > #include "qemu/range.h"
> > > > > #include "qapi/error.h"
> > > > > +#include "qemu/uuid.h"
> > > > >
> > > > > /* PCI bridge subsystem vendor ID helper functions */
> > > > > #define PCI_SSVID_SIZEOF 8
> > > > > #define PCI_SSVID_SVID 4
> > > > > #define PCI_SSVID_SSID 6
> > > > >
> > > > > +#define PCI_VENDOR_SIZEOF 20
> > > > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > > > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > > > > +
> > > > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > > uint16_t svid, uint16_t ssid,
> > > > > Error **errp)
> > > > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > > return pos;
> > > > > }
> > > > >
> > > > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > > > > +{
> > > > > + int pos;
> > > > > +
> > > > > + if (qemu_uuid_is_null(&d->uuid)) {
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > > > > + errp);
> > > > > + if (pos < 0) {
> > > > > + return pos;
> > > > > + }
> > > > > +
> > > > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > > > > + PCI_VENDOR_SIZEOF);
> > > > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > > > > + sizeof(QemuUUID));
> > > > > + return pos;
> > > > > +}
> > > > > +
> > > > > /* Accessor function to get parent bridge device from pci bus. */
> > > > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > > > > {
> > > > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > > > > index b71e369703..b4189d0ce3 100644
> > > > > --- a/include/hw/pci/pcie.h
> > > > > +++ b/include/hw/pci/pcie.h
> > > > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > > > > };
> > > > >
> > > > > #define COMPAT_PROP_PCP "power_controller_present"
> > > > > +#define COMPAT_PROP_UUID "uuid"
> > > > >
> > > > > /* PCI express capability helper functions */
> > > > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-28 3:46 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-28 3:46 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-28 05:14:50 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 27, 2018 at 06:07:59PM -0500, Venu Busireddy wrote:
> > On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
> > > On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > > > used to pair a virtio device with the passthrough device attached to
> > > > > that bridge.
> > > > >
> > > > > This capability is added to the bridge iff the "uuid" option is specified
> > > > > for the bridge.
> > > >
> > > > I think the name should be more explicit. How about "failover-group-id"?
> > >
> > > I can change it. But don't you think it is bit long?
> > >
> > > > >
> > > > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> > > >
> > > > I'd like to also tweak the device id in this case,
> > > > to make it easier for guests to know it's a grouping bridge.
> > >
> > > Could you please recommend a name for the new ID'd definition? Something
> > > in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
> >
> > How about these names and values for the device IDs?
> >
> > PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
>
> You do not need the second PCI, and group is one of the
> functions of bridge anyway.
>
> PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER?
Sounds good.
> > PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
> >
> > Thanks,
> >
> > Venu
>
> PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER?
Sounds good.
> It's becoming annoying though - we'll need one for each type :(
>
> Ideas/options:
> - use revision ID to distinguish from regular bridge
What would we use for the revision? For example, "pci-bridge" (default
one) currently uses revision 0. Should we use revision 1 for the group
bridge? If we do that, what if in the future we need to up the revision
for the default bridge?
> - use device serial # cap for the bridge when it's an express device
We could do that. But if we are defining a new Device ID for the PCI
case, we might as well do so for the PCIe case too, and be consistent?
The other advantage in defining a new ID is, 'lspci' could right away
tell what type of bridge it is (if we update PCI IDs). No need to map
the revision to a bridge type!
Unless you have strong reservations against, I think the notion of
different Device ID for the grouping bridge sounds cleaner. Do you agree?
Venu
>
> > > > > ---
> > > > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
> > > > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
> > > > > include/hw/pci/pcie.h | 1 +
> > > > > 3 files changed, 35 insertions(+)
> > > > >
> > > > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> > > > > index b2d861d216..bbbc6fa1c6 100644
> > > > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
> > > > > bridge_dev->msi = ON_OFF_AUTO_OFF;
> > > > > }
> > > > >
> > > > > + err = pci_bridge_vendor_init(dev, 0, errp);
> > > > > + if (err < 0) {
> > > > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
> > > > > + goto vendor_cap_err;
> > > > > + }
> > > > > +
> > > > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
> > > > > if (err) {
> > > > > goto slotid_error;
> > > > > @@ -109,6 +115,7 @@ slotid_error:
> > > > > if (shpc_present(dev)) {
> > > > > shpc_cleanup(dev, &bridge_dev->bar);
> > > > > }
> > > > > +vendor_cap_err:
> > > > > shpc_error:
> > > > > pci_bridge_exitfn(dev);
> > > > > }
> > > > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
> > > > > ON_OFF_AUTO_AUTO),
> > > > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
> > > > > DEFINE_PROP_END_OF_LIST(),
> > > > > };
> > > > >
> > > > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> > > > > index 40a39f57cb..cb8b3dad2a 100644
> > > > > --- a/hw/pci/pci_bridge.c
> > > > > +++ b/hw/pci/pci_bridge.c
> > > > > @@ -34,12 +34,17 @@
> > > > > #include "hw/pci/pci_bus.h"
> > > > > #include "qemu/range.h"
> > > > > #include "qapi/error.h"
> > > > > +#include "qemu/uuid.h"
> > > > >
> > > > > /* PCI bridge subsystem vendor ID helper functions */
> > > > > #define PCI_SSVID_SIZEOF 8
> > > > > #define PCI_SSVID_SVID 4
> > > > > #define PCI_SSVID_SSID 6
> > > > >
> > > > > +#define PCI_VENDOR_SIZEOF 20
> > > > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
> > > > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
> > > > > +
> > > > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > > uint16_t svid, uint16_t ssid,
> > > > > Error **errp)
> > > > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
> > > > > return pos;
> > > > > }
> > > > >
> > > > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
> > > > > +{
> > > > > + int pos;
> > > > > +
> > > > > + if (qemu_uuid_is_null(&d->uuid)) {
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
> > > > > + errp);
> > > > > + if (pos < 0) {
> > > > > + return pos;
> > > > > + }
> > > > > +
> > > > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
> > > > > + PCI_VENDOR_SIZEOF);
> > > > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
> > > > > + sizeof(QemuUUID));
> > > > > + return pos;
> > > > > +}
> > > > > +
> > > > > /* Accessor function to get parent bridge device from pci bus. */
> > > > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
> > > > > {
> > > > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> > > > > index b71e369703..b4189d0ce3 100644
> > > > > --- a/include/hw/pci/pcie.h
> > > > > +++ b/include/hw/pci/pcie.h
> > > > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
> > > > > };
> > > > >
> > > > > #define COMPAT_PROP_PCP "power_controller_present"
> > > > > +#define COMPAT_PROP_UUID "uuid"
> > > > >
> > > > > /* PCI express capability helper functions */
> > > > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-28 2:14 ` Michael S. Tsirkin
@ 2018-06-28 8:10 ` Siwei Liu
-1 siblings, 0 replies; 55+ messages in thread
From: Siwei Liu @ 2018-06-28 8:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 7:14 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Jun 27, 2018 at 06:07:59PM -0500, Venu Busireddy wrote:
>> On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
>> > On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
>> > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
>> > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
>> > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
>> > > > used to pair a virtio device with the passthrough device attached to
>> > > > that bridge.
>> > > >
>> > > > This capability is added to the bridge iff the "uuid" option is specified
>> > > > for the bridge.
>> > >
>> > > I think the name should be more explicit. How about "failover-group-id"?
>> >
>> > I can change it. But don't you think it is bit long?
>> >
>> > > >
>> > > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
>> > >
>> > > I'd like to also tweak the device id in this case,
>> > > to make it easier for guests to know it's a grouping bridge.
>> >
>> > Could you please recommend a name for the new ID'd definition? Something
>> > in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
>>
>> How about these names and values for the device IDs?
>>
>> PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
>
> You do not need the second PCI, and group is one of the
> functions of bridge anyway.
>
> PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER?
>
>
>> PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
>>
>> Thanks,
>>
>> Venu
>
> PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER?
>
>
> It's becoming annoying though - we'll need one for each type :(
>
> Ideas/options:
> - use revision ID to distinguish from regular bridge
> - use device serial # cap for the bridge when it's an express device
>
IMO, from guest implementation point of view, it would be the best to
use a single consistent mechanism all across. The serial number cap is
too PCIE specific.
-Siwei
>
>> > > > ---
>> > > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
>> > > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
>> > > > include/hw/pci/pcie.h | 1 +
>> > > > 3 files changed, 35 insertions(+)
>> > > >
>> > > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
>> > > > index b2d861d216..bbbc6fa1c6 100644
>> > > > --- a/hw/pci-bridge/pci_bridge_dev.c
>> > > > +++ b/hw/pci-bridge/pci_bridge_dev.c
>> > > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
>> > > > bridge_dev->msi = ON_OFF_AUTO_OFF;
>> > > > }
>> > > >
>> > > > + err = pci_bridge_vendor_init(dev, 0, errp);
>> > > > + if (err < 0) {
>> > > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
>> > > > + goto vendor_cap_err;
>> > > > + }
>> > > > +
>> > > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
>> > > > if (err) {
>> > > > goto slotid_error;
>> > > > @@ -109,6 +115,7 @@ slotid_error:
>> > > > if (shpc_present(dev)) {
>> > > > shpc_cleanup(dev, &bridge_dev->bar);
>> > > > }
>> > > > +vendor_cap_err:
>> > > > shpc_error:
>> > > > pci_bridge_exitfn(dev);
>> > > > }
>> > > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
>> > > > ON_OFF_AUTO_AUTO),
>> > > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
>> > > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
>> > > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
>> > > > DEFINE_PROP_END_OF_LIST(),
>> > > > };
>> > > >
>> > > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
>> > > > index 40a39f57cb..cb8b3dad2a 100644
>> > > > --- a/hw/pci/pci_bridge.c
>> > > > +++ b/hw/pci/pci_bridge.c
>> > > > @@ -34,12 +34,17 @@
>> > > > #include "hw/pci/pci_bus.h"
>> > > > #include "qemu/range.h"
>> > > > #include "qapi/error.h"
>> > > > +#include "qemu/uuid.h"
>> > > >
>> > > > /* PCI bridge subsystem vendor ID helper functions */
>> > > > #define PCI_SSVID_SIZEOF 8
>> > > > #define PCI_SSVID_SVID 4
>> > > > #define PCI_SSVID_SSID 6
>> > > >
>> > > > +#define PCI_VENDOR_SIZEOF 20
>> > > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
>> > > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
>> > > > +
>> > > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
>> > > > uint16_t svid, uint16_t ssid,
>> > > > Error **errp)
>> > > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
>> > > > return pos;
>> > > > }
>> > > >
>> > > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
>> > > > +{
>> > > > + int pos;
>> > > > +
>> > > > + if (qemu_uuid_is_null(&d->uuid)) {
>> > > > + return 0;
>> > > > + }
>> > > > +
>> > > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
>> > > > + errp);
>> > > > + if (pos < 0) {
>> > > > + return pos;
>> > > > + }
>> > > > +
>> > > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
>> > > > + PCI_VENDOR_SIZEOF);
>> > > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
>> > > > + sizeof(QemuUUID));
>> > > > + return pos;
>> > > > +}
>> > > > +
>> > > > /* Accessor function to get parent bridge device from pci bus. */
>> > > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
>> > > > {
>> > > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
>> > > > index b71e369703..b4189d0ce3 100644
>> > > > --- a/include/hw/pci/pcie.h
>> > > > +++ b/include/hw/pci/pcie.h
>> > > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
>> > > > };
>> > > >
>> > > > #define COMPAT_PROP_PCP "power_controller_present"
>> > > > +#define COMPAT_PROP_UUID "uuid"
>> > > >
>> > > > /* PCI express capability helper functions */
>> > > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
@ 2018-06-28 8:10 ` Siwei Liu
0 siblings, 0 replies; 55+ messages in thread
From: Siwei Liu @ 2018-06-28 8:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 7:14 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Jun 27, 2018 at 06:07:59PM -0500, Venu Busireddy wrote:
>> On 2018-06-26 23:08:12 -0500, Venu Busireddy wrote:
>> > On 2018-06-27 07:02:36 +0300, Michael S. Tsirkin wrote:
>> > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
>> > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
>> > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
>> > > > used to pair a virtio device with the passthrough device attached to
>> > > > that bridge.
>> > > >
>> > > > This capability is added to the bridge iff the "uuid" option is specified
>> > > > for the bridge.
>> > >
>> > > I think the name should be more explicit. How about "failover-group-id"?
>> >
>> > I can change it. But don't you think it is bit long?
>> >
>> > > >
>> > > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
>> > >
>> > > I'd like to also tweak the device id in this case,
>> > > to make it easier for guests to know it's a grouping bridge.
>> >
>> > Could you please recommend a name for the new ID'd definition? Something
>> > in lines of PCI_DEVICE_ID_REDHAT_<blah blah>.
>>
>> How about these names and values for the device IDs?
>>
>> PCI_DEVICE_ID_REDHAT_PCI_BRIDGE_GRP (0x0010) for pci-bridge, and
>
> You do not need the second PCI, and group is one of the
> functions of bridge anyway.
>
> PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER?
>
>
>> PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE_GRP (0x0011) for pcie-downstream
>>
>> Thanks,
>>
>> Venu
>
> PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER?
>
>
> It's becoming annoying though - we'll need one for each type :(
>
> Ideas/options:
> - use revision ID to distinguish from regular bridge
> - use device serial # cap for the bridge when it's an express device
>
IMO, from guest implementation point of view, it would be the best to
use a single consistent mechanism all across. The serial number cap is
too PCIE specific.
-Siwei
>
>> > > > ---
>> > > > hw/pci-bridge/pci_bridge_dev.c | 8 ++++++++
>> > > > hw/pci/pci_bridge.c | 26 ++++++++++++++++++++++++++
>> > > > include/hw/pci/pcie.h | 1 +
>> > > > 3 files changed, 35 insertions(+)
>> > > >
>> > > > diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
>> > > > index b2d861d216..bbbc6fa1c6 100644
>> > > > --- a/hw/pci-bridge/pci_bridge_dev.c
>> > > > +++ b/hw/pci-bridge/pci_bridge_dev.c
>> > > > @@ -71,6 +71,12 @@ static void pci_bridge_dev_realize(PCIDevice *dev, Error **errp)
>> > > > bridge_dev->msi = ON_OFF_AUTO_OFF;
>> > > > }
>> > > >
>> > > > + err = pci_bridge_vendor_init(dev, 0, errp);
>> > > > + if (err < 0) {
>> > > > + error_append_hint(errp, "Can't init group ID, error %d\n", err);
>> > > > + goto vendor_cap_err;
>> > > > + }
>> > > > +
>> > > > err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0, errp);
>> > > > if (err) {
>> > > > goto slotid_error;
>> > > > @@ -109,6 +115,7 @@ slotid_error:
>> > > > if (shpc_present(dev)) {
>> > > > shpc_cleanup(dev, &bridge_dev->bar);
>> > > > }
>> > > > +vendor_cap_err:
>> > > > shpc_error:
>> > > > pci_bridge_exitfn(dev);
>> > > > }
>> > > > @@ -162,6 +169,7 @@ static Property pci_bridge_dev_properties[] = {
>> > > > ON_OFF_AUTO_AUTO),
>> > > > DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
>> > > > PCI_BRIDGE_DEV_F_SHPC_REQ, true),
>> > > > + DEFINE_PROP_UUID(COMPAT_PROP_UUID, PCIDevice, uuid, false),
>> > > > DEFINE_PROP_END_OF_LIST(),
>> > > > };
>> > > >
>> > > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
>> > > > index 40a39f57cb..cb8b3dad2a 100644
>> > > > --- a/hw/pci/pci_bridge.c
>> > > > +++ b/hw/pci/pci_bridge.c
>> > > > @@ -34,12 +34,17 @@
>> > > > #include "hw/pci/pci_bus.h"
>> > > > #include "qemu/range.h"
>> > > > #include "qapi/error.h"
>> > > > +#include "qemu/uuid.h"
>> > > >
>> > > > /* PCI bridge subsystem vendor ID helper functions */
>> > > > #define PCI_SSVID_SIZEOF 8
>> > > > #define PCI_SSVID_SVID 4
>> > > > #define PCI_SSVID_SSID 6
>> > > >
>> > > > +#define PCI_VENDOR_SIZEOF 20
>> > > > +#define PCI_VENDOR_CAP_LEN_OFFSET 2
>> > > > +#define PCI_VENDOR_GROUP_ID_OFFSET 4
>> > > > +
>> > > > int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
>> > > > uint16_t svid, uint16_t ssid,
>> > > > Error **errp)
>> > > > @@ -57,6 +62,27 @@ int pci_bridge_ssvid_init(PCIDevice *dev, uint8_t offset,
>> > > > return pos;
>> > > > }
>> > > >
>> > > > +int pci_bridge_vendor_init(PCIDevice *d, uint8_t offset, Error **errp)
>> > > > +{
>> > > > + int pos;
>> > > > +
>> > > > + if (qemu_uuid_is_null(&d->uuid)) {
>> > > > + return 0;
>> > > > + }
>> > > > +
>> > > > + pos = pci_add_capability(d, PCI_CAP_ID_VNDR, offset, PCI_VENDOR_SIZEOF,
>> > > > + errp);
>> > > > + if (pos < 0) {
>> > > > + return pos;
>> > > > + }
>> > > > +
>> > > > + pci_set_word(d->config + pos + PCI_VENDOR_CAP_LEN_OFFSET,
>> > > > + PCI_VENDOR_SIZEOF);
>> > > > + memcpy(d->config + pos + PCI_VENDOR_GROUP_ID_OFFSET, &d->uuid,
>> > > > + sizeof(QemuUUID));
>> > > > + return pos;
>> > > > +}
>> > > > +
>> > > > /* Accessor function to get parent bridge device from pci bus. */
>> > > > PCIDevice *pci_bridge_get_device(PCIBus *bus)
>> > > > {
>> > > > diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
>> > > > index b71e369703..b4189d0ce3 100644
>> > > > --- a/include/hw/pci/pcie.h
>> > > > +++ b/include/hw/pci/pcie.h
>> > > > @@ -82,6 +82,7 @@ struct PCIExpressDevice {
>> > > > };
>> > > >
>> > > > #define COMPAT_PROP_PCP "power_controller_present"
>> > > > +#define COMPAT_PROP_UUID "uuid"
>> > > >
>> > > > /* PCI express capability helper functions */
>> > > > int pcie_cap_init(PCIDevice *dev, uint8_t offset, uint8_t type,
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.
2018-06-27 4:02 ` [virtio-dev] " Michael S. Tsirkin
(?)
(?)
@ 2018-06-28 8:25 ` Daniel P. Berrangé
2018-06-28 10:07 ` [virtio-dev] Retrieving configuration metadata from hypervisor (was: Re: [Qemu-devel] " Cornelia Huck
-1 siblings, 1 reply; 55+ messages in thread
From: Daniel P. Berrangé @ 2018-06-28 8:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Venu Busireddy, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 07:02:36AM +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > used to pair a virtio device with the passthrough device attached to
> > that bridge.
> >
> > This capability is added to the bridge iff the "uuid" option is specified
> > for the bridge.
>
> I think the name should be more explicit. How about "failover-group-id"?
>
> >
> > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
>
> I'd like to also tweak the device id in this case,
> to make it easier for guests to know it's a grouping bridge.
I tend to think this proposal is rather too narrow. The need to tell
the guest OS about the intended usage of devices is a pretty common use
case, of which setting up bonding NIC pair is just one example.
OpenStack already has this problem & took the approach of providing some
structured JSON metadata to the guest that lists all devices (well NICs
and disks at least) with identifying metadata (eg PCI address, MAC addr,
disk serial and anything else relevant), and also assigns freeform string
"tags" against each. eg the host admin could specify tags "lanA" and "lanB"
for two NICs, so the guest knows which NIC to use for which purpose. This
kind of tagging could easily cover setting up bonded pairs. Or for a disk
they could tag it "oracledata" or "apachecache" to indicate what kind of
data to use on the disk, etc
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html
I'm not suggesting the impl used in OpenStack is perfect - there's a number
of pain points in it, but I think it shows the need for a general solution
to the problem of the host admin informing the guest OS about the intended
usage of devices being provided. I think freeform string tags do this
pretty well. The key problem is how to expose such tags - openstack took
approach of an out of band JSON doc exposed from its metadata service and
or cloud init config drive, because that was its only viable option.
Perhaps there is a way to expose tags at a low level though if we can
integrate with QEMU somehow ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 55+ messages in thread
* [Qemu-devel] Retrieving configuration metadata from hypervisor (was: Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.)
2018-06-28 8:25 ` [Qemu-devel] " Daniel P. Berrangé
@ 2018-06-28 10:07 ` Cornelia Huck
0 siblings, 0 replies; 55+ messages in thread
From: Cornelia Huck @ 2018-06-28 10:07 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Michael S. Tsirkin, Marcel Apfelbaum, virtio-dev, Venu Busireddy,
qemu-devel, qemu-s390x
On Thu, 28 Jun 2018 09:25:32 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Wed, Jun 27, 2018 at 07:02:36AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > used to pair a virtio device with the passthrough device attached to
> > > that bridge.
> > >
> > > This capability is added to the bridge iff the "uuid" option is specified
> > > for the bridge.
As an aside, I don't think that will work for s390, see
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg07785.html.
> >
> > I think the name should be more explicit. How about "failover-group-id"?
> >
> > >
> > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> >
> > I'd like to also tweak the device id in this case,
> > to make it easier for guests to know it's a grouping bridge.
>
> I tend to think this proposal is rather too narrow. The need to tell
> the guest OS about the intended usage of devices is a pretty common use
> case, of which setting up bonding NIC pair is just one example.
FWIW, there was also discussion of making "pair those devices" a more
general virtio mechanism (see
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg06339.html
and around).
>
> OpenStack already has this problem & took the approach of providing some
> structured JSON metadata to the guest that lists all devices (well NICs
> and disks at least) with identifying metadata (eg PCI address, MAC addr,
> disk serial and anything else relevant), and also assigns freeform string
> "tags" against each. eg the host admin could specify tags "lanA" and "lanB"
> for two NICs, so the guest knows which NIC to use for which purpose. This
> kind of tagging could easily cover setting up bonded pairs. Or for a disk
> they could tag it "oracledata" or "apachecache" to indicate what kind of
> data to use on the disk, etc
>
> https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html
>
> I'm not suggesting the impl used in OpenStack is perfect - there's a number
> of pain points in it, but I think it shows the need for a general solution
> to the problem of the host admin informing the guest OS about the intended
> usage of devices being provided. I think freeform string tags do this
> pretty well. The key problem is how to expose such tags - openstack took
> approach of an out of band JSON doc exposed from its metadata service and
> or cloud init config drive, because that was its only viable option.
As another example, s390 has a mechanism for providing configuration
information to a guest as well (see drivers/s390/char/sclp_sd.c in
Linux; for a guest user space exploiter, see
https://github.com/ibm-s390-tools/s390-tools/commit/7d355b0fec964ad84ecaf88eb946121d39486070
and follow-ons; the hypervisor implementation is proprietary AFAIK).
>
> Perhaps there is a way to expose tags at a low level though if we can
> integrate with QEMU somehow ?
I'd really like to see a data format that is flexible enough to cover
existing needs (which can be used with different hypervisor<->guest
interfaces.) We'd probably need to standardize it somehow if we want to
tie in with the virtio OASIS spec.
That said, for the net device standby functionality, it might be easier
to just go with the VIRTIO_NET_F_STANDBY_UUID proposal while we discuss
a more generic mechanism.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [virtio-dev] Retrieving configuration metadata from hypervisor (was: Re: [Qemu-devel] [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.)
@ 2018-06-28 10:07 ` Cornelia Huck
0 siblings, 0 replies; 55+ messages in thread
From: Cornelia Huck @ 2018-06-28 10:07 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Michael S. Tsirkin, Marcel Apfelbaum, virtio-dev, Venu Busireddy,
qemu-devel, qemu-s390x
On Thu, 28 Jun 2018 09:25:32 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Wed, Jun 27, 2018 at 07:02:36AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote:
> > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device
> > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be
> > > used to pair a virtio device with the passthrough device attached to
> > > that bridge.
> > >
> > > This capability is added to the bridge iff the "uuid" option is specified
> > > for the bridge.
As an aside, I don't think that will work for s390, see
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg07785.html.
> >
> > I think the name should be more explicit. How about "failover-group-id"?
> >
> > >
> > > Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
> >
> > I'd like to also tweak the device id in this case,
> > to make it easier for guests to know it's a grouping bridge.
>
> I tend to think this proposal is rather too narrow. The need to tell
> the guest OS about the intended usage of devices is a pretty common use
> case, of which setting up bonding NIC pair is just one example.
FWIW, there was also discussion of making "pair those devices" a more
general virtio mechanism (see
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg06339.html
and around).
>
> OpenStack already has this problem & took the approach of providing some
> structured JSON metadata to the guest that lists all devices (well NICs
> and disks at least) with identifying metadata (eg PCI address, MAC addr,
> disk serial and anything else relevant), and also assigns freeform string
> "tags" against each. eg the host admin could specify tags "lanA" and "lanB"
> for two NICs, so the guest knows which NIC to use for which purpose. This
> kind of tagging could easily cover setting up bonded pairs. Or for a disk
> they could tag it "oracledata" or "apachecache" to indicate what kind of
> data to use on the disk, etc
>
> https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html
>
> I'm not suggesting the impl used in OpenStack is perfect - there's a number
> of pain points in it, but I think it shows the need for a general solution
> to the problem of the host admin informing the guest OS about the intended
> usage of devices being provided. I think freeform string tags do this
> pretty well. The key problem is how to expose such tags - openstack took
> approach of an out of band JSON doc exposed from its metadata service and
> or cloud init config drive, because that was its only viable option.
As another example, s390 has a mechanism for providing configuration
information to a guest as well (see drivers/s390/char/sclp_sd.c in
Linux; for a guest user space exploiter, see
https://github.com/ibm-s390-tools/s390-tools/commit/7d355b0fec964ad84ecaf88eb946121d39486070
and follow-ons; the hypervisor implementation is proprietary AFAIK).
>
> Perhaps there is a way to expose tags at a low level though if we can
> integrate with QEMU somehow ?
I'd really like to see a data format that is flexible enough to cover
existing needs (which can be used with different hypervisor<->guest
interfaces.) We'd probably need to standardize it somehow if we want to
tie in with the virtio OASIS spec.
That said, for the net device standby functionality, it might be easier
to just go with the VIRTIO_NET_F_STANDBY_UUID proposal while we discuss
a more generic mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-27 19:29 ` [virtio-dev] " Venu Busireddy
(?)
(?)
@ 2018-06-28 10:17 ` Roman Kagan
-1 siblings, 0 replies; 55+ messages in thread
From: Roman Kagan @ 2018-06-28 10:17 UTC (permalink / raw)
To: Venu Busireddy
Cc: Michael S . Tsirkin, Marcel Apfelbaum, virtio-dev, qemu-devel
On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > I must have missed something in those threads, but where does this UUID
> > thing come about? AFAICS this identifier doesn't need to be
> > "universally" unique, nor persistent; it only has to be unique across
> > the VM and stable throughout the VM lifetime.
>
> The notion of using UUID came up in the thread
>
> https://www.spinics.net/lists/netdev/msg499011.html
Yes I saw it and it looks like UUID came out of miscommunication:
>> >> As Stephen said, Hyper-V supports the serial UUID thing from
>> >> day-one.
but I don't see Stephen's message where he claims that. In reality
> > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > to be implied in the thread you refer to.
>
> Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
It's u32, see
drivers/pci/controller/pci-hyperv.c:struct pci_function_description::ser
and
drivers/net/hyperv/hyperv_net.h:struct nvsp_4_send_vf_association::serial
> However, what we are doing is similar to that. Instead of 32 bits,
> we are using 128 bits.
UUID is far less convenient to handle than an integer. But anyway I
think this should rather be transport-specific, see below.
> > I wonder if it makes more sense to drop the concept of failover groups,
> > and just refer to the standby device by device-id, like
> >
> > -device virtio-net-pci,id=foo \
> > -device pcie-downstream,failover=foo
>
> Isn't this the same as what this patch series proposes? In your
> suggestion, "foo" is the entity that connects the passthrough device
> and the failover device. In this patch set, that "foo" is the UUID,
> and the options "id" and "failover" are replaced by "uuid". Do you agree?
No it's not the same.
I think this whole "failover group" concept is a misnomer: there can
only be two participating devices, they need a tighter coupling to each
other than just sharing a common identifier exposed to the guest, and
their relationship is strongly asymmetric.
Rather, the two devices
- need to be of matching types to be able to do failover (like
a virtio-net-pci and a pcie-downstream, or a hv-net and a
hv-pci-bridge, etc.)
- need to communicate status information, adressing Michael's concern
re. PT visibility: as I wrote
> > The bridge device will [...] defer the visibility of the PT device
> > behind the bridge until the guest acknowledged the support for
> > failover on the PV device.
- need to communicate a common identifier and have a
transport-specific scheme to present it to the guest, but this
common identifier *doesn't* generally have to be
* of the same type for all transports[*]
* globally unique
* persistent
* provided by / visible to the management layer
Now linking two devices in QEMU by making one of them know the device-id
of the other seems to be the most natural thing.
[*] e.g. for Hyper-V it's u32 (set by the third party); virtio may
define different schemes depending on the kind of PT device, e.g. u64 if
using a PCIe device (and put it in its device serial number cap),
something else otherwise.
Roman.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-28 3:27 ` [virtio-dev] " Venu Busireddy
@ 2018-06-29 18:55 ` Venu Busireddy
-1 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-29 18:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 22:27:33 -0500, Venu Busireddy wrote:
> On 2018-06-28 04:54:16 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> > > On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > > > store pairing information..." [4] were made.
> > > > > > > >
> > > > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > > > the VM and stable throughout the VM lifetime.
> > > > > > >
> > > > > > > The notion of using UUID came up in the thread
> > > > > > >
> > > > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > > > >
> > > > > > That's probably because it was expected one of standard serial number capabilities
> > > > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > > > >
> > > > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > > > does not have to be unique.
> > > > > >
> > > > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > > > to be implied in the thread you refer to.
> > > > > > >
> > > > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > > > we are using 128 bits.
> > > > > >
> > > > > > That's OK. The name is confusing though. It's a failover group id,
> > > > > > not a UUID.
> > > > >
> > > > > Sure, we can name it whatever we want. I can change it to
> > > > > "failover-group-id", if that is what we want to call it.
> > > > >
> > > > > But what is more important is, what is represented by that name? I thought
> > > > > we were going to use UUID. The QEMU command line changes in this patch
> > > > > set expect the user to specify an UUID as the value for this option
> > > > > (whatever we name it). Are we still in agreement about that, or do you
> > > > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > > > 64-bit number, or an arbitrary string?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Venu
> > > >
> > > > If we don't really need a UUID, I'd avoid that requirement.
> > >
> > > I don't see the need for a 128-bit UUID. I just took that approach because
> > > UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> > > Since it is unlikely to have more than 4 billion devices in the system,
> > > a 32-bit value would be more than enough to uniquely identify devices!
> > >
> > > I am looking for direction from you :-). Roman already opined that UUID
> > > may be an overkill. It appears that you too are leaning that way. Would
> > > it be acceptable if I change the group identifier ("failover-group-id")
> > > to a 32-bit value? If you concur, I will start reworking my patch. Could
> > > you please confirm?
> > >
> > > Thanks,
> > >
> > > Venu
> >
> > I would do a 64 bit one, just in case we want to use PCI Express Device
> > Serial Number down the road.
>
> Will do.
I have incorporated all the changes suggested by you. They are:
* Changed the failover group identifier from UUID to a 64-bit value.
* Changed the command line option from "uuid" to * "failover-group-id".
* Tweaked the "pci-bridge" device's Device ID to
* PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER.
* Added to new device "pcie-downstream" with Device ID
PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER (to support the PCIe case).
* Changed the patch for virtio specification to reflect the above
changes.
Shall I post v3 for review?
Thanks,
Venu
> > > >
> > > >
> > > > > >
> > > > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > > > is also included here. Following is the updated proposal.
> > > > > > > > >
> > > > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > >
> > > > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > > > The "uuid" is a string in UUID format.
> > > > > > > > >
> > > > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > > > the Q35 model is supported.
> > > > > > > > >
> > > > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > > > >
> > > > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > > > the UUID created in step 4.
> > > > > > > > >
> > > > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > >
> > > > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > > > >
> > > > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > > > >
> > > > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > > > and just refer to the standby device by device-id, like
> > > > > > > >
> > > > > > > > -device virtio-net-pci,id=foo \
> > > > > > > > -device pcie-downstream,failover=foo
> > > > > > >
> > > > > > > Isn't this the same as what this patch series proposes? In your
> > > > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Venu
> > > > > > >
> > > > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > > > for failover on the PV device.
> > > > > > > >
> > > > > > > > Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-29 18:55 ` Venu Busireddy
0 siblings, 0 replies; 55+ messages in thread
From: Venu Busireddy @ 2018-06-29 18:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On 2018-06-27 22:27:33 -0500, Venu Busireddy wrote:
> On 2018-06-28 04:54:16 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> > > On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > > > store pairing information..." [4] were made.
> > > > > > > >
> > > > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > > > the VM and stable throughout the VM lifetime.
> > > > > > >
> > > > > > > The notion of using UUID came up in the thread
> > > > > > >
> > > > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > > > >
> > > > > > That's probably because it was expected one of standard serial number capabilities
> > > > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > > > >
> > > > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > > > does not have to be unique.
> > > > > >
> > > > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > > > to be implied in the thread you refer to.
> > > > > > >
> > > > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > > > we are using 128 bits.
> > > > > >
> > > > > > That's OK. The name is confusing though. It's a failover group id,
> > > > > > not a UUID.
> > > > >
> > > > > Sure, we can name it whatever we want. I can change it to
> > > > > "failover-group-id", if that is what we want to call it.
> > > > >
> > > > > But what is more important is, what is represented by that name? I thought
> > > > > we were going to use UUID. The QEMU command line changes in this patch
> > > > > set expect the user to specify an UUID as the value for this option
> > > > > (whatever we name it). Are we still in agreement about that, or do you
> > > > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > > > 64-bit number, or an arbitrary string?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Venu
> > > >
> > > > If we don't really need a UUID, I'd avoid that requirement.
> > >
> > > I don't see the need for a 128-bit UUID. I just took that approach because
> > > UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> > > Since it is unlikely to have more than 4 billion devices in the system,
> > > a 32-bit value would be more than enough to uniquely identify devices!
> > >
> > > I am looking for direction from you :-). Roman already opined that UUID
> > > may be an overkill. It appears that you too are leaning that way. Would
> > > it be acceptable if I change the group identifier ("failover-group-id")
> > > to a 32-bit value? If you concur, I will start reworking my patch. Could
> > > you please confirm?
> > >
> > > Thanks,
> > >
> > > Venu
> >
> > I would do a 64 bit one, just in case we want to use PCI Express Device
> > Serial Number down the road.
>
> Will do.
I have incorporated all the changes suggested by you. They are:
* Changed the failover group identifier from UUID to a 64-bit value.
* Changed the command line option from "uuid" to * "failover-group-id".
* Tweaked the "pci-bridge" device's Device ID to
* PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER.
* Added to new device "pcie-downstream" with Device ID
PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER (to support the PCIe case).
* Changed the patch for virtio specification to reflect the above
changes.
Shall I post v3 for review?
Thanks,
Venu
> > > >
> > > >
> > > > > >
> > > > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > > > is also included here. Following is the updated proposal.
> > > > > > > > >
> > > > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > >
> > > > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > > > The "uuid" is a string in UUID format.
> > > > > > > > >
> > > > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > > > the Q35 model is supported.
> > > > > > > > >
> > > > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > > > >
> > > > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > > > the UUID created in step 4.
> > > > > > > > >
> > > > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > >
> > > > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > > > >
> > > > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > > > >
> > > > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > > > and just refer to the standby device by device-id, like
> > > > > > > >
> > > > > > > > -device virtio-net-pci,id=foo \
> > > > > > > > -device pcie-downstream,failover=foo
> > > > > > >
> > > > > > > Isn't this the same as what this patch series proposes? In your
> > > > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Venu
> > > > > > >
> > > > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > > > for failover on the PV device.
> > > > > > > >
> > > > > > > > Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
2018-06-29 18:55 ` [virtio-dev] Re: [Qemu-devel] " Venu Busireddy
@ 2018-06-29 21:59 ` Michael S. Tsirkin
-1 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-29 21:59 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Fri, Jun 29, 2018 at 01:55:07PM -0500, Venu Busireddy wrote:
> On 2018-06-27 22:27:33 -0500, Venu Busireddy wrote:
> > On 2018-06-28 04:54:16 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > > > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > > > > store pairing information..." [4] were made.
> > > > > > > > >
> > > > > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > > > > the VM and stable throughout the VM lifetime.
> > > > > > > >
> > > > > > > > The notion of using UUID came up in the thread
> > > > > > > >
> > > > > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > > > > >
> > > > > > > That's probably because it was expected one of standard serial number capabilities
> > > > > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > > > > >
> > > > > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > > > > does not have to be unique.
> > > > > > >
> > > > > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > > > > to be implied in the thread you refer to.
> > > > > > > >
> > > > > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > > > > we are using 128 bits.
> > > > > > >
> > > > > > > That's OK. The name is confusing though. It's a failover group id,
> > > > > > > not a UUID.
> > > > > >
> > > > > > Sure, we can name it whatever we want. I can change it to
> > > > > > "failover-group-id", if that is what we want to call it.
> > > > > >
> > > > > > But what is more important is, what is represented by that name? I thought
> > > > > > we were going to use UUID. The QEMU command line changes in this patch
> > > > > > set expect the user to specify an UUID as the value for this option
> > > > > > (whatever we name it). Are we still in agreement about that, or do you
> > > > > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > > > > 64-bit number, or an arbitrary string?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Venu
> > > > >
> > > > > If we don't really need a UUID, I'd avoid that requirement.
> > > >
> > > > I don't see the need for a 128-bit UUID. I just took that approach because
> > > > UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> > > > Since it is unlikely to have more than 4 billion devices in the system,
> > > > a 32-bit value would be more than enough to uniquely identify devices!
> > > >
> > > > I am looking for direction from you :-). Roman already opined that UUID
> > > > may be an overkill. It appears that you too are leaning that way. Would
> > > > it be acceptable if I change the group identifier ("failover-group-id")
> > > > to a 32-bit value? If you concur, I will start reworking my patch. Could
> > > > you please confirm?
> > > >
> > > > Thanks,
> > > >
> > > > Venu
> > >
> > > I would do a 64 bit one, just in case we want to use PCI Express Device
> > > Serial Number down the road.
> >
> > Will do.
>
> I have incorporated all the changes suggested by you. They are:
>
> * Changed the failover group identifier from UUID to a 64-bit value.
> * Changed the command line option from "uuid" to * "failover-group-id".
> * Tweaked the "pci-bridge" device's Device ID to
> * PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER.
> * Added to new device "pcie-downstream" with Device ID
> PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER (to support the PCIe case).
> * Changed the patch for virtio specification to reflect the above
> changes.
>
> Shall I post v3 for review?
>
> Thanks,
>
> Venu
Why not?
> > > > >
> > > > >
> > > > > > >
> > > > > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > > > > is also included here. Following is the updated proposal.
> > > > > > > > > >
> > > > > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > > >
> > > > > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > > > > The "uuid" is a string in UUID format.
> > > > > > > > > >
> > > > > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > > > > the Q35 model is supported.
> > > > > > > > > >
> > > > > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > > > > >
> > > > > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > > > > the UUID created in step 4.
> > > > > > > > > >
> > > > > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > > >
> > > > > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > > > > >
> > > > > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > > > > >
> > > > > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > > > > and just refer to the standby device by device-id, like
> > > > > > > > >
> > > > > > > > > -device virtio-net-pci,id=foo \
> > > > > > > > > -device pcie-downstream,failover=foo
> > > > > > > >
> > > > > > > > Isn't this the same as what this patch series proposes? In your
> > > > > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Venu
> > > > > > > >
> > > > > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > > > > for failover on the PV device.
> > > > > > > > >
> > > > > > > > > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices...
@ 2018-06-29 21:59 ` Michael S. Tsirkin
0 siblings, 0 replies; 55+ messages in thread
From: Michael S. Tsirkin @ 2018-06-29 21:59 UTC (permalink / raw)
To: Venu Busireddy; +Cc: Roman Kagan, Marcel Apfelbaum, virtio-dev, qemu-devel
On Fri, Jun 29, 2018 at 01:55:07PM -0500, Venu Busireddy wrote:
> On 2018-06-27 22:27:33 -0500, Venu Busireddy wrote:
> > On 2018-06-28 04:54:16 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jun 27, 2018 at 05:34:17PM -0500, Venu Busireddy wrote:
> > > > On 2018-06-27 23:12:12 +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 27, 2018 at 02:59:01PM -0500, Venu Busireddy wrote:
> > > > > > On 2018-06-27 22:47:05 +0300, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jun 27, 2018 at 02:29:58PM -0500, Venu Busireddy wrote:
> > > > > > > > On 2018-06-27 15:24:58 +0300, Roman Kagan wrote:
> > > > > > > > > On Tue, Jun 26, 2018 at 10:49:30PM -0500, Venu Busireddy wrote:
> > > > > > > > > > The patch set "Enable virtio_net to act as a standby for a passthru
> > > > > > > > > > device" [1] deals with live migration of guests that use passthrough
> > > > > > > > > > devices. However, that scheme uses the MAC address for pairing
> > > > > > > > > > the virtio device and the passthrough device. The thread "netvsc:
> > > > > > > > > > refactor notifier/event handling code to use the failover framework"
> > > > > > > > > > [2] discusses an alternate mechanism, such as using an UUID, for pairing
> > > > > > > > > > the devices. Based on that discussion, proposals "Add "Group Identifier"
> > > > > > > > > > to virtio PCI capabilities." [3] and "RFC: Use of bridge devices to
> > > > > > > > > > store pairing information..." [4] were made.
> > > > > > > > >
> > > > > > > > > I must have missed something in those threads, but where does this UUID
> > > > > > > > > thing come about? AFAICS this identifier doesn't need to be
> > > > > > > > > "universally" unique, nor persistent; it only has to be unique across
> > > > > > > > > the VM and stable throughout the VM lifetime.
> > > > > > > >
> > > > > > > > The notion of using UUID came up in the thread
> > > > > > > >
> > > > > > > > https://www.spinics.net/lists/netdev/msg499011.html
> > > > > > >
> > > > > > > That's probably because it was expected one of standard serial number capabilities
> > > > > > > (VPD or PCI Express serial #) will be used, which are expected to be unique.
> > > > > > >
> > > > > > > If you are rolling your own vendor specific one, it's just an ID and
> > > > > > > does not have to be unique.
> > > > > > >
> > > > > > > > > FWIW Hyper-V uses a 32-bit integer for this purpose, not a UUID as seems
> > > > > > > > > to be implied in the thread you refer to.
> > > > > > > >
> > > > > > > > Yes, Hyper-V uses a serial number (but I think it is 64-bit value).
> > > > > > > > However, what we are doing is similar to that. Instead of 32 bits,
> > > > > > > > we are using 128 bits.
> > > > > > >
> > > > > > > That's OK. The name is confusing though. It's a failover group id,
> > > > > > > not a UUID.
> > > > > >
> > > > > > Sure, we can name it whatever we want. I can change it to
> > > > > > "failover-group-id", if that is what we want to call it.
> > > > > >
> > > > > > But what is more important is, what is represented by that name? I thought
> > > > > > we were going to use UUID. The QEMU command line changes in this patch
> > > > > > set expect the user to specify an UUID as the value for this option
> > > > > > (whatever we name it). Are we still in agreement about that, or do you
> > > > > > propose something else to be used? If so, what is it? A 32-bit number, a
> > > > > > 64-bit number, or an arbitrary string?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Venu
> > > > >
> > > > > If we don't really need a UUID, I'd avoid that requirement.
> > > >
> > > > I don't see the need for a 128-bit UUID. I just took that approach because
> > > > UUID was mentioned in "https://www.spinics.net/lists/netdev/msg499011.html".
> > > > Since it is unlikely to have more than 4 billion devices in the system,
> > > > a 32-bit value would be more than enough to uniquely identify devices!
> > > >
> > > > I am looking for direction from you :-). Roman already opined that UUID
> > > > may be an overkill. It appears that you too are leaning that way. Would
> > > > it be acceptable if I change the group identifier ("failover-group-id")
> > > > to a 32-bit value? If you concur, I will start reworking my patch. Could
> > > > you please confirm?
> > > >
> > > > Thanks,
> > > >
> > > > Venu
> > >
> > > I would do a 64 bit one, just in case we want to use PCI Express Device
> > > Serial Number down the road.
> >
> > Will do.
>
> I have incorporated all the changes suggested by you. They are:
>
> * Changed the failover group identifier from UUID to a 64-bit value.
> * Changed the command line option from "uuid" to * "failover-group-id".
> * Tweaked the "pci-bridge" device's Device ID to
> * PCI_DEVICE_ID_REDHAT_BRIDGE_FAILOVER.
> * Added to new device "pcie-downstream" with Device ID
> PCI_DEVICE_ID_REDHAT_DOWNPORT_FAILOVER (to support the PCIe case).
> * Changed the patch for virtio specification to reflect the above
> changes.
>
> Shall I post v3 for review?
>
> Thanks,
>
> Venu
Why not?
> > > > >
> > > > >
> > > > > > >
> > > > > > > > > > The current patch set includes all the feedback received for proposals [3]
> > > > > > > > > > and [4]. For the sake of completeness, patch for the virtio specification
> > > > > > > > > > is also included here. Following is the updated proposal.
> > > > > > > > > >
> > > > > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability
> > > > > > > > > > "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > > >
> > > > > > > > > > 2. Enhance the QEMU CLI to include a "uuid" option to the virtio device.
> > > > > > > > > > The "uuid" is a string in UUID format.
> > > > > > > > > >
> > > > > > > > > > 3. Enhance the QEMU CLI to include a "uuid" option to the bridge device.
> > > > > > > > > > The "uuid" is a string in UUID format. Currently, PCIe bridge for
> > > > > > > > > > the Q35 model is supported.
> > > > > > > > > >
> > > > > > > > > > 4. The operator creates a unique identifier string using 'uuidgen'.
> > > > > > > > > >
> > > > > > > > > > 5. When the virtio device is created, the operator uses the "uuid" option
> > > > > > > > > > (for example, '-device virtio-net-pci,uuid="string"') and specifies
> > > > > > > > > > the UUID created in step 4.
> > > > > > > > > >
> > > > > > > > > > QEMU stores the UUID in the virtio device's configuration space
> > > > > > > > > > in the capability "VIRTIO_PCI_CAP_GROUP_ID_CFG".
> > > > > > > > > >
> > > > > > > > > > 6. When assigning a PCI device to the guest in passthrough mode, the
> > > > > > > > > > operator first creates a bridge using the "uuid" option (for example,
> > > > > > > > > > '-device pcie-downstream,uuid="string"') to specify the UUID created
> > > > > > > > > > in step 4, and then attaches the passthrough device to the bridge.
> > > > > > > > > >
> > > > > > > > > > QEMU stores the UUID in the configuration space of the bridge as
> > > > > > > > > > Vendor-Specific capability (0x09). The "Vendor" here is not to be
> > > > > > > > > > confused with a specific organization. Instead, the vendor of the
> > > > > > > > > > bridge is QEMU. To avoid mixing up with other bridges, the bridge
> > > > > > > > > > will be created with vendor ID 0x1b36 (PCI_VENDOR_ID_REDHAT) and
> > > > > > > > > > device ID 0x000e (PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE) if the "uuid"
> > > > > > > > > > option is specified. Otherwise, current defaults are used.
> > > > > > > > >
> > > > > > > > > I wonder if it makes more sense to drop the concept of failover groups,
> > > > > > > > > and just refer to the standby device by device-id, like
> > > > > > > > >
> > > > > > > > > -device virtio-net-pci,id=foo \
> > > > > > > > > -device pcie-downstream,failover=foo
> > > > > > > >
> > > > > > > > Isn't this the same as what this patch series proposes? In your
> > > > > > > > suggestion, "foo" is the entity that connects the passthrough device
> > > > > > > > and the failover device. In this patch set, that "foo" is the UUID,
> > > > > > > > and the options "id" and "failover" are replaced by "uuid". Do you agree?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Venu
> > > > > > > >
> > > > > > > > > The bridge device will then lookup the failover device, figure out the
> > > > > > > > > common identifier to expose to the guest, and defer the visibility of
> > > > > > > > > the PT device behind the bridge until the guest acknowledged the support
> > > > > > > > > for failover on the PV device.
> > > > > > > > >
> > > > > > > > > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2018-06-29 21:59 UTC | newest]
Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-27 3:49 [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices Venu Busireddy
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
2018-06-27 3:49 ` [Qemu-devel] [PATCH v2 1/4] Add a true or false option to the DEFINE_PROP_UUID macro Venu Busireddy
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
2018-06-27 3:49 ` [Qemu-devel] [PATCH v2 2/4] Add "Group Identifier" support to virtio devices Venu Busireddy
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
2018-06-27 3:49 ` [Qemu-devel] [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge Venu Busireddy
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
2018-06-27 4:02 ` [Qemu-devel] " Michael S. Tsirkin
2018-06-27 4:02 ` [virtio-dev] " Michael S. Tsirkin
2018-06-27 4:08 ` [Qemu-devel] " Venu Busireddy
2018-06-27 4:08 ` Venu Busireddy
2018-06-27 23:07 ` [Qemu-devel] " Venu Busireddy
2018-06-27 23:07 ` Venu Busireddy
2018-06-28 2:14 ` [Qemu-devel] " Michael S. Tsirkin
2018-06-28 2:14 ` Michael S. Tsirkin
2018-06-28 3:46 ` [Qemu-devel] " Venu Busireddy
2018-06-28 3:46 ` Venu Busireddy
2018-06-28 8:10 ` [Qemu-devel] " Siwei Liu
2018-06-28 8:10 ` Siwei Liu
2018-06-28 8:25 ` [Qemu-devel] " Daniel P. Berrangé
2018-06-28 10:07 ` [Qemu-devel] Retrieving configuration metadata from hypervisor (was: Re: [PATCH v2 3/4] Add "Group Identifier" support to Red Hat PCI bridge.) Cornelia Huck
2018-06-28 10:07 ` [virtio-dev] Retrieving configuration metadata from hypervisor (was: Re: [Qemu-devel] " Cornelia Huck
2018-06-27 3:49 ` [Qemu-devel] [PATCH v2 4/4] Add "Group Identifier" support to Red Hat PCI Express bridge Venu Busireddy
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
2018-06-27 3:49 ` [Qemu-devel] [PATCH v2 virtio 1/1] Add "Group Identifier" to virtio PCI capabilities Venu Busireddy
2018-06-27 3:49 ` [virtio-dev] " Venu Busireddy
2018-06-27 4:06 ` [Qemu-devel] [PATCH v2 0/4] Use of unique identifier for pairing virtio and passthrough devices Michael S. Tsirkin
2018-06-27 4:06 ` [virtio-dev] " Michael S. Tsirkin
2018-06-27 4:12 ` [Qemu-devel] " Venu Busireddy
2018-06-27 4:12 ` Venu Busireddy
2018-06-27 7:21 ` [Qemu-devel] " Siwei Liu
2018-06-27 7:21 ` Siwei Liu
2018-06-27 8:17 ` [Qemu-devel] " Cornelia Huck
2018-06-27 8:17 ` Cornelia Huck
2018-06-27 12:24 ` [Qemu-devel] " Roman Kagan
2018-06-27 19:29 ` Venu Busireddy
2018-06-27 19:29 ` [virtio-dev] " Venu Busireddy
2018-06-27 19:47 ` Michael S. Tsirkin
2018-06-27 19:47 ` [virtio-dev] " Michael S. Tsirkin
2018-06-27 19:59 ` Venu Busireddy
2018-06-27 19:59 ` [virtio-dev] " Venu Busireddy
2018-06-27 20:12 ` Michael S. Tsirkin
2018-06-27 20:12 ` [virtio-dev] " Michael S. Tsirkin
2018-06-27 22:34 ` Venu Busireddy
2018-06-27 22:34 ` [virtio-dev] " Venu Busireddy
2018-06-28 1:54 ` Michael S. Tsirkin
2018-06-28 1:54 ` [virtio-dev] " Michael S. Tsirkin
2018-06-28 3:27 ` Venu Busireddy
2018-06-28 3:27 ` [virtio-dev] " Venu Busireddy
2018-06-29 18:55 ` [Qemu-devel] [virtio-dev] " Venu Busireddy
2018-06-29 18:55 ` [virtio-dev] Re: [Qemu-devel] " Venu Busireddy
2018-06-29 21:59 ` [Qemu-devel] [virtio-dev] " Michael S. Tsirkin
2018-06-29 21:59 ` [virtio-dev] Re: [Qemu-devel] " Michael S. Tsirkin
2018-06-28 10:17 ` Roman Kagan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.