On 06/23/2015 11:31 AM, Alex Williamson wrote:
> On Mon, 2015-06-22 at 14:44 -0400, Laine Stump wrote:
>> This is backed by the qemu device ioh3420.
>> ---
>> src/qemu/qemu_command.c | 20 ++++++++++++++++++++
>> .../qemuxml2argv-pcie-root-port.args | 10 ++++++++++
>> tests/qemuxml2argvtest.c | 7 +++++++
>> 3 files changed, 37 insertions(+)
>> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port.args
>>
>> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
>> index 4952797..01ac690 100644
>> --- a/src/qemu/qemu_command.c
>> +++ b/src/qemu/qemu_command.c
>> @@ -1598,6 +1598,12 @@ qemuCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
>> */
>> flags = VIR_PCI_CONNECT_TYPE_PCIE;
>> break;
>> + case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
>> + /* pcie-root-port can only connect to pcie-root, isn't
>> + * hot-pluggable
>> + */
>> + flags = VIR_PCI_CONNECT_TYPE_PCIE_ROOT;
>> + break;
>> default:
>> break;
>> }
>> @@ -2345,6 +2351,10 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
>> */
>> flags = VIR_PCI_CONNECT_TYPE_PCIE;
>> break;
>> + case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
>> + /* pcie-root-port can only plug into pcie-root */
>> + flags = VIR_PCI_CONNECT_TYPE_PCIE_ROOT;
>> + break;
>> default:
>> flags = VIR_PCI_CONNECT_HOTPLUGGABLE | VIR_PCI_CONNECT_TYPE_PCI;
>> break;
>> @@ -4605,6 +4615,16 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef,
>> }
>> virBufferAsprintf(&buf, "i82801b11-bridge,id=%s", def->info.alias);
>> break;
>> + case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT:
>> + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_IOH3420)) {
>> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>> + _("The pcie-root-port (ioh3420) controller "
>> + "is not supported in this QEMU binary"));
>> + goto error;
>> + }
>> + virBufferAsprintf(&buf, "ioh3420,port=%d,chassis=%d,id=%s",
>> + def->idx, def->idx, def->info.alias);
> So you didn't like the idea of using the flat devfn as the port number
> for root ports? I'm not a fan of QEMU's use of chassis_nr for bridges
> and with an 8bit limit on port numbers, using idx we'll run out of bits
> at some point.
No, I just didn't understand your point until you re-explained on IRC a
little while ago. I'm changing it as you suggest.
In the meantime, I'm thinking about the other point that you made on IRC
- that we're putting logic into libvirt to derive some of these
parameters (port, chassis, chassis_nr) but in the future may decide that
we need to derive them a different way, and if we do that to an existing
machine during migration, things will get "seriously messed up". Even if
this change takes place while the guest isn't running, the guest OS
could get upset about such a change. All this implies that we really
need to be saving the derived values in the config to avoid such surprises.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list