linux-kernel - [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support

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: <patchbomb.1220826072@localhost>
Date:	Sun, 07 Sep 2008 15:21:12 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Xen Devel <xen-devel@...ts.xensource.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support

Hi Ingo,

This series begins to lay the groundwork for Xen domain 0 support.
Domain 0 is much like a normal Xen domain, but it is also allowed to
have direct access to the underlying hardware (including both IO space
and various BIOS tables), so it can run device drivers, etc.  This
means that we need to be able to distinguish between a Xen domain's
normal pseudo-physical address space, and the real machine physical
address space.

This series:
 - Adds a new pte flag - _PAGE_IOMAP - used to indicate that a mapping
   is intended to map an IO device, and the physical address is
   actually a real machine physical address rather than a
   pseudo-physical address.  This is exposed as PAGE_KERNEL_IO and so
   on.  ioremap() and early_ioremap() are modified to set this flag,
   as they (should) always be used to map IO devices and not other
   memory.  By default __supported_pte_mask masks this flag out, so it
   won't end up in the final pagetable.  The Xen (and any other) code
   which cares about this flag unmask it from __supported_pte_mask.

 - Add early_memremap() to deal with the cases where early_ioremap()
   actually being used to map normal memory.

 - Remove a bogus check in x86-64's implementation of
   set_pte_vaddr_pud(), which prevents memory mappings from being
   updated.

 - Convert __acpi_map_table to use early_ioremap(), rather than have
   its own implementation.

 - Make __acpi_map_table always map the memory rather than assuming
   that the linear map maps some of the acpi tables.  This won't be
   true in the virtual case, and always mapping doesn't hurt in the
   native case.

I've tested these patches on both 32 and 64 native booting, and it all
works for me.

Thanks,
	J

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/