Hello, I noticed several places where virt_to_phys() or phys_to_virt() translations are used obviously inappropriately. The reason it does not lead to faults is x86 uses identity paging and the two functions simply return the address passed. I guessed there are several (many?) more places the two functions are misused. To hit those hidden issues I uncoupled 1:1 mapping so virt_to_phys() and phys_to_virt() would apply PAGE_OFFSET to addresses. It turned out masked faults indeed exist and they probably worth fixing. Another finding is memory mapped hardware should probably be reworked to use only MMIO accessors (readl, writel etc) to be consistent with other architectures. I wonder, if the issues described above are issues indeed and if it worth further efforts? Patches 1-4,7 bug and style fixes; Patches 5,6,8 draft reworks and fixes as result of patches 9,10; Patches 9,10 rework of virtual memory layout; Thanks! Cc: Radim Krčmář <rkrcmar@xxxxxxxxxx> Signed-off-by: Alexander Gordeev <agordeev@xxxxxxxxxx> Alexander Gordeev (10): x86: vm: Remove virt_to_phys() on CR3 initialization x86: vm: Remove install_pte() redundant argument x86: vm: Improve suboptimal large page allocation x86: Remove virt_to_phys_cr3() interface x86: Find ACPI tables using proper MMIO access x86: emulator: virt_to_phys() and phys_to_virt() misused x86: apic: Remove duplicate outb implementation x86: apic: Access registers using proper MMIO access x86: vm: Enable non-identity paging x86: vm: Redefine virtual memory layout lib/x86/acpi.c | 32 ++++++++++++----- lib/x86/apic.c | 13 ++++--- lib/x86/apic.h | 2 ++ lib/x86/asm/io.h | 12 ------- lib/x86/asm/page.h | 5 +++ lib/x86/vm.c | 103 ++++++++++++++++++++++++++++++++--------------------- lib/x86/vm.h | 4 +-- x86/asyncpf.c | 9 +++-- x86/emulator.c | 10 +++--- x86/eventinj.c | 6 ++-- x86/hypercall.c | 2 +- x86/rmap_chain.c | 2 +- x86/s3.c | 10 ++++-- x86/taskswitch2.c | 2 +- 14 files changed, 128 insertions(+), 84 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
