| 2da19ffd395d0fdba4ccbc4a3c751554059d4aa3 |
|
23-May-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
commit 5842f5768599094758931b74190cdf93641a8e35 upstream.
We need to make sure that those parameters are setup to be correct.
As such the value of 0 is deemed invalid and we find that we
bail out. The hypervisor sets by default all of them to be zero
and when the hypercall is done does a simple:
a.value = d->arch.hvm_domain.params[a.index];
Which means that if the Xen toolstack forgot to setup the proper
HVM_PARAM_CONSOLE_EVTCHN (or the PFN one), we would get the
default value of 0 and use that.
Fixes-Oracle-Bug: 14091238
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/drivers/tty/hvc/hvc_xen.c
|
| 85fc3e3eba89272acb005f320ccafa0588a48f49 |
|
23-May-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
commit a32c88b9386ce3df87f28dd46bdc3776cd6edf75 upstream.
We weren't resetting the parameter to be passed in to a
known default. Nor were we checking the return value of
hvm_get_parameter.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/drivers/tty/hvc/hvc_xen.c
|
| 6a07cbc4ef9cea9f9eabc676fd6b8c03c11f51cc |
|
23-May-2012 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
xen/hvc: Collapse error logic.
commit 2e5ad6b9c45d43cc4e7b8ac5ded1c55a7c4a3893 upstream.
All of the error paths are doing the same logic. In which
case we might as well collapse them in one path.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/drivers/tty/hvc/hvc_xen.c
|
| 284e7be895509cdaf9f58e2f789c00b5e9da2244 |
|
15-May-2012 |
Dan Carpenter <dan.carpenter@oracle.com> |
hvc_xen: NULL dereference on allocation failure
commit 201a52bea928687b7557728b176ac4f8a37d5cbd upstream.
If kzalloc() returns a NULL here, we pass a NULL to
xencons_disconnect_backend() which will cause an Oops.
Also I removed the __GFP_ZERO while I was at it since kzalloc() implies
__GFP_ZERO.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/drivers/tty/hvc/hvc_xen.c
|
| cf8e019b523a8caa95b56ff0ce62a4856b14395f |
|
21-Feb-2012 |
Stefano Stabellini <stefano.stabellini@eu.citrix.com> |
hvc_xen: introduce HVC_XEN_FRONTEND
Introduce a new config option HVC_XEN_FRONTEND to enable/disable the
xenbus based pv console frontend.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
/drivers/tty/hvc/hvc_xen.c
|
| 02e19f9c7cacfb33d7b2f5cace7972fa60f92319 |
|
30-Jan-2012 |
Stefano Stabellini <stefano.stabellini@eu.citrix.com> |
hvc_xen: implement multiconsole support
This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.
Changes in v3:
- call hvc_remove before removing the console from xenconsoles;
- do not lock xencons_lock twice in the destruction path;
- use the DEFINE_XENBUS_DRIVER macro.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
/drivers/tty/hvc/hvc_xen.c
|
| eb5ef07151ba3c3cb4bcef0c8f146ff1115eaa55 |
|
27-Jan-2012 |
Stefano Stabellini <stefano.stabellini@eu.citrix.com> |
hvc_xen: support PV on HVM consoles
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
/drivers/tty/hvc/hvc_xen.c
|
| dced35aeb0367dda2636ee9ee914bda14510dcc9 |
|
28-Mar-2011 |
Thomas Gleixner <tglx@linutronix.de> |
drivers: Final irq namespace conversion
Scripted with coccinelle.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
/drivers/tty/hvc/hvc_xen.c
|
| bbd5a762b4c56609ad4c501298556ab1f00710cc |
|
07-Mar-2011 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
xen/hvc: Disable probe_irq_on/off from poking the hvc-console IRQ line.
This fixes a particular nasty racing problem found when using
Xen hypervisor with the console (hvc) output being routed to the
serial port and the serial port receiving data when
probe_irq_off(probe_irq_on) is running.
Specifically the bug manifests itself with:
[ 4.470693] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 4.470693] IP: [<ffffffff810a8c65>] handle_IRQ_event+0xe/0xc9
..snip..
[ 4.470693] Call Trace:
[ 4.470693] <IRQ>
[ 4.470693] [<ffffffff810aa645>] handle_percpu_irq+0x3c/0x69
[ 4.470693] [<ffffffff8123cda7>] __xen_evtchn_do_upcall+0xfd/0x195
[ 4.470693] [<ffffffff810308cf>] ? xen_restore_fl_direct_end+0x0/0x1
[ 4.470693] [<ffffffff8123d873>] xen_evtchn_do_upcall+0x32/0x47
[ 4.470693] [<ffffffff81034dfe>] xen_do_hypervisor_callback+0x1e/0x30
[ 4.470693] <EOI>
[ 4.470693] [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1000
[ 4.470693] [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1000
[ 4.470693] [<ffffffff810301c5>] ? xen_force_evtchn_callback+0xd/0xf
[ 4.470693] [<ffffffff810308e2>] ? check_events+0x12/0x20
[ 4.470693] [<ffffffff81030889>] ? xen_irq_enable_direct_end+0x0/0x7
[ 4.470693] [<ffffffff810ab0a0>] ? probe_irq_on+0x8f/0x1d7
[ 4.470693] [<ffffffff812b105e>] ? serial8250_config_port+0x7b7/0x9e6
[ 4.470693] [<ffffffff812ad66c>] ? uart_add_one_port+0x11b/0x305
The bug is trigged by three actors working together:
A). serial_8250_config_port calling
probe_irq_off(probe_irq_on())
wherein all of the IRQ handlers are being started and shut off.
The functions utilize the sleep functions so the minimum time
they are run is 120 msec.
B). Xen hypervisor receiving on the serial line any character and
setting the bits in the event channel - during this 120 msec timeframe.
C). The hvc API makes a call to 'request_irq' (and hence setting desc->action
to a valid value), much much later - when user space opens
/dev/console (hvc_open). To make the console usable during bootup,
the Xen HVC implementation sets the IRQ chip (and correspondingly
the event channel) much earlier. The IRQ chip handler that is used
is the handle_percpu_irq (aaca49642b92c8a57d3ca5029a5a94019c7af69f)
Back to the issue. When A) is being called it ends up calling the
xen_percpu_chip's chip->startup twice and chip->shutdown once. Those
are set to the default_startup and mask_irq (events.c) respectivly.
If (and this seems to depend on what serial concentrator you use), B)
gets data from the serial port it sets in the event channel a pending bit.
When A) calls chip->startup(), the masking of the pending bit, and
unmasking of the event channel mask, and also setting of the upcall_pending
flag is done (since there is data present on the event channel).
If before the 120 msec has elapsed, any IRQ handler (Xen IRQ has one
IRQ handler, which checks the event channels bitmap to figure which one
to call) is called we end up calling the handle_percpu_irq. The
handle_percpu_irq calls desc->action (which is NULL) and we blow up.
Caveats: I could only reproduce this on 2.6.32 pvops. I am not sure
why this is not showing up on 2.6.38 kernel.
The probe_irq_on/off has code to disable poking specific IRQ lines. This is
done by using the set_irq_noprobe() and then we do not have to
worry about the handle_percpu_irq being called before the IRQ action
handler has been installed.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
/drivers/tty/hvc/hvc_xen.c
|
| 728674a7e466628df2aeec6d11a2ae1ef968fb67 |
|
13-Jan-2011 |
Greg Kroah-Hartman <gregkh@suse.de> |
tty: move hvc drivers to drivers/tty/hvc/
As requested by Arnd Bergmann, the hvc drivers are now
moved to the drivers/tty/hvc/ directory. The virtio_console.c driver
was also moved, as it required the hvc_console.h file to be able to be
built, and it really is a hvc driver.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
/drivers/tty/hvc/hvc_xen.c
|