Re: [Xen-devel] [PATCH XEN] x86/pt: add a MSI unmask flag to XEN_DOMCTL_bind_pt_irq

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.08.17 at 11:47, <roger.pau@xxxxxxxxxx> wrote:
> @@ -438,6 +439,22 @@ int pt_irq_create_bind(
>              pi_update_irte(vcpu ? &vcpu->arch.hvm_vmx.pi_desc : NULL,
>                             info, pirq_dpci->gmsi.gvec);
>  
> +        if ( pt_irq_bind->u.msi.gflags & VMSI_UNMASKED )
> +        {
> +            struct irq_desc *desc = irq_to_desc(info->arch.irq);
> +            unsigned long flags;
> +
> +            if ( !desc )
> +            {
> +                pt_irq_destroy_bind(d, pt_irq_bind);
> +                return -EINVAL;
> +            }
> +
> +            spin_lock_irqsave(&desc->lock, flags);
> +            guest_mask_msi_irq(desc, false);
> +            spin_unlock_irqrestore(&desc->lock, flags);
> +        }
> +
>          break;
>      }

I think you would better use pirq_spin_lock_irq_desc() here. And
wouldn't the addition better be moved up a little (perhaps right
after the dropping of the domain's event lock)?

> --- a/xen/include/asm-x86/hvm/irq.h
> +++ b/xen/include/asm-x86/hvm/irq.h
> @@ -136,6 +136,7 @@ struct dev_intx_gsi_link {
>  #define VMSI_DM_MASK      0x200
>  #define VMSI_DELIV_MASK   0x7000
>  #define VMSI_TRIG_MODE    0x8000
> +#define VMSI_UNMASKED     0x10000

As pointed out earlier this effectively is a change to domctl.h, which
(if it hadn't happened already in this release cycle) would require
bumping of the interface version. Please add a note to the commit
message clarifying this, as this complicates possible intentions of
backporting this change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel