On Thu, 29 Feb 2024 13:00:27 +0000 Ankit Agrawal <ank...@nvidia.com> wrote:
> >> >>> Jonathan, you pointed out interface design issues in your review of > >> >>> v2.> > >> >> Are you fully satisfied with the interface in v3? > >> >> > >> >> Yes. I'm fine with the interface in this version (though it's v7, so > >> >> I'm lost > >> >> on v2 vs v3!) > >> > > >> > Looks like I can't count to 7! > >> > > >> > With NUMA capitalized in the doc comment, QAPI schema > >> > Acked-by: Markus Armbruster <arm...@redhat.com> > >> > > >> > Thanks! > >> > >> Thanks! Will fix that in the next version. > > > > The following is really me arguing with myself, so can probably be > > ignored, but maybe it will spark an idea from someone else! > > > > One trivial tweak that might make our life easier if anyone adds > > support in the future for the other device handle type might be to go > > with simply dev rather than pci-dev. > > > > There is a sticky corner though if a device is a PCI device > > and in ACPI DSDT so maybe we are better off adding acpi-dev > > to take either pci-dev or acpi-dev? > > That use case does complicate the situation. Do you of any such > use case for generic initiator? In physical systems yes - in QEMU not yet, though it's a quirk of the available ids to get to the ACPI devices (which oddly are PCI devices :() > > As for your suggestion of using acpi-dev as the arg to take both > pci-dev and acpi-dev.. Would that mean sending a pure pci device > (not the corner case you mentioned) through the acpi-dev argument > as well? Not sure if that would appropriate. Ah, looking up my description is unclear. I meant two optional parameters pci-dev or acpi-dev - which one was supplied would indicate the type of handle to be used. > > > Annoyingly for generic ports, (I'm reusing this infrastructure here) > > the kernel code currently only deals with the ACPI form (for CXL host > > bridges). Given I point that at the bus of a PXB_CXL it is both > > a PCI device, and the only handle we have for getting to the > > Root Bridge ACPI handle. > > So IIUC, you need to pass a PCI device to the generic port object, but use > that to reach the ACPI handle and build the Generic port affinity structure > for an ACPI device? Yes. Slightly shortcut is that the UID is the bus number for all the relevant devices so I can abuse that. QEMU doesn't keep track of the ACPI handles directly so this is the current cleanest solution. > > > So I think I've argued myself around to thinking we need to extend > > the interface with another optional parameter if we ever do support > > the ACPI handle for generic initiators :( > > > > Jonatha
