Dave Kleikamp [Wed, 21 Mar 2012 20:06:42 +0000 (15:06 -0500)]
btrfs: create btrfs_file_write_iter()
Since btrfs has it's own aio_write function, it needs a similar
write_iter. This patch patterns btrfs_file_write_iter on
btrfs_file_aio_write, then has the latter call the former.
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Narendra_K@Dell.com [Fri, 18 Mar 2011 17:22:14 +0000 (10:22 -0700)]
x86/PCI: Preserve existing pci=bfsort whitelist for Dell systems
Commit 6e8af08dfa40b747002207d3ce8e8b43a050d99f enables pci=bfsort on
future Dell systems. But the identification string 'Dell System' matches
on already existing whitelist, which do not have SMBIOS type 0xB1,
causing pci=bfsort not being set on existing whitelist.
This patch fixes the regression by moving the type 0xB1 check beyond the
existing whitelist so that existing whitelist is walked before.
Konrad Rzeszutek Wilk [Tue, 13 Mar 2012 22:05:58 +0000 (18:05 -0400)]
xen/blkback: Disable DISCARD support for loopback device (but leave for phy).
Until we back-port the changes from 3.3 which alter the loopback device
to support the full gamma of discard attributes. Otherwise we have to
punch through loop device to retrieve the underlaying disk size and
do other nasty things to get the proper information.
Also there is the outstanding issue that Logical Volumes won't pass
through the DISCARD support, so in most cases we can't take advantage of
this code until that gets fixed.
Fixes Oracle BZ#13779884 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Mike Snitzer [Wed, 6 Jul 2011 19:30:50 +0000 (21:30 +0200)]
block: eliminate potential for infinite loop in blkdev_issue_discard
Due to the recently identified overflow in read_capacity_16() it was
possible for max_discard_sectors to be zero but still have discards
enabled on the associated device's queue.
Eliminate the possibility for blkdev_issue_discard to infinitely loop.
Interestingly this issue wasn't identified until a device, whose
discard_granularity was 0 due to read_capacity_16 overflow, was consumed
by blk_stack_limits() to construct limits for a higher-level DM
multipath device. The multipath device's resulting limits never had the
discard limits stacked because blk_stack_limits() will only do so if
the bottom device's discard_granularity != 0. This resulted in the
multipath device's limits.max_discard_sectors being 0.
Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
[Fixes Oracle BZ13779884] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk>
Konrad Rzeszutek Wilk [Wed, 14 Mar 2012 00:47:44 +0000 (20:47 -0400)]
config: Use the xen-acpi-processor instead of the cpufreq-xen driver.
The xen-acpi-processor (CONFIG_XEN_ACPI_PROCESSOR=y) is a more modern
version of the cpufreq-xen driver that can automatically inhibit
the cpufreq scaling drivers.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Konrad Rzeszutek Wilk [Fri, 3 Feb 2012 21:03:20 +0000 (16:03 -0500)]
xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.
This driver solves three problems:
1). Parse and upload ACPI0007 (or PROCESSOR_TYPE) information to the
hypervisor - aka P-states (cpufreq data).
2). Upload the the Cx state information (cpuidle data).
3). Inhibit CPU frequency scaling drivers from loading.
The reason for wanting to solve 1) and 2) is such that the Xen hypervisor
is the only one that knows the CPU usage of different guests and can
make the proper decision of when to put CPUs and packages in proper states.
Unfortunately the hypervisor has no support to parse ACPI DSDT tables, hence it
needs help from the initial domain to provide this information. The reason
for 3) is that we do not want the initial domain to change P-states while the
hypervisor is doing it as well - it causes rather some funny cases of P-states
transitions.
For this to work, the driver parses the Power Management data and uploads said
information to the Xen hypervisor. It also calls acpi_processor_notify_smm()
to inhibit the other CPU frequency scaling drivers from being loaded.
Everything revolves around the 'struct acpi_processor' structure which
gets updated during the bootup cycle in different stages. At the startup, when
the ACPI parser starts, the C-state information is processed (processor_idle)
and saved in said structure as 'power' element. Later on, the CPU frequency
scaling driver (powernow-k8 or acpi_cpufreq), would call the the
acpi_processor_* (processor_perflib functions) to parse P-states information
and populate in the said structure the 'performance' element.
Since we do not want the CPU frequency scaling drivers from loading
we have to call the acpi_processor_* functions to parse the P-states and
call "acpi_processor_notify_smm" to stop them from loading.
There is also one oddity in this driver which is that under Xen, the
physical online CPU count can be different from the virtual online CPU count.
Meaning that the macros 'for_[online|possible]_cpu' would process only
up to virtual online CPU count. We on the other hand want to process
the full amount of physical CPUs. For that, the driver checks if the ACPI IDs
count is different from the APIC ID count - which can happen if the user
choose to use dom0_max_vcpu argument. In such a case a backup of the PM
structure is used and uploaded to the hypervisor.
[v1-v2: Initial RFC implementations that were posted]
[v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>]
[v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
[v5: Cleaned up the driver, fix bug under Athlon XP]
[v6: Changed the driver to a CPU frequency governor]
[v7: Jan Beulich <jbeulich@suse.com> suggestion to make it a cpufreq scaling driver
made me rework it as driver that inhibits cpufreq scaling driver]
[v8: Per Jan's review comments, fixed up the driver] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
Oleg Nesterov [Tue, 31 Jan 2012 16:15:11 +0000 (17:15 +0100)]
proc: make sure mem_open() doesn't pin the target's memory
Once /proc/pid/mem is opened, the memory can't be released until
mem_release() even if its owner exits.
Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
before access_remote_vm(), this verifies that this mm is still alive.
I am not sure what should mem_rw() return if atomic_inc_not_zero()
fails. With this patch it returns zero to match the "mm == NULL" case,
may be it should return -EINVAL like it did before e268337d.
Perhaps it makes sense to add the additional fatal_signal_pending()
check into the main loop, to ensure we do not hold this memory if
the target task was oom-killed.
Chris Mason [Tue, 28 Feb 2012 17:42:44 +0000 (12:42 -0500)]
Btrfs: fix casting error in scrub reada code
The reada code from scrub was casting down a u64 to
an unsigned long so it could insert it into a radix tree.
What it really wanted to do was cast down the result of a shift, instead
of casting down the u64. The bug resulted in trying to insert our
reada struct into the wrong place, which caused soft lockups and other
problems.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Konrad Rzeszutek Wilk [Mon, 27 Feb 2012 01:08:48 +0000 (20:08 -0500)]
Merge branch 'stable/cpufreq-xen.v6.rebased' into uek2-merge
* stable/cpufreq-xen.v6.rebased:
[CPUFREQ] xen: governor for Xen hypervisor frequency scaling.
xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
Konrad Rzeszutek Wilk [Fri, 3 Feb 2012 21:03:20 +0000 (16:03 -0500)]
[CPUFREQ] xen: governor for Xen hypervisor frequency scaling.
This CPU freq governor leaves the frequency decision to the Xen hypervisor.
To do that the driver parses the Power Management data and uploads said
information to the Xen hypervisor. Then the Xen hypervisor can select the
proper Cx and Pxx states for the initial domain and all other domains.
To upload the information, this CPU frequency driver reads Power Management (PM)
(_Pxx and _Cx) which are populated in the 'struct acpi_processor' structure.
It simply reads the contents of that structure and pass it up the Xen hypervisor.
For that to work we depend on the appropriate CPU frequency scaling driver
to do the heavy-lifting - so that the contents is correct.
The CPU frequency governor it has been loaded also sets up a timer
to check if the ACPI IDs count is different from the APIC ID count - which
can happen if the user choose to use dom0_max_vcpu argument. In such a case
a backup of the PM structure is used and uploaded to the hypervisor.
[v1-v2: Initial RFC implementations that were posted]
[v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>]
[v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
[v5: Cleaned up the driver, fix bug under Athlon XP]
[v6: Changed the driver to a CPU frequency governor] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
Konrad Rzeszutek Wilk [Tue, 14 Feb 2012 03:26:32 +0000 (22:26 -0500)]
xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset_xen module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.
For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.
The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.
Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".
With this in place, instead of
C3 ACPI IOPORT 415
we get now
C3:ACPI FFH INTEL MWAIT 0x20
Note: The cpu_idle which would be calling the mwait variants for idling
never gets set b/c we set the default pm_idle to be the hypercall variant.
Acked-by: Jan Beulich <JBeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Konrad Rzeszutek Wilk [Fri, 24 Feb 2012 05:35:13 +0000 (00:35 -0500)]
Merge branch 'stable/not-upstreamed' into uek2-merge
* stable/not-upstreamed:
Xen: Export host physical CPU information to dom0
xen/mce: Change the machine check point
Add mcelog support from xen platform
When a MCE/CMCI error happens (or by polling), the related error
information will be sent to privileged pv-ops domain by XEN. This
patch will help to fetch the xen-logged information by hypercall
and then convert XEN-format log into Linux format MCELOG. It makes
using current available mcelog tools for native Linux possible.
With this patch, after mce/cmci error log information is sent to
pv-ops guest, Running mcelog tools in the guest, you will get same
detailed decoded mce information as in Native Linux.
Nathanael Rensen [Tue, 7 Feb 2012 05:50:24 +0000 (13:50 +0800)]
usb: xen pvusb driver
Port the original Xen PV USB drivers developed by Noboru Iwamatsu
<n_iwamatsu@jp.fujitsu.com> to the Linux pvops kernel. The backend driver
resides in dom0 with access to the physical USB device. The frontend driver
resides in a domU to provide paravirtualised access to physical USB devices.
For usage, see http://wiki.xensource.com/xenwiki/XenUSBPassthrough.
Signed-off-by: Nathanael Rensen <nathanael@polymorpheus.com>. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
Note: The approach in upstream is to get rid of the microcode
driver altogether and do at early bootup. Even as early as
syslinux/pxeboot or initial kernel image. But those patches
are not yet ready.
Konrad Rzeszutek Wilk [Fri, 24 Feb 2012 04:54:01 +0000 (23:54 -0500)]
Merge branch 'devel/acpi-s3.v4.rebased' into uek2-merge
* devel/acpi-s3.v4.rebased:
xen/pci:use hypercall PHYSDEVOP_restore_msi_ext to restore MSI/MSI-X vectors
xen/acpi/sleep: Register to the acpi_suspend_lowlevel a callback.
xen/acpi/sleep: Enable ACPI sleep via the __acpi_override_sleep
xen/acpi: Domain0 acpi parser related platform hypercall
xen: Utilize the restore_msi_irqs hook.
x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel.
x86, acpi, tboot: Have a ACPI sleep override instead of calling tboot_sleep.
x86: Expand the x86_msi_ops to have a restore MSIs.
Konrad Rzeszutek Wilk [Fri, 24 Feb 2012 04:49:59 +0000 (23:49 -0500)]
Merge branch 'stable/processor-passthru.v5.rebased' into uek2-merge
* stable/processor-passthru.v5.rebased:
xen/processor-passthru: Provide an driver that passes struct acpi_processor data to the hypervisor.
xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
xen/setup/pm/acpi: Remove the call to boot_option_idle_override.
xen/acpi: Domain0 acpi parser related platform hypercall
xen/pm_idle: Make pm_idle be default_idle under Xen.
cpuidle: stop depending on pm_idle
cpuidle: replace xen access to x86 pm_idle and default_idle
cpuidle: create bootparam "cpuidle.off=1"
Konrad Rzeszutek Wilk [Fri, 24 Feb 2012 04:47:20 +0000 (23:47 -0500)]
xen/processor-passthru: Provide an driver that passes struct acpi_processor data to the hypervisor.
The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'struct acpi_processor' per-cpu structure.
We read the contents of that structure and pass it up the Xen hypervisor.
The ACPI processor along with the CPU freq driver does all the heavy-lifting
for us (filtering, calling ACPI functions, etc) so that the contents is correct.
After we are done parsing the information, we wait in case of hotplug CPUs
get loaded and then pass that information to the hypervisor.
[v1-v2: Initial RFC implementations that were posted]
[v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>]
[v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
[v5: Cleaned up the driver, fix bug under Athlon XP] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
Konrad Rzeszutek Wilk [Tue, 14 Feb 2012 03:26:32 +0000 (22:26 -0500)]
xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset_xen module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.
For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.
The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.
Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".
With this in place, instead of
C3 ACPI IOPORT 415
we get now
C3:ACPI FFH INTEL MWAIT 0x20
Note: The cpu_idle which would be calling the mwait variants for idling
never gets set b/c we set the default pm_idle to be the hypercall variant.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Yu Ke [Wed, 24 Mar 2010 18:01:13 +0000 (11:01 -0700)]
xen/acpi: Domain0 acpi parser related platform hypercall
This patches implements the xen_platform_op hypercall, to pass the parsed
ACPI info to hypervisor.
Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Tian Kevin <kevin.tian@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
[v1: Added DEFINE_GUEST.. in appropiate headers]
[v2: Ripped out typedefs] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Konrad Rzeszutek Wilk [Mon, 21 Nov 2011 23:02:02 +0000 (18:02 -0500)]
xen/pm_idle: Make pm_idle be default_idle under Xen.
The idea behind commit d91ee5863b71 ("cpuidle: replace xen access to x86
pm_idle and default_idle") was to have one call - disable_cpuidle()
which would make pm_idle not be molested by other code. It disallows
cpuidle_idle_call to be set to pm_idle (which is excellent).
But in the select_idle_routine() and idle_setup(), the pm_idle can still
be set to either: amd_e400_idle, mwait_idle or default_idle. This
depends on some CPU flags (MWAIT) and in AMD case on the type of CPU.
In case of mwait_idle we can hit some instances where the hypervisor
(Amazon EC2 specifically) sets the MWAIT and we get:
In the case of amd_e400_idle we don't get so spectacular crashes, but we
do end up making an MSR which is trapped in the hypervisor, and then
follow it up with a yield hypercall. Meaning we end up going to
hypervisor twice instead of just once.
The previous behavior before v3.0 was that pm_idle was set to
default_idle regardless of select_idle_routine/idle_setup.
We want to do that, but only for one specific case: Xen. This patch
does that.
Fixes RH BZ #739499 and Ubuntu #881076 Reported-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cc: Kevin Hilman <khilman@deeprootsystems.com>
cc: Paul Mundt <lethal@linux-sh.org>
cc: x86@kernel.org Acked-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Fri, 1 Apr 2011 22:28:35 +0000 (18:28 -0400)]
cpuidle: replace xen access to x86 pm_idle and default_idle
When a Xen Dom0 kernel boots on a hypervisor, it gets access
to the raw-hardware ACPI tables. While it parses the idle tables
for the hypervisor's beneift, it uses HLT for its own idle.
Rather than have xen scribble on pm_idle and access default_idle,
have it simply disable_cpuidle() so acpi_idle will not load and
architecture default HLT will be used.
cc: xen-devel@lists.xensource.com Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Jeremy Fitzhardinge [Sat, 28 Mar 2009 00:39:15 +0000 (17:39 -0700)]
xen: add CPU microcode update driver
Xen does all the hard work for us, including choosing the right update
method for this cpu type and actually doing it for all cpus. We just
need to supply it with the firmware blob.
Because Xen updates all CPUs (and the kernel's virtual cpu numbers have
no fixed relationship with the underlying physical cpus), we only bother
doing anything for cpu "0".
[ Impact: allow CPU microcode update in Xen dom0 ] Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Yu Ke [Wed, 24 Mar 2010 18:01:13 +0000 (11:01 -0700)]
xen/acpi: Domain0 acpi parser related platform hypercall
This patches implements the xen_platform_op hypercall, to pass the parsed
ACPI info to hypervisor.
Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Tian Kevin <kevin.tian@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
[v1: Added DEFINE_GUEST.. in appropiate headers]
[v2: Ripped out typedefs] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Chris Mason [Wed, 22 Feb 2012 17:36:24 +0000 (12:36 -0500)]
Btrfs: clear the extent uptodate bits during parent transid failures
If btrfs reads a block and finds a parent transid mismatch, it clears
the uptodate flags on the extent buffer, and the pages inside it. But
we only clear the uptodate bits in the state tree if the block straddles
more than one page.
This is from an old optimization from to reduce contention on the extent
state tree. But it is buggy because the code that retries a read from
a different copy of the block is going to find the uptodate state bits
set and skip the IO.
The end result of the bug is that we'll never actually read the good
copy (if there is one).
The fix here is to always clear the uptodate state bits, which is safe
because this code is only called when the parent transid fails.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Joe Jin [Thu, 19 Jan 2012 08:04:25 +0000 (16:04 +0800)]
fnic: return zero on fnic_reset() success
When issue LIP by sysfs found write("1") returned 8194, this caused by
fnic_reset() return SUCCESS to store_fc_private_host_issue_lip(). Return 0/-1
for fnic_reset() fix this issue.
Tested-by: Sriharsha <sriharsha.devdas@oracle.com> Signed-off-by: Joe Jin <joe.jin@oracle.com> Cc: Abhijeet Joglekar <abjoglek@cisco.com> Cc: Venkata Siva Vijayendra Bhamidipati <vbhamidi@cisco.com> Cc: Brian Uchino <buchino@cisco.com> CC: stable@vger.kernel.org
Vasu Dev [Fri, 28 Oct 2011 18:34:23 +0000 (11:34 -0700)]
[SCSI] libfc: improve flogi retries to avoid lport stuck
Adds more cases to do flogi retry, now also retry
on getting bad response due to either no ELS response
or flogi response payload length not large enough.
In those cases flogi was not retried and that
was leaving lport offline.
Signed-off-by: Vasu Dev <vasu.dev@intel.com> Tested-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
(cherry picked from commit 907c07d45199f954ddcf66c2c9763c87d012cb15)
Vasu Dev [Fri, 28 Oct 2011 18:34:17 +0000 (11:34 -0700)]
[SCSI] libfc: avoid exchanges collision during lport reset
Currently timer delay is large and is using msleep to avoid
avoid exchanges collision across lport reset, so instead
do this by initializing exches pool indexes during
reset also.
Signed-off-by: Vasu Dev <vasu.dev@intel.com> Tested-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
(cherry picked from commit b6e3c84034b93e6acc895711f74730e235dfe9d2)
Williams, Mitch A [Thu, 19 May 2011 05:37:59 +0000 (05:37 +0000)]
igbvf: update version number
Update the version number to match version conventions. Bump the major
version to indicate that new hardware support (i350) has been added.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Konrad Rzeszutek Wilk [Wed, 15 Feb 2012 15:48:39 +0000 (10:48 -0500)]
Merge branch 'stable/bug.fixes-3.3.rebased' into uek2-merge
* stable/bug.fixes-3.3.rebased:
xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback
xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
The reason for this should be obvious from this call-chain:
cpu_bringup_and_idle:
\- cpu_bringup
| \-[preempt_disable]
|
|- cpu_idle
\- play_dead [assuming the user offlined the VCPU]
| \
| +- (xen_play_dead)
| \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
| | onlines it starts from here]
| \- cpu_bringup [preempt_disable]
|
+- preempt_enable_no_reschedule()
+- schedule()
\- preempt_enable()
So we have two preempt_disble() and one preempt_enable(). Calling
preempt_enable() after the cpu_bringup() in the xen_play_dead
fixes the imbalance.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Konrad Rzeszutek Wilk [Wed, 1 Feb 2012 21:07:41 +0000 (16:07 -0500)]
xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
When the initial domain starts, it prints (depending on the
amount of CPUs) a slew of
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
which provide no useful information - as the error is a valid
issue - but not on the initial domain. The reason is that the
XenStore is not accessible at that time (it is after all the
first guest) so the CPU hotplug watch cannot parse "availability/cpu"
attribute.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
When isolating for migration, migration starts at the start of a zone
which is not necessarily pageblock aligned. Further, it stops isolating
when COMPACT_CLUSTER_MAX pages are isolated so migrate_pfn is generally
not aligned. This allows isolate_migratepages() to call pfn_to_page() on
an invalid PFN which can result in a crash. This was originally reported
against a 3.0-based kernel with the following trace in a crash dump.
The migrate_pfn is just below a memory hole and the free scanner is beyond
the hole. When isolate_migratepages started, it scans from migrate_pfn to
migrate_pfn+pageblock_nr_pages which is now in a memory hole. It checks
pfn_valid() on the first PFN but then scans into the hole where there are
not necessarily valid struct pages.
This patch ensures that isolate_migratepages calls pfn_valid when
necessary.
Reported-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com> Tested-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Acked-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- unify vlan and nonvlan rx path
- kill enic->vlan_group and enic_vlan_rx_register
Signed-off-by: Jiri Pirko <jpirko@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6ede746b62627b6f03fe88afad1a07d38917b85d)
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
Vasanthy Kolluri [Fri, 17 Jun 2011 07:56:48 +0000 (07:56 +0000)]
enic: Add support to configure hardware interrupt coalesce timers in a platform independent way
enic driver and the underlying hardware use different units for representing the interrupt coalesce timer.
Driver converts the interrupt coalesce timer in usec to hardware cycles while setting the relevant hardware
registers. The conversion factor can be different for each of the adapter hardware types. So it is dynamically
learnt from the adapter firmware using the devcmd CMD_INTR_COAL_CONVERT. This allows the driver to configure
the hardware interrupt coalesce timers in a platform independent way.
Signed-off-by: Danny Guo <dannguo@cisco.com> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com> Signed-off-by: David Wang <dwang2@cisco.com> Signed-off-by: David S. Miller <davem@conan.davemloft.net>
(cherry picked from commit ea7ea65a3b37bf207d5c352ac6254506b3dc3901)
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com> Signed-off-by: Danny Guo <dannguo@cisco.com> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com> Signed-off-by: David Wang <dwang2@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b880a954b9e2585ce325aedd76e4741880cab180)
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
Vasanthy Kolluri [Thu, 9 Jun 2011 10:37:02 +0000 (10:37 +0000)]
enic: Get/Set interrupt resource index for transmit and receive queues
Instead of deriving the index of a transmit/receive interrupt resource
from the transmit/receive queue index, always save and retrieve it
using an additional variable.
Signed-off-by: Christian Benvenuti <benve@cisco.com> Signed-off-by: Danny Guo <dannguo@cisco.com> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com> Signed-off-by: David Wang <dwang2@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7d260ec26ee56495bcb32491d44ed4590cc838a0)
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
Vasanthy Kolluri [Thu, 9 Jun 2011 10:36:57 +0000 (10:36 +0000)]
enic: Log device configuration in detail during driver load
Signed-off-by: Christian Benvenuti <benve@cisco.com> Signed-off-by: Danny Guo <dannguo@cisco.com> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com> Signed-off-by: David Wang <dwang2@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e1fb77bfd062b8d38fb0e428ae0edcd2dc4ec07b)
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
Vasanthy Kolluri [Thu, 9 Jun 2011 10:36:52 +0000 (10:36 +0000)]
enic: Pass 802.1p bits for packets tagged with vlan zero
enic driver currently passes 802.1p bits to the upper layers for packets
tagged with non-zero vlan ids only. This patch extends such behaviour to
zero vlan tagged packets also.
The patch is dependant on the following kernel patches:
Signed-off-by: Christian Benvenuti <benve@cisco.com> Signed-off-by: Danny Guo <dannguo@cisco.com> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com> Signed-off-by: David Wang <dwang2@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8757446d8df4446fc7f5d24ad6d53e9f265cc021)
Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com>
projects / users / jedix / linux-maple.git / log