[XEN,v9,3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

Commit Message

Chen, Jiqian June 7, 2024, 8:11 a.m. UTC

On PVH dom0, the gsis don't get registered, but
the gsi of a passthrough device must be configured for it to
be able to be mapped into a hvm domU.
On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
passthrough devices to register gsi when dom0 is PVH.
So, add PHYSDEVOP_setup_gsi for above purpose.

Signed-off-by: Huang Rui <[e-mail]>
Signed-off-by: Jiqian Chen <[e-mail]>
---
The code link that will call this hypercall on linux kernel side is as follows
https://lore.kernel.org/lkml/[e-mail]/T/#u
---
 xen/arch/x86/hvm/hypercall.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Jan Beulich June 10, 2024, 4:04 p.m. UTC | #1

On 07.06.2024 10:11, Jiqian Chen wrote:
> On PVH dom0, the gsis don't get registered, but
> the gsi of a passthrough device must be configured for it to
> be able to be mapped into a hvm domU.
> On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
> passthrough devices to register gsi when dom0 is PVH.

"it calls" implies that ...

> So, add PHYSDEVOP_setup_gsi for above purpose.
> 
> Signed-off-by: Huang Rui <[e-mail]>
> Signed-off-by: Jiqian Chen <[e-mail]>
> ---
> The code link that will call this hypercall on linux kernel side is as follows
> https://lore.kernel.org/lkml/[e-mail]/T/#u

... the code only to be added there would already be upstream. As I think the
hypervisor change wants to come first, this part of the description will want
re-wording to along the lines of "will need to" or some such.

As to GSIs not being registered: If that's not a problem for Dom0's own
operation, I think it'll also want/need explaining why what is sufficient for
Dom0 alone isn't sufficient when pass-through comes into play.

Jan

Chen, Jiqian June 12, 2024, 10:15 a.m. UTC | #2

On 2024/6/11 00:04, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> On PVH dom0, the gsis don't get registered, but
>> the gsi of a passthrough device must be configured for it to
>> be able to be mapped into a hvm domU.
>> On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
>> passthrough devices to register gsi when dom0 is PVH.
> 
> "it calls" implies that ...
> 
>> So, add PHYSDEVOP_setup_gsi for above purpose.
>>
>> Signed-off-by: Huang Rui <[e-mail]>
>> Signed-off-by: Jiqian Chen <[e-mail]>
>> ---
>> The code link that will call this hypercall on linux kernel side is as follows
>> https://lore.kernel.org/lkml/[e-mail]/T/#u
> 
> ... the code only to be added there would already be upstream. As I think the
> hypervisor change wants to come first, this part of the description will want
> re-wording to along the lines of "will need to" or some such.
Thanks, I will change in next version.

> 
> As to GSIs not being registered: If that's not a problem for Dom0's own
> operation, I think it'll also want/need explaining why what is sufficient for
> Dom0 alone isn't sufficient when pass-through comes into play.
OK, I will add in next version.

> 
> Jan

Stefano Stabellini July 22, 2024, 9:27 p.m. UTC | #3

On Fri, 7 Jun 2024, Jiqian Chen wrote:
> On PVH dom0, the gsis don't get registered, but
> the gsi of a passthrough device must be configured for it to
> be able to be mapped into a hvm domU.
> On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
> passthrough devices to register gsi when dom0 is PVH.
> So, add PHYSDEVOP_setup_gsi for above purpose.
> 
> Signed-off-by: Huang Rui <[e-mail]>
> Signed-off-by: Jiqian Chen <[e-mail]>

Reviewed-by: Stefano Stabellini <[e-mail]>

Patch

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index fa5d50a0dd22..164f4eefa043 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -86,6 +86,7 @@  long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -ENOSYS;
         break;
 
+    case PHYSDEVOP_setup_gsi:
     case PHYSDEVOP_pci_mmcfg_reserved:
     case PHYSDEVOP_pci_device_add:
     case PHYSDEVOP_pci_device_remove: