Rather than assume a single port, add a 'struct ports_device' which
stores data related to all the ports for that device.

Currently, there's only one port and is hooked up with hvc, but that
will change.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Now we can use an allocation function to remove our global console variable.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Keep a list of all ports being used as a console, and provide a lock
and a lookup function.  The hvc callbacks only give us a vterm number,
so we need to map this.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Part of removing our "one console" assumptions, use vdev->priv to point
to the port (currently == the global console).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This makes taking locks around the get_buf vq operation easier, as well
as complements the add_inbuf() operation.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

add_inbuf() assumed one port and one inbuf per port. Remove that
assumption.

Also move the function so that put_chars and get_chars are together.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Collect port buffer, used_len, offset fields into a single structure.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We are heading towards a multiple-"port" system, so as part of weaning off
globals we encapsulate the information into 'struct port'.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We support only one virtio_console device at a time. If multiple are
found, error out if one is already initialized.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is nicer for modern R/O protection.  And noone needs it non-const, so
constify the callers as well.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linuxppc-dev@ozlabs.org

That way, we can make it const as is good kernel style.  We use a separate
indirection for the early console, rather than mugging ops.put_chars.

We rename it hv_ops, too.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Remove old lguest-style comments.

[Amit: - wingify comments acc. to kernel style
       - indent comments ]
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

vq operations depend on vq->data[i] being NULL to figure out if the vq
entry is in use (since the previous patch).

We have to initialize them to NULL to ensure we don't work with junk
data and trigger false BUG_ONs.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Shirley Ma <xma@us.ibm.com>

There's currently no way for a virtio driver to ask for unused
buffers, so it has to keep a list itself to reclaim them at shutdown.
This is redundant, since virtio_ring stores that information.  So
add a new hook to do this.
Signed-off-by: NShirley Ma <xma@us.ibm.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Allow reading various alignment values from the config page.  This
allows the guest to much better align I/O requests depending on the
storage topology.

Note that the formats for the config values appear a bit messed up,
but we follow the formats used by ATA and SCSI so they are expected in
the storage world.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

virtio is communicating with a virtual "device" that actually runs on
another host processor. Thus SMP barriers can be used to control
memory access ordering.

Where possible, we should use SMP barriers which are more lightweight than
mandatory barriers, because mandatory barriers also control MMIO effects on
accesses through relaxed memory I/O windows (which virtio does not use)
(compare specifically smp_rmb and rmb on x86_64).

We can't just use smp_mb and friends though, because
we must force memory ordering even if guest is UP since host could be
running on another CPU, but SMP barriers are defined to barrier() in
that configuration. So, for UP fall back to mandatory barriers instead.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

With DEBUG defined, we add an ->in_use flag to detect if the caller
invokes two virtio methods in parallel.  The barriers attempt to ensure
timely update of the ->in_use flag.

But they're voodoo: if we need these barriers it implies that the
calling code doesn't have sufficient synchronization to ensure the
code paths aren't invoked at the same time anyway, and we want to
detect it.

Also, adding barriers changes timing, so turning on debug has more
chance of hiding real problems.

Thanks to MST for drawing my attention to this code...

CC: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Two years ago 5bbf89fc removed the horrible bzImage unpacking code.
Now it's time to remove the unneeded zlib.h include, too.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

