Re: [PATCH 3/3] hvm/pirq: allow control domains usage of PHYSDEVOP_{un,}map_pirq

[Alex Olson <this.is.a0lson@xxxxxxxxx>]

I wasn't sure of the distinction between hardware domain and control domain for 
these commands, but they appear to be blocked at the moment when dom0 executes 
them, including a lot at boot.  Are you suggesting to use 
is_hardware_domain(currd) instead in my diff?    

Or should the hardware domain always be able to execute any physdev op command? 
(such as to bypass the switch statement entirely)


It looks like hvm_physdev_op() is the only real caller of do_physdev_op(), and  
several other commands (besides the ones in the diff below) are also being 
blocked by the default case of hvm_physdev_op.

PHYSDEVOP_pirq_eoi_gmfn_v2
PHYSDEVOP_pirq_eoi_gmfn_v1
PHYSDEVOP_IRQ_UNMASK_NOTIFY // legacy?
PHYSDEVOP_apic_read
PHYSDEVOP_apic_write
PHYSDEVOP_alloc_irq_vector
PHYSDEVOP_set_iopl
PHYSDEVOP_set_iobitmap
PHYSDEVOP_restore_msi
PHYSDEVOP_restore_msi_ext
PHYSDEVOP_setup_gsi
PHYSDEVOP_get_free_pirq
PHYSDEVOP_dbgp_op

Thanks

-Alex

On Thu, 2022-03-03 at 17:47 +0100, Jan Beulich wrote:
> On 03.03.2022 17:45, Alex Olson wrote:
> > --- a/xen/arch/x86/hvm/hypercall.c
> > +++ b/xen/arch/x86/hvm/hypercall.c
> > @@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >  
> >      switch ( cmd )
> >      {
> > +
> > +    case PHYSDEVOP_manage_pci_add:
> > +    case PHYSDEVOP_manage_pci_remove:
> > +    case PHYSDEVOP_pci_device_add:
> > +    case PHYSDEVOP_pci_device_remove:
> > +    case PHYSDEVOP_manage_pci_add_ext:
> > +    case PHYSDEVOP_prepare_msix:
> > +    case PHYSDEVOP_release_msix:
> > +        if ( is_control_domain(currd) )
> > +            break;
> 
> These are all operations which I think are purposefully permitted to
> be invoked by the hardware domain only. That's where all the devices
> live when they're not passed through to guests.
> 
> Jan
>