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

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Tue, Aug 06, 2013 at 10:52:58AM +0100, Andrew Cooper 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.
> 
> There are no obvious hooks in the PF driver to receive notification of
> these backchannel resets.
> 

Doesn't the PF driver log some entries to dom0 kernel dmesg when the VF in domU 
resets itself? 

-- Pasi


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