Acked-by: Ian Munsie <imun...@au1.ibm.com>
Acked-by: Ian Munsie
Acked-by: Ian Munsie <imun...@au1.ibm.com>
Acked-by: Ian Munsie
Acked-by: Ian Munsie <imun...@au1.ibm.com>
Acked-by: Ian Munsie
Acked-by: Ian Munsie <imun...@au1.ibm.com>
Acked-by: Ian Munsie
Acked-by: Ian Munsie <imun...@au1.ibm.com>
Acked-by: Ian Munsie
Acked-by: Ian Munsie <imun...@au1.ibm.com>
Acked-by: Ian Munsie
Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100:
> It would also avoid entering
> WARN(1, "afu_read must be buggy\n");
> if the driver changes its mind between the 2 calls :-)
Honestly, it had better not - that would be a gross violation of the
poll & read semantics
Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100:
> It would also avoid entering
> WARN(1, "afu_read must be buggy\n");
> if the driver changes its mind between the 2 calls :-)
Honestly, it had better not - that would be a gross violation of the
poll & read semantics
Excerpts from Vaibhav Jain's message of 2016-03-10 01:37:56 +1100:
> > +select CXL_AFU_DRIVER_OPS
> I suggest wrapping the driver_ops struct definition and other related
> functions inside a #ifdef CONFIG_CXL_AFU_DRIVER_OPS.
No, the kconfig option is there so that cxlflash can add support for
Excerpts from Vaibhav Jain's message of 2016-03-10 01:37:56 +1100:
> > +select CXL_AFU_DRIVER_OPS
> I suggest wrapping the driver_ops struct definition and other related
> functions inside a #ifdef CONFIG_CXL_AFU_DRIVER_OPS.
No, the kconfig option is there so that cxlflash can add support for
Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100:
> So on afu_read(), we may call afu_driver_ops->event_pending() twice
> before calling afu_driver_ops->deliver_event(). Actually, in the
> (likely) scenario where there's only an afu_driver event pending, we
> *will* call
Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100:
> So on afu_read(), we may call afu_driver_ops->event_pending() twice
> before calling afu_driver_ops->deliver_event(). Actually, in the
> (likely) scenario where there's only an afu_driver event pending, we
> *will* call
From: Ian Munsie <imun...@au1.ibm.com>
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver such as cxlflash can fill these
out and associate it with a context to enable passing custom AFU
specific events to userspace.
The cxl driver wil
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver such as cxlflash can fill these
out and associate it with a context to enable passing custom AFU
specific events to userspace.
The cxl driver will call event_pending() during
ctures they may use.
Signed-off-by: Michael Neuling <mi...@neuling.org>
Signed-off-by: Ian Munsie <imun...@au1.ibm.com>
Reviewed-by: Matthew R. Ochs <mro...@linux.vnet.ibm.com>
---
No changes since v1, added Matt Ochs reviewed-by tag.
drivers/misc/cxl/api.c | 21 +++
.
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
Reviewed-by: Matthew R. Ochs
---
No changes since v1, added Matt Ochs reviewed-by tag.
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions
Excerpts from Matt Ochs's message of 2016-03-08 11:26:55 +1100:
> Any reason for adding these extra lines as part of this commit?
mpe asked for some newlines here in the v1 submission, and it only
really made sense to do so if all the related sections had consistent
whitespace as well.
> > +/*
>
Excerpts from Matt Ochs's message of 2016-03-08 11:26:55 +1100:
> Any reason for adding these extra lines as part of this commit?
mpe asked for some newlines here in the v1 submission, and it only
really made sense to do so if all the related sections had consistent
whitespace as well.
> > +/*
>
From: Ian Munsie <imun...@au1.ibm.com>
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver such as cxlflash can fill these
out and associate it with a context to enable passing custom AFU
specific events to userspace.
The cxl driver wil
ctures they may use.
Signed-off-by: Michael Neuling <mi...@neuling.org>
Signed-off-by: Ian Munsie <imun...@au1.ibm.com>
---
No changes since v1
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 i
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver such as cxlflash can fill these
out and associate it with a context to enable passing custom AFU
specific events to userspace.
The cxl driver will call event_pending() during
.
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
---
No changes since v1
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie <imun...@au1.ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Munsie
If the cxl_context_alloc() call fails, we return immediately without
releasing the reference on the AFU device, allowing it to leak.
This patch switches to using goto style error handling so that the
device is released in common code for both error paths, and will also
simplify
From: Ian Munsie
The cxl user api uses the address_space associated with the file when we
need to force unmap all cxl mmap regions (e.g. on eeh, driver detach,
etc). Currently, contexts allocated through the kernel api do not do
this and instead skip the mmap invalidation, potentially allowing
From: Ian Munsie imun...@au1.ibm.com
The cxl user api uses the address_space associated with the file when we
need to force unmap all cxl mmap regions (e.g. on eeh, driver detach,
etc). Currently, contexts allocated through the kernel api do not do
this and instead skip the mmap invalidation
From: Ian Munsie imun...@au1.ibm.com
If the cxl_context_alloc() call fails, we return immediately without
releasing the reference on the AFU device, allowing it to leak.
This patch switches to using goto style error handling so that the
device is released in common code for both error paths
Excerpts from Michael Ellerman's message of 2015-08-19 15:30:46 +1000:
> On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
> > From: Ian Munsie
> >
> > This adds an afu_driver_ops structure with event_pending and
> > deliver_event callbacks. An AFU driver can f
Excerpts from Michael Ellerman's message of 2015-08-19 15:30:46 +1000:
On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
From: Ian Munsie imun...@au1.ibm.com
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver can fill these out
Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
> Do we really need the accessors? They don't buy anything I can see over just
> using ctx->priv directly.
The reasoning there is because we don't currently expose the contents of
stuct cxl_context to afu drivers, rather they
.
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index e0f0c78..5f0b22e
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver can fill these out and associate
it with a context to enable passing custom AFU specific events to
userspace.
The cxl driver will call event_pending() during poll, select, read
From: Ian Munsie imun...@au1.ibm.com
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver can fill these out and associate
it with a context to enable passing custom AFU specific events to
userspace.
The cxl driver will call event_pending() during
they may use.
Signed-off-by: Michael Neuling mi...@neuling.org
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/misc/cxl
Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
Do we really need the accessors? They don't buy anything I can see over just
using ctx-priv directly.
The reasoning there is because we don't currently expose the contents of
stuct cxl_context to afu drivers, rather they
From: Ian Munsie
userspace programs using cxl currently have to use two strategies for
dealing with MMIO errors simultaneously. They have to check every read
for a return of all Fs in case the adapter has gone away and the kernel
has not yet noticed, and they have to deal with SIGBUS in case
From: Ian Munsie imun...@au1.ibm.com
userspace programs using cxl currently have to use two strategies for
dealing with MMIO errors simultaneously. They have to check every read
for a return of all Fs in case the adapter has gone away and the kernel
has not yet noticed, and they have to deal
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Excerpts from Sukadev Bhattiprolu's message of 2015-07-17 11:51:04 +1000:
> Are you seeing this on big-endian or little-endian system?
>
> IIRC, I saw the opposite behavior on an LE system a few months ago.
> i.e. without 1028ccf5, 'perf listf|grep syscall' failed.
>
> Applying 1028ccf5, seemed
Excerpts from Sukadev Bhattiprolu's message of 2015-07-17 11:51:04 +1000:
Are you seeing this on big-endian or little-endian system?
IIRC, I saw the opposite behavior on an LE system a few months ago.
i.e. without 1028ccf5, 'perf listf|grep syscall' failed.
Applying 1028ccf5, seemed to fix
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie
We are probably also missing an idr_destroy(>contexts_idr); in
cxl_release_afu() as well if you wanted to send a patch for that.
Cheers,
-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
Acked-by: Ian Munsie imun...@au1.ibm.com
We are probably also missing an idr_destroy(afu-contexts_idr); in
cxl_release_afu() as well if you wanted to send a patch for that.
Cheers,
-Ian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
From: Ian Munsie
It was discovered that if a process mmaped their problem state area they
were able to access one page more than expected, potentially allowing
them to access the problem state area of an unrelated process.
This was due to a simple off by one error in the mmap fault handler
From: Ian Munsie
This patch makes the mmap call fail outright if the requested region is
larger than the problem state area assigned to the context so the error
is reported immediately rather than waiting for an attempt to access an
address out of bounds.
Although we never expect users to map
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Munsie imun...@au1.ibm.com
It was discovered that if a process mmaped their problem state area they
were able to access one page more than expected, potentially allowing
them to access the problem state area of an unrelated process.
This was due to a simple off by one error in the mmap
From: Ian Munsie imun...@au1.ibm.com
This patch makes the mmap call fail outright if the requested region is
larger than the problem state area assigned to the context so the error
is reported immediately rather than waiting for an attempt to access an
address out of bounds.
Although we never
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Munsie
The afu fd release path was identified as a significant bottleneck in
the overall performance of cxl. While an optimal AFU design would
minimise the need to close & reopen the AFU fd, it is not always
practical to avoid.
The bottleneck seems to be down to the
From: Ian Munsie imun...@au1.ibm.com
The afu fd release path was identified as a significant bottleneck in
the overall performance of cxl. While an optimal AFU design would
minimise the need to close reopen the AFU fd, it is not always
practical to avoid.
The bottleneck seems to be down
Excerpts from Joe Perches's message of 2015-02-24 01:59:45 +1100:
> On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote:
> > 24 of the %.16llx
> > matches are in drivers/misc/cxl/, so internal consistency wins.
>
> I think that's more an argument for changing all of the
> cx1 uses to
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Excerpts from Joe Perches's message of 2015-02-24 01:59:45 +1100:
On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote:
24 of the %.16llx
matches are in drivers/misc/cxl/, so internal consistency wins.
I think that's more an argument for changing all of the
cx1 uses to %016llx.
I
Excerpts from Rasmus Villemoes's message of 2015-02-21 00:26:22 +1100:
> C99 says that a precision given as simply '.' with no following digits
> or * should be interpreted as 0. The kernel's printf implementation,
> however, treats this case as if the precision was omitted. C99 also
> says that
Excerpts from Rasmus Villemoes's message of 2015-02-21 00:26:22 +1100:
C99 says that a precision given as simply '.' with no following digits
or * should be interpreted as 0. The kernel's printf implementation,
however, treats this case as if the precision was omitted. C99 also
says that if
From: Ian Munsie
We were missing a return statement in the PSL interrupt handler in the
case of an AFU error, which would trigger an "Unhandled CXL PSL IRQ"
warning. We do actually handle these type of errors (by notifying
userspace), so add the missing return IRQ_HANDLED so we d
From: Ian Munsie
An AFU may optionally contain one or more PCIe like configuration
records, which can be used to identify the AFU.
This patch adds support for exposing the raw config space and the
vendor, device and class code under sysfs. These will appear in a
subdirectory of the AFU device
From: Ian Munsie
If an AFU claims to have a configuration record but doesn't actually
contain a vendor and device ID, fail the AFU initialisation. Right now
this is just a way of politely letting AFU developers know that they
need to fix their config space, but later on we may expose the AFUs
From: Ian Munsie imun...@au1.ibm.com
If an AFU claims to have a configuration record but doesn't actually
contain a vendor and device ID, fail the AFU initialisation. Right now
this is just a way of politely letting AFU developers know that they
need to fix their config space, but later on we may
From: Ian Munsie imun...@au1.ibm.com
An AFU may optionally contain one or more PCIe like configuration
records, which can be used to identify the AFU.
This patch adds support for exposing the raw config space and the
vendor, device and class code under sysfs. These will appear in a
subdirectory
From: Ian Munsie imun...@au1.ibm.com
We were missing a return statement in the PSL interrupt handler in the
case of an AFU error, which would trigger an Unhandled CXL PSL IRQ
warning. We do actually handle these type of errors (by notifying
userspace), so add the missing return IRQ_HANDLED so we
From: Ian Munsie
This patch adds tracepoints throughout the cxl driver, which can provide
insight into:
- Context lifetimes
- Commands sent to the PSL and AFU and their completion status
- Segment and page table misses and their resolution
- PSL and AFU interrupts
- slbia calls from the powerpc
From: Ian Munsie imun...@au1.ibm.com
This patch adds tracepoints throughout the cxl driver, which can provide
insight into:
- Context lifetimes
- Commands sent to the PSL and AFU and their completion status
- Segment and page table misses and their resolution
- PSL and AFU interrupts
- slbia
Acked-By: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-By: Ian Munsie imun...@au1.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Grimm
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 2ccd0a9..f801c28 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -319,6 +319,7 @@ static int
From: Ian Munsie
An issue was introduced with "cxl: Unmap MMIO regions when detaching a
context" (b123429e6a9e8d03aacf888d23262835f0081448) where closing a
context normally could also unmap the problem state area of other
contexts currently using the AFU.
It was also discovered
From: Ian Munsie imun...@au1.ibm.com
An issue was introduced with cxl: Unmap MMIO regions when detaching a
context (b123429e6a9e8d03aacf888d23262835f0081448) where closing a
context normally could also unmap the problem state area of other
contexts currently using the AFU.
It was also discovered
.
Signed-off-by: Ryan Grimm gr...@linux.vnet.ibm.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 2ccd0a9..f801c28 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
> From: Ian Munsie
>
> If we need to force detach a context (e.g. due to EEH or simply force
> unbinding the driver) we should prevent the userspace contexts from
> being able to access the Problem State Area MMIO
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
From: Ian Munsie imun...@au1.ibm.com
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO
From: Ian Munsie
We had a known sleep while atomic bug if a CXL device was forcefully
unbound while it was in use. This could occur as a result of EEH, or
manually induced with something like this while the device was in use:
echo :01:00.0 > /sys/bus/pci/drivers/cxl-pci/unbind
The is
From: Ian Munsie
In this particular error path we have already allocated the AFU
interrupts, but have not yet set the status to STARTED. The detach
context code will only attempt to release the interrupts if the context
is in state STARTED, so in this case the interrupts would remain
allocated
From: Ian Munsie
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO region further, which
they may have mapped with mmap().
This patch unmaps any mapped MMIO
From: Ian Munsie
Upon inspection of the implementation specific registers, it was
discovered that the high bit of the implementation specific RXCTL
register was enabled, which enables the DEADB00F debug feature.
The debug feature causes MMIO reads to a disabled AFU to respond with
0xDEADB00F
From: Ian Munsie
When we deactivate the AFU directed mode we free the scheduled process
area, but did not clear the register in the hardware that has a pointer
to it.
This should be fine since we will have already cleared out every context
and we won't do anything that would cause the hardware
From: Ian Munsie
If a context is being detached and we get a translation fault for it
there is little point getting it's mm and handling the fault, so just
respond with an address error and return earlier.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/fault.c | 6 ++
1 file changed, 6
From: Ian Munsie
In the event that something goes wrong in the hardware and it is unable
to complete a process element comment we would end up polling forever,
effectively making the associated process unkillable.
This patch adds a timeout to the process element command code path, so
that we
From: Ian Munsie imun...@au1.ibm.com
In the event that something goes wrong in the hardware and it is unable
to complete a process element comment we would end up polling forever,
effectively making the associated process unkillable.
This patch adds a timeout to the process element command code
From: Ian Munsie imun...@au1.ibm.com
If a context is being detached and we get a translation fault for it
there is little point getting it's mm and handling the fault, so just
respond with an address error and return earlier.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
drivers/misc/cxl
From: Ian Munsie imun...@au1.ibm.com
When we deactivate the AFU directed mode we free the scheduled process
area, but did not clear the register in the hardware that has a pointer
to it.
This should be fine since we will have already cleared out every context
and we won't do anything that would
From: Ian Munsie imun...@au1.ibm.com
Upon inspection of the implementation specific registers, it was
discovered that the high bit of the implementation specific RXCTL
register was enabled, which enables the DEADB00F debug feature.
The debug feature causes MMIO reads to a disabled AFU to respond
From: Ian Munsie imun...@au1.ibm.com
In this particular error path we have already allocated the AFU
interrupts, but have not yet set the status to STARTED. The detach
context code will only attempt to release the interrupts if the context
is in state STARTED, so in this case the interrupts would
From: Ian Munsie imun...@au1.ibm.com
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO region further, which
they may have mapped with mmap().
This patch
From: Ian Munsie imun...@au1.ibm.com
We had a known sleep while atomic bug if a CXL device was forcefully
unbound while it was in use. This could occur as a result of EEH, or
manually induced with something like this while the device was in use:
echo :01:00.0 /sys/bus/pci/drivers/cxl-pci
1 - 100 of 146 matches
Mail list logo
