On 11/30/2017 8:46 AM, Jan Beulich wrote:
>>>> On 30.11.17 at 15:15, <[email protected]> wrote:
>> On 11/30/2017 2:27 AM, Jan Beulich wrote:
>>>>>> On 29.11.17 at 18:38, <[email protected]> wrote:
>>>>>> In the case of bus or slot reset, our goal is to reset connected PCIe
>>>>>> fabric/card/endpoint.
>>>>>> The connected card/endpoint can be multi-function device. So, same
>>>>>> walk-through and checking
>>>>>> is needed irrespective of type of reset being used.
>>>>> I don't follow: The scope of other devices/functions possibly
>>>>> affected by a reset depends on the type of reset, doesn't it?
>>>> For PCIe platforms, both slot and bus reset endup resetting all connected
>>>> device/functions on thesecondary bus (behind the root-port or
>>>> downstream-port).
>>> According to my understanding this contradicts the comment
>>> ahead of pci_reset_slot(), which talks of multiple slots per bus.
>>> In such a setup, I can't see why resetting on slot would affect
>>> other slots on the same bus. At the same time the comment
>>> says that the slot reset may resolve to a bus one when there's
>>> just a single slot on the bus.
>> For legacy PCI/PCI-X, we can have multiple slots per bus but not with
>> PCI-Express
>> (each link will be on a separate bus).
> Is that true even for root complex integrated end points? A
> random system's lspci output doesn't seem to agree with what
> you say. A typical example would be USB controllers all sitting
> on bus 0, but having different slot numbers. You clearly won't
> be able to ever bus-reset these, and if you checked all devices
> on bus 0 you would then also not be able to slot-reset them.
Here, slot reset refers to any PCIe slot that implements or supports
hotplug feature. The slot reset ultimately invokes "pciehp_reset_slot()".
W.r.t integrated endpoints, these can be reset either through FLR or
secondary bus reset methods only.
Cheers
GOVINDA
Jan,
Do you have any further comments on the current version of this patch?.
Otherwise, I will work on the review comments and publish next version
of this patch later this week. Please let me know. Thanks.
Cheers
GOVINDA
On 12/1/2017 10:16 AM, Govinda Tatti wrote:
>
> On 11/30/2017 8:46 AM, Jan Beulich wrote:
>>>>> On 30.11.17 at 15:15, <[email protected]> wrote:
>>> On 11/30/2017 2:27 AM, Jan Beulich wrote:
>>>>>>> On 29.11.17 at 18:38, <[email protected]> wrote:
>>>>>>> In the case of bus or slot reset, our goal is to reset connected
>>>>>>> PCIe
>>>>>>> fabric/card/endpoint.
>>>>>>> The connected card/endpoint can be multi-function device. So, same
>>>>>>> walk-through and checking
>>>>>>> is needed irrespective of type of reset being used.
>>>>>> I don't follow: The scope of other devices/functions possibly
>>>>>> affected by a reset depends on the type of reset, doesn't it?
>>>>> For PCIe platforms, both slot and bus reset endup resetting all
>>>>> connected
>>>>> device/functions on thesecondary bus (behind the root-port or
>>>>> downstream-port).
>>>> According to my understanding this contradicts the comment
>>>> ahead of pci_reset_slot(), which talks of multiple slots per bus.
>>>> In such a setup, I can't see why resetting on slot would affect
>>>> other slots on the same bus. At the same time the comment
>>>> says that the slot reset may resolve to a bus one when there's
>>>> just a single slot on the bus.
>>> For legacy PCI/PCI-X, we can have multiple slots per bus but not with
>>> PCI-Express
>>> (each link will be on a separate bus).
>> Is that true even for root complex integrated end points? A
>> random system's lspci output doesn't seem to agree with what
>> you say. A typical example would be USB controllers all sitting
>> on bus 0, but having different slot numbers. You clearly won't
>> be able to ever bus-reset these, and if you checked all devices
>> on bus 0 you would then also not be able to slot-reset them.
> Here, slot reset refers to any PCIe slot that implements or supports
> hotplug feature. The slot reset ultimately invokes "pciehp_reset_slot()".
> W.r.t integrated endpoints, these can be reset either through FLR or
> secondary bus reset methods only.
>
> Cheers
> GOVINDA
>
> _______________________________________________
> Xen-devel mailing list
> [email protected]
> https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 04.12.17 at 17:16, <[email protected]> wrote:
> Do you have any further comments on the current version of this patch?.
No. I'm not fully understanding your most recent slot related comments,
but I'll trust you and Konrad to get this into suitable shape.
Jan