Re: PCIe hotplug

On Jul 22, 2012, at 9:12 PM, Alexander Kabaev wrote:

> On Sun, 22 Jul 2012 20:22:33 -0600
> Scott Long <scottl@samsco.org> wrote:
>=20
>>=20
>> On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote:
>>=20
>>> Is anyone looking at PCIe hotplug support?
>>>=20
>>> I'm especially interested if anyone has a strategy for device
>>> re-insertion and reassociating the reinserted device with its old
>>> device_t so that it gets the same unit number.. (assumes access to
>>> a serial number or similar) Even if it is put back into a different
>>> slot.
>>>=20
>>=20
>> Would the PCI system be responsible for figuring out this serial
>> number?  I don't think that it can, but it's a question to answer, I
>> guess.  If it can't then it's up to the driver to generate a unique
>> cookie that would be stored by the PCI subsystem.  This cookie would
>> have to be based off of data that can be retrieved from the PCI
>> config space and/or VPD space, since anything more would require
>> resource allocation, which is only allowed in the DEV_ATTACH phase,
>> and once you've hit that phase you've already pretty much sealed the
>> deal on unit number assignment.
>>=20
>> So what would probably happen is that the PCI layer provides a ring
>> buffer of cookie storage and a set of accessors for the drivers.  The
>> cookies would map to a key-value pair with the device unit name and
>> number.  During probe, a driver can look at PCI config space and
>> generate a cookie.  That cookie can then be communicated up to the
>> PCI layer for storage.  Maybe the driver calls a match routine that
>> returns a unit number on match and a store on failure, then the
>> driver calls a set_unit_number accessor.  Only the driver that wins
>> the bid would win the unit number reassignment or cookie storage.  Or
>> maybe the driver passes the cookie up as part of its return code, and
>> the match and unit assignment happens automatically.  Drivers that
>> don't want to participate in this simply wouldn't, and everything
>> would continue to operate the same way.  The two sticky parts are
>> rogue/buggy drivers that abuse the api and cause a flood of cookies
>> to be generated, and questions on when a unit number is eligible for
>> reuse.  For the first one, a ring buffer of cookies would solve the
>> immediate problem, but you might still have some risk of drivers
>> selectively wrapping the buffer for whatever accidental or evil
>> purpose.  For the second problem, maybe a unit number stays
>> persistent only if the PCIe hot remove mechanism requests it, and
>> then only until the ring-buffer wraps.
>>=20
>> Scott
>>=20
>=20
> I do not think the whole problem as depicted by Julian is even worth
> solving. Why keeping any data for the device that might _never_ come
> back? What if the device hierarchy just starts from the PCI-e and
> extends upwards and user still holds on to some vestiges of a previous
> device chain (say, by keeping a character control device sharing the
> same unit number open, common practice)? Reusing unit number is much
> trickier then, and might not be even possible. So, before one jumps
> into 'how', can we agree on 'why' first? When device goes away, it is
> not just this device's device_t that is disappearing, it is a whole
> tree rooted at that device. I see no point in trying to reconstruct
> that.

There's a reason that PC Card and CardBus never supported this at all.  =
The assumption was that reconnecting devices is so cheap that it isn't =
worth the bother.  This is true for all but some specialized devices =
today: network information is easy to reconstruct, storage drives are =
easy to reconfigure (since we already fail all in-flight transactions =
when the device goes away), etc.  I can see some advantage to having =
storage cope, but there already geom classes that can help people code =
when drives can go away.

> PCI-e hotplug proper is very much orthogonal to the question of unit
> numbering and IS worth supporting.

Yes.  totally agreed.

Warner

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"