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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.08.13 at 11:52, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 06/08/13 09:29, Jan Beulich wrote:
>>>>> On 05.08.13 at 18:03, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.

Re-enable? Not set up? That would at once deal with your valid
concern regarding MSI addr/data.

This still looks to me like a device/driver specific bug rather than a
general SR-IOV issue...

Jan


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