On 12/01/2016 10:55 PM, Alex Williamson wrote: > On Thu, 1 Dec 2016 21:40:00 +0800 >>> If an AER fault occurs and the user doesn't do a reset, what >>> happens when that device is released and a host driver tries to make >>> use of it? The user makes no commitment to do a reset and there are >>> only limited configurations where we even allow the user to perform a >>> reset. >>> >> >> Limited? Do you mean the things __pci_dev_reset() can do? > > I mean that there are significant device and guest configuration > restrictions in order to support AER. For instance, all the functions > of the slot need to appear in a PCI-e topology in the guest with all > the functions in the right place such that a guest bus reset translates > into a host bus reset. The physical functions cannot be split between > guests even if IOMMU isolation would otherwise allow it. The user > needs to explicitly enable AER support for the devices. A VM need to > be specifically configured for AER support in order to set any sort of > expectations of a guest directed bus reset, let alone a guarantee that > it will happen. So all the existing VMs, where functions are split > between guests, or the topology isn't exactly right, or AER isn't > enabled see a regression from the above change as the device is no > longer reset. > I am not clear why set these restrictions in the current design. I take a glance at older versions of qemu's patchset, their thoughts is: translate a guest bus reset into a host bus reset(Which is unreasonable[*] to me). And I guess, that's the *cause* of these restrictions? Is there any other stories behind these restrictions? [*] In physical world, set bridge's secondary bus reset would send hot-reset TLP to all functions below, trigger every device's reset separately. Emulated device should behave the same, means just using each device's DeviceClass->reset method. -- Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
