----- Forwarded message from Jeremy Fitzhardinge jeremy@goop.org -----
From: Jeremy Fitzhardinge jeremy@goop.org To: Ingo Molnar mingo@elte.hu Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" hpa@zytor.com, Xen Devel xen-devel@lists.xensource.com, Andi Kleen andi@firstfloor.org Date: Sun, 07 Sep 2008 15:21:12 -0700 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
On Mon, 8 Sep 2008, Pasi Kärkkäinen wrote:
Subject: [Fedora-xen] [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support
----- Forwarded message from Jeremy Fitzhardinge jeremy@goop.org -----
From: Jeremy Fitzhardinge jeremy@goop.org To: Ingo Molnar mingo@elte.hu Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" hpa@zytor.com, Xen Devel xen-devel@lists.xensource.com, Andi Kleen andi@firstfloor.org Date: Sun, 07 Sep 2008 15:21:12 -0700 Subject: [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support
Is anyone going to build kernel and/or xen rpms with these patches for testing?
Paul
On Mon, Sep 08, 2008 at 01:43:04PM -0400, Paul Wouters wrote:
On Mon, 8 Sep 2008, Pasi Kärkkäinen wrote:
Subject: [Fedora-xen] [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support
----- Forwarded message from Jeremy Fitzhardinge jeremy@goop.org -----
From: Jeremy Fitzhardinge jeremy@goop.org To: Ingo Molnar mingo@elte.hu Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" hpa@zytor.com, Xen Devel xen-devel@lists.xensource.com, Andi Kleen andi@firstfloor.org Date: Sun, 07 Sep 2008 15:21:12 -0700 Subject: [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support
Is anyone going to build kernel and/or xen rpms with these patches for testing?
No, because they don't provide a Dom0. The provide the *groundwork* on which Xen dom0 kernel patches will be laid. The plan for Dom0 will be to incorporate them in rawhide when they are merged in whatever LKML dev tree lines with with rawhide at that time. Jeremy's patches have been flowing into LKML tree pretty quickly in recent times, so if the patches are approved by upstream kernel devs, it shouldn't be too much of a time-lag before they make their work into rawhide
Daniel