On Sat, 2021-05-15 at 13:23 +0200, Mauro Carvalho Chehab wrote:
> Em Sat, 15 May 2021 10:24:28 +0100
> David Woodhouse escreveu:
> > > Let's take one step back, in order to return to the intents of this
> > > UTF-8, as the discussions here are not centered into the pa
On Sat, 2021-05-15 at 10:22 +0200, Mauro Carvalho Chehab wrote:
> > > Here, U is not working. No idea why. I haven't
> > > test it for *years*, as I din't see any reason why I would
> > > need to type UTF-8 characters by numbers until we started
> > > this thread.
> >
> >
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice o
On Wed, 2021-05-12 at 17:17 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 10:14:44 -0400
> "Theodore Ts'o" escreveu:
>
> > On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> > > v2:
> > > - removed EM/EN DASH conversion from this patchset;
> >
> > Are you
Your title 'Use ASCII subset' is now at least a bit *closer* to
describing what the patches are actually doing, but it's still a bit
misleading because you're only doing it for *some* characters.
And the wording is still indicative of a fundamentally *misguided*
motivation for doing any of this.
On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
>
> - it helps people needing to touch the documents using non-utf8 locales[1];
> - it makes easier to grep for a text;
>
> [1] There are still some widely used distros nowadays
On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8.
>
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This
On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
>
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools
On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote:
> Hm, I have no idea. :) What would I look for in the BIOS?
For a start, what is the actual failure mode?
> I figured since g4 was busted, surely q35 was too, since it's even
> older...
Oh no, they all have different failures. Intel never
On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
> enabled. Without this, a Q35 system can only enable IOMMU when booting
> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".
Hm, is this definitely the same bug? Or
On Mon, 2016-08-15 at 13:53 +0100, Chris Wilson wrote:
>
> So it is really just what happens to commands for this client when it
> dies/exits. The kneejerk reaction is to say the pages should be kept
> alive as they are now for !svm. We could be faced with a situation where
> the client copies
On Mon, 2016-08-15 at 13:23 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 01:13:25PM +0100, David Woodhouse wrote:
> > On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> > > On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> > > >
>
On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> >
> > + struct task_struct *task;
>
> We don't need the task, we need the mm.
>
> Holding the task is not sufficient.
From the pure DMA point of view, you don't need the
On Mon, 2016-08-15 at 14:48 +0300, Mika Kuoppala wrote:
>
>
> +static void i915_svm_fault_cb(struct device *dev, int pasid, u64 addr,
> + u32 private, int rwxp, int response)
> +{
> +}
> +
> +static struct svm_dev_ops i915_svm_ops = {
> + .fault_cb =
On Tue, 2015-10-13 at 22:34 +0100, David Woodhouse wrote:
> If the device itself reports ATS in its PCIe capabilities, but the BIOS
> neglects to provide an ATSR structure to indicate that the root port can
> also cope, then assume the latter is lying.
Except, of course, that integrate
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables on supported hardware.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/Kconfig | 8 ++
drivers/iommu/Makefile | 1 +
drivers/iommu/intel-iommu.c | 14 ++
drivers/iommu/intel-svm.c
The behaviour if you enable PASID support after ATS is undefined. So we
have to enable it first, even if we don't know whether we'll need it.
This is safe enough; unless we set up a context that permits it, the device
can't actually *do* anything with it.
Signed-off-by: David Woodhouse
If the device itself reports ATS in its PCIe capabilities, but the BIOS
neglects to provide an ATSR structure to indicate that the root port can
also cope, then assume the latter is lying.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 2 ++
drivers/iommu/intel-svm.c | 9 +
include/linux/dma_remapping.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
This provides basic PASID support for endpoint devices, tested with a
version of the i915 driver.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 111
drivers/iommu/intel-svm.c
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/dmar.c| 42 +++---
include/linux/intel-iommu.h | 10 +-
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/
Largely based on the driver-mode implementation by Jesse Barnes.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 22 +-
drivers/iommu/intel-svm.c | 173
include/linux/intel-iommu.h | 26
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 3 ++-
drivers/iommu/intel-svm.c | 26 +-
include/linux/intel-iommu.h | 3 +++
include/linux/intel-svm.h | 21 ++---
4 files changed, 48 insertions
with 'intel_iommu=pasid28' on the command line.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 20 ++--
include/linux/intel-iommu.h | 2 +-
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iom
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
include/linux/intel-iommu.h | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 6240063..08802b9 100644
--- a/include/linux/intel-i
Fix fault response codes (swap INVALID vs. FAILURE)
Fix PASID/PRI capability handling
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2015-10-09 at 00:50 +0100, David Woodhouse wrote:
> This patch set enables PASID support for the Intel IOMMU, along with
> page request support.
>
> Like its AMD counterpart, it exposes an IOMMU-specific API. I believe
> we'll have a session at the Kernel Summit later this
On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
> > On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
> > >
> > > Hm if this still works the same way as on older platforms then pagef
rently in my own code — using idr_for_each_entry() on the IDR
I use to allocate PASIDs. That's fine while there is a relatively low
number of PASIDs allocated (i.e. a low number of *processes* using
PASIDs, since there's one-PASID-per-process). But if we end up with
lots, th
we *could* contrive to give you
precise exceptions when the hardware doesn't really do that sanely.
But I was really trying hard to avoid the necessity for that kind of
hack to work around stupid hardware :)
--
David WoodhouseOpen Source Technology Centr
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
>
> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
> /** Execlists no. of times this request has been sent to the ELSP */
> int elsp_submitted;
>
> + /* core fence obj for this request, may be exported */
> +
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
> We just need to pass in an address to execute and some flags, since we
> don't have to worry about buffer relocation or any of the other usual
> stuff. Returns a fence to be used for synchronization.
> ---
> drivers/gpu/drm/i915/i915_dma.c
On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote:
>
> Could someone clarify what this means from the TDR point of view,
> please? When you say "context blew up" I'm guessing that you mean that
> come context caused the fault handler to get involved somehow?
>
> Does this imply that the
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-svm.c | 115 +++-
include/linux/intel-iommu.h | 21
2 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 22 +-
drivers/iommu/intel-svm.c | 71 +
include/linux/intel-iommu.h | 5
3 files changed, 97 insertions(+), 1 deletion(-)
diff
If the device itself reports ATS in its PCIe capabilities, but the BIOS
neglects to provide an ATSR structure to indicate that the root port can
also cope, then assume the latter is lying.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.
() will be *given* the PASID that they are to
use. In general we seem to be converging on using a single PASID space
across *all* IOMMUs in the system, and this will support that mode of
operation.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables on supported hardware.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/Kconfig | 8 ++
drivers/iommu/Makefile | 1 +
drivers/iommu/intel-iommu.c | 14 ++
drivers/iommu/intel-svm.c
with 'intel_iommu=pasid28' on the command line.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 20 ++--
include/linux/intel-iommu.h | 2 +-
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iom
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/dmar.c| 42 +++---
include/linux/intel-iommu.h | 10 +-
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/
.
Eventually we'll also want the PASID space to be system-wide, not just
per-IOMMU. But when we have that requirement we'll also have a way to
achieve it.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/iommu/intel-iommu.c | 100 ++
drivers/iommu/intel
On Wed, 2015-10-07 at 09:28 -0700, Jesse Barnes wrote:
> On 10/07/2015 09:14 AM, Daniel Vetter wrote:
> > On Wed, Oct 07, 2015 at 08:16:42AM -0700, Jesse Barnes wrote:
> > > On 10/07/2015 06:00 AM, David Woodhouse wrote:
> > > > On Fri, 2015-09-04 at 0
) in there to get the test to succeed.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
status reg 2
dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 88
DMAR:[fault reason 23] Unknown
fbcon: inteldrmfb (fb0) is primary device
Signed-off-by: David Woodhouse david.woodho...@intel.com
Cc: sta...@vger.kernel.org
---
[17:01] danvet can you pls submit this as a patch to intel
it's reset the hardware to *stop*
doing whatever DMA the BIOS set it up with.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ Alex's patch prevents assignment to VM guests of *any* device which
On Tue, 2014-06-17 at 09:15 +0200, Daniel Vetter wrote:
We've always been struggling with stolen handling, and we've' always
been struggling with vt-d stuff. Also pass-through seems to be a major
pain (I've never tried myself). Given all that I'm voting for keeping
the RMRR and everything else
On Tue, 2014-06-17 at 06:22 -0600, Alex Williamson wrote:
On Tue, 2014-06-17 at 08:04 +0100, David Woodhouse wrote:
On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote:
Any idea what an off-the-shelf Asus motherboard would be doing with an
RMRR on the Intel HD graphics
On Thu, 2014-03-20 at 09:36 +0200, Jani Nikula wrote:
Or an additional knob, in case it's really not working and people want
to get other things depending on prelim hw support done.
Yeah. Perhaps the best answer is a 'disable_silicon_workarounds' option,
to disable *all* workarounds for
On Thu, 2014-03-20 at 10:45 +0100, Daniel Vetter wrote:
I'd agree that this would be nice, but my maintainer time is not
endless and when I have users screaming regression I do have to do
something. And yeah with the track record set of some of the earliest
vtd+gfx chips I'm fairly aggressive
On Tue, 2014-03-18 at 14:59 +0200, Jani Nikula wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes,
On Mon, 2014-03-17 at 12:21 +, Chris Wilson wrote:
+EXPORT_SYMBOL(interval_tree_insert);
+EXPORT_SYMBOL(interval_tree_remove);
+EXPORT_SYMBOL(interval_tree_iter_first);
+EXPORT_SYMBOL(interval_tree_iter_next);
I'd prefer to see EXPORT_SYMBOL_GPL for this.
--
dwmw2
smime.p7s
On Mon, 2014-03-17 at 16:17 +, David Woodhouse wrote:
Can't tell though, because my machine is still dying in an endless
stream of
[ 199.647850] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR*
Interrupt arrived before CRTCs were setup up
Except when the failure mode is different
...@vger.kernel.org
Cc: David Woodhouse dw...@infradead.org
Reported-and-tested-by: Mihai Moldovan io...@ionic.de
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/iommu/intel-iommu.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
So don't bother, but instead disable it by default to allow distros to
unconditionally enable DMAR support.
Acked-By: David Woodhouse david.woodho...@intel.com
On Tue, 2011-12-20 at 08:54 -0800, Eric Anholt wrote:
- seq_printf(m, %p: %s%s %8zd %04x %04x %d %d%s%s%s,
+ seq_printf(m, %p: %s%s %8zdKB %04x %04x %d %d%s%s%s,
obj-base,
get_pin_flag(obj),
get_tiling_flag(obj),
-
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote:
So the user has to choose between 5W of power saving or having dmar? And
we default to
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
Things I've tried that don't work around the issue:
- Disable dmar for the igfx with intel_iommu=igfx_off
- Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
idling while flushing).
Well, the ILK workaround was only
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
Hm, that comment confuses me a bit. I've always thought that igfx_off only
instantiates a identity mapping and leaves the dmar unit on. Is that
wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the one
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
Those are needed by the rc6 and semaphores support in i915 driver.
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.
This is
On Fri, 2011-11-11 at 14:48 +0100, Joerg Roedel wrote:
+#define intel_iommu_gfx_mapped 1
That ought to be zero; if the IOMMU code isn't present, it's
*definitely* not mapped through the IOMMU :)
But I'm fairly sure this was already noticed and a patch is on its way
upstream already.
It's my
61 matches
Mail list logo
