On Wed, 15 Mar 2023, Roger Pau Monné wrote: > On Sun, Mar 12, 2023 at 03:54:52PM +0800, Huang Rui wrote: > > From: Chen Jiqian > > > > PVH is also hvm type domain, but PVH hasn't X86_EMU_USE_PIRQ > > flag. So, when dom0 is PVH and call PHYSDEVOP_map_pirq, it > > will fail at check has_pirq(); > > > > Signed-off-by: Chen Jiqian > > Signed-off-by: Huang Rui > > --- > > xen/arch/x86/hvm/hypercall.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c > > index 405d0a95af..16a2f5c0b3 100644 > > --- a/xen/arch/x86/hvm/hypercall.c > > +++ b/xen/arch/x86/hvm/hypercall.c > > @@ -89,8 +89,6 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > > case PHYSDEVOP_eoi: > > case PHYSDEVOP_irq_status_query: > > case PHYSDEVOP_get_free_pirq: > > - if ( !has_pirq(currd) ) > > - return -ENOSYS; > > Since I've taken a look at the Linux side of this, it seems like you > need PHYSDEVOP_map_pirq and PHYSDEVOP_setup_gsi, but the later is not > in this list because has never been available to HVM type guests. > > I would like to better understand the usage by PVH dom0 for GSI > passthrough before deciding on what to do here. IIRC QEMU also uses > PHYSDEVOP_{un,}map_pirq in order to allocate MSI(-X) interrupts. I'll let Ray reply here, but I think you are right: HYSDEVOP_{un,}map_pirq are needed so that QEMU can run in PVH Dom0 to support HVM guests.