On 09.01.2024 11:16, Chen, Jiqian wrote: > On 2024/1/9 17:38, Jan Beulich wrote: >> On 09.01.2024 09:18, Chen, Jiqian wrote: >>> A new hypercall using for granting gsi? If so, how does the caller know to >>> call which hypercall to grant permission, XEN_DOMCTL_irq_permission or that >>> new hypercall? >> >> Either we add a feature indicator, or the caller simply tries the >> new GSI interface first. > I am still not sure how to use and implement it. > Taking pci_add_dm_done as an example, for now its implementation is: > pci_add_dm_done > xc_physdev_map_pirq > xc_domain_irq_permission(,,pirq,) > XEN_DOMCTL_irq_permission > > And assume the new hypercall is XEN_DOMCTL_gsi_permission, do you mean: > pci_add_dm_done > xc_physdev_map_pirq > ret = xc_domain_gsi_permission(,,gsi,) > XEN_DOMCTL_gsi_permission > if ( ret != 0 ) > xc_domain_irq_permission(,,pirq,) > XEN_DOMCTL_irq_permission
No, falling back shouldn't be "blind". Fallback should only happen when the new sub-op isn't implemented (hence why a feature indicator may be necessary), and only if calling the existing sub-op promises to be useful (which iirc would limit that to the PV Dom0 case). > But if so, I have a question that in XEN_DOMCTL_gsi_permission, when to fail > and when to success? I'm afraid I don't understand the question. Behavior there isn't to be fundamentally different from that for XEN_DOMCTL_irq_permission. It's just that the incoming value is in another value space. > Or do you mean: > pci_add_dm_done > xc_physdev_map_pirq > ret = xc_domain_irq_permission(,,pirq,) > XEN_DOMCTL_irq_permission > if ( ret != 0 ) > xc_domain_gsi_permission(,,gsi,) > XEN_DOMCTL_gsi_permission No, this looks the wrong way round. > And in XEN_DOMCTL_gsi_permission, as long as the current domain has the > access of gsi, then granting gsi to caller should be successful. Right? I think so; see above. Jan
