Am 03.06.2014 um 07:54 schrieb Paul Mackerras pau...@samba.org:
On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to
On Tue, 2014-06-03 at 09:45 +0200, Alexander Graf wrote:
For EEH it could as well be a dumb eventfd - really just a side
channel that can tell user space that something happened
asynchronously :).
Which the host kernel may have no way to detect without actively poking
at the device (fences in
On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE
Am 21.05.2014 um 02:13 schrieb Benjamin Herrenschmidt
b...@kernel.crashing.org:
On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote:
Instead of
if (passed_flag)
return;
you would do
if (trigger_irqfd) {
trigger_irqfd();
return;
}
which would be a much
Am 21.05.2014 um 02:19 schrieb Benjamin Herrenschmidt
b...@kernel.crashing.org:
On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote:
So how about we just implement this whole thing properly as irqfd?
Whether QEMU can actually do anything with the interrupt is a different
question
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE so that the guest
can have chance to handle that.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE so that the guest
can have chance to handle that.
Signed-off-by:
On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE so
On 20.05.14 13:56, Gavin Shan wrote:
On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch
On Tue, May 20, 2014 at 02:14:56PM +0200, Alexander Graf wrote:
On 20.05.14 13:56, Gavin Shan wrote:
On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead,
On 20.05.14 14:45, Gavin Shan wrote:
On Tue, May 20, 2014 at 02:14:56PM +0200, Alexander Graf wrote:
On 20.05.14 13:56, Gavin Shan wrote:
On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
On 20.05.14 10:30, Gavin Shan wrote:
If we detects frozen state on PE that has been
On Tue, 2014-05-20 at 21:56 +1000, Gavin Shan wrote:
.../...
I think what you want is an irqfd that the in-kernel eeh code
notifies when it sees a failure. When such an fd exists, the kernel
skips its own error handling.
Yeah, it's a good idea and something for me to improve in phase
On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote:
Instead of
if (passed_flag)
return;
you would do
if (trigger_irqfd) {
trigger_irqfd();
return;
}
which would be a much nicer, generic interface.
But that's not how PAPR works.
Cheers,
Ben.
--
To
On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote:
So how about we just implement this whole thing properly as irqfd?
Whether QEMU can actually do anything with the interrupt is a different
question - we can leave it be for now. But we could model all the code
with the assumption that
On Wed, May 21, 2014 at 10:12:11AM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-20 at 21:56 +1000, Gavin Shan wrote:
.../...
I think what you want is an irqfd that the in-kernel eeh code
notifies when it sees a failure. When such an fd exists, the kernel
skips its own error handling.
15 matches
Mail list logo
