<div dir="ltr"><div>Hi Igor,</div><div><br></div><div>I have tried some scenarios and recorded the status in this document[1].</div><div>Could you please help to check the test result? </div><div>Is my test matrix enough? (I will test again once qemu is ready)</div><div>Thank you!</div><div><br></div><div>BTW, current test results for pxb:</div>Q35+ pcie-expander-bus - works<br>PC + pci-expander-bus  - not work<div><div> <br></div><div><br></div><div>[1] <a href="https://docs.google.com/document/d/1C5wseFWLTpNPaeRls8Z8yppocLslTvz9HCIojR9bHHY/edit#">https://docs.google.com/document/d/1C5wseFWLTpNPaeRls8Z8yppocLslTvz9HCIojR9bHHY/edit#</a></div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><font color="#666666">Yalan</font></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 9, 2022 at 5:39 AM Igor Mammedov <<a href="mailto:imammedo@redhat.com">imammedo@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 8, 2022 at 5:44 PM Laine Stump <<a href="mailto:laine@redhat.com" target="_blank">laine@redhat.com</a>> wrote:<br>
><br>
> On 12/8/22 11:15 AM, Julia Suvorova wrote:<br>
> > On Thu, Nov 3, 2022 at 9:26 AM Amnon Ilan <<a href="mailto:ailan@redhat.com" target="_blank">ailan@redhat.com</a>> wrote:<br>
> >><br>
> >><br>
> >><br>
> >> On Thu, Nov 3, 2022 at 12:13 AM Amnon Ilan <<a href="mailto:ailan@redhat.com" target="_blank">ailan@redhat.com</a>> wrote:<br>
> >>><br>
> >>><br>
> >>><br>
> >>> On Wed, Nov 2, 2022 at 6:47 PM Laine Stump <<a href="mailto:laine@redhat.com" target="_blank">laine@redhat.com</a>> wrote:<br>
> >>>><br>
> >>>> On 11/2/22 11:58 AM, Igor Mammedov wrote:<br>
> >>>>> On Wed, 2 Nov 2022 15:20:39 +0000<br>
> >>>>> Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
> >>>>><br>
> >>>>>> On Wed, Nov 02, 2022 at 04:08:43PM +0100, Igor Mammedov wrote:<br>
> >>>>>>> On Wed, 2 Nov 2022 10:43:10 -0400<br>
> >>>>>>> Laine Stump <<a href="mailto:laine@redhat.com" target="_blank">laine@redhat.com</a>> wrote:<br>
> >>>>>>><br>
> >>>>>>>> On 11/1/22 7:46 AM, Igor Mammedov wrote:<br>
> >>>>>>>>> On Mon, 31 Oct 2022 14:48:54 +0000<br>
> >>>>>>>>> Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
> >>>>>>>>><br>
> >>>>>>>>>> On Mon, Oct 31, 2022 at 04:32:27PM +0200, Edward Haas wrote:<br>
> >>>>>>>>>>> Hi Igor and Laine,<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> I would like to revive a 2 years old discussion [1] about consistent network<br>
> >>>>>>>>>>> interfaces in the guest.<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> That discussion mentioned that a guest PCI address may change in two cases:<br>
> >>>>>>>>>>> - The PCI topology changes.<br>
> >>>>>>>>>>> - The machine type changes.<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Usually, the machine type is not expected to change, especially if one<br>
> >>>>>>>>>>> wants to allow migrations between nodes.<br>
> >>>>>>>>>>> I would hope to argue this should not be problematic in practice, because<br>
> >>>>>>>>>>> guest images would be made per a specific machine type.<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Regarding the PCI topology, I am not sure I understand what changes<br>
> >>>>>>>>>>> need to occur to the domxml for a defined guest PCI address to change.<br>
> >>>>>>>>>>> The only think that I can think of is a scenario where hotplug/unplug is<br>
> >>>>>>>>>>> used,<br>
> >>>>>>>>>>> but even then I would expect existing devices to preserve their PCI address<br>
> >>>>>>>>>>> and the plug/unplug device to have a reserved address managed by the one<br>
> >>>>>>>>>>> acting on it (the management system).<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Could you please help clarify in which scenarios the PCI topology can cause<br>
> >>>>>>>>>>> a mess to the naming of interfaces in the guest?<br>
> >>>>>>>>>>><br>
> >>>>>>>>>>> Are there any plans to add the acpi_index support?<br>
> >>>>>>>>>><br>
> >>>>>>>>>> This was implemented a year & a half ago<br>
> >>>>>>>>>><br>
> >>>>>>>>>>      <a href="https://libvirt.org/formatdomain.html#network-interfaces" rel="noreferrer" target="_blank">https://libvirt.org/formatdomain.html#network-interfaces</a><br>
> >>>>>>>>>><br>
> >>>>>>>>>> though due to QEMU limitations this only works for the old<br>
> >>>>>>>>>> i440fx chipset, not Q35 yet.<br>
> >>>>>>>>><br>
> >>>>>>>>> Q35 should work partially too. In its case acpi-index support<br>
> >>>>>>>>> is limited to hotplug enabled root-ports and PCIe-PCI bridges.<br>
> >>>>>>>>> One also has to enable ACPI PCI hotplug (it's enled by default<br>
> >>>>>>>>> on recent machine types) for it to work (<a href="http://i.e.it" rel="noreferrer" target="_blank">i.e.it</a>'s not supported<br>
> >>>>>>>>> in native PCIe hotplug mode).<br>
> >>>>>>>>><br>
> >>>>>>>>> So if mgmt can put nics on root-ports/bridges, then acpi-index<br>
> >>>>>>>>> should just work on Q35 as well.<br>
> >>>>>>>><br>
> >>>>>>>> With only a few exceptions (e.g. the first ich9 audio device, which is<br>
> >>>>>>>> placed directly on the root bus at 00:1B.0 because that is where the<br>
> >>>>>>>> ich9 audio device is located on actual Q35 hardware), libvirt will<br>
> >>>>>>>> automatically put all PCI devices (including network interfaces) on a<br>
> >>>>>>>> pcie-root-port.<br>
> >>>>>>>><br>
> >>>>>>>> After seeing reports that "acpi index doesn't work with Q35<br>
> >>>>>>>> machinetypes" I just assumed that was correct and didn't try it. But<br>
> >>>>>>>> after seeing the "should work partially" statement above, I tried it<br>
> >>>>>>>> just now and an <interface> of a Q35 guest that had its PCI address<br>
> >>>>>>>> auto-assigned by libvirt (and so was placed on a pcie-root-port)m and<br>
> >>>>>>>> had <acpi index='4'/> was given the name "eno4". So what exactly is it<br>
> >>>>>>>> that *doesn't* work?<br>
> >>>>>>><br>
> >>>>>>>   From QEMU side:<br>
> >>>>>>> acpi-index requires:<br>
> >>>>>>>    1. acpi pci hotplug enabled (which is default on relatively new q35 machine types)<br>
> >>>>>>>    2. hotpluggble pci bus (root-port, various pci bridges)<br>
> >>>>>>>    3. NIC can be cold or hotplugged, guest should pick up acpi-index of the device<br>
> >>>>>>>       currently plugged into slot<br>
> >>>>>>> what doesn't work:<br>
> >>>>>>>    1. device attached to host-bridge directly  (work in progress)<br>
> >>>>>>>          (q35)<br>
> >>>>>>>    2. devices attached to any PXB port and any hierarchy hanging of it (there are not plans to make it work)<br>
> >>>>>>>          (q35, pc)<br>
> >>>>>><br>
> >>>>>> I'd say this is still a relatively important, as the PXBs are needed<br>
> >>>>>> to create a NUMA placement aware topology for guests, and I'd say it<br>
> >>>>>> is undesirable to loose acpi-index if a guest is updated to be NUMA<br>
> >>>>>> aware, or if a guest image can be deployed in either normal or NUMA<br>
> >>>>>> aware setups.<br>
> >>>>><br>
> >>>>> it's not only Q35 but also PC.<br>
> >>>>> We basically do not generate ACPI hierarchy for PXBs at all,<br>
> >>>>> so neither ACPI hotplug nor depended acpi-index would work.<br>
> >>>>> It's been so for many years and no one have asked to enable<br>
> >>>>> ACPI hotplug on them so far.<br>
> >>>><br>
> >>>> I'm guessing (based on absolutely 0 information :-)) that there would be<br>
> >>>> more demand for acpi-index (and the resulting predictable interface<br>
> >>>> names) than for acpi hotplug for NUMA-aware setup.<br>
> >>><br>
> >>><br>
> >>> My guess is similar, but it is still desirable to have both (i.e. support ACPI-indexing/hotplug with Numa-aware)<br>
> >>> Adding @Peter Xu to check if our setups for SAP require NUMA-aware topology<br>
> >>><br>
> >>> How big of a project would it be to enable ACPI-indexing/hotplug with PXB?<br>
> ><br>
> > Why would you need to add acpi hotplug on pxb?<br>
> ><br>
> >> Adding +Julia Suvorova and +Tsirkin, Michael to help answer this question<br>
> >><br>
> >> Thanks,<br>
> >> Amnon<br>
> >><br>
> >>><br>
> >>> Since native PCI was improved, we can still compromise on switching to native-PCI-hotplug when PXB is required (and no fixed indexing)<br>
> ><br>
> > Native hotplug works on pxb as is, without disabling acpi hotplug.<br>
><br>
> Are you saying you can add an acpi-index to a device plugged into a pxb,<br>
> that index will be recognized (and used to name the device), but it will<br>
> still do native hotplug?<br>
<br>
nope, acpi-index won't work on pxb hierarchy, it works only PCI tree<br>
hanging off main host bridge.<br>
<br>
><br>
> That sounds okay to me, since it ticks all the functional marks<br>
> (hotplug, consistent device names, NUMA-aware). It's possible there are<br>
> some things I'm misunderstanding or haven't thought of though...<br>
><br>
><br>
> ><br>
> >>> Thanks,<br>
> >>> Amnon<br>
> >>><br>
> >>><br>
> >>>><br>
> >>>><br>
> >>>> Anyway, it sounds like (*within the confines of how libvirt constructs<br>
> >>>> the PCI topology*) we actually have functional parity of acpi-index<br>
> >>>> between 440fx and Q35.<br>
> >>>><br>
> ><br>
><br>
<br>
</blockquote></div>