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

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Thu, Aug 24, 2017 at 04:07:40AM -0600, Jan Beulich wrote:
> >>> 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)?

Shouldn't the unmask happen after the posted interrupt is setup? Or it
doesn't really matter?

I though it was safer to unmask once the bind process was finished.

> > --- 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.

Ack, thanks.

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