On 03/03/2022 10:30, Roger Pau Monne wrote:
> Control domains (including domains having control over a single other
> guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
> bindings of interrupts from devices assigned to the controlled guest.
>
> As such relax the check for HVM based guests and allow the usage of
> the hypercalls for any control domains. Note that further safety
> checks will be performed in order to assert that the current domain
> has the right permissions against the target of the hypercall.
>
> Reported-by: Alex Olson <[email protected]>
> Reported-by: Andrew Cooper <[email protected]>
> Signed-off-by: Roger Pau Monné <[email protected]>
> ---
> xen/arch/x86/hvm/hypercall.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index 030243810e..9128e4d025 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> case PHYSDEVOP_map_pirq:
> case PHYSDEVOP_unmap_pirq:
> + /*
> + * Control domain (and domains controlling others) need to use
> + * PHYSDEVOP_{un,}map_pirq in order to setup interrupts for
> passthrough
> + * devices on behalf of other guests.
> + */
> + if ( is_control_domain(currd) || currd->target )
> + break;
Hmm. In a split control/hardware domain model, then qemu is in the
hardware domain rather than the control domain. I suspect this wants
extending with || is_hardware_domain(currd).
Also, the sentence about later safety checks really ought to be in this
source comment too.
~Andrew