When running under qemu-kvm-0.11.0:

	BUG: unable to handle kernel paging request at 56e58955
	...
	Process vballoon (pid: 1297, ti=c7976000 task=c70a6ca0 task.ti=c7
	...
	Call Trace:
	 [<c88253a3>] ? balloon+0x1b3/0x440 [virtio_balloon]
	 [<c041c2d7>] ? schedule+0x327/0x9d0
	 [<c88251f0>] ? balloon+0x0/0x440 [virtio_balloon]
	 [<c014a2d4>] ? kthread+0x74/0x80
	 [<c014a260>] ? kthread+0x0/0x80
	 [<c0103b36>] ? kernel_thread_helper+0x6/0x30

need_stats_update should be zero-initialized.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Acked-by: NAdam Litke <agl@us.ibm.com>

This is a fix for my earlier patch: "virtio: Add memory statistics reporting to
the balloon driver (V4)".

I discovered that all_vm_events() can sleep and therefore stats collection
cannot be done in interrupt context.  One solution is to handle the interrupt
by noting that stats need to be collected and waking the existing vballoon
kthread which will complete the work via stats_handle_request().  Rusty, is
this a saner way of doing business?

There is one issue that I would like a broader opinion on.  In stats_request, I
update vb->need_stats_update and then wake up the kthread.  The kthread uses
vb->need_stats_update as a condition variable.  Do I need a memory barrier
between the update and wake_up to ensure that my kthread sees the correct
value?  My testing suggests that it is not needed but I would like some
confirmation from the experts.
Signed-off-by: NAdam Litke <agl@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Changes since V3:
 - Do not do endian conversions as they will be done in the host
 - Report stats that reference a quantity of memory in bytes
 - Minor coding style updates

Changes since V2:
 - Increase stat field size to 64 bits
 - Report all sizes in kb (not pages)
 - Drop anon_pages stat and fix endianness conversion

Changes since V1:
 - Use a virtqueue instead of the device config space

When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests.  The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval.  The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure.  This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host.  A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them directly to the hypervisor.

This patch enables the guest-side support by adding stats collection and
reporting to the virtio balloon driver.
Signed-off-by: NAdam Litke <agl@us.ibm.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (minor fixes)

This is needed to compile with CONFIG_VIRTIO_PCI=y,
because virtio_pci_remove is marked __devexit.
Signed-off-by: NJamie Lokier <jamie@shareable.org>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  MIPS: BCM47xx: Fix 128MB RAM support
  MIPS: Highmem: Fix build error

Merge branch 'parisc/tracehook' of git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland

* 'parisc/tracehook' of git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland:
  Revert "parisc: HAVE_ARCH_TRACEHOOK"

803bf5ec ("fs/exec.c: restrict initial
stack space expansion to rlimit") attempts to limit the initial stack to
20*PAGE_SIZE.  Unfortunately, in attempting ensure the stack is not
reduced in size, we ended up not changing the stack at all.

This size reduction check is not necessary as the expand_stack call does
this already.

This caused a regression in UML resulting in most guest processes being
killed.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Reviewed-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: NWANG Cong <xiyou.wangcong@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: Serge Hallyn <serue@us.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jouni Malinen <j@w1.fi>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 4410f391 ("fbdev: add support for
handoff from firmware to hw framebuffers") didn't add fb_destroy
operation to efifb.  Fix it and change aperture_size to match size
passed to request_mem_region.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15151Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Reported-by: NAlex Zhavnerchik <alex.vizor@gmail.com>
Tested-by: NAlex Zhavnerchik <alex.vizor@gmail.com>
Acked-by: NPeter Jones <pjones@redhat.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

geode-mfgpt: restore previous behavior for selecting IRQ

The MFGPT IRQ used to be, in order of decreasing priority,
 * IRQ supplied by the user as a boot-time parameter,
 * IRQ previously set by the BIOS or another driver,
 * default IRQ given at compile time.

Return to this behavior, which got broken when splitting the
MFGPT/clocksource driver for 2.6.33-rc1.
Signed-off-by: NJens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: NAndres Salomon <dilinger@collabora.co.uk>
Cc: Jordan Crouse <jordan.crouse@amd.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: john stultz <johnstul@us.ibm.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is retry of reverted 859ddf09
("idr: fix a critical misallocation bug") which contained two bugs.

* pa[idp->layers] should be cleared even if it's not used by
  sub_alloc() because it's used by mark idr_mark_full().

* The original condition check also assigned pa[l] to p which the new
  code didn't do thus leaving p pointing at the wrong layer.

Both problems have been fixed and the idr code has received good amount
testing using userland testing setup where simple bitmap allocator is
run parallel to verify the result of idr allocation.

The bug this patch fixes is caused by sub_alloc() optimization path
bypassing out-of-room condition check and restarting allocation loop
with starting value higher than maximum allowed value.  For detailed
description, please read commit message of 859ddf09.
Signed-off-by: NTejun Heo <tj@kernel.org>
Based-on-patch-from: Eric Paris <eparis@redhat.com>
Reported-by: NEric Paris <eparis@redhat.com>
Tested-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Tested-by: NSerge Hallyn <serue@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

find_task_by_vpid() is not safe without rcu_read_lock().  2.6.33-rc7 got
RCU protection for sys_setpriority() but missed it for sys_getpriority().
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Acked-by: NSerge Hallyn <serue@us.ibm.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Presently the oom-killer is memcg aware and it finds the worst process
from processes under memcg(s) in oom.  Then, it kills victim's child
first.

It may kill a child in another cgroup and may not be any help for
recovery.  And it will break the assumption users have.

This patch fixes it.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: NMinchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Reviewed-by: NDaisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Acked-by: NDavid Rientjes <rientjes@google.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Ignoring the last page when ddr size is 128M. Cached accesses to last page
is causing the processor to prefetch using address above 128M stepping out
of the DDR address space.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/981/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

arch/mips/mm/highmem.c: In function 'kmap_init':
arch/mips/mm/highmem.c:130: error: 'init_mm' undeclared (first use in this function)
arch/mips/mm/highmem.c:130: error: (Each undeclared identifier is reported only once
arch/mips/mm/highmem.c:130: error: for each function it appears in.)
Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org>
Cc: linux-mips <linux-mips@linux-mips.org>
Patchwork: http://patchwork.linux-mips.org/patch/980/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This reverts commit 81bf550d.

HAVE_ARCH_TRACEHOOK requires defining the user_regset interfaces,
including task_user_regset_view().  parisc doesn't do that yet,
so don't lie about it.
Signed-off-by: NRoland McGrath <roland@redhat.com>

Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf probe: Init struct probe_point and set counter correctly
  hw-breakpoint: Keep track of dr7 local enable bits
  hw-breakpoints: Accept breakpoints on NULL address
  perf_events: Fix FORK events

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: usbtouchscreen - extend coordinate range for Generaltouch devices
  Input: polldev can cause crash in case when polling disabled

Commit 84b79f8d (drm/i915: Fix crash
while aborting hibernation) attempted to fix a regression introduced
by commit cbda12d7 (drm/i915:
implement new pm ops for i915), but it went too far trying to split
the freeze/suspend and resume/thaw parts of the code.  As a result,
it introduced another regression, which only is visible on some systems.

Fix the problem by merging i915_drm_suspend() with
i915_drm_freeze() and moving some code from i915_resume()
into i915_drm_thaw(), so that intel_opregion_free() and
intel_opregion_init() are also executed in the freeze and thaw code
paths, respectively.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: NPedro Ribeiro <pedrib@gmail.com>
Tested-by: NTino Keitel <tino.keitel@tikei.de>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Clear struct probe_point before using it in
show_perf_probe_events(), and set pp->found counter correctly in
synthesize_perf_probe_point(). Without this initialization,
clear_probe_point() will free random addresses.
Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: systemtap <systemtap@sources.redhat.com>
Cc: DLE <dle-develop@lists.sourceforge.net>
LKML-Reference: <20100218181652.26547.57790.stgit@dhcp-100-2-132.bos.redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Generaltouch protocol allows for coordinates in [0, 0xffff] range and
there are devices reporting coordinates as high as 0x7fff so let's update
the driver to reflect that.
Signed-off-by: NRoy Yin <yhch@generaltouch.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  sparc32: Fix struct stat uid/gid types.

Commit 085219f7
("sparc32: use proper types in struct stat")

Accidently changed the struct stat uid/gid members
to uid_t and gid_t, but those get set to
__kernel_uid32_t and __kernel_gid32_t respectively.
Those are of type 'int' but the structure is meant
to have 'short'.  So use uid16_t and gid16_t to
correct this.
Reported-by: NRob Landley <rob@landley.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>