Xen devel - Oct 2012 - Why guest is disallowed to change mask bit

Hi,

I am curious to know why Xen disallows guest to change the mask bit of 
MSI-X
vector control as show in the comment out section in msixtbl_write().
Our SR-IOV driver got driver reload failure because it cannot enable 
interrupt.

      /* Do not allow the mask bit to be changed. */
#if 0 /* XXX
        * As the mask bit is the only defined bit in the word, and as the
        * host MSI-X code doesn''t preserve the other bits anyway, doing
        * this is pointless. So for now just discard the write (also
        * saving us from having to determine the matching irq_desc).
        */
     spin_lock_irqsave(&desc->lock, flags);
     orig = readl(virt);
     val &= ~PCI_MSIX_VECTOR_BITMASK;
     val |= orig & PCI_MSIX_VECTOR_BITMASK;
     writel(val, virt);
     spin_unlock_irqrestore(&desc->lock, flags);
#endif

     r = X86EMUL_OKAY;

Thanks.

Chien

>>> On 19.10.12 at 20:45, Chien-Hua Yen <chien.yen@oracle.com>
wrote:
> I am curious to know why Xen disallows guest to change the mask bit of 
> MSI-X
> vector control as show in the comment out section in msixtbl_write().
> Our SR-IOV driver got driver reload failure because it cannot enable 
> interrupt.
> 
>       /* Do not allow the mask bit to be changed. */
> #if 0 /* XXX
>         * As the mask bit is the only defined bit in the word, and as the
>         * host MSI-X code doesn''t preserve the other bits anyway,
doing
>         * this is pointless. So for now just discard the write (also
>         * saving us from having to determine the matching irq_desc).
>         */
>      spin_lock_irqsave(&desc->lock, flags);
>      orig = readl(virt);
>      val &= ~PCI_MSIX_VECTOR_BITMASK;
>      val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
>      spin_unlock_irqrestore(&desc->lock, flags);
> #endif
> 
>      r = X86EMUL_OKAY;
Did you look for the conversation that happened before this
change got committed? As the XXX pretty clearly indicates, the
code ought to not be commented out, but the hypervisor
and/or qemu would have to emulate the mask bit - guests can''t
be permitted write access to the bit because the hypervisor itself
makes use of it.

At the time when the change above was discussed, no drivers
were known that would play with that bit during normal
operation, and hence there was no immediate need to implement
the missing emulation. Unless caused by a bug elsewhere (which
seems possible given the context you provided in private mail),
the only chance for addressing your  problem would be to add
that implementation now. Simply uncommenting the code above
ought to not help (or if it does [on a hypervisor having -unstable
c/s 24805:618cbd27bac0], it would indicate that the security
problem intended to be fixed with this and the other associated
changes is actually still present).

Jan