Merge branch 'x86/vt-d' of...

		  only safe with partial memory descriptor list support enabled

		  (allow_ext_sg=1).

		* comp_vector, a number in the range 0..n-1 specifying the

		  MSI-X completion vector. Some HCA's allocate multiple (n)

		  MSI-X vectors per HCA port. If the IRQ affinity masks of

		  these interrupts have been configured such that each MSI-X

		  interrupt is handled by a different CPU then the comp_vector

		  parameter can be used to spread the SRP completion workload

		  over multiple CPU's.

		  MSI-X completion vector of the first RDMA channel. Some

		  HCA's allocate multiple (n) MSI-X vectors per HCA port. If

		  the IRQ affinity masks of these interrupts have been

		  configured such that each MSI-X interrupt is handled by a

		  different CPU then the comp_vector parameter can be used to

		  spread the SRP completion workload over multiple CPU's.

		* tl_retry_count, a number in the range 2..7 specifying the

		  IB RC retry count.

		* queue_size, the maximum number of commands that the

		descriptor list in an SRP_CMD when communicating with an SRP

		target.

What:		/sys/class/scsi_host/host<n>/ch_count

Date:		April 1, 2015

KernelVersion:	3.19

Contact:	linux-rdma@vger.kernel.org

Description:	Number of RDMA channels used for communication with the SRP

		target.

What:		/sys/class/scsi_host/host<n>/cmd_sg_entries

Date:		May 19, 2011

KernelVersion:	2.6.39

Description:	Maximum number of data buffer descriptors that may be sent to

		the target in a single SRP_CMD request.

What:		/sys/class/scsi_host/host<n>/comp_vector

Date:		September 2, 2013

KernelVersion:	3.11

Contact:	linux-rdma@vger.kernel.org

Description:	Completion vector used for the first RDMA channel.

What:		/sys/class/scsi_host/host<n>/dgid

Date:		June 17, 2006

KernelVersion:	2.6.17

that the driver using the simple domain call irq_create_mapping()

before any irq_find_mapping() since the latter will actually work

for the static IRQ assignment case.

==== Hierarchy IRQ domain ====

On some architectures, there may be multiple interrupt controllers

involved in delivering an interrupt from the device to the target CPU.

Let's look at a typical interrupt delivering path on x86 platforms:

Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU

There are three interrupt controllers involved:

1) IOAPIC controller

2) Interrupt remapping controller

3) Local APIC controller

To support such a hardware topology and make software architecture match

hardware architecture, an irq_domain data structure is built for each

interrupt controller and those irq_domains are organized into hierarchy.

When building irq_domain hierarchy, the irq_domain near to the device is

child and the irq_domain near to CPU is parent. So a hierarchy structure

as below will be built for the example above.

	CPU Vector irq_domain (root irq_domain to manage CPU vectors)

		^

		|

	Interrupt Remapping irq_domain (manage irq_remapping entries)

		^

		|

	IOAPIC irq_domain (manage IOAPIC delivery entries/pins)

There are four major interfaces to use hierarchy irq_domain:

1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt

   controller related resources to deliver these interrupts.

2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller

   related resources associated with these interrupts.

3) irq_domain_activate_irq(): activate interrupt controller hardware to

   deliver the interrupt.

3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware

   to stop delivering the interrupt.

Following changes are needed to support hierarchy irq_domain.

1) a new field 'parent' is added to struct irq_domain; it's used to

   maintain irq_domain hierarchy information.

2) a new field 'parent_data' is added to struct irq_data; it's used to

   build hierarchy irq_data to match hierarchy irq_domains. The irq_data

   is used to store irq_domain pointer and hardware irq number.

3) new callbacks are added to struct irq_domain_ops to support hierarchy

   irq_domain operations.

With support of hierarchy irq_domain and hierarchy irq_data ready, an

irq_domain structure is built for each interrupt controller, and an

irq_data structure is allocated for each irq_domain associated with an

IRQ. Now we could go one step further to support stacked(hierarchy)

irq_chip. That is, an irq_chip is associated with each irq_data along

the hierarchy. A child irq_chip may implement a required action by

itself or by cooperating with its parent irq_chip.

With stacked irq_chip, interrupt controller driver only needs to deal

with the hardware managed by itself and may ask for services from its

parent irq_chip when needed. So we could achieve a much cleaner

software architecture.

For an interrupt controller driver to support hierarchy irq_domain, it

needs to:

1) Implement irq_domain_ops.alloc and irq_domain_ops.free

2) Optionally implement irq_domain_ops.activate and

   irq_domain_ops.deactivate.

3) Optionally implement an irq_chip to manage the interrupt controller

   hardware.

4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,

   they are unused with hierarchy irq_domain.

Hierarchy irq_domain may also be used to support other architectures,

such as ARM, ARM64 etc.

	executed in user mode, or executed in the idle loop, we can

	safely free up that item.

	Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the

	Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the

	same effect, but require that the readers manipulate CPU-local

	counters.  These counters allow limited types of blocking within

	RCU read-side critical sections.  SRCU also uses CPU-local

o	I hear that RCU needs work in order to support realtime kernels?

	This work is largely completed.  Realtime-friendly RCU can be

	enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration

	enabled via the CONFIG_PREEMPT_RCU kernel configuration

	parameter.  However, work is in progress for enabling priority

	boosting of preempted RCU read-side critical sections.	This is

	needed if you have CPU-bound realtime threads.

	Stall-warning messages may be enabled and disabled completely via

	/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.

CONFIG_RCU_CPU_STALL_VERBOSE

	This kernel configuration parameter causes the stall warning to

	also dump the stacks of any tasks that are blocking the current

	RCU-preempt grace period.

CONFIG_RCU_CPU_STALL_INFO

	This kernel configuration parameter causes the stall warning to

and that the stall was affecting RCU-sched.  This message will normally be

followed by a stack dump of the offending CPU.  On TREE_RCU kernel builds,

RCU and RCU-sched are implemented by the same underlying mechanism,

while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented

while on PREEMPT_RCU kernel builds, RCU is instead implemented

by rcu_preempt_state.

On the other hand, if the offending CPU fails to print out a stall-warning

This message indicates that CPU 2 detected that CPUs 3 and 5 were both

causing stalls, and that the stall was affecting RCU-bh.  This message

will normally be followed by stack dumps for each CPU.  Please note that

TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,

PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,

and that the tasks will be indicated by PID, for example, "P3421".

It is even possible for a rcu_preempt_state stall to be caused by both

CPUs -and- tasks, in which case the offending CPUs and tasks will all

o	A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that

	is running at a higher priority than the RCU softirq threads.

	This will prevent RCU callbacks from ever being invoked,

	and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent

	and in a CONFIG_PREEMPT_RCU kernel will further prevent

	RCU grace periods from ever completing.  Either way, the

	system will eventually run out of memory and hang.  In the

	CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning

	CONFIG_PREEMPT_RCU case, you might see stall-warning

	messages.

o	A hardware or software issue shuts off the scheduler-clock

for rcutree and next for rcutiny.

CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats

CONFIG_TREE_RCU and CONFIG_PREEMPT_RCU debugfs Files and Formats

These implementations of RCU provide several debugfs directories under the

top-level directory "rcu":

rcu/rcu_sched

Each directory contains files for the corresponding flavor of RCU.

Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.

Note that rcu/rcu_preempt is only present for CONFIG_PREEMPT_RCU.

For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,

so that activity for both appears in rcu/rcu_sched.