GitHub/LineageOS/android_kernel_motorola_exynos9610.git
17 years ago[PATCH] i386: Don't delete cpu_devs data to identify different x86 types in late_initcall
Thomas Renninger [Wed, 2 May 2007 17:27:22 +0000 (19:27 +0200)]
[PATCH] i386: Don't delete cpu_devs data to identify different x86 types in late_initcall

In arch/i386/cpu/common.c there is:
cpu_devs[X86_VENDOR_INTEL]
cpu_devs[X86_VENDOR_CYRIX]
cpu_devs[X86_VENDOR_AMD]
...
They are all filled with data early.
The data (struct) got set to NULL  for all, but Intel in different
late_initcall (exit_cpu_vendor) calls.
I don't see what sense this makes at all, maybe something that got
forgotten with the HOTPLUG_CPU extenstions?

Please check/review whether initdata, cpuinitdata is still ok and this
still works with HOTPLUG_CPU and without, it should...

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: davej@redhat.com
17 years ago[PATCH] i386: type may be unused
David Rientjes [Wed, 2 May 2007 17:27:22 +0000 (19:27 +0200)]
[PATCH] i386: type may be unused

In the case of !CONFIG_PCI_DIRECT && !CONFIG_PCI_MMCONFIG, type is
unreferened.

Cc: Andi Kleen <ak@suse.de>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Some additional chipset register values validation.
Olivier Galibert [Wed, 2 May 2007 17:27:22 +0000 (19:27 +0200)]
[PATCH] i386: Some additional chipset register values validation.

On i945, a mmconfig range hitting the f0000000-ffffffff zone conflicts
with the APIC registers and others.  Consider it invalid.

On E7520, values 0000 and f000 for the window register are defined
invalid in the documentation.

I haven't seen a bios use these values, but who trusts biosen these
days?

Signed-off-by: Olivier Galibert <galibert@pobox.com>
Signed-off-by: Andi Kleen <ak@suse.de>
 arch/i386/pci/mmconfig-shared.c |   25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

17 years ago[PATCH] i386: Add missing !X86_PAE dependincy to the 2G/2G split.
Bill Irwin [Wed, 2 May 2007 17:27:22 +0000 (19:27 +0200)]
[PATCH] i386: Add missing !X86_PAE dependincy to the 2G/2G split.

Only 1GB-aligned kernel/user splits are now handled for PAE. The
2GB/2GB split attempts to avoid aliasing vmallocspace with the 1:1
mapping for physical memory by using an actual split of 1.875/2.125
to accommodate 128MB of vmallocspace out of what would otherwise
be a full 2GB for userspace. That attempt disturbs the alignment
required by PAE for 2GB/2GB splits, and furthermore does not provide
a 2GB/2GB split as advertised.

This patch resolves the issues here in two manners. The first is
by providing a true 2GB/2GB split in addition to the 1.875/2.125
split. The second is by renaming the 1.875/2.125 split to
CONFIG_VMSPLIT_2G_OPT analogously to CONFIG_VMSPLIT_3G_OPT, which
performs a similar manuever to avoid aliasing vmallocspace with
the 1:1 mapping for physical memory around the 3GB boundary. With
the 1.875/2.125 split properly-named, its config option is then
tagged as depending on !HIGHMEM to express the PAE implementation's
current inability to deal with such unaligned splits.

This patch is essentially a combination of two patches, one written
by Eric Biederman and the other by Eric Dumazet. If they could add
their Signed-off-by: to this, I'd be much obliged.

Signed-off-by: William Irwin <wli@holomorphy.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Mark Lord <lkml@rtr.ca>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Don't exclude asm-offsets.c in Documentation/dontdiff
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Don't exclude asm-offsets.c in Documentation/dontdiff

asm-offsets.c is valid source code and needs to be diffed.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: avoid redundant preempt_disable in __unlazy_fpu
Jan Kiszka [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] i386: avoid redundant preempt_disable in __unlazy_fpu

There are two callers of __unlazy_fpu, unlazy_fpu and __switch_to, and
none of them appear to require additional preempt_disable/enable here.
Let's open-code save_init_fpu in __unlazy_fpu to save a few ops.

Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: white space fixes in i387.h
Jan Kiszka [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] i386: white space fixes in i387.h

Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Drop noisy e820 debugging printks
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] i386: Drop noisy e820 debugging printks

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Fix allnoconfig error in genapic_flat.c
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Fix allnoconfig error in genapic_flat.c

Fix:

In file included from include2/asm/apic.h:5,
                 from include2/asm/smp.h:15,
                 from linux/arch/x86_64/kernel/genapic_flat.c:18:
linux/include/linux/pm.h: In function ‘call_platform_enable_wakeup’:
linux/include/linux/pm.h:331: error: ‘EIO’ undeclared (first use in this function)
linux/include/linux/pm.h:331: error: (Each undeclared identifier is reported only once
linux/include/linux/pm.h:331: error: for each function it appears in.)

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Shut up warnings for vfat compat ioctls on other file systems
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Shut up warnings for vfat compat ioctls on other file systems

vfat implements compat handlers for these ioctls, but when they
were executed on other file systems the kernel would still complain
about an unknown compat ioctl.  Just declare them as compatible
and let them be rejected when not needed by the normal path.

This makes wine runs a lot quieter

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Share identical video.S between i386 and x86-64
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Share identical video.S between i386 and x86-64

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Remove CONFIG_REORDER
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Remove CONFIG_REORDER

The option never worked well and functionlist wasn't well maintained.
Also it made the build very slow on many binutils version.

So just remove it.

Cc: arjan@linux.intel.com
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Print type and size correctly for unknown compat ioctls
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Print type and size correctly for unknown compat ioctls

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Remove copy_*_user BUG_ONs for (size < 0)
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] i386: Remove copy_*_user BUG_ONs for (size < 0)

access_ok checks this case anyways, no need to check twice.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Little cleanups in smpboot.c
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] i386: Little cleanups in smpboot.c

- Remove #if that is always set
- Fix warning

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Don't enable NUMA for a single node in K8 NUMA scanning
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86-64: Don't enable NUMA for a single node in K8 NUMA scanning

This was supposed to see the full memory on a ASUS A8SX motherboard
with 4GB RAM where the northbridge reports less memory, but it didn't
help there. But it's a reasonable change so let's include it anyways.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86: Use RDTSCP for synchronous get_cycles if possible
Andi Kleen [Wed, 2 May 2007 17:27:21 +0000 (19:27 +0200)]
[PATCH] x86: Use RDTSCP for synchronous get_cycles if possible

