On Tue, Aug 01, 2023 at 11:57:51AM +0200, Igor Mammedov wrote: > 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. Yes I was talking about unplug. > 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. And it's very clear that it's more efficient for removal. > Regardless of that we can't just switch to BusCheck exclusively > without harming existing setups which can legitimately use both > methods. -- MST
