On 12/14/2023 10:26 AM, Ethan Zhao wrote:
On 12/13/2023 7:59 PM, Baolu Lu wrote:
On 2023/12/13 11:46, Ethan Zhao wrote:
For those endpoint devices connect to system via hotplug capable ports,
users could request a warm reset to the device by flapping device's
link
through setting the slot's link control register, as pciehpt_ist()
DLLSC
interrupt sequence response, pciehp will unload the device driver and
then power it off.
Is it possible for pciehp to disable ATS on the device before unloading
the driver? Or should the device follow some specific steps to warm
reset the device?
In this case, link down first, then pciehp_ist() got DLLSC interrupt
to know
that, I don't think it makes sense to disable device ATS here, but it
could
flag the device is ATS disabled, well, "disconnected" is enough to let
vt-d like software knows the device state.
For hot "unplug" cases:
1. safe_removal
Users request unplug the device via sysfs or press the attention button,
Then pciehp will response to unconfig device/unload device driver, power
if off, and devcie is ready to remove. in this case, devTLB invalidate
request is sent before device link to be brought down or device power
to be turned off. so it doesn't trigger the hard lockup.
2. supprise_removal
Users remove the devece directly or bring the device link down/turn off
device power first by setting pci config space, link-down/not-present/
power-off are all handled by pciehp the same way "supprise_removal", in
such case, pciehp_ist() will flag the device as "disconnected" first, then
unconfig the devcie, unload driver, iommu release device(issing devTLB
flush)
delete device. so we checking the device state could work such cases.
But I am still think about if there are other windows.
Thanks,
Ethan
What happens if IOMMU issues device TLB invalidation after link down but
before pci_dev_is_disconnected() returns true?
Seems it wouldn't happen with hotplug cases, safe_removal or
supprise_removal.
Thanks,
Ethan
Best regards,
baolu