RDTSCP is already synchronous and doesn't need an explicit CPUID.
This is a little faster and more importantly avoids VMEXITs on Hypervisors.

Original patch from Joerg Roedel, but reworked by AK
Also includes miscompilation fix by Eric Biederman

Cc: "Joerg Roedel" <joerg.roedel@amd.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Add X86_FEATURE_RDTSCP
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Add X86_FEATURE_RDTSCP

Following x86-64
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Implement X86_FEATURE_SYNC_RDTSC on i386
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Implement X86_FEATURE_SYNC_RDTSC on i386

Syncs up with x86-64.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Implement alternative_io for i386
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Implement alternative_io for i386

Ported from x86-64.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Evaluate constant cpu features at runtime
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Evaluate constant cpu features at runtime

Redefine cpu_has() to evaluate cpu features already checked in early
boot at compile time.  This way the compiler might eliminate some dead code.
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Verify important CPUID bits in real mode
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Verify important CPUID bits in real mode

Check some CPUID bits that are needed for compiler generated early in boot.
When the system is still in real mode before changing the VESA BIOS mode
it is possible to still display an visible error message on the screen.

Similar to x86-64.

Includes cleanups from Eric Biederman

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Drop -traditional in arch/i386/boot
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Drop -traditional in arch/i386/boot

Needed for followon patch

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Drop -traditional for arch/x86_64/boot
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: Drop -traditional for arch/x86_64/boot

Follows i386 and useful cleanup.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Use symbolic CPU features in early CPUID check
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: Use symbolic CPU features in early CPUID check

Dead to magic numbers!

Generated code is the same.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Avoid overflows during apic timer calibration
David P. Reed [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: Avoid overflows during apic timer calibration

- Use 64bit TSC calculations to avoid handling overflow
- Use 32bit unsigned arithmetic for the APIC timer. This
way overflows are handled correctly.
- Fix exit check of loop to account for apic timer counting down

Signed-off-by: dpreed@reed.com
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Shut up 32bit emulation for SIOCGIFCOUNT
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: Shut up 32bit emulation for SIOCGIFCOUNT

The kernel doesn't implement it, but some programs like java use it
anyways. Shut the code up.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Define IGNORE_IOCTL() macro for compat_ioctls
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: Define IGNORE_IOCTL() macro for compat_ioctls

Define a new IGNORE_IOCTL() to let a compat ioctl not be warned about even when
it is not implemented.

This is the same as COMPATIBLE_IOCTL internally, but better self documentng.

Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs
  call it on others too.
- The ioctl is not implemented in the native kernel, but programs
  call it commonly anyways.
Most other reasons are not valid.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: Use the 32bit wd_ops for 64bit too.
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: Use the 32bit wd_ops for 64bit too.

This mainly removes a lot of code, replacing it with calls into the new 32bit
perfctr-watchdog.c

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Clean up NMI watchdog code
Andi Kleen [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] i386: Clean up NMI watchdog code

- Introduce a wd_ops structure
- Convert the various nmi watchdogs over to it
- This allows to split the perfctr reservation from the watchdog
setup cleanly.
- Do perfctr reservation globally as it should have always been
- Remove dead code referenced only by unused EXPORT_SYMBOLs

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: set node_possible_map at runtime - try 2
Suresh Siddha [Wed, 2 May 2007 17:27:20 +0000 (19:27 +0200)]
[PATCH] x86-64: set node_possible_map at runtime - try 2

Set the node_possible_map at runtime on x86_64.  On a non NUMA system,
num_possible_nodes() will now say '1'.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@engr.sgi.com>
17 years ago[PATCH] x86-64: Dynamically adjust machine check interval
Tim Hockin [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] x86-64: Dynamically adjust machine check interval

Background:
 We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
 especially when we are trying really hard to stress the system out.  The
 current MCE poller uses a static interval which does not care whether it
 has or has not found MCEs recently.

Description:
 This patch makes the MCE poller adjust the polling interval dynamically.
 If we find an MCE, poll 2x faster (down to 10 ms).  When we stop finding
 MCEs, poll 2x slower (up to check_interval seconds).  The check_interval
 tunable becomes the max polling interval.  The "Machine check events
 logged" printk() is rate limited to the check_interval, which should be
 identical behavior to the old functionality.

Result:
 If you start to take a lot of correctable errors (not exceptions), you
 log them faster and more accurately (less chance of overflowing the MCA
 registers).  If you don't take a lot of errors, you will see no change.

Alternatives:
 I considered simply reducing the polling interval to 10 ms immediately
 and keeping it there as long as we continue to find errors.  This felt a
 bit heavy handed, but does perform significantly better for the default
 check_interval of 5 minutes (we're using a few seconds when testing for
 DRAM errors).  I could be convinced to go with this, if anyone felt it
 was not too aggressive.

Testing:
 I used an error-injecting DIMM to create lots of correctable DRAM errors
 and verified that the polling interval accelerates.  The printk() only
 happens once per check_interval seconds.

Patch:
 This patch is against 2.6.21-rc7.

Signed-Off-By: Tim Hockin <thockin@google.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: ignore vgacon if hardware not present
Gerd Hoffmann [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] x86-64: ignore vgacon if hardware not present

Avoid trying to set up vgacon if there's no vga hardware present.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Alan <alan@lxorguk.ukuu.org.uk>
Acked-by: Ingo Molnar <mingo@elte.hu>
17 years ago[PATCH] i386: fix wrong comment for syscall stack layout
Andi Kleen [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] i386: fix wrong comment for syscall stack layout

`ret_from_sys_call' label no longer exist and `syscall_exit' label was
introduced instead.

Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: unexport cpu_llc_id
Andrew Morton [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] x86-64: unexport cpu_llc_id

WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:cpu_llc_id from __ksymtab between '__ksymtab_cpu_llc_id' (at offset 0x4a0) and '__ksymtab_smp_num_siblings'

It is strange to export a __cpuinitdata symbols to modules, and no module
appears to use it anyway.

Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: convert to the kthread API
Eric W. Biederman [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] i386: convert to the kthread API

This patch just trivial converts from calling kernel_thread and daemonize
to just calling kthread_run.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: pte simplify ops
Zachary Amsden [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] i386: pte simplify ops

Add comment and condense code to make use of native_local_ptep_get_and_clear
function.  Also, it turns out the 2-level and 3-level paging definitions were
identical, so move the common definition into pgtable.h

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: pte xchg optimization
Zachary Amsden [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] i386: pte xchg optimization

In situations where page table updates need only be made locally, and there is
no cross-processor A/D bit races involved, we need not use the heavyweight
xchg instruction to atomically fetch and clear page table entries.  Instead,
we can just read and clear them directly.

This introduces a neat optimization for non-SMP kernels; drop the atomic xchg
operations from page table updates.

Thanks to Michel Lespinasse for noting this potential optimization.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: pte clear optimization
Zachary Amsden [Wed, 2 May 2007 17:27:19 +0000 (19:27 +0200)]
[PATCH] i386: pte clear optimization

When exiting from an address space, no special hypervisor notification of page
table updates needs to occur; direct page table hypervisors, such as Xen,
switch to another address space first (init_mm) and unprotects the page tables
to avoid the cost of trapping to the hypervisor for each pte_clear.  Shadow
mode hypervisors, such as VMI and lhype don't need to do the extra work of
calling through paravirt-ops, and can just directly clear the page table
entries without notifiying the hypervisor, since all the page tables are about
to be freed.

So introduce native_pte_clear functions which bypass any paravirt-ops
notification.  This results in a significant performance win for VMI and
removes some indirect calls from zap_pte_range.

Note the 3-level paging already had a native_pte_clear function, thus
demanding argument conformance and extra args for the 2-level definition.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: remove xtime_lock'ing around cpufreq notifier
Daniel Walker [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: remove xtime_lock'ing around cpufreq notifier

The locking of the xtime_lock around the cpu notifier is unessesary now.
At one time the tsc was used after a frequency change for timekeeping, but
the re-write of timekeeping no longer uses the TSC unless the frequency is
constant.

The variables that are changed in this section of code had also once been
used for timekeeping, but not any longer ..

Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: john stultz <johnstul@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] x86-64: skip cache_free_alien() on non NUMA
Siddha, Suresh B [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] x86-64: skip cache_free_alien() on non NUMA

Set use_alien_caches to 0 on non NUMA platforms.  And avoid calling the
cache_free_alien() when use_alien_caches is not set.  This will avoid the
cache miss that happens while dereferencing slabp to get nodeid.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <clameter@engr.sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] x86-64: Auto compute __NR_syscall_max at compile time
Andi Kleen [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] x86-64: Auto compute __NR_syscall_max at compile time

