On Thu, Mar 03, 2022 at 05:47:48PM +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:
The add/remove options are already available to a PVH hardware
domain.
> > + case PHYSDEVOP_manage_pci_add_ext:
This shouldn't be needed in principle for a PVH hardware domain, as
the plan it to emulate accesses to the SR-IOV capability and detect
VFs that way.
> > + case PHYSDEVOP_prepare_msix:
> > + case PHYSDEVOP_release_msix:
Those two are likely fine to use for a PVH hardware domain (not the
control domain). AFAICT they shouldn't interact badly with vPCI.
> > + 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.
Indeed. I think it's only the {prepare,release}_msix operations that
needs adding (but would need confirmation they actually work as
intended in a PVH setup).
Thanks, Roger.
