linux-kernel - Overhead of io{read,write}{8,16,32,64} on x86

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>] [thread-next>] [day] [month] [year] [list]

Message-Id: <82076999-9346-473d-8841-1480cd70b527@app.fastmail.com>
Date:   Tue, 31 Oct 2023 21:41:26 +0000
From:   "Jiaxun Yang" <jiaxun.yang@...goat.com>
To:     linux-arch@...r.kernel.org
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, arnd@...db.de,
        bhe@...hat.com
Subject: Overhead of io{read,write}{8,16,32,64} on x86

Hi all,

I'm trying to improve Kernel's support of devices that have ioports
mapped into MMIO, that involves converting existing driver which is
using {in,out}{l,w,b} to use io{read,write}{8,16,32,64}, so they can
benefit from ioport_map and pci_iomap.

However, the problem is io{read,write}{8,16,32,64} will incur penalty
on x86 by introducing extra function calls (they are not inlined) and
having extra condition judgment on MMIO vs PIO.

x86 folks, do you think this kind of overhead is acceptable? I do think
most of PCI/ISA drivers will need to be converted.

linux-arch folks, do you think it will be better if we introduce a
variant of io{read,write}{8,16,32,64} that direct to PIO on x86 but
remains the same functionality on other architectures?

Thanks
- Jiaxun