Re: [PATCH v2] interrupts: allow guest to set and clear MSI-X mask bit

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 06/08/13 09:29, Jan Beulich wrote:
>>>> On 05.08.13 at 18:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 05/08/13 12:49, Jan Beulich wrote:
>>> But a proper solution would of course be preferred. That may involve
>>> notifying Xen of the reset from the PF driver.
>> That is making the assumption that the PF driver is even aware that the
>> reset has occurred.  If the PF driver can get at the reset information,
>> I still cant see Xen specific hooks being accepted upstream.
> You sort of contradict your earlier statement here that "the VF
> requests the PF to reset itself" (where you probably meant "it",
> as the VF is hardly allowed to cause a reset of the PF): Such an
> operation should imo be visible to the PF driver.
>
> And then, even if the reset is being done, shouldn't the interrupt
> setup occur _after_ the reset? Which would make Xen clear the
> flag...

The observed behaviour is this:  On startup, the VF driver issues this
backchannel reset of itself (the VF) which, amongst other things, sets
the mask bit.  It leaves the MSI/MSI-X addr and data fields alone, but
on further consideration, relying on this behaviour might not be a good
idea.  The VF is then expected to re-enable the interrupt at its
convenience.

There are no obvious hooks in the PF driver to receive notification of
these backchannel resets.

~Andrew

>
>> Fundamentally, given that only the VM is in a position to actually know
>> about the state of the mask bit (As we cant possibly have Xen polling
>> for the state), then the guest has to have access to the mask bit.
> No, that continues to not be an option as long as Xen uses the mask
> bit itself. Once again, the obvious immediate solution would appear
> to be to carry out the write with the OR of both the guest intended
> and the hypervisor required mask bits, thus allowing the bit to get
> cleared immediately if Xen doesn't need it to be set (and the clearing
> would happen subsequently if Xen needs the flag to be set at the
> point of the guest write). This requires associating back the table
> entry to the IRQ in question (if any), in order to look at
> irq_desc->msi_desc->msi_attrib.masked.
>
> Jan
>