7 p.m.
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(-)
7 p.m.
New subject: [libvirt] [PATCH 1/3] indroduce pci-bridge device for domain definition
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(a)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
7 p.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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(a)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
9:13 a.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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;
+
+}
8:28 p.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
在 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
9:38 p.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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;
>> +
>> +}
>
9:21 a.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
9:01 p.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
10:57 a.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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
7:14 p.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
在 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
11:04 a.m.
New subject: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
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 :|
7 p.m.
New subject: [libvirt] [PATCH 3/3] document pci-pridge device
Signed-off-by: liguang <lig.fnst(a)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
1:38 a.m.
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
2:12 a.m.
在 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
2:28 a.m.
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
>
>
2:52 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
3:12 a.m.
在 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
4:07 a.m.
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
>>>
>>>
>>
>
6:47 p.m.
在 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
8:02 p.m.
在 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
4:22 a.m.
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 :|
10:08 p.m.
在 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
4337
days inactive
4350
days old
21 comments
6 participants
participants (6)
-
Daniel P. Berrange -
Dave Allan -
Ján Tomko -
li guang -
liguang
-
Osier Yang