[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1525312776.14025.29.camel@arista.com>
Date: Thu, 03 May 2018 02:59:36 +0100
From: Dmitry Safonov <dima@...sta.com>
To: Lu Baolu <baolu.lu@...ux.intel.com>, linux-kernel@...r.kernel.org,
joro@...tes.org, "Raj, Ashok" <ashok.raj@...el.com>
Cc: 0x7f454c46@...il.com, Alex Williamson <alex.williamson@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
iommu@...ts.linux-foundation.org
Subject: Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in
irq handler
On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote:
> Hi,
>
> On 05/03/2018 08:52 AM, Dmitry Safonov wrote:
> > AFAICS, we're doing fault-clearing in a loop inside irq handler.
> > That means that while we're clearing if a fault raises, it'll make
> > an irq level triggered (or on edge) on lapic. So, whenever we
> > return
> > from the irq handler, irq will raise again.
> >
>
> Uhm, double checked with the spec. Interrupts should be generated
> since we always clear the fault overflow bit.
>
> Anyway, we can't clear faults in a limited loop, as the spec says in
> 7.3.1:
Mind to elaborate?
ITOW, I do not see a contradiction. We're still clearing faults in FIFO
fashion. There is no limitation to do some spare work in between
clearings (return from interrupt, then fault again and continue).
> Software is expected to process the non-recoverable faults reported
> through the Fault Recording
> Registers in a circular FIFO fashion starting from the Fault
> Recording Register referenced by the Fault
> Recording Index (FRI) field, until it finds a Fault Recording
> Register with no faults (F field Clear).
>
> Best regards,
> Lu Baolu
--
Thanks,
Dmitry
Powered by blists - more mailing lists