No need to maintain it anymore

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: check capability
Joachim Deguara [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: check capability

Currently the i386 architecture checks the family for mce capability and this
removes that and uses the CPUID information.  Tested on a K8 revE and a
family10h processor.

This eliminates checking of a set AMD procesor family if mce is
allowed and relies on the information being in CPUID.

Signed-off-by: Joachim Deguara <joachim.deguara@amd.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: clean up flush_tlb_others fn
Keshavamurthy, Anil S [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: clean up flush_tlb_others fn

Cleanup flush_tlb_others(), no functional change.

Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: replace spin_lock_irqsave with spin_lock
Hisashi Hifumi [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: replace spin_lock_irqsave with spin_lock

IRQ is already disabled through local_irq_disable().  So
spin_lock_irqsave() can be replaced with spin_lock().

Signed-off-by: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: avoid checking for cpu gone when CONFIG_HOTPLUG_CPU not defined
Keshavamurthy, Anil S [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: avoid checking for cpu gone when CONFIG_HOTPLUG_CPU not defined

Avoid checking for cpu gone in mm hot path when CONFIG_HOTPLUG_CPU is not
defined.

Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Cc: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] x86-64: move __vgetcpu_mode & __jiffies to the vsyscall_2 zone
Eric Dumazet [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] x86-64: move __vgetcpu_mode & __jiffies to the vsyscall_2 zone

We apparently hit the 1024 limit of vsyscall_0 zone when some debugging
options are set, or if __vsyscall_gtod_data is 64 bytes larger.

In order to save 128 bytes from the vsyscall_0 zone, we move __vgetcpu_mode
& __jiffies to vsyscall_2 zone where they really belong, since they are
used only from vgetcpu() (which is in this vsyscall_2 area).

After patch is applied, new layout is :

ffffffffff600000 T vgettimeofday
ffffffffff60004e t vsysc2
ffffffffff600140 t vread_hpet
ffffffffff600150 t vread_tsc
ffffffffff600180 D __vsyscall_gtod_data
ffffffffff600400 T vtime
ffffffffff600413 t vsysc1
ffffffffff600800 T vgetcpu
ffffffffff600870 D __vgetcpu_mode
ffffffffff600880 D __jiffies
ffffffffff600c00 T venosys_1

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: PARAVIRT: fix startup_ipi_hook config dependency
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: fix startup_ipi_hook config dependency

startup_ipi_hook depends on CONFIG_X86_LOCAL_APIC, so move it to the
right part of the paravirt_ops initialization.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: fix mtrr sections
Randy Dunlap [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: fix mtrr sections

Fix section mismatch warnings in mtrr code.
Fix line length on one source line.

WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103)
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x180)
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x199)
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x1c1)

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] x86-64: Use safe_apic_wait_icr_idle in __send_IPI_dest_field - x86_64
Fernando Luis [** ISO-8859-1 charset **] VázquezCao [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] x86-64: Use safe_apic_wait_icr_idle in __send_IPI_dest_field - x86_64

