On Mon, 31 Jul 2023 17:54:21 -0400 "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > On Mon, Jul 31, 2023 at 04:42:51PM -0500, Bjorn Helgaas wrote: > > I would expect hot-add to be handled via a Bus Check to the *parent* > > of a new device, so the device tree would only need to describe > > hardware that's present at boot. That would mean pci_root.c would > > have some .notify() handler, but I don't see anything there. > > That has a big performance cost though - OSPM has no way to figure out > on which slot the new device is, so has to rescan the whole bus. > Spec says following about OSPM receiving DeviceCheck ACPI6.5r 5.6.6 Device Object Notifications) " If the device has appeared, OSPM will re-enumerate from the parent. If the device has disappeared, OSPM will invalidate the state of the device. OSPM may optimize out re-enumeration. ... If the device is a bridge, OSPM _may_ re-enumerate the bridge and the child bus. " The later statement is was added somewhere after 1.0b spec. According to debug logs when I was testing that hotplug still works I saw 're-enumerate from the parent', behavior. So there is space to optimize if there would be demand for that. And 6.5 spec has 'Device Light Check', though using that would require some ugly juggling with checking supported revisions & co which were never reliable in practice. I don't know what Windows does in that case. However if one has deep hierarchy, a BusCheck shall cause expensive deep scan. While for DeviceCheck it's optional 'may', and even that may is vague enough that one can read it as if it's 'a new bridge' then scan behind it while one can ignore existing bridge if it isn't DeviceCheck target. Regardless of that we can't just switch to BusCheck exclusively without harming existing setups which can legitimately use both methods.
