| Message ID | 20240112061317.418658-4-Jiqian.Chen@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Support device passthrough when dom0 is PVH on Xen | expand |
On Fri, 12 Jan 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. > > Co-developed-by: Huang Rui <ray.huang@amd.com> > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > --- > xen/arch/x86/hvm/hypercall.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c > index 493998b42ec5..46f51ee459f6 100644 > --- a/xen/arch/x86/hvm/hypercall.c > +++ b/xen/arch/x86/hvm/hypercall.c > @@ -76,6 +76,12 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > case PHYSDEVOP_unmap_pirq: > break; > > + case PHYSDEVOP_setup_gsi: > + if ( !is_hardware_domain(currd) ) > + return -EOPNOTSUPP; > + ASSERT(!has_pirq(currd)); Do we really need this assert? I understand that the use case right now is for !has_pirq(currd) but in general it doesn't seem to me that PHYSDEVOP_setup_gsi and !has_pirq should be tied together. Aside from that, it looks fine. > + break; > + > case PHYSDEVOP_eoi: > case PHYSDEVOP_irq_status_query: > case PHYSDEVOP_get_free_pirq: > -- > 2.34.1 >
On 2024/2/23 08:44, Stefano Stabellini wrote: > On Fri, 12 Jan 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. >> >> Co-developed-by: Huang Rui <ray.huang@amd.com> >> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >> --- >> xen/arch/x86/hvm/hypercall.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c >> index 493998b42ec5..46f51ee459f6 100644 >> --- a/xen/arch/x86/hvm/hypercall.c >> +++ b/xen/arch/x86/hvm/hypercall.c >> @@ -76,6 +76,12 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) >> case PHYSDEVOP_unmap_pirq: >> break; >> >> + case PHYSDEVOP_setup_gsi: >> + if ( !is_hardware_domain(currd) ) >> + return -EOPNOTSUPP; >> + ASSERT(!has_pirq(currd)); > > Do we really need this assert? I understand that the use case right now > is for !has_pirq(currd) but in general it doesn't seem to me that > PHYSDEVOP_setup_gsi and !has_pirq should be tied together. Make sense, thanks for explanation, I will delete this in next version. > > Aside from that, it looks fine. > > >> + break; >> + >> case PHYSDEVOP_eoi: >> case PHYSDEVOP_irq_status_query: >> case PHYSDEVOP_get_free_pirq: >> -- >> 2.34.1 >>
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c index 493998b42ec5..46f51ee459f6 100644 --- a/xen/arch/x86/hvm/hypercall.c +++ b/xen/arch/x86/hvm/hypercall.c @@ -76,6 +76,12 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case PHYSDEVOP_unmap_pirq: break; + case PHYSDEVOP_setup_gsi: + if ( !is_hardware_domain(currd) ) + return -EOPNOTSUPP; + ASSERT(!has_pirq(currd)); + break; + case PHYSDEVOP_eoi: case PHYSDEVOP_irq_status_query: case PHYSDEVOP_get_free_pirq:
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. Co-developed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> --- xen/arch/x86/hvm/hypercall.c | 6 ++++++ 1 file changed, 6 insertions(+)