Use safe_apic_wait_icr_idle to check ICR idle bit if the vector is
NMI_VECTOR to avoid potential hangups in the event of crash when kdump
tries to stop the other CPUs.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Use safe_apic_wait_icr_idle in safe_apic_wait_icr_idle - i386
Fernando Luis [** ISO-8859-1 charset **] VázquezCao [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: Use safe_apic_wait_icr_idle in safe_apic_wait_icr_idle - i386

Use safe_apic_wait_icr_idle to check ICR idle bit if the vector is
NMI_VECTOR to avoid potential hangups in the event of crash when kdump
tries to stop the other CPUs.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: __send_IPI_dest_field - x86_64
Fernando Luis [** ISO-8859-1 charset **] VázquezCao [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] x86-64: __send_IPI_dest_field - x86_64

Implement __send_IPI_dest_field which can be used to send IPIs when the
"destination shorthand" field of the ICR is set to 00 (destination
field). Use it whenever possible.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: __send_IPI_dest_field - i386
Fernando Luis [** ISO-8859-1 charset **] VázquezCao [Wed, 2 May 2007 17:27:18 +0000 (19:27 +0200)]
[PATCH] i386: __send_IPI_dest_field - i386

Implement __send_IPI_dest_field which can be used to send IPIs when the
"destination shorthand" field of the ICR is set to 00 (destination
field). Use it whenever possible.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: use safe_apic_wait_icr_idle in smpboot.c - x86_64
Fernando Luis VazquezCao [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86-64: use safe_apic_wait_icr_idle in smpboot.c - x86_64

inquire_remote_apic is used for APIC debugging, so use
safe_apic_wait_icr_idle  instead of apic_wait_icr_idle to avoid possible
lockups when APIC delivery fails.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: use safe_apic_wait_icr_idle in smpboot.c
Fernando Luis VazquezCao [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] i386: use safe_apic_wait_icr_idle in smpboot.c

__inquire_remote_apic is used for APIC debugging, so use
safe_apic_wait_icr_idle  instead of apic_wait_icr_idle to avoid possible
lockups when APIC delivery fails.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: use safe_apic_wait_icr_idle in smpboot.c - x86_64
Fernando Luis VazquezCao [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86-64: use safe_apic_wait_icr_idle in smpboot.c - x86_64

The functionality provided by the new safe_apic_wait_icr_idle is being
open-coded all over "kernel/smpboot.c". Use safe_apic_wait_icr_idle
instead to consolidate code and ease maintenance.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: use safe_apic_wait_icr_idle - i386
Fernando Luis VazquezCao [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] i386: use safe_apic_wait_icr_idle - i386

The functionality provided by the new safe_apic_wait_icr_idle is being
open-coded all over "kernel/smpboot.c". Use safe_apic_wait_icr_idle
instead to consolidate code and ease maintenance.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86-64: safe_apic_wait_icr_idle - x86_64
Fernando Luis VazquezCao [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86-64: safe_apic_wait_icr_idle - x86_64

apic_wait_icr_idle looks like this:

static __inline__ void apic_wait_icr_idle(void)
{
  while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
    cpu_relax();
}

The busy loop in this function would not be problematic if the
corresponding status bit in the ICR were always updated, but that does
not seem to be the case under certain crash scenarios. Kdump uses an IPI
to stop the other CPUs in the event of a crash, but when any of the
other CPUs are locked-up inside the NMI handler the CPU that sends the
IPI will end up looping forever in the ICR check, effectively
hard-locking the whole system.

Quoting from Intel's "MultiProcessor Specification" (Version 1.4), B-3:

"A local APIC unit indicates successful dispatch of an IPI by
resetting the Delivery Status bit in the Interrupt Command
Register (ICR). The operating system polls the delivery status
bit after sending an INIT or STARTUP IPI until the command has
been dispatched.

A period of 20 microseconds should be sufficient for IPI dispatch
to complete under normal operating conditions. If the IPI is not
successfully dispatched, the operating system can abort the
command. Alternatively, the operating system can retry the IPI by
writing the lower 32-bit double word of the ICR. This “time-out”
mechanism can be implemented through an external interrupt, if
interrupts are enabled on the processor, or through execution of
an instruction or time-stamp counter spin loop."

Intel's documentation suggests the implementation of a time-out
mechanism, which, by the way, is already being open-coded in some parts
of the kernel that tinker with ICR.

Create a apic_wait_icr_idle replacement that implements the time-out
mechanism and that can be used to solve the aforementioned problem.

AK: moved both functions out of line
AK: Added improved loop from Keith Owens

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: safe_apic_wait_icr_idle - i386
Fernando Luis VazquezCao [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] i386: safe_apic_wait_icr_idle - i386

apic_wait_icr_idle looks like this:

static __inline__ void apic_wait_icr_idle(void)
{
  while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
    cpu_relax();
}

The busy loop in this function would not be problematic if the
corresponding status bit in the ICR were always updated, but that does
not seem to be the case under certain crash scenarios. Kdump uses an IPI
to stop the other CPUs in the event of a crash, but when any of the
other CPUs are locked-up inside the NMI handler the CPU that sends the
IPI will end up looping forever in the ICR check, effectively
hard-locking the whole system.

Quoting from Intel's "MultiProcessor Specification" (Version 1.4), B-3:

"A local APIC unit indicates successful dispatch of an IPI by
resetting the Delivery Status bit in the Interrupt Command
Register (ICR). The operating system polls the delivery status
bit after sending an INIT or STARTUP IPI until the command has
been dispatched.

A period of 20 microseconds should be sufficient for IPI dispatch
to complete under normal operating conditions. If the IPI is not
successfully dispatched, the operating system can abort the
command. Alternatively, the operating system can retry the IPI by
writing the lower 32-bit double word of the ICR. This “time-out”
mechanism can be implemented through an external interrupt, if
interrupts are enabled on the processor, or through execution of
an instruction or time-stamp counter spin loop."

Intel's documentation suggests the implementation of a time-out
mechanism, which, by the way, is already being open-coded in some parts
of the kernel that tinker with ICR.

Create a apic_wait_icr_idle replacement that implements the time-out
mechanism and that can be used to solve the aforementioned problem.

AK: moved both functions out of line
AK: added improved loop from Keith Owens

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Enable support for fixed-range IORRs to keep RdMem & WrMem in sync
Bernhard Kaindl [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] i386: Enable support for fixed-range IORRs to keep RdMem & WrMem in sync

If our copy of the MTRRs of the BSP has RdMem or WrMem set, and
we are running on an AMD64/K8 system, the boot CPU must have had
MtrrFixDramEn and MtrrFixDramModEn set (otherwise our RDMSR would
have copied these bits cleared), so we set them on this CPU as well.

This allows us to keep the AMD64/K8 RdMem and WrMem bits in sync
across the CPUs of SMP systems in order to fullfill the duty of
system software to "initialize and maintain MTRR consistency
across all processors." as written in the AMD and Intel manuals.

If an WRMSR instruction fails because MtrrFixDramModEn is not
set, I expect that also the Intel-style MTRR bits are not updated.

AK: minor cleanup, moved MSR defines around

Signed-off-by: Bernhard Kaindl <bk@suse.de>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Dave Jones <davej@codemonkey.org.uk>
17 years ago[PATCH] x86: Save and restore the fixed-range MTRRs of the BSP when suspending
Bernhard Kaindl [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86: Save and restore the fixed-range MTRRs of the BSP when suspending

Note: This patch didn'nt need an update since it's initial post.

Some BIOSes may modify fixed-range MTRRs in SMM, e.g. when they
transition the system into ACPI mode, which is entered thru an SMI,
triggered by Linux in acpi_enable().

SMIs which cause that Linux is interrupted and BIOS code is
executed (which may change e.g. fixed-range MTRRs) in SMM may
be raised by an embedded system controller which is often found
in notebooks also at other occasions.

If we would not update our copy of the fixed-range MTRRs before
suspending to RAM or to disk, restore_processor_state() would
set the fixed-range MTRRs of the BSP using old backup values
which may be outdated and this could cause the system to fail
later during resume.

This patch ensures that our copy of the fixed-range MTRRs
is updated when saving the boot processor state on suspend
to disk and suspend to RAM.

In combination with other patches this allows to fix s2ram
and s2disk on the Acer Ferrari 1000 notebook and at least
s2disk on the Acer Ferrari 5000 notebook.

Signed-off-by: Bernhard Kaindl <bk@suse.de>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Dave Jones <davej@codemonkey.org.uk>
17 years ago[PATCH] x86: Save the MTRRs of the BSP before booting an AP
Bernhard Kaindl [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86: Save the MTRRs of the BSP before booting an AP

Applied fix by Andew Morton:
http://lkml.org/lkml/2007/4/8/88 - Fix `make headers_check'.

AMD and Intel x86 CPU manuals state that it is the responsibility of
system software to initialize and maintain MTRR consistency across
all processors in Multi-Processing Environments.

Quote from page 188 of the AMD64 System Programming manual (Volume 2):

7.6.5 MTRRs in Multi-Processing Environments

"In multi-processing environments, the MTRRs located in all processors must
characterize memory in the same way. Generally, this means that identical
values are written to the MTRRs used by the processors." (short omission here)
"Failure to do so may result in coherency violations or loss of atomicity.
Processor implementations do not check the MTRR settings in other processors
to ensure consistency. It is the responsibility of system software to
initialize and maintain MTRR consistency across all processors."

Current Linux MTRR code already implements the above in the case that the
BIOS does not properly initialize MTRRs on the secondary processors,
but the case where the fixed-range MTRRs of the boot processor are changed
after Linux started to boot, before the initialsation of a secondary
processor, is not handled yet.

In this case, secondary processors are currently initialized by Linux
with MTRRs which the boot processor had very early, when mtrr_bp_init()
did run, but not with the MTRRs which the boot processor uses at the
time when that secondary processors is actually booted,
causing differing MTRR contents on the secondary processors.

Such situation happens on Acer Ferrari 1000 and 5000 notebooks where the
BIOS enables and sets AMD-specific IORR bits in the fixed-range MTRRs
of the boot processor when it transitions the system into ACPI mode.
The SMI handler of the BIOS does this in SMM, entered while Linux ACPI
code runs acpi_enable().

Other occasions where the SMI handler of the BIOS may change bits in
the MTRRs could occur as well. To initialize newly booted secodary
processors with the fixed-range MTRRs which the boot processor uses
at that time, this patch saves the fixed-range MTRRs of the boot
processor before new secondary processors are started. When the
secondary processors run their Linux initialisation code, their
fixed-range MTRRs will be updated with the saved fixed-range MTRRs.

If CONFIG_MTRR is not set, we define mtrr_save_state
as an empty statement because there is nothing to do.

Possible TODOs:

*) CPU-hotplugging outside of SMP suspend/resume is not yet tested
   with this patch.

*) If, even in this case, an AP never runs i386/do_boot_cpu or x86_64/cpu_up,
   then the calls to mtrr_save_state() could be replaced by calls to
   mtrr_save_fixed_ranges(NULL) and  mtrr_save_state() would not be
   needed.

   That would need either verification of the CPU-hotplug code or
   at least a test on a >2 CPU machine.

*) The MTRRs of other running processors are not yet checked at this
   time but it might be interesting to syncronize the MTTRs of all
   processors before booting. That would be an incremental patch,
   but of rather low priority since there is no machine known so
   far which would require this.

AK: moved prototypes on x86-64 around to fix warnings

Signed-off-by: Bernhard Kaindl <bk@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Cc: Dave Jones <davej@codemonkey.org.uk>
17 years ago[PATCH] x86: Adds mtrr_save_fixed_ranges() for use in two later patches.
Bernhard Kaindl [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86: Adds mtrr_save_fixed_ranges() for use in two later patches.

In this current implementation which is used in other patches,
mtrr_save_fixed_ranges() accepts a dummy void pointer because
in the current implementation of one of these patches, this
function may be called from smp_call_function_single() which
requires that this function takes a void pointer argument.

This function calls get_fixed_ranges(), passing mtrr_state.fixed_ranges
which is the element of the static struct which stores our current
backup of the fixed-range MTRR values which all CPUs shall be
using.

Because  mtrr_save_fixed_ranges calls get_fixed_ranges after
kernel initialisation time, __init needs to be removed from
the declaration of get_fixed_ranges().

If CONFIG_MTRR is not set, we define mtrr_save_fixed_ranges
as an empty statement because there is nothing to do.

AK: Moved prototypes for x86-64 around to fix warnings

Signed-off-by: Bernhard Kaindl <bk@suse.de>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Dave Jones <davej@codemonkey.org.uk>
17 years ago[PATCH] x86-64: Move mtrr prototypes from proto.h to mtrr.h
Andi Kleen [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] x86-64: Move mtrr prototypes from proto.h to mtrr.h

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Clean up ELF note generation
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] i386: Clean up ELF note generation

Three cleanups:

1: ELF notes are never mapped, so there's no need to have any access
flags in their phdr.

2: When generating them from asm, tell the assembler to use a SHT_NOTE
section type.  There doesn't seem to be a way to do this from C.

3: Use ANSI rather than traditional cpp behaviour to stringify the
macro argument.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
17 years ago[PATCH] i386: PARAVIRT: Export paravirt_ops for non GPL modules too
Andi Kleen [Wed, 2 May 2007 17:27:17 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Export paravirt_ops for non GPL modules too

Otherwise non GPL modules cannot even do basic operations
like disabling interrupts anymore, which would be excessive.

Longer term should split the single structure up into
internal and external symbols and not export the internal
ones at all.

Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86: PARAVIRT: Jeremy Fitzhardinge <jeremy@goop.org>
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] x86: PARAVIRT: Jeremy Fitzhardinge <jeremy@goop.org>

The other symbols used to delineate the alt-instructions sections have the
form __foo/__foo_end.  Rename parainstructions to match.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: Convert VMI timer to use clock events
Zachary Amsden [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Convert VMI timer to use clock events

Convert VMI timer to use clock events, making it properly able to use the NO_HZ
infrastructure.  On UP systems, with no local APIC, we just continue to route
these events through the PIT.  On systems with a local APIC, or SMP, we provide
a single source interrupt chip which creates the local timer IRQ.  It actually
gets delivered by the APIC hardware, but we don't want to use the same local
APIC clocksource processing, so we create our own handler here.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
CC: Dan Hecht <dhecht@vmware.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: Thomas Gleixner <tglx@linutronix.de>
17 years ago[PATCH] i386: Implement vmi_kmap_atomic_pte
Zachary Amsden [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Implement vmi_kmap_atomic_pte

Implement vmi_kmap_atomic_pte in terms of the backend set_linear_mapping
operation.  The conversion is rather straighforward; call kmap_atomic
and then inform the hypervisor of the page mapping.

The _flush_tlb damage is due to macros being pulled in from highmem.h.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Now that the VDSO can be relocated, we can support it in VMI configurat...
Zachary Amsden [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Now that the VDSO can be relocated, we can support it in VMI configurations.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Clean up arch/i386/kernel/cpu/mcheck/p4.c
Zachary Amsden [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Clean up arch/i386/kernel/cpu/mcheck/p4.c

No, just no.  You do not use goto to skip a code block.  You do not
return an obvious variable from a singly-inlined function and give
the function a return value.  You don't put unexplained comments
about kmalloc in code which doesn't do dynamic allocation.  And
you don't leave stray warnings around for no good reason.

Also, when possible, it is better to use block scoped variables
because gcc can sometime generate better code.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: PARAVIRT: Allow boot-time disable of paravirt_ops patching
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Allow boot-time disable of paravirt_ops patching

Add "noreplace-paravirt" to disable paravirt_ops patching.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: In compat mode, the return value here was uninitialized.
Zachary Amsden [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: In compat mode, the return value here was uninitialized.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86: update for i386 and x86-64 check_bugs
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] x86: update for i386 and x86-64 check_bugs

Remove spurious comments, headers and keywords from x86-64 bugs.[ch].

Use identify_boot_cpu()

AK: merged with other patch

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: map enough initial memory to create lowmem mappings
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: map enough initial memory to create lowmem mappings

head.S creates the very initial pagetable for the kernel.  This just
maps enough space for the kernel itself, and an allocation bitmap.
The amount of mapped memory is rounded up to 4Mbytes, and so this
typically ends up mapping 8Mbytes of memory.

When booting, pagetable_init() needs to create mappings for all
lowmem, and the pagetables for these mappings are allocated from the
free pages around the kernel in low memory.  If the number of
pagetable pages + kernel size exceeds head.S's initial mapping, it
will end up faulting on an unmapped page.  This will only happen with
specific combinations of kernel size and memory size.

This patch makes sure that head.S also maps enough space to fit the
kernel pagetables as well as the kernel itself.  It ends up using an
additional two pages of unreclaimable memory.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Zachary Amsden <zach@vmware.com>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
17 years ago[PATCH] i386: Fix UP gdt bugs
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Fix UP gdt bugs

Fixes two problems with the GDT when compiling for uniprocessor:
 - There's no percpu segment, so trying to load its selector into %fs fails.
   Use a null selector instead.
 - The real gdt needs to be loaded at some point.  Do it in cpu_init().

Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
17 years ago[PATCH] i386: Define per_cpu_offset
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Define per_cpu_offset

Define per_cpu_offset in asm-i386/percpu.h when SMP defined, like
asm-generic/percpu.h does for UP.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: cleanups to help using per-cpu variables from asm
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: cleanups to help using per-cpu variables from asm

This patch does a few small cleanups:
 - use PER_CPU_NAME to generate the names of per-cpu variables
 - use lea to add the per_cpu offset in PER_CPU(), because it doesn't
   affect condition flags
 - add PER_CPU_VAR which allows direct access to pre-cpu variables
   with the %fs: prefix on SMP.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Convert PDA into the percpu section
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:16 +0000 (19:27 +0200)]
[PATCH] i386: Convert PDA into the percpu section

Currently x86 (similar to x84-64) has a special per-cpu structure
called "i386_pda" which can be easily and efficiently referenced via
the %fs register.  An ELF section is more flexible than a structure,
allowing any piece of code to use this area.  Indeed, such a section
already exists: the per-cpu area.

So this patch:
(1) Removes the PDA and uses per-cpu variables for each current member.
(2) Replaces the __KERNEL_PDA segment with __KERNEL_PERCPU.
(3) Creates a per-cpu mirror of __per_cpu_offset called this_cpu_off, which
    can be used to calculate addresses for this CPU's variables.
(4) Simplifies startup, because %fs doesn't need to be loaded with a
    special segment at early boot; it can be deferred until the first
    percpu area is allocated (or never for UP).

The result is less code and one less x86-specific concept.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: Page-align the GDT
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: Page-align the GDT

Xen wants a dedicated page for the GDT.  I believe VMI likes it too.
lguest, KVM and native don't care.

Simple transformation to page-aligned "struct gdt_page".

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Jeremy Fitzhardinge <jeremy@xensource.com>
17 years ago[PATCH] x86-64: deflate inflate_dynamic too
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] x86-64: deflate inflate_dynamic too

inflate_dynamic() has piggy stack usage too, so heap allocate it too.
I'm not sure it actually gets used, but it shows up large in "make
checkstack".

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] x86: deflate stack usage in lib/inflate.c
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] x86: deflate stack usage in lib/inflate.c

inflate_fixed and huft_build together use around 2.7k of stack.  When
using 4k stacks, I saw stack overflows from interrupts arriving while
unpacking the root initrd:

do_IRQ: stack overflow: 384
 [<c0106b64>] show_trace_log_lvl+0x1a/0x30
 [<c01075e6>] show_trace+0x12/0x14
 [<c010763f>] dump_stack+0x16/0x18
 [<c0107ca4>] do_IRQ+0x6d/0xd9
 [<c010202b>] xen_evtchn_do_upcall+0x6e/0xa2
 [<c0106781>] xen_hypervisor_callback+0x25/0x2c
 [<c010116c>] xen_restore_fl+0x27/0x29
 [<c0330f63>] _spin_unlock_irqrestore+0x4a/0x50
 [<c0117aab>] change_page_attr+0x577/0x584
 [<c0117b45>] kernel_map_pages+0x8d/0xb4
 [<c016a314>] cache_alloc_refill+0x53f/0x632
 [<c016a6c2>] __kmalloc+0xc1/0x10d
 [<c0463d34>] malloc+0x10/0x12
 [<c04641c1>] huft_build+0x2a7/0x5fa
 [<c04645a5>] inflate_fixed+0x91/0x136
 [<c04657e2>] unpack_to_rootfs+0x5f2/0x8c1
 [<c0465acf>] populate_rootfs+0x1e/0xe4

(This was under Xen, but there's no reason it couldn't happen on bare
  hardware.)

This patch mallocs the local variables, thereby reducing the stack
usage to sane levels.

Also, up the heap size for the kernel decompressor to deal with the
extra allocation.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Tim Yamin <plasmaroo@gentoo.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ian Molton <spyro@f2s.com>
17 years ago[PATCH] i386: PARAVIRT: drop unused ptep_get_and_clear
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: drop unused ptep_get_and_clear

In shadow mode hypervisors, ptep_get_and_clear achieves the desired
purpose of keeping the shadows in sync by issuing a native_get_and_clear,
followed by a call to pte_update, which indicates the PTE has been
modified.

Direct mode hypervisors (Xen) have no need for this anyway, and will trap
the update using writable pagetables.

This means no hypervisor makes use of ptep_get_and_clear; there is no
reason to have it in the paravirt-ops structure.  Change confusing
terminology about raw vs. native functions into consistent use of
native_pte_xxx for operations which do not invoke paravirt-ops.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: PARAVIRT: Clean up paravirt patchable wrappers
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Clean up paravirt patchable wrappers

Replace all the open-coded macros for generating calls with a pair of
more general macros (__PVOP_CALL/VCALL), and redefine all the
PVOP_V?CALL[0-4] in terms of them.

[ Andrew, Andi: this should slot in immediately after "Document asm-i386/paravirt.h"
  (paravirt_ops-document-asm-i386-paravirth.patch) ]

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
17 years ago[PATCH] i386: PARAVIRT: Use enums for paravirt lazy flush modi
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Use enums for paravirt lazy flush modi

Remove #defines, add enum for PARAVIRT_LAZY_FLUSH.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: PARAVIRT: flush lazy mmu updates on kunmap_atomic
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: flush lazy mmu updates on kunmap_atomic

kunmap_atomic should flush any pending lazy mmu updates, mainly to be
consistent with kmap_atomic, and to preserve its normal behaviour.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: PARAVIRT: add kmap_atomic_pte for mapping highpte pages
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: add kmap_atomic_pte for mapping highpte pages

Xen and VMI both have special requirements when mapping a highmem pte
page into the kernel address space.  These can be dealt with by adding
a new kmap_atomic_pte() function for mapping highptes, and hooking it
into the paravirt_ops infrastructure.

Xen specifically wants to map the pte page RO, so this patch exposes a
helper function, kmap_atomic_prot, which maps the page with the
specified page protections.

This also adds a kmap_flush_unused() function to clear out the cached
kmap mappings.  Xen needs this to clear out any potential stray RW
mappings of pages which will become part of a pagetable.

[ Zach - vmi.c will need some attention after this patch.  It wasn't
  immediately obvious to me what needs to be done. ]

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Zachary Amsden <zach@vmware.com>
17 years ago[PATCH] i386: PARAVIRT: revert map_pt_hook.
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: revert map_pt_hook.

Back out the map_pt_hook to clear the way for kmap_atomic_pte.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Zachary Amsden <zach@vmware.com>
17 years ago[PATCH] i386: PARAVIRT: add flush_tlb_others paravirt_op
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:15 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: add flush_tlb_others paravirt_op

This patch adds a pv_op for flush_tlb_others.  Linux running on native
hardware uses cross-CPU IPIs to flush the TLB on any CPU which may
have a particular mm's pagetable entries cached in its TLB.  This is
inefficient in a paravirtualized environment, since the hypervisor
knows which real CPUs actually contain cached mappings, which may be a
small subset of a guest's VCPUs.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
17 years ago[PATCH] i386: PARAVIRT: add common patching machinery
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: add common patching machinery

Implement the actual patching machinery.  paravirt_patch_default()
contains the logic to automatically patch a callsite based on a few
simple rules:

 - if the paravirt_op function is paravirt_nop, then patch nops
 - if the paravirt_op function is a jmp target, then jmp to it
 - if the paravirt_op function is callable and doesn't clobber too much
    for the callsite, call it directly

paravirt_patch_default is suitable as a default implementation of
paravirt_ops.patch, will remove most of the expensive indirect calls
in favour of either a direct call or a pile of nops.

Backends may implement their own patcher, however.  There are several
helper functions to help with this:

paravirt_patch_nop nop out a callsite
paravirt_patch_ignore leave the callsite as-is
paravirt_patch_call patch a call if the caller and callee
have compatible clobbers
paravirt_patch_jmp patch in a jmp
paravirt_patch_insns patch some literal instructions over
the callsite, if they fit

This patch also implements more direct patches for the native case, so
that when running on native hardware many common operations are
implemented inline.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Zachary Amsden <zach@vmware.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Acked-by: Ingo Molnar <mingo@elte.hu>
17 years ago[PATCH] i386: PARAVIRT: Document asm-i386/paravirt.h
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Document asm-i386/paravirt.h

Clean things up, and broadly document:
 - the paravirt_ops functions themselves
 - the patching mechanism

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
17 years ago[PATCH] i386: PARAVIRT: Consistently wrap paravirt ops callsites to make them patchable
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Consistently wrap paravirt ops callsites to make them patchable

Wrap a set of interesting paravirt_ops calls in a wrapper which makes
the callsites available for patching.  Unfortunately this is pretty
ugly because there's no way to get gcc to generate a function call,
but also wrap just the callsite itself with the necessary labels.

This patch supports functions with 0-4 arguments, and either void or
returning a value.  64-bit arguments must be split into a pair of
32-bit arguments (lower word first).  Small structures are returned in
registers.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Zachary Amsden <zach@vmware.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
17 years ago[PATCH] i386: PARAVIRT: Fix patch site clobbers to include return register
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Fix patch site clobbers to include return register

Fix a few clobbers to include the return register.  The clobbers set
is the set of all registers modified (or may be modified) by the code
snippet, regardless of whether it was deliberate or accidental.

Also, make sure that callsites which are used in contexts which don't
allow clobbers actually save and restore all clobberable registers.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Zachary Amsden <zach@vmware.com>
17 years ago[PATCH] i386: PARAVIRT: Use patch site IDs computed from offset in paravirt_ops structure
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Use patch site IDs computed from offset in paravirt_ops structure

Use patch type identifiers derived from the offset of the operation in
the paravirt_ops structure.  This avoids having to maintain a separate
enum for patch site types.

Also, since the identifier is derived from the offset into
paravirt_ops, the offset can be derived from the identifier.  This is
used to remove replicated information in the various callsite macros,
which has been a source of bugs in the past.

This patch also drops the fused save_fl+cli operation, which doesn't
really add much and makes things more complex - specifically because
it breaks the 1:1 relationship between identifiers and offsets.  If
this operation turns out to be particularly beneficial, then the right
answer is to define a new entrypoint for it.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Zachary Amsden <zach@vmware.com>
17 years ago[PATCH] i386: PARAVIRT: rename struct paravirt_patch to paravirt_patch_site for clarity
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: rename struct paravirt_patch to paravirt_patch_site for clarity

Rename struct paravirt_patch to paravirt_patch_site, so that it
clearly refers to a callsite, and not the patch which may be applied
to that callsite.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Zachary Amsden <zach@vmware.com>
17 years ago[PATCH] x86: PARAVIRT: add hooks to intercept mm creation and destruction
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:14 +0000 (19:27 +0200)]
[PATCH] x86: PARAVIRT: add hooks to intercept mm creation and destruction

Add hooks to allow a paravirt implementation to track the lifetime of
an mm.  Paravirtualization requires three hooks, but only two are
needed in common code.  They are:

arch_dup_mmap, which is called when a new mmap is created at fork

arch_exit_mmap, which is called when the last process reference to an
  mm is dropped, which typically happens on exit and exec.

The third hook is activate_mm, which is called from the arch-specific
activate_mm() macro/function, and so doesn't need stub versions for
other architectures.  It's called when an mm is first used.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: linux-arch@vger.kernel.org
Cc: James Bottomley <James.Bottomley@SteelEye.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
17 years ago[PATCH] i386: PARAVIRT: Allow paravirt backend to choose kernel PMD sharing
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:13 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Allow paravirt backend to choose kernel PMD sharing

Normally when running in PAE mode, the 4th PMD maps the kernel address space,
which can be shared among all processes (since they all need the same kernel
mappings).

Xen, however, does not allow guests to have the kernel pmd shared between page
tables, so parameterize pgtable.c to allow both modes of operation.

There are several side-effects of this.  One is that vmalloc will update the
kernel address space mappings, and those updates need to be propagated into
all processes if the kernel mappings are not intrinsically shared.  In the
non-PAE case, this is done by maintaining a pgd_list of all processes; this
list is used when all process pagetables must be updated.  pgd_list is
threaded via otherwise unused entries in the page structure for the pgd, which
means that the pgd must be page-sized for this to work.

Normally the PAE pgd is only 4x64 byte entries large, but Xen requires the PAE
pgd to page aligned anyway, so this patch forces the pgd to be page
aligned+sized when the kernel pmd is unshared, to accomodate both these
requirements.

Also, since there may be several distinct kernel pmds (if the user/kernel
split is below 3G), there's no point in allocating them from a slab cache;
they're just allocated with get_free_page and initialized appropriately.  (Of
course the could be cached if there is just a single kernel pmd - which is the
default with a 3G user/kernel split - but it doesn't seem worthwhile to add
yet another case into this code).

[ Many thanks to wli for review comments. ]

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Zachary Amsden <zach@vmware.com>
Cc: Christoph Lameter <clameter@sgi.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
17 years ago[PATCH] i386: PARAVIRT: Allocate a fixmap slot
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:13 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Allocate a fixmap slot

Allocate a fixmap slot for use by a paravirt_ops implementation.  This
is intended for early-boot bootstrap mappings.  Once the zones and
allocator have been set up, it would be better to use get_vm_area() to
allocate some virtual space.

Xen uses this to map the hypervisor's shared info page, which doesn't
have a pseudo-physical page number, and therefore can't be mapped
ordinarily.  It is needed early because it contains the vcpu state,
including the interrupt mask.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
17 years ago[PATCH] i386: PARAVIRT: Hooks to set up initial pagetable
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:13 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Hooks to set up initial pagetable

This patch introduces paravirt_ops hooks to control how the kernel's
initial pagetable is set up.

In the case of a native boot, the very early bootstrap code creates a
simple non-PAE pagetable to map the kernel and physical memory.  When
the VM subsystem is initialized, it creates a proper pagetable which
respects the PAE mode, large pages, etc.

When booting under a hypervisor, there are many possibilities for what
paging environment the hypervisor establishes for the guest kernel, so
the constructon of the kernel's pagetable depends on the hypervisor.

In the case of Xen, the hypervisor boots the kernel with a fully
constructed pagetable, which is already using PAE if necessary.  Also,
Xen requires particular care when constructing pagetables to make sure
all pagetables are always mapped read-only.

In order to make this easier, kernel's initial pagetable construction
has been changed to only allocate and initialize a pagetable page if
there's no page already present in the pagetable.  This allows the Xen
paravirt backend to make a copy of the hypervisor-provided pagetable,
allowing the kernel to establish any more mappings it needs while
keeping the existing ones.

A slightly subtle point which is worth highlighting here is that Xen
requires all kernel mappings to share the same pte_t pages between all
pagetables, so that updating a kernel page's mapping in one pagetable
is reflected in all other pagetables.  This makes it possible to
allocate a page and attach it to a pagetable without having to
explicitly enumerate that page's mapping in all pagetables.

And:

+From: "Eric W. Biederman" <ebiederm@xmission.com>

If we don't set the leaf page table entries it is quite possible that
will inherit and incorrect page table entry from the initial boot
page table setup in head.S.  So we need to redo the effort here,
so we pick up PSE, PGE and the like.

Hypervisors like Xen require that their page tables be read-only,
which is slightly incompatible with our low identity mappings, however
I discussed this with Jeremy he has modified the Xen early set_pte
function to avoid problems in this area.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: William Irwin <bill.irwin@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
17 years ago[PATCH] i386: PARAVIRT: Add pagetable accessors to pack and unpack pagetable entries
Jeremy Fitzhardinge [Wed, 2 May 2007 17:27:13 +0000 (19:27 +0200)]
[PATCH] i386: PARAVIRT: Add pagetable accessors to pack and unpack pagetable entries

Add a set of accessors to pack, unpack and modify page table entries
(at all levels).  This allows a paravirt implementation to control the
contents of pgd/pmd/pte entries.  For example, Xen uses this to
convert the (pseudo-)physical address into a machine address when
populating a pagetable entry, and converting back to pphys address
when an entry is read.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Ingo Molnar <mingo@elte.hu>