On Mon, Nov 13, 2023 at 11:14:00AM +0000, Ankit Agrawal wrote: > > It also looks like this support just silently fails if the device > > string isn't the right type or isn't found. That's not good. Should > > the previous patch validate the device where the Error return is more > > readily available rather than only doing a strdup there? Maybe then we > > should store the object there rather than a char buffer. > > AFAIU in a normal flow currently, a qemu -object is (parsed and) created much > earlier that a -device. This complicates the situation as when the > acpi-generic-initiator object is being created, the device is not available > for > error check. Maybe I should treat this object specially to create much later? > > > Don't we also still need to enforce that the device is not hotpluggable > > since we're tying it to this fixed ACPI object? That was implicit when > > previously testing for the non-hotpluggable vfio-pci device type, but > > should rely on something like device_get_hotpluggable() now. > > I think this will be similarly problematic as above due to the sequence of > object creation. > > > Also the ACPI Generic Initiator supports either a PCI or ACPI device > > handle, where we're only adding PCI support here. What do we want ACPI > > device support to look like? Is it sufficient that device= only > > accepts a PCI device now and fails on anything else and would later be > > updated to accept an ACPI device or should the object have different > > entry points, ex. pci_dev = vs acpi_dev= where it might later be > > introspected whether ACPI device support exists? > > I am fine with either way. If we prefer different entry points, I can make the > change.
Not the expert on QOM. Hope one of QOM maintainers can answer.
