On 2024/5/17 16:20, Jan Beulich wrote: > On 17.05.2024 10:08, Chen, Jiqian wrote: >> On 2024/5/16 21:08, Jan Beulich wrote: >>> On 16.05.2024 11:52, Jiqian Chen wrote: >>>> struct physdev_pci_device { >>>> /* IN */ >>>> uint16_t seg; >>> >>> Is re-using this struct for this new sub-op sufficient? IOW are all >>> possible resets equal, and hence it doesn't need specifying what kind of >>> reset was done? For example, other than FLR most reset variants reset all >>> functions in one go aiui. Imo that would better require only a single >>> hypercall, just to avoid possible confusion. It also reads as if FLR would >>> not reset as many registers as other reset variants would. >> If I understood correctly that you mean in this hypercall it needs to >> support resetting both one function and all functions of a slot(dev)? >> But it can be done for caller to use a cycle to call this reset hypercall >> for each slot function. > > It could, yes, but since (aiui) there needs to be an indication of the > kind of reset anyway, we can as well avoid relying on the caller doing > so (and at the same time simplify what the caller needs to do). Since the corresponding kernel patch has been merged into linux_next branch https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240515&id=b272722511d5e8ae580f01830687b8a6b2717f01, if it's not very mandatory and necessary, just let the caller handle it temporarily. Or it can add a new hypercall to reset all functions in one go in future potential requirement, like PHYSDEVOP_pci_device_state_reset_all_func.
> > Jan -- Best regards, Jiqian Chen.