Re: [Xen-devel] [PATCH 2/2] vpci/msi: fix update of bound MSI interrupts

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.05.18 at 16:27, <roger.pau@xxxxxxxxxx> wrote:
> On Mon, May 14, 2018 at 06:29:37AM -0600, Jan Beulich wrote:
>> >>> On 08.05.18 at 11:25, <roger.pau@xxxxxxxxxx> wrote:
>> > --- a/xen/arch/x86/hvm/vmsi.c
>> > +++ b/xen/arch/x86/hvm/vmsi.c
>> > @@ -699,6 +699,29 @@ static int vpci_msi_update(const struct pci_dev 
>> > *pdev, uint32_t data,
>> >      return 0;
>> >  }
>> >  
>> > +int vpci_msi_arch_update(struct vpci_msi *msi, const struct pci_dev *pdev)
>> > +{
>> > +    int rc;
>> > +
>> > +    ASSERT(msi->arch.pirq != INVALID_PIRQ);
>> > +
>> > +    pcidevs_lock();
>> > +    rc = vpci_msi_update(pdev, msi->data, msi->address, msi->vectors,
>> > +                         msi->arch.pirq, msi->mask);
>> > +    if ( rc )
>> > +    {
>> > +        spin_lock(&pdev->domain->event_lock);
>> > +        unmap_domain_pirq(pdev->domain, msi->arch.pirq);
>> 
>> This looks quite undesirable - a failed update should leave the interrupt in 
>> its
>> prior state rather than unbinding it. Is that overly difficult to achieve?
> 
> Oh, TBH I would expect that writing an invalid data or address fields
> will disable MSI instead of keep using the old values. I'm not sure I
> see the reason to keep using the old values, certainly that could make
> something else go very wonky inside of the guest itself.

Yeah, true, neither is proper behavior comparing to a simple config space
write (which can't really fail). Crashing the guest may be a more appropriate
action here then. But with what you say I'd also be fine if you kept it as is.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel