In commit 1083:211849d9d511 the wheel event was lost due to an
incorrect backport of upstream commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6. With this change the wheel
event is available again in the guest.
Olaf Hering [Thu, 22 Sep 2011 17:57:57 +0000 (18:57 +0100)]
linux-2.6.18/Input: mousedev - handle mice that use absolute
coordinates
After commit 1083:211849d9d511 the mouse multiplexer /dev/input/mice
does not receive updates because the base kernel lacks a change from
2.6.24. If xorg.conf uses the mouse driver instead of the evdev
driver,
the mouse is stuck because now the "Xen Virtual Pointer" is not seen
as
a mouse anymore. Adding the backported patch below fixes it.
Input: mousedev - handle mice that use absolute coordinates
Devices like the HP Integrated Remote Console Virtual Mouse,
which are
standard equipment on all Proliant and Integrity servers,
produce
absolute coordinates instead of relative coordinates. This is
done to
synchronize the position of the mouse cursor on the client
desktop
with the mouse cursor position on the server. Mousedev is not
designed to pass those absolute events directly to X, but it
can
translate them into relative movements. It currently does
this for
tablet like devices and touchpads. This patch merely tells it
to also
include a device with ABS_X, ABS_Y, and mouse buttons in its
list of
devices to process input for.
This patch enables the mouse pointer to move when using the
remote
console.
Jan Beulich [Sat, 17 Sep 2011 15:29:02 +0000 (16:29 +0100)]
xen/backends: use kzalloc() in favor of kmalloc()+memset()
This fixes the problem of three of those four memset()-s having
improper size arguments passed: Sizeof a pointer-typed expression
returns the size of the pointer, not that of the pointed to data.
Reported-by: Julia Lawall <julia@diku.dk> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Jan Beulich [Fri, 19 Aug 2011 08:53:47 +0000 (09:53 +0100)]
xen/i386: follow-up to c/s 1101
The numbers obtained from the hypervisor really can't ever lead to an
overflow here, only the original calculation going through the order
of the range could have. This avoids the (as Jeremy points outs)
somewhat ugly NULL-based calculation here.
Jan Beulich [Mon, 25 Jul 2011 12:49:25 +0000 (13:49 +0100)]
xen/x86: use dynamically adjusted upper bound for contiguous regions
After years of not causing problems, the 2MB (order 9) limit on
contiguous regions' size was recently found to prevent booting of
certain systems - at least the FC variant of the MPT driver can
(possibly only for out-of-tree and/or post-2.6.18 versions) require
allocation of a buffer quite a bit larger than 2Mb.
Rather than increasing the limit on the order to 10, make the whole
logic dynamic - start out with a static order and respective argument
buffers large enough to allow initialization up to the point where
core_initcall()-s get processed, and from then on dynamically allocate
(and re-size) argument buffers on demand.
whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...
), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).
Jan Beulich [Fri, 8 Jul 2011 12:23:47 +0000 (13:23 +0100)]
blkfront: avoid NULL de-reference in CDROM ioctl handling
Just like already done in the default case, for CDROM_GET_CAPABILITY
info->gd should not be blindly de-referenced, as the ioctl can be
called prior to full device setup having completed.
- don't use xenbus_gather() for just a single, non-string item (as it
doesn't do format checking on its inputs)
- grant references don't need to be parsed as "long", since
grant_ref_t
is a typedef of uint32_t
- in the frontend protocol determination logic in blkback and blktap,
don't parse into a local buffer - use the allocated string directly
Jan Beulich [Wed, 1 Jun 2011 15:16:45 +0000 (16:16 +0100)]
xenbus: don't BUG() on user mode induced conditions
Neither allocation failure nor inability to locate a user mode
specified transaction ID should lead to a kernel crash. For
XS_TRANSACTION_END also don't issue anything to xenbus if the
specified ID doesn't match that of any active transaction.
Jan Beulich [Wed, 1 Jun 2011 15:09:50 +0000 (16:09 +0100)]
xen/blktap: fix locking
blktap_read_ufe_ring() invalidating the mmap index of a request could
race with blktap_clear_pte() reading it. Move the invalidation into
the info->mm->mmap_sem protected region in fast_flush_area(), noting
that doing this on the failure path of dispatch_rw_block_io() is
benign.
Jan Beulich [Thu, 26 May 2011 11:33:41 +0000 (12:33 +0100)]
xen/blkback: don't fail empty barrier requests
The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.
Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.
While at it also add overflow checking to the math in vbd_translate().
Laszlo Ersek [Thu, 26 May 2011 07:07:05 +0000 (08:07 +0100)]
netfront: plug a theoretical leak on setup_device()'s error path
Suppose the frontend is in XenbusStateInitialising and the backend
advances to XenbusStateInitWait. backend_changed() will call
network_connect() -> talk_to_backend() -> setup_device().
If bind_listening_port_to_irqhandler() fails (due to event channel
allocation failure, dynamic IRQ allocation failure etc), then the
grant references and the shared ring pages remain allocated. The error
percolates back to backend_changed() without any cleanup.
backend_changed() will not change the frontend state; it will stay in
XenbusStateInitialising. If the backend retries XenbusStateInitWait
(possibly through a fake, no-op mediate state, like
XenbusStateClosed), then the frontend repeats the above call chain and
leaks the previously unreleased ring pages and grant references.
If setup_device() fails to grant access to the RX page before it tries
to call bind_listening_port_to_irqhandler(), then only the TX page /
grant reference are leaked in the next round.
I'm not sure what happens when the RX page allocation fails:
xenbus_dev_fatal() is called then, which changes the frontend's state
and seems to preclude a second immediate call to network_connect(). I
think this patch shouldn't hurt in that case either (or after
earlier failures in setup_device() for that matter).
A virtualized display device is usually viewed with the vncviewer
application, either by 'xm vnc domU' or with vncviewer
localhost:port. vncviewer and the RFB protocol provides absolute
coordinates to the virtual display. These coordinates are either
passed through to a PV guest or converted to relative coordinates
for a HVM guest.
A PV guest receives these coordinates and passes them to the
kernels evdev driver. There it can be picked up by applications
such as the xorg-input drivers. Using absolute coordinates avoids
issues such as guest mouse pointer not tracking host mouse pointer
due to wrong mouse acceleration settings in the guests X display.
Advertise either absolute or relative coordinates to the input
system and the evdev driver, depending on what dom0 provides. The
xorg-input driver prefers relative coordinates even if a devices
provides both.
Laszlo Ersek [Mon, 16 May 2011 12:26:45 +0000 (13:26 +0100)]
xenbus: fix xenbus_transaction_start() hang caused by double xenbus_transaction_end()
vbd_resize() up_read()'s xs_state.suspend_mutex twice in a row via
double xenbus_transaction_end() calls. The next down_read() in
xenbus_transaction_start() (at eg. the next resize attempt) hangs.
See RHBZ#618317.
Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jan Beulich <jbeulich@novell.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Jan Beulich [Mon, 9 May 2011 09:02:19 +0000 (10:02 +0100)]
xen/blkfront: fix data size for xenbus_gather in connect()
From: Marek Marczykowski <marmarek@mimuw.edu.pl>
barrier variable is int, not long. This overflow caused another
variable override: "err" (in PV code) and "binfo" (in xenlinux code -
drivers/xen/blkfront/blkfront.c). The latter caused incorrect device
flags (RO/removable etc).
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Olaf Hering [Tue, 5 Apr 2011 11:42:02 +0000 (12:42 +0100)]
kdump pv-on-hvm: reset PV devices in crash kernel
After triggering a crash dump in a HVM guest, the PV backend drivers
will remain in connected state. When the kdump kernel starts the PV
drivers will skip such devices. As a result, no root device is found
and the vmcore cant be saved.
With this change all frontend devices with state XenbusStateConnected
will be reset by changing the state file to
Closing/Closed/Initializing. This will trigger a disconnect in the
backend drivers. Now the frontend drivers will find the backend
drivers in state Initwait and can connect.
[PATCH] kdump: introduce "reset_devices" command line option
Resetting the devices during driver initialization can be a costly
operation in terms of time (especially scsi devices). This option
can be
used by drivers to know that user forcibly wants the devices to be
reset
during initialization.
This option can be useful while kernel is booting in unreliable
environment. For ex. during kdump boot where devices are in
unknown
random state and BIOS execution has been skipped.
Jan Beulich [Sat, 2 Apr 2011 14:54:29 +0000 (15:54 +0100)]
xenbus: fix type inconsistency with xenbus_conn()
Its (bogus) declaration in xenbus_dev.c was inconsistent with the
actual implementation, leaving room for stack corruption on 64-bit
systems. Thus move the declaration to a header included by both
parties, and use proper types for the parameters.
Additionally, the function is needed on privileged kernels only, and
hence neither the potentially forward-incompatible HAVE_UNLOCKED_IOCTL
conditionals in xenbus_dev.c are needed, nor does the function (and
its helper) need to be compiled in unprivileged builds.
Jan Beulich [Wed, 2 Mar 2011 10:24:28 +0000 (10:24 +0000)]
xen/fbfront: fix regression from c/s 1068
Unfortunately we managed to not catch in our automatic testing this
oversight during the porting of the corresponding pv-ops patch
(info->irq now getting set later, which doesn't matter for pv-ops as
that has the event channel at hand).
Jan Beulich [Thu, 10 Feb 2011 09:06:04 +0000 (09:06 +0000)]
blktap: a small fix and assorted cleanup
The main cleanup item is to convert the index map from a plain
"unsigned long" holding two merged together integers into a proper
structure (at once halving its size on 64-bit).
Additionally, add a previously missing range check of res.id in
blktap_read_ufe_ring() and remove blkif_reqs (which could have been
set via module load option to a value other than the default, which
code elsewhere isn't capable of handling).
Jan Beulich [Wed, 9 Feb 2011 08:59:29 +0000 (08:59 +0000)]
xen/fb: fix potential memory leak
From: Joe Jin <joe.jin@oracle.com>
This patch fixes a potential memory leak when xenfb connect to
the backend fails.
Thanks for Ian's review and comments.
[v2: reworded the commit message a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Joe Jin <joe.jin@oracle.com> Tested-by: Gurudas Pai <gurudas.pai@oracle.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Made apply to linux-2.6.18-xen.hg.
Keir Fraser [Wed, 9 Feb 2011 08:38:55 +0000 (08:38 +0000)]
netback: allow arbitrary mtu size until frontend connects
Allow arbitrary mtu size until the frontend is connected. Once the
connection is established, adjust mtu by checking if the backend
supports the 'feature-sg'. If the backend does support it, keep the
current mtu. Otherwise set it to the default value, which is 1500.
based on two commits from
https://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git
This allows large MTU to be configured by the VIF hotplug
script. Previously this would fail because at the point the hotplug
script runs the VIF features have most likely not been negotiated with
the frontend and so SG has not yet been enabled. Invert this behaviour
so that SG is assumed present until negotiations prove otherwise and
reduce MTU at that point.
Make sure that if a feature flag is disabled by ethtool on netback
that we do not gratuitously re-enabled it when we check the frontend
features during ring connection.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Keir Fraser [Tue, 25 Jan 2011 14:09:27 +0000 (14:09 +0000)]
xen, vscsi: >2TB patch
This patch fixes current 2TB limitation of the xen vscsi driver.
Both frontend (command size) and backend (missing READ_16/WRITE_16
commands) driver need a fix. Also an scsi command added to support
ALUA. Tested thoroughly on 4TB external RAID.
I also enabled some more commands to allow operating LTO tape
drives and autoloaders (tested on HP Ultrium 1/8 + Bacula).
Still more scsi commands might be missing for other specific
devices (why not to enable all scsi commands by default ?).
Signed-off-by: Samuel Kvasnica <samuel.kvasnica@ims.co.at> Acked-by: Jan Beulich <jbeulich@novell.com>
Keir Fraser [Fri, 17 Dec 2010 16:40:58 +0000 (16:40 +0000)]
xen/netback: Always pull through PKT_PROT_LEN bytes into the linear part of an skb
Previously PKT_PROT_LEN would only have an effect on the first
fragment.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
xen/netback: try to pull a minimum of 72 bytes into the skb data area
... when receiving a packet into netback. The previous number, 64,
tended to place a fragment boundary in the middle of the TCP header
options and led to unnecessary fragmentation in Windows <-> Windows
networking.
xen/netback: Re-define PKT_PROT_LEN to be bigger.
Re-define PKT_PROT_LEN to be big enough to handle maximal IPv4 and TCP
options and phrase the definition so that it's reasonably obvious
that's what it's for.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Keir Fraser [Fri, 17 Dec 2010 10:09:15 +0000 (10:09 +0000)]
xen/gntdev: add range check for IOCTL_GNTDEV_UNMAP_GRANT_REF arguments,
..., move all user memory accesses out of semaphore protected region,
simplify, clean up, and remove some bogus printk()-s in gntdev_ioctl()
and its helpers.
The purpose of free_list_sem seems questionable: It is only ever being
acquired for write access, and always with grants_sem already held
in write mode.
Keir Fraser [Fri, 10 Dec 2010 10:48:31 +0000 (10:48 +0000)]
xen/netloop: make netloop permanent
with reference to RH BZ#567540 [0], this patch makes the netloop
module permanent (like netback is currently). It reverts parts of
xen-unstable c/s 9019:271cb04a4f2b [1] [2] (though that has a typo:
"__init clean_loopback", so it was probably changed later too).
The patch fixes the problem of "rmmod netloop" hanging, resulting in
blocked tasks and inability to shut down cleanly:
... kernel: unregister_netdevice: waiting for veth4 to become
free. Usage count = 1
The problem was also reported for Debian [3] and on the Fedora-xen
mailing list [4].
Keir Fraser [Tue, 23 Nov 2010 13:58:38 +0000 (13:58 +0000)]
blkback/blktap/netback: Fix CVE-2010-3699
A guest can cause the backend driver to leak a kernel
thread. Such leaked threads hold references to the device, whichmakes
the device impossible to tear down. If shut down, the guest remains a
zombie domain, the xenwatch process hangs, and most xm commands will
stop working.
This patch tries to do the following, for all of netback, blkback,
blktap:
- identify/extract idempotent teardown operations,
- add/move the invocation of said teardown operation
right before we're about to allocate new resources in the
Connected states.
Keir Fraser [Fri, 19 Nov 2010 13:20:06 +0000 (13:20 +0000)]
blktap2: fix synchronization in blktap_device_run_queue()
c/s 896 (use of blk_rq_map_sg()) made the problem worse, but from what
I can tell there had been races (ring and stats updates) before. If
that's not a correct observation, a perhaps better solution might be
to move the struct scatterlist array out of struct blktap (and make it
e.g. an on-stack variable, the problem being that
blktap_device_process_request() has a pretty large stack frame
already - shrinking this might be possible by moving e.g. the
struct blktap_grant_table and struct blkif_request blkif_req instances
the other way if the locking change here is the right thing to do).
Keir Fraser [Tue, 16 Nov 2010 11:31:19 +0000 (11:31 +0000)]
xen/evtchn: clear secondary CPUs' cpu_evtchn_mask[] after restore
To bind all event channels to CPU#0, it is not sufficient to set all
of its cpu_evtchn_mask[] bits; all other CPUs also need to get their
bits cleared. Otherwise, evtchn_do_upcall() will start handling
interrupts on CPUs they're not intended to run on, which can be
particularly bad for per-CPU ones.
Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Keir Fraser <keir@xen.org>
Keir Fraser [Mon, 15 Nov 2010 09:32:57 +0000 (09:32 +0000)]
pcifront: fix PCI reference leak
Stanse found that when pdev is found and has no driver a reference is
leaked in pcifront_common_process. So add pci_dev_put there. For the
pdev == NULL case, pci_dev_put(NULL) is fine.
Keir Fraser [Wed, 3 Nov 2010 08:20:42 +0000 (08:20 +0000)]
netback: take net_schedule_list_lock when removing entry from net_schedule_list
There is a race in net_tx_build_mops between checking if
net_schedule_list is empty and actually dequeuing the first entry on
the list. If another thread dequeues the only entry on the list during
this window we crash because list_first_entry expects a non-empty
list. Therefore after the initial lock free check for an empty list
check again with the lock held before dequeueing the entry.
Based on a patch by Tomasz Wroblewski.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Keir Fraser [Mon, 4 Oct 2010 12:30:33 +0000 (13:30 +0100)]
linux/pcifront: claim PCI resources also on rescan
Condensed from the following two patches:
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommitdiff;h=
=3D621d869f36b215d63bb99e7ecd7a11f029821b85=20
xen-pcifront: Claim PCI resources before going live.
author Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=09
Fri, 18 Jun 2010 19:31:47 +0000 (15:31 -0400)
committer Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=09
Fri, 18 Jun 2010 19:40:37 +0000 (15:40 -0400)
We were missing the important step of claiming (and setting the
parent of IO and MEM regions to 'PCI IO' and 'PCI mem' respectivly)
of the BARs. This meant that during hot inserts we would get:
igb 0000:01:00.1: device not available (can't reserve [mem
0xfb840000-0xfb8=
5ffff])
even thought the memory region had been reserved before.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommitdiff;h=
=3D4a65de894fc0af05397eedca180d0ea7d8c6caba=20
xen-pcifront: Don't race with udev when discovering new devices.
We inadvertly would call 'pci_bus_add_device' right after discovering
the device, but before claiming the BARs. This ended up firing off
a uevent and udev loading the module and the modules failing to
request_region as they were not claimed. We fix this by holding off
going live by calling 'pci_bus_add_devices' at the end.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Jan Beulich <jbeulich@novell.com> Reported-by: Rafal Wojtczuk <rafal@invisiblethingslab.com>
xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.
This avoids any other hardirq handler seeing a very stale jiffies
value immediately after wakeup from a long idle period. The one
observable symptom of this was a USB keyboard, with software keyboard
repeat, which would always repeat a key immediately that it was
pressed. This is due to the key press waking the guest, the key
handler immediately runs, sees an old jiffies value, and then that
jiffies value significantly updated, before the key is unpressed.
xen/x86: synchronize vmalloc_sync_all() with mm_{,un}pin()
As recently diagnosed by Citrix engineers, mm_{,un}pin() and
vmalloc_sync_all() aren't properly synchronized. So we add a backlink
to the referencing struct mm_struct to the pgd's struct page, and use
this to lock the page table updates in vmalloc_sync_all().
Due to the way pgd-s get allocated and put on the global list on i386,
we have to account for the backlink not to be set yet (in which case
they cannot be subject to (un)pinning.
Along the way, I found it necessary/desirable to also fix
- a potential NULL dereference in i386's pgd_alloc(),
- x86-64 adding not yet cleaned out pgd-s to the global list, and
- x86-64 removing pgd-s from the global list rather late.
xen/blkfront: forward unknown IOCTLs to scsi_cmd_ioctl() for /dev/sdX
Certain utilities (here: parted) expect certain SCSI IOCTLs (here:
SCSI_IOCTL_GET_IDLUN) to not fail on /dev/sdX devices. Rather than
handling them one-by-one, just forward control to scsi_cmd_ioctl().
Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
GNTTABOP_copy operations properly to allow usage of xenpaging without
causing crashes or data corruption.
Remove the existing retry code from net_rx_action(),
dispatch_rw_block_io(), net_accel_map_grants_contig() and
net_accel_map_iomem_page() and replace all relevant
HYPERVISOR_grant_table_op() calls with a retry loop. This loop is
implemented as a macro to allow different GNTTABOP_* args. It will
sleep up to 33 seconds and wait for the page to be paged in again.
All ->status checks were updated to use the GNTST_* namespace. All
return values are converted from GNTST_* namespace to 0/-EINVAL, since
all callers did not use the actual return value.
Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
Because xen-compat.h defines __XEN_INTERFACE_VERSION__ only if __XEN__
or __XEN_TOOLS__ is defined, I added #include xen-compat.h before
#define __XEN_TOOLS__.
I confirmed that dom0 kernel could be built without warnings and
guests could be created.
xen: netback: save interrupt state in add_to_net_schedule_list_tail
add_to_net_schedule_list_tail is called from both hard interrupt
context (add_to_net_schedule_list_tail) and soft interrupt/process
context (netif_schedule_work) so use the interrupt state saving
spinlock variants.
xen/x86: make __direct_remap_pfn_range()'s return value meaningful
From: Olaf Hering <ohering@novell.com>
This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
Because the cpumap member of struct xen_sysctl_cpupool_op is used only
when the operation is XEN_SYSCTL_CPUPOOL_OP_INFO or
XEN_SYSCTL_CPUPOOL_OP_FREEINFO, in case of others, xencomm_map to
cpumap fails, thus XEN_SYSCTL_cpupool_op fails.
Keir Fraser [Tue, 10 Aug 2010 14:47:41 +0000 (15:47 +0100)]
xen/x86: eliminate nesting of run-queue locks inside xtime_lock
From: Zdenek Salvet <salvet@ics.muni.cz>
According to Debian bug 591362 this has been causing problems. While
no proof was given that the inverse lock order does actually occur
anywhere (with interrupts enabled), it is plain unnecessary to take
the risk.
Signed-off-by: Jan Beulich <jbeulich@novell.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Keir Fraser [Tue, 10 Aug 2010 14:46:56 +0000 (15:46 +0100)]
blktap2: eliminate bogus clearing of PG_reserved
While making sure PG_reserved is set for pages allocated from the
balloon driver (and to be used for I/O) is a necessary thing to do
(as 2.6.18's as well as pv-ops' balloon drivers don't guarantee this
for the pages returned from alloc_empty_pages_and_page_vec()),
clearing this flag again when a page is no longer in use for I/O is
bogus at best (after all, the page at that point is not associated
with any MFN anymore), and causes problems when the balloon driver
properly marks all such pages as reserved and checks, upon their
return, that they are still marked this way.
Keir Fraser [Mon, 2 Aug 2010 10:02:18 +0000 (11:02 +0100)]
xenoprofile: Add IBS support
Add IBS support for AMD family 10h processors. The major
implementation is derived from latest Linux. Two hypercalls are added,
which is necessary for IBS feature detection and user mode parameter
read.
Keir Fraser [Fri, 18 Jun 2010 13:11:57 +0000 (14:11 +0100)]
xen/x86: fix for special behavior of first sys_settimeofday(NULL, &tz) invocation
The data Xen's time implementation maintains to make do_gettimeofday()
return values monotonic needs to be reset not only during normal
do_gettimeofday() invocations, but also when the clock gets warped
due to the hardware (CMOS) clock running on local (rather than UTC)
time.
Additionally there was a time window in do_gettimeofday() (between
the end of the xtime read loop and the acquiring of the monotonicity
data lock) where, if on another processor do_settimeofday() would
execute to completion, the zeroes written by the latter could get
overwritten by the former with values obtained before the time was
updated. This now gets prevented by maintaining a version for the
monotonicity data.
This fixes the following errors:
/arch/ia64/xen/xcom_privcmd.c: In function `xencomm_privcmd_sysctl':
/arch/ia64/xen/xcom_privcmd.c:295: error: case label not within a
switch statement
/arch/ia64/xen/xcom_privcmd.c:305: error: break statement not within
loop or switch
Since 1018:b7eb9756e522 inserted lines in outside of a switch
statement. This patch corrects it.
blktap: fix cleanup after unclean application exit #2
When an application using blktap devices doesn't close the mmap-s of
/dev/xen/blktapN and the frontend driver never connects, we cannot
defer the mmput() on the stored mm until blktap_release() or the exit
path of the worker thread, as the former will never be called without
the mm's reference count dropping to zero, and the worker thread
would never get started.
- array indices got checked after having indexed the array already
- several were off by one
- BLKTAP_IOCTL_FREEINTF should not be used on other than the control
device (or the logic should be changed to that when thus used only
the respective device can be freed)
- BLKTAP_IOCTL_MINOR can reasonably also be used on non-control
- devices
(returning that device's minor and ignoring the passed in argument)
xen/blktap: fix cleanup after unclean application exit
When an application using blktap devices doesn't close the file handle
(or mmap-s) of /dev/xen/blktapN, we cannot defer the mmput() on the
stored mm until blktap_release(), as that will never be called without
the mm's reference count dropping to zero.
Keir Fraser [Tue, 30 Mar 2010 17:28:34 +0000 (18:28 +0100)]
xen/balloon: Fix return value interpretation for XENMEM_get_pod_target
Unfortunately c/s 989 didn't consider what I would call a quirk in
pre-3.4 Xen, resulting in XENMEM_get_pod_target calls to not return
-ENOSYS as one would normally expect.
projects / legacy / linux-2.6.18-xen.git / log