linux-kernel - Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0db974d40cd8c5dcc723d43c328bac923e0fe33a.camel@icenowy.me>
Date: Tue, 02 Jul 2024 18:01:05 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Christian König <christian.koenig@....com>, Jiaxun
 Yang <jiaxun.yang@...goat.com>, Huang Rui <ray.huang@....com>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>,  Thomas Zimmermann <tzimmermann@...e.de>, David
 Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined
 when snooping not available

在 2024-07-02星期二的 11:27 +0200，Christian König写道：
> Am 02.07.24 um 11:06 schrieb Icenowy Zheng:
> > [SNIP]
> > However I don't think the definition of the AGP spec could apply on
> > all
> > PCI(e) implementations. The AGP spec itself don't apply on
> > implementations that do not implement AGP (which is the most PCI(e)
> > implementations today), and it's not in the reference list of the
> > PCIe
> > spec, so it does no help on this context.
> 
> No, exactly that is not correct.
> 
> See as I explained the No-Snoop extension to PCIe was created to help
> with AGP support and later merged into the base PCIe specification.
> 
> So the AGP spec is now part of the PCIe spec.
> [SNIP]

I don't think AGP spec is part of the PCIe spec, at least not part of
the PCIe spec I was reading. It does not contain the word "AGP" at all,
and despite it has a "Reference Documents" chapter, this chapter didn't
include the AGP spec, unlike PCI spec / PCI-X addendum which are listed
there.

In addition, your logic that No-Snoop is related to AGP only apply when
discussing about the history of PCIe, not when inspecting it from a
synchronic view, which is what new implementers of a spec should do.

> > > We have quite a bunch of V4L, sound and I also think network
> > > devices
> > > which work like that. But those are non-PCI devices.
> > I think in the Linux kernel most drivers (of course including PCI
> > ones)
> > use DMA buffer in this way, which makes them natually compatible
> > with
> > non-coherent PCIe implementations. TTM is one of the few exceptions
> > here.
> 
> Yes and that is absolutely intentional.
> 
> See we don't want to support any non-coherent PCIe implementation.
> 

However, considering users exist for this setup, I here seriously hope
the support to be gained since today.

> [SNIP]
> > > And if I'm not completely mistaken the RISC-V specification was
> > > also
> > > updated to disallow stuff like this.
> > > 
> > > So yes you can have boards which implement non-snooped PCIe, but
> > > you
> > > get
> > > exactly zero support from hardware vendors to run software on it.
> > > 
> > It's a quite usual case for free softwares to get no support from
> > hardware vendors, and some of them are even developed by reverse
> > engineering. I don't think it as a blocker for the Linux kernel to
> > merge as many hardwares' support as possible.
> 
> We seem to have a misunderstanding here, this is not a software
> issue. 
> The hardware platform is considered broken by the hardware vendor!

I don't think in this case Arm Ltd / RISC-V International is considered
the vendor -- the SoC vendor is. You can rarely get support directly
from the CPU ISA vendor (or CPU IP vendor, which differs mostly in the
RISC-V situation) in the case a SoC or a final product with some SoC is
purchased, and the SoC/product's vendor would rarely declare their
hardware platform as broken.

> 
> In other words people have stitched together hardware in a way which
> is 
> not supported by the creator of that hardware.
> 
> So as long as you can't convince anybody from ARM or the RISC-V team
> or 
> whoever created that hardware to confirm that the hardware actually 
> works you won't get any support for that.

The world isn't black-or-white, and the thing contradictory to
"confirmed working" is "not confirmed working" instead of "confirmed
not working". To get the thing really working (or prove it doesn't work
at all by practice) is part of the traditional fun of a hacker.

> 
> Regards,
> Christian.