[libvirt] [PATCH 0/3] add pci-bridge device and address type
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> src/conf/domain_conf.c | 88 +++++++++++++++++++++++++++++++++++++++++++++--- src/conf/domain_conf.h | 22 ++++++++++++ src/qemu/qemu_command.c | 52 +++++++++++++++++++++++++++++++++++++++++++--- docs/formatdomain.html.in | 23 +++++++++++++++++++++++ 4 files changed, 176 insertions(+), 9 deletions(-)
add some definitions for pci-bridge device, and parse elements for pci-bridge, here we bear in mind that pci-bridge is pci bus, so mostly we treat ADDRESS_TYPE_PCIBRIDGE as ADDRESS_TYPE_PCI Signed-off-by: liguang <lig.fnst@cn.fujitsu.com> --- src/conf/domain_conf.c | 88 +++++++++++++++++++++++++++++++++++++++++++++--- src/conf/domain_conf.h | 22 ++++++++++++ 2 files changed, 105 insertions(+), 5 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 6a7646e..4e7fcca 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -167,11 +167,13 @@ VIR_ENUM_IMPL(virDomainDevice, VIR_DOMAIN_DEVICE_LAST, "redirdev", "smartcard", "chr", - "memballoon") + "memballoon", + "pci-bridge") VIR_ENUM_IMPL(virDomainDeviceAddress, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST, "none", "pci", + "pci-bridge", "drive", "virtio-serial", "ccid", @@ -680,6 +682,13 @@ VIR_ENUM_IMPL(virDomainNumatuneMemPlacementMode, "static", "auto"); +VIR_ENUM_IMPL(virDomainPCIbridge, + VIR_DOMAIN_PCIBRIDGE_TYPE_LAST, + "root", + "subordinate", + "secondary"); + + #define VIR_DOMAIN_XML_WRITE_FLAGS VIR_DOMAIN_XML_SECURE #define VIR_DOMAIN_XML_READ_FLAGS VIR_DOMAIN_XML_INACTIVE @@ -1029,6 +1038,16 @@ void virDomainControllerDefFree(virDomainControllerDefPtr def) VIR_FREE(def); } +void virDomainPCIbridgeDefFree(virDomainPCIbridgeDefPtr def) +{ + if (!def) + return; + + virDomainDeviceInfoClear(&def->info); + + VIR_FREE(def); +} + void virDomainFSDefFree(virDomainFSDefPtr def) { if (!def) @@ -2256,6 +2275,7 @@ virDomainDeviceInfoFormat(virBufferPtr buf, virDomainDeviceAddressTypeToString(info->type)); switch (info->type) { + case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE: case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI: virBufferAsprintf(buf, " domain='0x%.4x' bus='0x%.2x' slot='0x%.2x' function='0x%.1x'", info->addr.pci.domain, @@ -2671,6 +2691,7 @@ virDomainDeviceInfoParseXML(xmlNodePtr node, } switch (info->type) { + case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE: case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI: if (virDevicePCIAddressParseXML(address, &info->addr.pci) < 0) goto cleanup; @@ -4541,9 +4562,11 @@ virDomainControllerDefParseXML(xmlNodePtr node, if (def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO && def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390 && - def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { + def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI && + def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Controllers must use the 'pci' address type")); + _("Controllers must use the" + "'pci or pci-bridge' address type")); goto error; } @@ -5138,9 +5161,11 @@ virDomainNetDefParseXML(virCapsPtr caps, if (def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO && def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390 && - def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { + def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI && + def->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Network interfaces must use 'pci' address type")); + _("Network interfaces must use " + "'pci or pci-bridge' address type")); goto error; } @@ -6176,6 +6201,42 @@ error: goto cleanup; } +static virDomainPCIbridgeDefPtr +virDomainPCIbridgeDefParseXML(const xmlNodePtr node, + unsigned int flags) +{ + char *type; + virDomainPCIbridgeDefPtr def; + + if (VIR_ALLOC(def) < 0) { + virReportOOMError(); + return NULL; + } + + type = virXMLPropString(node, "type"); + if (type == NULL) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("strongly suggest to have a type for pci-bridge")); + goto error; + } + if ((def->type = virDomainPCIbridgeTypeFromString(type)) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("unknown type for pci-bridge '%s'"), type); + goto error; + } + + if (virDomainDeviceInfoParseXML(node, NULL, &def->info, flags) < 0) + goto error; + +out: + return def; + +error: + virDomainPCIbridgeDefFree(def); + def = NULL; + goto out; +} + /* Parse the XML definition for a hub device */ static virDomainHubDefPtr @@ -10197,6 +10258,23 @@ static virDomainDefPtr virDomainDefParseXML(virCapsPtr caps, } VIR_FREE(nodes); + /* analysis of pci-bridge devices */ + def->pcibridges = NULL; + if ((n = virXPathNodeSet("./devices/pci-bridge", ctxt, &nodes)) < 0) { + goto error; + } + if (n && VIR_REALLOC_N(def->pcibridges, def->npcibridges) < 0) + goto no_memory; + for (i = 0 ; i < n ; i++) { + virDomainPCIbridgeDefPtr pbg; + + pbg = virDomainPCIbridgeDefParseXML(nodes[i], flags); + if (!pbg) + goto error; + def->pcibridges[def->npcibridges++] = pbg; + } + VIR_FREE(nodes); + /* analysis of the watchdog devices */ def->watchdog = NULL; if ((n = virXPathNodeSet("./devices/watchdog", ctxt, &nodes)) < 0) { diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 5062e07..b3ff85b 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -109,6 +109,9 @@ typedef virDomainChrDef *virDomainChrDefPtr; typedef struct _virDomainMemballoonDef virDomainMemballoonDef; typedef virDomainMemballoonDef *virDomainMemballoonDefPtr; +typedef struct _virDomainPCIbridgeDef virDomainPCIbridgeDef; +typedef virDomainPCIbridgeDef *virDomainPCIbridgeDefPtr; + typedef struct _virDomainSnapshotObj virDomainSnapshotObj; typedef virDomainSnapshotObj *virDomainSnapshotObjPtr; @@ -134,6 +137,7 @@ typedef enum { VIR_DOMAIN_DEVICE_SMARTCARD, VIR_DOMAIN_DEVICE_CHR, VIR_DOMAIN_DEVICE_MEMBALLOON, + VIR_DOMAIN_DEVICE_PCIBRIDGE, VIR_DOMAIN_DEVICE_LAST } virDomainDeviceType; @@ -159,6 +163,7 @@ struct _virDomainDeviceDef { virDomainSmartcardDefPtr smartcard; virDomainChrDefPtr chr; virDomainMemballoonDefPtr memballoon; + virDomainPCIbridgeDefPtr pcibridge; } data; }; @@ -185,6 +190,7 @@ enum virDomainVirtType { enum virDomainDeviceAddressType { VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI, + VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCID, @@ -1034,6 +1040,19 @@ struct _virDomainSmartcardDef { virDomainDeviceInfo info; }; +enum { + VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT, + VIR_DOMAIN_PCIBRIDGE_TYPE_SUBORDINATE, + VIR_DOMAIN_PCIBRIDGE_TYPE_SECONDARY, + + VIR_DOMAIN_PCIBRIDGE_TYPE_LAST +}; + +struct _virDomainPCIbridgeDef { + int type; + virDomainDeviceInfo info; +}; + struct _virDomainHubDef { int type; virDomainDeviceInfo info; @@ -1811,6 +1830,9 @@ struct _virDomainDef { size_t nseclabels; virSecurityLabelDefPtr *seclabels; + size_t npcibridges; + virDomainPCIbridgeDefPtr *pcibridges; + /* Only 1 */ virDomainWatchdogDefPtr watchdog; virDomainMemballoonDefPtr memballoon; -- 1.7.2.5
generally, root pci-bridge refers to bus 0, 'id=pci-bridge0', then the following devices sitting on this bus will set 'bus=pci-bridge0', subordinate bus has 'id=pci-birdge1', and devices sitting on it will set 'bus=pci-bridge1', and so forth. Signed-off-by: liguang <lig.fnst@cn.fujitsu.com> --- src/qemu/qemu_command.c | 52 +++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 48 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 04a9512..e98b6c9 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1762,13 +1762,15 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, virDomainDeviceInfoPtr info, qemuCapsPtr caps) { - if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI || + info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { if (info->addr.pci.domain != 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Only PCI device addresses with domain=0 are supported")); return -1; } - if (info->addr.pci.bus != 0) { + if (info->addr.pci.bus != 0 && + info->type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Only PCI device addresses with bus=0 are supported")); return -1; @@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for > 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0"); - else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; } +char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1"); + + if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT) && + (qemuBuildDeviceAddressStr(&buf, &dev->info, caps) < 0)) + goto error; + else + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto error; + } + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; + +} char * qemuBuildSoundDevStr(virDomainSoundDefPtr sound, @@ -5604,6 +5635,19 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandAddArgList(cmd, "-bootloader", def->os.bootloader, NULL); } + for (i = 0; i < def->npcibridges; i++) { + virDomainPCIbridgeDefPtr pbdg = def->pcibridges[i]; + + if (qemuCapsGet(caps, QEMU_CAPS_DEVICE)) { + char *optstr; + virCommandAddArg(cmd, "-device"); + if (!(optstr = qemuBuildPCIbridgeDevStr(pbdg, caps, i))) + goto error; + virCommandAddArg(cmd, optstr); + VIR_FREE(optstr); + } + } + for (i = 0 ; i < def->ndisks ; i++) { virDomainDiskDefPtr disk = def->disks[i]; -- 1.7.2.5
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for > 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
+ + if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT) && + (qemuBuildDeviceAddressStr(&buf, &dev->info, caps) < 0)) + goto error; + else + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto error; + } + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; + +}
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for > 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus, so only pci.0 accepted now.
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
chassis number is not so important, here, I just set all bridges in same chassis.
+ + if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT) && + (qemuBuildDeviceAddressStr(&buf, &dev->info, caps) < 0)) + goto error; + else + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto error; + } + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; + +}
-- regards! li guang
On 2013年01月04日 10:28, li guang wrote:
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for> 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus, so only pci.0 accepted now.
At this point, I think it's better to ask the QEMU developers to be involved in next series, to make sure things are right.
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
chassis number is not so important, here, I just set all bridges in same chassis.
+ + if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT)&& + (qemuBuildDeviceAddressStr(&buf,&dev->info, caps)< 0)) + goto error; + else + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto error; + } + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; + +}
On Fri, Jan 04, 2013 at 11:38:42AM +0800, Osier Yang wrote:
On 2013年01月04日 10:28, li guang wrote:
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for> 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus, so only pci.0 accepted now.
At this point, I think it's better to ask the QEMU developers to be involved in next series, to make sure things are right.
Regardless of what qemu does today, I don't think it's a good idea to hardcode this to 0 since it's not clear what will happen in the future. Somebody more familiar with the specifics correct me if I'm off base there. Dave
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
chassis number is not so important, here, I just set all bridges in same chassis.
+ + if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT)&& + (qemuBuildDeviceAddressStr(&buf,&dev->info, caps)< 0)) + goto error; + else + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto error; + } + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; + +}
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 2013年01月04日 23:21, Dave Allan wrote:
On Fri, Jan 04, 2013 at 11:38:42AM +0800, Osier Yang wrote:
On 2013年01月04日 10:28, li guang wrote:
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for> 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus, so only pci.0 accepted now.
At this point, I think it's better to ask the QEMU developers to be involved in next series, to make sure things are right.
Regardless of what qemu does today, I don't think it's a good idea to hardcode this to 0 since it's not clear what will happen in the future. Somebody more familiar with the specifics correct me if I'm off base there.
Right, again, the rule is we have to consider as much as possible to make sure the things are capable with future. Either the XMLs or the codes.
Dave
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
chassis number is not so important, here, I just set all bridges in same chassis.
+ + if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT)&& + (qemuBuildDeviceAddressStr(&buf,&dev->info, caps)< 0)) + goto error; + else + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto error; + } + + return virBufferContentAndReset(&buf); + +error: + virBufferFreeAndReset(&buf); + return NULL; + +}
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 01/04/13 03:28, li guang wrote:
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for > 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus, so only pci.0 accepted now.
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
chassis number is not so important, here, I just set all bridges in same chassis.
Each bridge must have a unique chassis #. You *must* set it to a value > 0. I don't check that it is unique, just that it is >0. If you make it non unique, guest will be confused.
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02765.html Jan
在 2013-01-07一的 17:57 +0100，Ján Tomko写道：
On 01/04/13 03:28, li guang wrote:
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for > 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus, so only pci.0 accepted now.
- else + } else { virBufferAsprintf(buf, ",bus=pci"); + } if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON) virBufferAddLit(buf, ",multifunction=on"); else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF) @@ -3455,6 +3460,32 @@ error: return NULL; }
+char * +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev, + qemuCapsPtr caps, int idx) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
The chassis number has to be unique for each bridge.
chassis number is not so important, here, I just set all bridges in same chassis.
Each bridge must have a unique chassis #. You *must* set it to a value > 0. I don't check that it is unique, just that it is >0. If you make it non unique, guest will be confused.
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02765.html
Oh, to be a little pedantic, please refer to PCI-TO-PCI BRIDGE ARCHITECTURE SPECIFICATION, REV 1.2, page 146, as I said before, 'I just set all bridges in same chassis', that means, 1 main chassis(#0) ,1 expansion chassis(#1), maybe it seems strange, but It's not illegal. of course, I will consider your advice to make it unique. Thanks!
Jan
-- regards! li guang
On Thu, Jan 03, 2013 at 04:13:52PM +0100, Ján Tomko wrote:
On 12/26/12 02:00, liguang wrote:
@@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, * When QEMU grows support for > 1 PCI domain, then pci.0 change * to pciNN.0 where NN is the domain number */ - if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) + if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) { + virBufferAsprintf(buf, ",bus=pci-bridge%d", info->addr.pci.bus); + } else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) { virBufferAsprintf(buf, ",bus=pci.0");
Is there any way (or plan) to use more pci buses with QEMU other than with the pci bridges? If not, we could just name the bridges pci.%d. (If we index the bridges from 1).
That depends on the machine type you are using. The PC machine type only has a single PCI bridge. IIRC, the q35 machine type has multiple bridges. Either way I don't think this is a problem for libvirt. When we add PCI bridge devices we should just use the same 'pci.%d' as Jan suggests. If the machine type in question has 2 bridges by default, this simply means the user adding bridges must start from bus=2. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com> --- docs/formatdomain.html.in | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 8d9ab9e..05ed18a 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1972,6 +1972,7 @@ 0.13</span>). <code>multifunction</code> defaults to 'off', but should be set to 'on' for function 0 of a slot that will have multiple functions used. + Please note, you can also set type='pci-bridge' from now on. </dd> <dt><code>type='drive'</code></dt> <dd>Drive addresses have the following additional @@ -4223,6 +4224,28 @@ qemu-kvm -net nic,model=? /dev/null </dd> </dl> + <h4><a name="elementsPCIbridge">pci-bridge</a></h4> + + <p> + pci-bridge device was added aimed to arrange devices to multi-pci-bus, + for example: +<pre> + ... + <devices> + <pci-bridge type='root/'> + <pci-bridge type='subordinate'> + <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </pci-bridge> + <sound model='ac97'> + <address type='pci-bridge' domain='0x0000' bus='0x0' slot='0x06' function='0x0'/> + </sound> + <video model type='cirrus' vram='9216' heads='1'/> + <address type='pci-bridge' domain='0x0000' bus='0x1' slot='0x06' function='0x0'/> + </video> + </devices> + ...</pre> + + <h3><a name="seclabel">Security label</a></h3> <p> -- 1.7.2.5
On 2012年12月26日 09:00, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
I think this is rather not workable, E.g. how to known the video device attached to which pci bridge if there are multiple pci bridges? And the new address type "pci-bridge" looks bogus, as the address properties of a pci bridge are exactly same with a normal pci device. From the qemu patch: -device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u I think what we only need is to describe the relapship between pci bridge and pci bridge (if it's supported, the two types "root" and "subordinate" are not enough to describe the relatioship), also pci device and pci bridge. To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for <pcibridge> device. To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for <pcibridge> is needed, to indentify it, such as "id" or "name". Regards, Osier
在 2012-12-26三的 15:38 +0800，Osier Yang写道：
On 2012年12月26日 09:00, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
I think this is rather not workable, E.g. how to known the video device attached to which pci bridge if there are multiple pci bridges?
please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, and so forth, which was implemented in my patch 2/3
And the new address type "pci-bridge" looks bogus, as the address properties of a pci bridge are exactly same with a normal pci device.
From the qemu patch:
-device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u
I think what we only need is to describe the relapship between pci bridge and pci bridge (if it's supported, the two types "root" and "subordinate" are not enough to describe the relatioship), also pci device and pci bridge.
relationship between pci-bus and devices are embedded, just like pci.0, e.g. <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> means a device sitting on bus pci.0 slot 4 then after my changes <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> would have the same mean relationship between pci-bridges are primary and secondary, (as far as I know qemu doesn’t support multi-pci-bridges at present) so root and subordinate attribute may be enough, every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for <pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for <pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
-- regards! li guang
On 2012年12月26日 16:12, li guang wrote:
在 2012-12-26三的 15:38 +0800，Osier Yang写道：
On 2012年12月26日 09:00, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
I think this is rather not workable, E.g. how to known the video device attached to which pci bridge if there are multiple pci bridges?
please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, and so forth, which was implemented in my patch 2/3
That doesn't answer the question.
And the new address type "pci-bridge" looks bogus, as the address properties of a pci bridge are exactly same with a normal pci device.
From the qemu patch:
-device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u
I think what we only need is to describe the relapship between pci bridge and pci bridge (if it's supported, the two types "root" and "subordinate" are not enough to describe the relatioship), also pci device and pci bridge.
relationship between pci-bus and devices are embedded, just like pci.0, e.g. <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> means a device sitting on bus pci.0 slot 4 then after my changes <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> would have the same mean relationship between pci-bridges are primary and secondary, (as far as I know qemu doesn’t support multi-pci-bridges at present) so root and subordinate attribute may be enough,
No, even it's not supported now, the proposed XML should be designed compatible enough for future. Note that as long as a new XML is added, it can't changed/removed for back-compact, so when introducing new XMLs, you should consider the future. And on other hand, the introduced XML should be general enough for all drivers, not only QEMU. Anyway, regardless of the current qemu implementation, I think you should refer to the specification of PCI SGI, so that the proposed XML could be compatible enough for the future.
every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for<pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for<pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
On 2012年12月26日 16:28, Osier Yang wrote:
On 2012年12月26日 16:12, li guang wrote:
在 2012-12-26三的 15:38 +0800，Osier Yang写道：
On 2012年12月26日 09:00, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
I think this is rather not workable, E.g. how to known the video device attached to which pci bridge if there are multiple pci bridges?
please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, and so forth, which was implemented in my patch 2/3
That doesn't answer the question.
And the new address type "pci-bridge" looks bogus, as the address properties of a pci bridge are exactly same with a normal pci device.
From the qemu patch:
-device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u
I think what we only need is to describe the relapship between pci bridge and pci bridge (if it's supported, the two types "root" and "subordinate" are not enough to describe the relatioship), also pci device and pci bridge.
relationship between pci-bus and devices are embedded, just like pci.0, e.g. <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> means a device sitting on bus pci.0 slot 4 then after my changes <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> would have the same mean relationship between pci-bridges are primary and secondary, (as far as I know qemu doesn’t support multi-pci-bridges at present) so root and subordinate attribute may be enough,
By the way, what I get from Michael S. Tsirkin is: More than 2 bridges *should* work.
No, even it's not supported now, the proposed XML should be designed compatible enough for future. Note that as long as a new XML is added, it can't changed/removed for back-compact, so when introducing new XMLs, you should consider the future.
And on other hand, the introduced XML should be general enough for all drivers, not only QEMU.
Anyway, regardless of the current qemu implementation, I think you should refer to the specification of PCI SGI, so that the proposed XML could be compatible enough for the future.
every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for<pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for<pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
在 2012-12-26三的 16:28 +0800，Osier Yang写道：
On 2012年12月26日 16:12, li guang wrote:
在 2012-12-26三的 15:38 +0800，Osier Yang写道：
On 2012年12月26日 09:00, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
I think this is rather not workable, E.g. how to known the video device attached to which pci bridge if there are multiple pci bridges?
please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, and so forth, which was implemented in my patch 2/3
That doesn't answer the question.
video attached to root bridge(bus 0), slot 2 sound attached to bus 1 , slot 1
And the new address type "pci-bridge" looks bogus, as the address properties of a pci bridge are exactly same with a normal pci device.
From the qemu patch:
-device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u
I think what we only need is to describe the relapship between pci bridge and pci bridge (if it's supported, the two types "root" and "subordinate" are not enough to describe the relatioship), also pci device and pci bridge.
relationship between pci-bus and devices are embedded, just like pci.0, e.g. <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> means a device sitting on bus pci.0 slot 4 then after my changes <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> would have the same mean relationship between pci-bridges are primary and secondary, (as far as I know qemu doesn’t support multi-pci-bridges at present) so root and subordinate attribute may be enough,
No, even it's not supported now, the proposed XML should be designed compatible enough for future. Note that as long as a new XML is added, it can't changed/removed for back-compact, so when introducing new XMLs, you should consider the future.
And on other hand, the introduced XML should be general enough for all drivers, not only QEMU.
Anyway, regardless of the current qemu implementation, I think you should refer to the specification of PCI SGI, so that the proposed XML could be compatible enough for the future.
yes, I will, but any problem with the pci-bridge definition in XML? it's just a simple element. can you tell more details about problem of this new definition?
every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for<pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for<pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
-- regards! li guang
On 2012年12月26日 17:12, li guang wrote:
在 2012-12-26三的 16:28 +0800，Osier Yang写道：
On 2012年12月26日 16:12, li guang wrote:
在 2012-12-26三的 15:38 +0800，Osier Yang写道：
On 2012年12月26日 09:00, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
I think this is rather not workable, E.g. how to known the video device attached to which pci bridge if there are multiple pci bridges?
please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, and so forth, which was implemented in my patch 2/3
That doesn't answer the question.
video attached to root bridge(bus 0), slot 2 sound attached to bus 1 , slot 1
And the new address type "pci-bridge" looks bogus, as the address properties of a pci bridge are exactly same with a normal pci device.
From the qemu patch:
-device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u
I think what we only need is to describe the relapship between pci bridge and pci bridge (if it's supported, the two types "root" and "subordinate" are not enough to describe the relatioship), also pci device and pci bridge.
relationship between pci-bus and devices are embedded, just like pci.0, e.g. <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> means a device sitting on bus pci.0 slot 4 then after my changes <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> would have the same mean relationship between pci-bridges are primary and secondary, (as far as I know qemu doesn’t support multi-pci-bridges at present) so root and subordinate attribute may be enough,
No, even it's not supported now, the proposed XML should be designed compatible enough for future. Note that as long as a new XML is added, it can't changed/removed for back-compact, so when introducing new XMLs, you should consider the future.
And on other hand, the introduced XML should be general enough for all drivers, not only QEMU.
Anyway, regardless of the current qemu implementation, I think you should refer to the specification of PCI SGI, so that the proposed XML could be compatible enough for the future.
yes, I will, but any problem with the pci-bridge definition in XML? it's just a simple element. can you tell more details about problem of this new definition?
The point is how to known the pci device is attached to which pci bridge *if* multiple bridge is supported. I don't think the two types ("root" and "subordinate") could do the work.
every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for<pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for<pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
在 2012-12-26三的 18:07 +0800，Osier Yang写道：
No, even it's not supported now, the proposed XML should be designed compatible enough for future. Note that as long as a new XML is added, it can't changed/removed for back-compact, so when introducing new XMLs, you should consider the future.
And on other hand, the introduced XML should be general enough for all drivers, not only QEMU.
Anyway, regardless of the current qemu implementation, I think you should refer to the specification of PCI SGI, so that the proposed XML could be compatible enough for the future.
yes, I will, but any problem with the pci-bridge definition in XML? it's just a simple element. can you tell more details about problem of this new definition?
The point is how to known the pci device is attached to which pci bridge *if* multiple bridge is supported. I don't think the two types ("root" and "subordinate") could do the work.
okay, let me describe the implicit map rule between bridge and device, before this, we should bear in mind 1 bridge corresponding to only 1 bus root bridge (bus 0) | ----- subordinate bridge (bus 1) (slot 0, bus 0) | | | ----device 0 (slot 0, bus 1) | | | ----device 1 (slot 1, bus 1) | ------ device 0 (slot 2, bus 0) | ....... this map rule was in embedded in my changes.
every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for<pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for<pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
-- regards! li guang
在 2012-12-27四的 08:47 +0800，li guang写道：
在 2012-12-26三的 18:07 +0800，Osier Yang写道：
No, even it's not supported now, the proposed XML should be designed compatible enough for future. Note that as long as a new XML is added, it can't changed/removed for back-compact, so when introducing new XMLs, you should consider the future.
And on other hand, the introduced XML should be general enough for all drivers, not only QEMU.
Anyway, regardless of the current qemu implementation, I think you should refer to the specification of PCI SGI, so that the proposed XML could be compatible enough for the future.
yes, I will, but any problem with the pci-bridge definition in XML? it's just a simple element. can you tell more details about problem of this new definition?
The point is how to known the pci device is attached to which pci bridge *if* multiple bridge is supported. I don't think the two types ("root" and "subordinate") could do the work.
okay, let me describe the implicit map rule between bridge and device, before this, we should bear in mind 1 bridge corresponding to only 1 bus
root bridge (bus 0) | ----- subordinate bridge (bus 1) (slot 0, bus 0) | | | ----device 0 (slot 0, bus 1) | | | ----device 1 (slot 1, bus 1) | ------ device 0 (slot 2, bus 0) | .......
this map rule was in embedded in my changes.
maybe I have to describe more detail about the map rule between pci-bridge and devices, demo XML: <pci-bridge type='root'/> <pci-bridge type='secondary'> <address type='pci-bridge' bus='0x00' slot='0x00' function='0x0'/> </pci-bridge> <pci-bridge type='subordinate'> <address type='pci-bridge' bus='0x01' slot='0x00' function='0x0'/> </pci-bridge> <device-0> <address type='pci-bridge' bus='0x00' slot='0x01' function='0x0'/> </device-0> <device-1> <address type='pci-bridge' bus='0x01' slot='0x00' function='0x0'/> </device-1> <device-2> <address type='pci-bridge' bus='0x02' slot='0x00' function='0x0'/> </device-2> will have following structure: root bridge (bus 0) | -----secondary bridge (bus 1) (bus 0, slot 0) | | | ------subordinate bridge (bus 2) (bus 1, slot 0) | | | | | -------device 2 (bus 2, slot 0) | | | ------device 1 (bus 1, slot 1) | -----device 0 (bus 0, slot 1)
every subordinate will attach to root bridge, and has its own slot.
To describe the relationship between bridges, perhaps we will need "parent" and "child" properties for<pcibridge> device.
To describe the relatioship between a pci device and a pci bridge, a property like "bridge" for general pci device should be enough. In this case, another property for<pcibridge> is needed, to indentify it, such as "id" or "name".
only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt.
Regards, Osier
-- regards! li guang
On Wed, Dec 26, 2012 at 09:00:06AM +0800, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge>
We shouldn't be introducing a new <pci-bridge> device for this. The existing <controller> element is intended to handle all types of bus devices. Just need to define a new controller type. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
在 2013-01-02三的 10:22 +0000，Daniel P. Berrange写道：
On Wed, Dec 26, 2012 at 09:00:06AM +0800, liguang wrote:
Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge>
We shouldn't be introducing a new <pci-bridge> device for this. The existing <controller> element is intended to handle all types of bus devices. Just need to define a new controller type.
okay, let me try to do it.
Daniel
-- regards! li guang
participants (6)
-
Daniel P. Berrange -
Dave Allan -
Ján Tomko -
li guang -
liguang
-
Osier Yang