* [PATCH] powerpc/powernv: Update dump README file
From: Vasant Hegde @ 2013-11-18 11:09 UTC (permalink / raw)
To: linuxppc-dev
Update dump README file content.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-dump.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
index e102a80..9bc8ad3 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -317,9 +317,17 @@ static struct notifier_block dump_nb = {
};
-/* FIXME: debugfs README message */
+/* debugfs README message */
static const char readme_msg[] =
- "This file will be populated shortly..";
+ "Platform dump HOWTO:\n\n"
+ "files:\n"
+ " dump - Binary file, contains actual dump data\n"
+ " dump_available (r--) - New dump available notification\n"
+ " 0 : No dump present\n"
+ " 1 : Dump present\n"
+ " dump_control(-w-) - Dump control file\n"
+ " 1 : Send acknowledgement (dump copied)\n"
+ " 2 : Initiate FipS dump\n";
/* debugfs dump_control file operations */
static ssize_t dump_control_write(struct file *file,
^ permalink raw reply related
* Re: [v6][PATCH 0/5] powerpc/book3e: powerpc/book3e: make kgdb to work well
From: "“tiejun.chen”" @ 2013-11-18 8:36 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1382520685-11609-1-git-send-email-tiejun.chen@windriver.com>
On 10/23/2013 05:31 PM, Tiejun Chen wrote:
> Scott,
>
> Tested on fsl-p5040 DS.
Scott,
Any comments to this version?
Tiejun
>
> v6:
>
> * rebase
> * change the C code to initialize the exception stack addresses in the PACA instead.
> * Clear the PACA_IRQ_HARD_DIS force to exit directly from this debug exception
> without replaying interrupt.
> * so drop "book3e/kgdb: update thread's dbcr0".
>
> v5:
>
> * rebase on merge branch.
>
> Note the original patch, [ATCH 5/7] kgdb/kgdbts: support ppc64, is already merged
> by Jason.
>
> v4:
>
> * use DEFINE_PER_CPU to allocate kgdb's thread_info
> * add patch 7 to make usre copy thread_info only !__check_irq_replay
> * leave "andi. r14,r11,MSR_PR" out of "#ifndef CONFIG_KGDB"
> since cr0 is still used lately.
> * retest
>
> v3:
>
> * make work when enable CONFIG_RELOCATABLE
> * fix one typo in patch,
> "powerpc/book3e: store critical/machine/debug exception thread info":
> ld r1,PACAKSAVE(r13);
> -> ld r14,PACAKSAVE(r13);
> * remove copying the thread_info since booke and book3e always copy
> the thead_info now when we enter the debug exception, and so drop
> the v2 patch, "book3e/kgdb: Fix a single stgep case of lazy IRQ"
>
> v2:
>
> * Make sure we cover CONFIG_PPC_BOOK3E_64 safely
> * Use LOAD_REG_IMMEDIATE() to load properly
> the value of the constant expression in load debug exception stack
> * Copy thread infor form the kernel stack coming from usr
> * Rebase latest powerpc git tree
>
> v1:
>
> * Copy thread info only when we are from !user mode since we'll get kernel stack
> coming from usr directly.
> * remove save/restore EX_R14/EX_R15 since DBG_EXCEPTION_PROLOG already covered
> this.
> * use CURRENT_THREAD_INFO() conveniently to get thread.
> * fix some typos
> * add a patch to make sure gdb can generate a single step properly to invoke a
> kgdb state.
> * add a patch to if we need to replay an interrupt, we shouldn't restore that
> previous backup thread info to make sure we can replay an interrupt lately
> with a proper thread info.
> * rebase latest powerpc git tree
>
> v0:
>
> This patchset is used to support kgdb for book3e.
>
> ----------------------------------------------------------------
> Tiejun Chen (5):
> powerpc/book3e: initialize crit/mc/dbg kernel stack pointers
> powerpc/book3e: store crit/mc/dbg exception thread info
> powerpc/book3e: support kgdb for kernel space
> powerpc/kgdb: use DEFINE_PER_CPU to allocate kgdb's thread_info
> powerpc/book3e/kgdb: Fix a single stgep case of lazy IRQ
>
> arch/powerpc/kernel/exceptions-64e.S | 26 ++++++++++++++++++++++----
> arch/powerpc/kernel/kgdb.c | 13 ++++++++++---
> arch/powerpc/kernel/setup_64.c | 18 ++++++++++++------
> 3 files changed, 44 insertions(+), 13 deletions(-)
>
> Tiejun
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup
From: Mark Rutland @ 2013-11-18 12:09 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen, Arnd Bergmann,
Vinod Koul, Gerhard Sittig, Dan Williams, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1383290374-17484-5-git-send-email-a13xp0p0v88@gmail.com>
On Fri, Nov 01, 2013 at 07:19:33AM +0000, Alexander Popov wrote:
> From: Gerhard Sittig <gsi@denx.de>
>
> register the controller for device tree based lookup of DMA channels
> (non-fatal for backwards compatibility with older device trees), provide
> the '#dma-cells' property in the shared mpc5121.dtsi file, and introduce
> a bindings document for the MPC512x DMA controller
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> .../devicetree/bindings/dma/mpc512x-dma.txt | 55 ++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
> drivers/dma/mpc512x_dma.c | 21 +++++++--
> 3 files changed, 74 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> new file mode 100644
> index 0000000..a4867d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> @@ -0,0 +1,55 @@
> +* Freescale MPC512x DMA Controller
> +
> +The DMA controller in the Freescale MPC512x SoC can move blocks of
> +memory contents between memory and peripherals or memory to memory.
> +
> +Refer to the "Generic DMA Controller and DMA request bindings" description
> +in the dma.txt file for a more detailled discussion of the binding. The
> +MPC512x DMA engine binding follows the common scheme, but doesn't provide
> +support for the optional channels and requests counters (those values are
> +derived from the detected hardware features) and has a fixed client
> +specifier length of 1 integer cell (the value is the DMA channel, since
> +the DMA controller uses a fixed assignment of request lines per channel).
The fact that #dma-cells must be <1> isn't a difference from the
standard binding, and needs not be described here. The meaning of the
value should be in your description of #dma-cells below.
I'm not sure it's worth mentioning optional channels / request counters.
If anything, it would be better to update dma.txt to move the "Optional
properties" to something like "Suggested properties"...
> +
> +
> +DMA controller node properties:
> +
> +Required properties:
> +- compatible: should be "fsl,mpc5121-dma"
> +- reg: address and size of the DMA controller's register set
> +- interrupts: interrupt spec for the DMA controller
> +
> +Optional properties:
> +- #dma-cells: must be <1>, describes the number of integer cells
> + needed to specify the 'dmas' property in client nodes,
> + strongly recommended since common client helper code
> + uses this property
Rather than redundantly describing what the standard property means, it
would be better to describe what the cell actually means (i.e. which
value maps to which DMA channel in hardware, how many their are, etc).
> +
> +Example:
> +
> + dma0: dma@14000 {
> + compatible = "fsl,mpc5121-dma";
> + reg = <0x14000 0x1800>;
> + interrupts = <65 0x8>;
> + #dma-cells = <1>;
> + };
> +
> +
> +Client node properties:
> +
> +Required properties:
> +- dmas: list of DMA specifiers, consisting each of a handle
> + for the DMA controller and integer cells to specify
> + the channel used within the DMA controller
> +- dma-names: list of identifier strings for the DMA specifiers,
> + client device driver code uses these strings to
> + have DMA channels looked up at the controller
> +
I don't think its necessary or helpful to describe the client binding
here, it's in dma.txt
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup
From: Arnd Bergmann @ 2013-11-18 14:31 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen, Vinod Koul,
Gerhard Sittig, Alexander Popov, Dan Williams, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131118120957.GH30853@e106331-lin.cambridge.arm.com>
On Monday 18 November 2013, Mark Rutland wrote:
> > +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> > @@ -0,0 +1,55 @@
> > +* Freescale MPC512x DMA Controller
> > +
> > +The DMA controller in the Freescale MPC512x SoC can move blocks of
> > +memory contents between memory and peripherals or memory to memory.
> > +
> > +Refer to the "Generic DMA Controller and DMA request bindings" description
> > +in the dma.txt file for a more detailled discussion of the binding. The
> > +MPC512x DMA engine binding follows the common scheme, but doesn't provide
> > +support for the optional channels and requests counters (those values are
> > +derived from the detected hardware features) and has a fixed client
> > +specifier length of 1 integer cell (the value is the DMA channel, since
> > +the DMA controller uses a fixed assignment of request lines per channel).
>
> The fact that #dma-cells must be <1> isn't a difference from the
> standard binding, and needs not be described here. The meaning of the
> value should be in your description of #dma-cells below.
I think the value it has to be in there, and I have in the past asked other
people to add this. Note that in the generic binding, it says that it must
be "at least 1". You can have controllers that require a larger number, or
that can use 1 or 2 alternatively, depending on how the device is wired
up, e.g. when a dma controller has two master ports you would need a
second cell to specify the port number, but only if more than one port
is actually connected to a slave.
> I'm not sure it's worth mentioning optional channels / request counters.
> If anything, it would be better to update dma.txt to move the "Optional
> properties" to something like "Suggested properties"...
These are less clearly defined. In the generic binding, it's mostly a matter
of "if you need to pass this information, use these properties". The individual
binding can then make them mandatory if needed.
Arnd
^ permalink raw reply
* Ping^2 Re: [PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes
From: Joseph S. Myers @ 2013-11-18 14:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Liu Yu, linux-kernel, Shan Hai
In-Reply-To: <Pine.LNX.4.64.1311111428160.18663@digraph.polyomino.org.uk>
Ping^2. I still haven't seen any comments on any of these patches.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup
From: Mark Rutland @ 2013-11-18 15:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen, Vinod Koul,
Gerhard Sittig, Alexander Popov, Dan Williams, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <201311181531.54818.arnd@arndb.de>
On Mon, Nov 18, 2013 at 02:31:54PM +0000, Arnd Bergmann wrote:
> On Monday 18 November 2013, Mark Rutland wrote:
> > > +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> > > @@ -0,0 +1,55 @@
> > > +* Freescale MPC512x DMA Controller
> > > +
> > > +The DMA controller in the Freescale MPC512x SoC can move blocks of
> > > +memory contents between memory and peripherals or memory to memory.
> > > +
> > > +Refer to the "Generic DMA Controller and DMA request bindings" description
> > > +in the dma.txt file for a more detailled discussion of the binding. The
> > > +MPC512x DMA engine binding follows the common scheme, but doesn't provide
> > > +support for the optional channels and requests counters (those values are
> > > +derived from the detected hardware features) and has a fixed client
> > > +specifier length of 1 integer cell (the value is the DMA channel, since
> > > +the DMA controller uses a fixed assignment of request lines per channel).
> >
> > The fact that #dma-cells must be <1> isn't a difference from the
> > standard binding, and needs not be described here. The meaning of the
> > value should be in your description of #dma-cells below.
>
> I think the value it has to be in there, and I have in the past asked other
> people to add this. Note that in the generic binding, it says that it must
> be "at least 1". You can have controllers that require a larger number, or
> that can use 1 or 2 alternatively, depending on how the device is wired
> up, e.g. when a dma controller has two master ports you would need a
> second cell to specify the port number, but only if more than one port
> is actually connected to a slave.
The number of cells required should be described. My points were that it
should be described at the property description rather than in the introduction,
and that the fact that a specific value was required was not a
difference from the bindings as the paragraph implied.
>
> > I'm not sure it's worth mentioning optional channels / request counters.
> > If anything, it would be better to update dma.txt to move the "Optional
> > properties" to something like "Suggested properties"...
>
> These are less clearly defined. In the generic binding, it's mostly a matter
> of "if you need to pass this information, use these properties". The individual
> binding can then make them mandatory if needed.
Agreed. I'd prefer that bindings described the suggested properties they
used, rather than those they don't.
Thanks,
Mark.
^ permalink raw reply
* Re: Ping^2 Re: [PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes
From: Scott Wood @ 2013-11-18 19:07 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Liu Yu, linuxppc-dev, linux-kernel, Shan Hai
In-Reply-To: <Pine.LNX.4.64.1311181453560.32728@digraph.polyomino.org.uk>
On Mon, 2013-11-18 at 14:54 +0000, Joseph S. Myers wrote:
> Ping^2. I still haven't seen any comments on any of these patches.
>
Sorry for the delay -- I plan to take a look at them, but they came in
too late for the last pull request, especially since I'm not that
familiar with SPE and thus it'll take some time (and I've got other
time-consuming patches yet to review that came in even earlier). As
long as the patches are still "action required" in patchwork, there's no
need to ping unless it's been a few months.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use ELFv2 ABI to build the kernel
From: Scott Wood @ 2013-11-18 19:29 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev
In-Reply-To: <1384755694-30293-1-git-send-email-alistair@popple.id.au>
On Mon, 2013-11-18 at 17:21 +1100, Alistair Popple wrote:
> The kernel doesn't build correctly using the ELFv2 ABI. This patch
> ensures that the ELFv1 ABI is used when building a kernel with an
> ELFv2 enabled compiler.
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> ---
> arch/powerpc/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 607acf5..8a24636 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -111,6 +111,7 @@ endif
> endif
>
> CFLAGS-$(CONFIG_PPC64) := -mtraceback=no -mcall-aixdesc
> +CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,-mminimal-toc)
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
> CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
How hard would it be to get the kernel to work with the new ABI?
Do you know where I can find a document for it?
-Scott
^ permalink raw reply
* Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Scott Wood @ 2013-11-18 19:37 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: joro@8bytes.org, linuxppc-dev@lists.ozlabs.org,
iommu@lists.linux-foundation.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D0A5B0AE8@039-SN2MPN1-012.039d.mgd.msft.net>
On Thu, 2013-11-14 at 21:16 -0600, Sethi Varun-B16395 wrote:
> Haiying/Scott,
> Forgot to mention this, the PAMU driver has to handle stash destination
> settings both for power and dsp cores (on B4 platform). For the dsp
> cores we would expect the physical core id (not controlled by Linux).
> To make the interface consistent, I would expect the caller (for
> iommu_set_attr) to pass the physical core id.
That sounds like you need two different interfaces.
-Scott
^ permalink raw reply
* Re: [PATCH v3] powerpc: kvm: optimize "sc 1" as fast return
From: Alexander Graf @ 2013-11-18 20:45 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: Paul Mackerras, linuxppc-dev, kvm-ppc
In-Reply-To: <1384736947-21437-1-git-send-email-pingfank@linux.vnet.ibm.com>
On 17.11.2013, at 20:09, Liu Ping Fan <qemulist@gmail.com> wrote:
> In some scene, e.g openstack CI, PR guest can trigger "sc 1" =
frequently,
> this patch optimizes the path by directly delivering =
BOOK3S_INTERRUPT_SYSCALL
> to HV guest, so powernv can return to HV guest without heavy exit, =
i.e,
> no need to swap TLB, HTAB,.. etc
>=20
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 6 ------
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 12 +++++++++++-
> 2 files changed, 11 insertions(+), 7 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/book3s_hv.c =
b/arch/powerpc/kvm/book3s_hv.c
> index 62a2b5a..73dc852 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -628,12 +628,6 @@ static int kvmppc_handle_exit(struct kvm_run =
*run, struct kvm_vcpu *vcpu,
> /* hcall - punt to userspace */
> int i;
>=20
> - if (vcpu->arch.shregs.msr & MSR_PR) {
> - /* sc 1 from userspace - reflect to guest =
syscall */
> - kvmppc_book3s_queue_irqprio(vcpu, =
BOOK3S_INTERRUPT_SYSCALL);
> - r =3D RESUME_GUEST;
> - break;
> - }
Please document the fact that we never get here for
1) hypercall with MSR_PR
2) hypercall that was handled by rm code
so that when anyone reads the C file he doesn't have to dig through =
piles of asm code to understand what's happening.
> run->papr_hcall.nr =3D kvmppc_get_gpr(vcpu, 3);
> for (i =3D 0; i < 9; ++i)
> run->papr_hcall.args[i] =3D kvmppc_get_gpr(vcpu, =
4 + i);
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S =
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index c71103b..0d1e2c2 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1388,7 +1388,8 @@ kvmppc_hisi:
> hcall_try_real_mode:
> ld r3,VCPU_GPR(R3)(r9)
> andi. r0,r11,MSR_PR
> - bne guest_exit_cont
> + /* sc 1 from userspace - reflect to guest syscall */
> + bne sc_1_fast_return
> clrrdi r3,r3,2
> cmpldi r3,hcall_real_table_end - hcall_real_table
> bge guest_exit_cont
> @@ -1409,6 +1410,15 @@ hcall_try_real_mode:
> ld r11,VCPU_MSR(r4)
> b fast_guest_return
>=20
> +sc_1_fast_return:
> + mtspr SPRN_SRR0,r10
> + mtspr SPRN_SRR1,r11
> + li r10, BOOK3S_INTERRUPT_SYSCALL
> + li r11, (MSR_ME << 1) | 1 /* synthesize MSR_SF | MSR_ME */
> + rotldi r11, r11, 63
> + mr r4,r9
> + b fast_guest_return
While at it, please also document the input registers to =
fast_guest_return. As you've seen it's very easy to get them right when =
they're not properly documented in the header of the function.
Apart from these minor bits, the patch looks very sound and hopefully =
speeds up PR-in-HV by quite a bit.
Alex
^ permalink raw reply
* Re: [PATCH v4] powerpc: kvm: fix rare but potential deadlock scene
From: Alexander Graf @ 2013-11-18 21:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Liu Ping Fan, kvm-ppc
In-Reply-To: <20131116065517.GA18339@iris.ozlabs.ibm.com>
On 16.11.2013, at 01:55, Paul Mackerras <paulus@samba.org> wrote:
> On Fri, Nov 15, 2013 at 04:35:00PM +0800, Liu Ping Fan wrote:
>> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
>> realmode, so it can trigger the deadlock.
>>
>> Suppose the following scene:
>>
>> Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
>> vcpus.
>>
>> If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched
>> out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be
>> caught in realmode for a long time.
>>
>> What makes things even worse if the following happens,
>> On cpuM, bitlockX is hold, on cpuN, Y is hold.
>> vcpu_B_2 try to lock Y on cpuM in realmode
>> vcpu_A_2 try to lock X on cpuN in realmode
>>
>> Oops! deadlock happens
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>
> Reviewed-by: Paul Mackerras <paulus@samba.org>
Thanks, applied to kvm-ppc-queue.
Alex
^ permalink raw reply
* Re: [PATCH v4] powerpc: kvm: fix rare but potential deadlock scene
From: Alexander Graf @ 2013-11-18 21:43 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Liu Ping Fan, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <6E84B29F-6921-4309-9A73-3AD8D8C6872A@suse.de>
On 18.11.2013, at 16:32, Alexander Graf <agraf@suse.de> wrote:
>=20
> On 16.11.2013, at 01:55, Paul Mackerras <paulus@samba.org> wrote:
>=20
>> On Fri, Nov 15, 2013 at 04:35:00PM +0800, Liu Ping Fan wrote:
>>> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
>>> realmode, so it can trigger the deadlock.
>>>=20
>>> Suppose the following scene:
>>>=20
>>> Two physical cpuM, cpuN, two VM instances A, B, each VM has a group =
of
>>> vcpus.
>>>=20
>>> If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is =
switched
>>> out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will =
be
>>> caught in realmode for a long time.
>>>=20
>>> What makes things even worse if the following happens,
>>> On cpuM, bitlockX is hold, on cpuN, Y is hold.
>>> vcpu_B_2 try to lock Y on cpuM in realmode
>>> vcpu_A_2 try to lock X on cpuN in realmode
>>>=20
>>> Oops! deadlock happens
>>>=20
>>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>>=20
>> Reviewed-by: Paul Mackerras <paulus@samba.org>
>=20
> Thanks, applied to kvm-ppc-queue.
Actually, I've changed my mind and moved the patch to the for-3.13 =
branch instead. Please make sure to CC kvm@vger on all patches you =
submit though.
Alex
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use ELFv2 ABI to build the kernel
From: Alistair Popple @ 2013-11-19 0:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1384802965.1403.304.camel@snotra.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Mon, 18 Nov 2013 13:29:25 Scott Wood wrote:
> On Mon, 2013-11-18 at 17:21 +1100, Alistair Popple wrote:
[snip]
>
> How hard would it be to get the kernel to work with the new ABI?
We are preparing patches at the moment to allow the kernel to support a
userspace compiled with the new ABI, however the kernel itself still needs to
be built using the old ABI.
I'm not sure how hard it would be to compile a kernel with the new ABI. It
mostly compiles now however I'm guessing there's probably some code that would
need porting to make it functional.
> Do you know where I can find a document for it?
The ABI is still under development so there isn't any documentation available
for it yet.
> -Scott
Regards,
Alistair
[-- Attachment #2: Type: text/html, Size: 4307 bytes --]
^ permalink raw reply
* RE: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Varun Sethi @ 2013-11-19 2:42 UTC (permalink / raw)
To: Scott Wood
Cc: joro@8bytes.org, linuxppc-dev@lists.ozlabs.org,
iommu@lists.linux-foundation.org
In-Reply-To: <1384803449.1403.313.camel@snotra.buserror.net>
Rm9yIHRoZSBEU1AgY2FzZSBhZ2FpbiB3ZSBoYXZlIHRvIHNldCB1cCB0aGUgc3Rhc2ggYXR0cmli
dXRlLiBBcmUgeW91IHNheWluZyB0aGF0IHRoaXMgc2hvdWxkIGJlIGEgc2VwYXJhdGUgYXR0cmli
dXRlPyANCg0KLVZhcnVuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
V29vZCBTY290dC1CMDc0MjENCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTksIDIwMTMgMTow
NyBBTQ0KPiBUbzogU2V0aGkgVmFydW4tQjE2Mzk1DQo+IENjOiBXYW5nIEhhaXlpbmctUjU0OTY0
OyBqb3JvQDhieXRlcy5vcmc7IGlvbW11QGxpc3RzLmxpbnV4LQ0KPiBmb3VuZGF0aW9uLm9yZzsg
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gaW9t
bXUvZnNsX3BhbXU6IHVzZSBwaHlzaWNhbCBjcHUgaW5kZXggdG8gZmluZCB0aGUNCj4gbWF0Y2hl
ZCBjcHUgbm9kZXMNCj4gDQo+IE9uIFRodSwgMjAxMy0xMS0xNCBhdCAyMToxNiAtMDYwMCwgU2V0
aGkgVmFydW4tQjE2Mzk1IHdyb3RlOg0KPiA+IEhhaXlpbmcvU2NvdHQsDQo+ID4gRm9yZ290IHRv
IG1lbnRpb24gdGhpcywgdGhlIFBBTVUgZHJpdmVyIGhhcyB0byBoYW5kbGUgc3Rhc2gNCj4gPiBk
ZXN0aW5hdGlvbiBzZXR0aW5ncyBib3RoIGZvciBwb3dlciBhbmQgZHNwIGNvcmVzIChvbiBCNCBw
bGF0Zm9ybSkuDQo+ID4gRm9yIHRoZSBkc3AgY29yZXMgd2Ugd291bGQgZXhwZWN0IHRoZSBwaHlz
aWNhbCBjb3JlIGlkIChub3QgY29udHJvbGxlZA0KPiBieSBMaW51eCkuDQo+ID4gVG8gbWFrZSB0
aGUgaW50ZXJmYWNlIGNvbnNpc3RlbnQsIEkgd291bGQgZXhwZWN0IHRoZSBjYWxsZXIgKGZvcg0K
PiA+IGlvbW11X3NldF9hdHRyKSB0byBwYXNzIHRoZSBwaHlzaWNhbCBjb3JlIGlkLg0KPiANCj4g
VGhhdCBzb3VuZHMgbGlrZSB5b3UgbmVlZCB0d28gZGlmZmVyZW50IGludGVyZmFjZXMuDQo+IA0K
PiAtU2NvdHQNCj4gDQoNCg==
^ permalink raw reply
* Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Scott Wood @ 2013-11-19 3:04 UTC (permalink / raw)
To: Varun Sethi
Cc: joro@8bytes.org, linuxppc-dev@lists.ozlabs.org,
iommu@lists.linux-foundation.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D0A5B966D@039-SN2MPN1-012.039d.mgd.msft.net>
On Mon, 2013-11-18 at 20:42 -0600, Varun Sethi wrote:
> For the DSP case again we have to set up the stash attribute. Are you saying that this should be a separate attribute?
Not necessarily a separate attribute, but there should be some way to
distinguish whether you're providing a Linux cpu number or some external
stash destination.
-Scott
^ permalink raw reply
* RE: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Varun Sethi @ 2013-11-19 3:09 UTC (permalink / raw)
To: Scott Wood
Cc: joro@8bytes.org, linuxppc-dev@lists.ozlabs.org,
iommu@lists.linux-foundation.org
In-Reply-To: <1384830256.1403.340.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTksIDIwMTMgODozNCBBTQ0KPiBUbzogU2V0
aGkgVmFydW4tQjE2Mzk1DQo+IENjOiBXYW5nIEhhaXlpbmctUjU0OTY0OyBqb3JvQDhieXRlcy5v
cmc7IGlvbW11QGxpc3RzLmxpbnV4LQ0KPiBmb3VuZGF0aW9uLm9yZzsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gaW9tbXUvZnNsX3BhbXU6IHVz
ZSBwaHlzaWNhbCBjcHUgaW5kZXggdG8gZmluZCB0aGUNCj4gbWF0Y2hlZCBjcHUgbm9kZXMNCj4g
DQo+IE9uIE1vbiwgMjAxMy0xMS0xOCBhdCAyMDo0MiAtMDYwMCwgVmFydW4gU2V0aGkgd3JvdGU6
DQo+ID4gRm9yIHRoZSBEU1AgY2FzZSBhZ2FpbiB3ZSBoYXZlIHRvIHNldCB1cCB0aGUgc3Rhc2gg
YXR0cmlidXRlLiBBcmUgeW91DQo+IHNheWluZyB0aGF0IHRoaXMgc2hvdWxkIGJlIGEgc2VwYXJh
dGUgYXR0cmlidXRlPw0KPiANCj4gTm90IG5lY2Vzc2FyaWx5IGEgc2VwYXJhdGUgYXR0cmlidXRl
LCBidXQgdGhlcmUgc2hvdWxkIGJlIHNvbWUgd2F5IHRvDQo+IGRpc3Rpbmd1aXNoIHdoZXRoZXIg
eW91J3JlIHByb3ZpZGluZyBhIExpbnV4IGNwdSBudW1iZXIgb3Igc29tZSBleHRlcm5hbA0KPiBz
dGFzaCBkZXN0aW5hdGlvbi4NClllcywgdGhlIGN1cnJlbnQgaWRlYSBpcyB0byB1c2UgYSBzZXBh
cmF0ZSBMMiBjYWNoZSB0eXBlIGZvciB0aGUgRFNQIGNvcmVzIChQQU1VX0RTUF9MMl9DQUNIRSku
IERTUCBjb3JlcyBjYW4gc3Rhc2ggb25seSB0byB0aGUgTDIgY2FjaGUuDQoNCi1WYXJ1bg0KDQoN
Cg==
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use ELFv2 ABI to build the kernel
From: Michael Ellerman @ 2013-11-19 3:25 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev
In-Reply-To: <1384755694-30293-1-git-send-email-alistair@popple.id.au>
On Mon, Nov 18, 2013 at 05:21:34PM +1100, Alistair Popple wrote:
> The kernel doesn't build correctly using the ELFv2 ABI. This patch
> ensures that the ELFv1 ABI is used when building a kernel with an
> ELFv2 enabled compiler.
Let me check I've got this straight.
The ELFv2 ABI is still being developed, so there are no released
toolchains that support it right?
So this patch is precautionary, in that it means kernels from this
commit onward will build correctly with newer toolchains. Anyone wanting
to build an older kernel with a new toolchain will need to backport this
patch?
cheers
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix compiling error in powernv/rng.c
From: Michael Ellerman @ 2013-11-19 4:04 UTC (permalink / raw)
To: Li Zhong; +Cc: PowerPC email list, Paul Mackerras
In-Reply-To: <1384500964.2491.11.camel@ThinkPad-T5421>
On Fri, Nov 15, 2013 at 03:36:04PM +0800, Li Zhong wrote:
> This is seen when CONFIG_SMP is not enabled:
>
> arch/powerpc/platforms/powernv/rng.c: In function 'rng_init_per_cpu':
> arch/powerpc/platforms/powernv/rng.c:74: error: implicit declaration of function 'cpu_to_chip_id'
Hi Li,
We try whenever possible to avoid adding #ifdefs in C code.
Also on a multi chip system where there are multiple RNGs, your code for
UP will not necessarily choose the RNG on the same core as the cpu.
I have a different fix that I will send.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use ELFv2 ABI to build the kernel
From: Alistair Popple @ 2013-11-19 4:06 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20131119032553.GA27740@concordia>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
On Tue, 19 Nov 2013 14:25:53 Michael Ellerman wrote:
> On Mon, Nov 18, 2013 at 05:21:34PM +1100, Alistair Popple wrote:
> > The kernel doesn't build correctly using the ELFv2 ABI. This patch
> > ensures that the ELFv1 ABI is used when building a kernel with an
> > ELFv2 enabled compiler.
>
> Let me check I've got this straight.
>
> The ELFv2 ABI is still being developed, so there are no released
> toolchains that support it right?
I believe ELFv2 patches started going upstream to gcc last week.
> So this patch is precautionary, in that it means kernels from this
> commit onward will build correctly with newer toolchains. Anyone wanting
> to build an older kernel with a new toolchain will need to backport this
> patch?
No, only people wanting to build PPC64 little endian kernels with newer
toolchains should need this (as ELFv2 is the default for PPC64LE). In all
cases execpt PPC64LE the newer toolchains should default to ELFv1.
> cheers
Regards,
Alistair
[-- Attachment #2: Type: text/html, Size: 5114 bytes --]
^ permalink raw reply
* [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Bharat Bhushan @ 2013-11-19 5:17 UTC (permalink / raw)
To: alex.williamson, joro, bhelgaas, agraf, scottwood, stuart.yoder,
iommu, linux-pci, linuxppc-dev, linux-kernel
Cc: Bharat Bhushan
From: Bharat Bhushan <bharat.bhushan@freescale.com>
PAMU (FSL IOMMU) has a concept of primary window and subwindows.
Primary window corresponds to the complete guest iova address space
(including MSI space), with respect to IOMMU_API this is termed as
geometry. IOVA Base of subwindow is determined from the number of
subwindows (configurable using iommu API).
MSI I/O page must be within the geometry and maximum supported
subwindows, so MSI IO-page is setup just after guest memory iova space.
So patch 1/9-4/9(inclusive) are for defining the interface to get:
- Number of MSI regions (which is number of MSI banks for powerpc)
- MSI-region address range: Physical page which have the
address/addresses used for generating MSI interrupt
and size of the page.
Patch 5/9-7/9(inclusive) is defining the interface of setting up
MSI iova-base for a msi region(bank) for a device. so that when
msi-message will be composed then this configured iova will be used.
Earlier we were using iommu interface for getting the configured iova
which was not currect and Alex Williamson suggeested this type of interface.
patch 8/9 moves some common functions in a separate file so that these
can be used by FSL_PAMU implementation (next patch uses this).
These will be used later for iommu-none implementation. I believe we
can do more of this but will take step by step.
Finally last patch actually adds the support for FSL-PAMU :)
v1->v2
- Added interface for setting msi iova for a msi region for a device.
Earlier I added iommu interface for same but as per comment that is
removed and now created a direct interface between vfio and msi.
- Incorporated review comments (details is in individual patch)
Bharat Bhushan (9):
pci:msi: add weak function for returning msi region info
pci: msi: expose msi region information functions
powerpc: pci: Add arch specific msi region interface
powerpc: msi: Extend the msi region interface to get info from
fsl_msi
pci/msi: interface to set an iova for a msi region
powerpc: pci: Extend msi iova page setup to arch specific
pci: msi: Extend msi iova setting interface to powerpc arch
vfio: moving some functions in common file
vfio pci: Add vfio iommu implementation for FSL_PAMU
arch/powerpc/include/asm/machdep.h | 10 +
arch/powerpc/kernel/msi.c | 28 +
arch/powerpc/sysdev/fsl_msi.c | 132 +++++-
arch/powerpc/sysdev/fsl_msi.h | 25 +-
drivers/pci/msi.c | 35 ++
drivers/vfio/Kconfig | 6 +
drivers/vfio/Makefile | 5 +-
drivers/vfio/vfio_iommu_common.c | 227 ++++++++
drivers/vfio/vfio_iommu_common.h | 27 +
drivers/vfio/vfio_iommu_fsl_pamu.c | 1003 ++++++++++++++++++++++++++++++++++++
drivers/vfio/vfio_iommu_type1.c | 206 +--------
include/linux/msi.h | 14 +
include/linux/pci.h | 21 +
include/uapi/linux/vfio.h | 100 ++++
14 files changed, 1623 insertions(+), 216 deletions(-)
create mode 100644 drivers/vfio/vfio_iommu_common.c
create mode 100644 drivers/vfio/vfio_iommu_common.h
create mode 100644 drivers/vfio/vfio_iommu_fsl_pamu.c
^ permalink raw reply
* [PATCH 1/9 v2] pci:msi: add weak function for returning msi region info
From: Bharat Bhushan @ 2013-11-19 5:17 UTC (permalink / raw)
To: alex.williamson, joro, bhelgaas, agraf, scottwood, stuart.yoder,
iommu, linux-pci, linuxppc-dev, linux-kernel
Cc: Bharat Bhushan
In-Reply-To: <1384838233-24847-1-git-send-email-Bharat.Bhushan@freescale.com>
In Aperture type of IOMMU (like FSL PAMU), VFIO-iommu system need to know
the MSI region to map its window in h/w. This patch just defines the
required weak functions only and will be used by followup patches.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v1->v2
- Added description on "struct msi_region"
drivers/pci/msi.c | 22 ++++++++++++++++++++++
include/linux/msi.h | 14 ++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d5f90d6..2643a29 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -67,6 +67,28 @@ int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
return chip->check_device(chip, dev, nvec, type);
}
+int __weak arch_msi_get_region_count(void)
+{
+ return 0;
+}
+
+int __weak arch_msi_get_region(int region_num, struct msi_region *region)
+{
+ return 0;
+}
+
+int msi_get_region_count(void)
+{
+ return arch_msi_get_region_count();
+}
+EXPORT_SYMBOL(msi_get_region_count);
+
+int msi_get_region(int region_num, struct msi_region *region)
+{
+ return arch_msi_get_region(region_num, region);
+}
+EXPORT_SYMBOL(msi_get_region);
+
int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
diff --git a/include/linux/msi.h b/include/linux/msi.h
index b17ead8..ade1480 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -51,6 +51,18 @@ struct msi_desc {
};
/*
+ * This structure is used to get
+ * - physical address
+ * - size
+ * of a msi region
+ */
+struct msi_region {
+ int region_num; /* MSI region number */
+ dma_addr_t addr; /* Address of MSI region */
+ size_t size; /* Size of MSI region */
+};
+
+/*
* The arch hooks to setup up msi irqs. Those functions are
* implemented as weak symbols so that they /can/ be overriden by
* architecture specific code if needed.
@@ -64,6 +76,8 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
void default_teardown_msi_irqs(struct pci_dev *dev);
void default_restore_msi_irqs(struct pci_dev *dev, int irq);
+int arch_msi_get_region_count(void);
+int arch_msi_get_region(int region_num, struct msi_region *region);
struct msi_chip {
struct module *owner;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/9 v2] pci: msi: expose msi region information functions
From: Bharat Bhushan @ 2013-11-19 5:17 UTC (permalink / raw)
To: alex.williamson, joro, bhelgaas, agraf, scottwood, stuart.yoder,
iommu, linux-pci, linuxppc-dev, linux-kernel
Cc: Bharat Bhushan
In-Reply-To: <1384838233-24847-1-git-send-email-Bharat.Bhushan@freescale.com>
So by now we have defined all the interfaces for getting the msi region,
this patch expose the interface to linux subsystem. These will be used by
vfio subsystem for setting up iommu for MSI interrupt of direct assignment
devices.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v1->v2
- None
include/linux/pci.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index da172f9..c587034 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1142,6 +1142,7 @@ struct msix_entry {
u16 entry; /* driver uses to specify entry, OS writes */
};
+struct msi_region;
#ifndef CONFIG_PCI_MSI
static inline int pci_enable_msi_block(struct pci_dev *dev, unsigned int nvec)
@@ -1184,6 +1185,16 @@ static inline int pci_msi_enabled(void)
{
return 0;
}
+
+static inline int msi_get_region_count(void)
+{
+ return 0;
+}
+
+static inline int msi_get_region(int region_num, struct msi_region *region)
+{
+ return 0;
+}
#else
int pci_enable_msi_block(struct pci_dev *dev, unsigned int nvec);
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *maxvec);
@@ -1196,6 +1207,8 @@ void pci_disable_msix(struct pci_dev *dev);
void msi_remove_pci_irq_vectors(struct pci_dev *dev);
void pci_restore_msi_state(struct pci_dev *dev);
int pci_msi_enabled(void);
+int msi_get_region_count(void);
+int msi_get_region(int region_num, struct msi_region *region);
#endif
#ifdef CONFIG_PCIEPORTBUS
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/9 v2] powerpc: pci: Add arch specific msi region interface
From: Bharat Bhushan @ 2013-11-19 5:17 UTC (permalink / raw)
To: alex.williamson, joro, bhelgaas, agraf, scottwood, stuart.yoder,
iommu, linux-pci, linuxppc-dev, linux-kernel
Cc: Bharat Bhushan
In-Reply-To: <1384838233-24847-1-git-send-email-Bharat.Bhushan@freescale.com>
This patch adds the interface to get the msi region information from arch
specific code. The machine spicific code is not yet defined.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v1->v2
- None
arch/powerpc/include/asm/machdep.h | 8 ++++++++
arch/powerpc/kernel/msi.c | 18 ++++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 8b48090..8d1b787 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -30,6 +30,7 @@ struct file;
struct pci_controller;
struct kimage;
struct pci_host_bridge;
+struct msi_region;
struct machdep_calls {
char *name;
@@ -124,6 +125,13 @@ struct machdep_calls {
int (*setup_msi_irqs)(struct pci_dev *dev,
int nvec, int type);
void (*teardown_msi_irqs)(struct pci_dev *dev);
+
+ /* Returns the number of MSI regions (banks) */
+ int (*msi_get_region_count)(void);
+
+ /* Returns the requested region's address and size */
+ int (*msi_get_region)(int region_num,
+ struct msi_region *region);
#endif
void (*restart)(char *cmd);
diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
index 8bbc12d..1a67787 100644
--- a/arch/powerpc/kernel/msi.c
+++ b/arch/powerpc/kernel/msi.c
@@ -13,6 +13,24 @@
#include <asm/machdep.h>
+int arch_msi_get_region_count(void)
+{
+ if (ppc_md.msi_get_region_count) {
+ pr_debug("msi: Using platform get_region_count routine.\n");
+ return ppc_md.msi_get_region_count();
+ }
+ return 0;
+}
+
+int arch_msi_get_region(int region_num, struct msi_region *region)
+{
+ if (ppc_md.msi_get_region) {
+ pr_debug("msi: Using platform get_region routine.\n");
+ return ppc_md.msi_get_region(region_num, region);
+ }
+ return 0;
+}
+
int arch_msi_check_device(struct pci_dev* dev, int nvec, int type)
{
if (!ppc_md.setup_msi_irqs || !ppc_md.teardown_msi_irqs) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/9 v2] powerpc: msi: Extend the msi region interface to get info from fsl_msi
From: Bharat Bhushan @ 2013-11-19 5:17 UTC (permalink / raw)
To: alex.williamson, joro, bhelgaas, agraf, scottwood, stuart.yoder,
iommu, linux-pci, linuxppc-dev, linux-kernel
Cc: Bharat Bhushan
In-Reply-To: <1384838233-24847-1-git-send-email-Bharat.Bhushan@freescale.com>
The FSL MSI will provide the interface to get:
- Number of MSI regions (which is number of MSI banks for powerpc)
- Get the region address range: Physical page which have the
address/addresses used for generating MSI interrupt
and size of the page.
These are required to create IOMMU (Freescale PAMU) mapping for
devices which are directly assigned using VFIO.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v1->v2
- Atomic increment of bank index for parallel probe of msi node
arch/powerpc/sysdev/fsl_msi.c | 42 +++++++++++++++++++++++++++++++++++-----
arch/powerpc/sysdev/fsl_msi.h | 11 ++++++++-
2 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 77efbae..eeebbf0 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -109,6 +109,34 @@ static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
return 0;
}
+static int fsl_msi_get_region_count(void)
+{
+ int count = 0;
+ struct fsl_msi *msi_data;
+
+ list_for_each_entry(msi_data, &msi_head, list)
+ count++;
+
+ return count;
+}
+
+static int fsl_msi_get_region(int region_num, struct msi_region *region)
+{
+ struct fsl_msi *msi_data;
+
+ list_for_each_entry(msi_data, &msi_head, list) {
+ if (msi_data->bank_index == region_num) {
+ region->region_num = msi_data->bank_index;
+ /* Setting PAGE_SIZE as MSIIR is a 4 byte register */
+ region->size = PAGE_SIZE;
+ region->addr = msi_data->msiir & ~(region->size - 1);
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+
static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
{
if (type == PCI_CAP_ID_MSIX)
@@ -150,7 +178,8 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
if (reg && (len == sizeof(u64)))
address = be64_to_cpup(reg);
else
- address = fsl_pci_immrbar_base(hose) + msi_data->msiir_offset;
+ address = fsl_pci_immrbar_base(hose) +
+ (msi_data->msiir & 0xfffff);
msg->address_lo = lower_32_bits(address);
msg->address_hi = upper_32_bits(address);
@@ -393,6 +422,7 @@ static int fsl_of_msi_probe(struct platform_device *dev)
const struct fsl_msi_feature *features;
int len;
u32 offset;
+ static atomic_t bank_index = ATOMIC_INIT(-1);
match = of_match_device(fsl_of_msi_ids, &dev->dev);
if (!match)
@@ -436,18 +466,15 @@ static int fsl_of_msi_probe(struct platform_device *dev)
dev->dev.of_node->full_name);
goto error_out;
}
- msi->msiir_offset =
- features->msiir_offset + (res.start & 0xfffff);
/*
* First read the MSIIR/MSIIR1 offset from dts
* On failure use the hardcode MSIIR offset
*/
if (of_address_to_resource(dev->dev.of_node, 1, &msiir))
- msi->msiir_offset = features->msiir_offset +
- (res.start & MSIIR_OFFSET_MASK);
+ msi->msiir = res.start + features->msiir_offset;
else
- msi->msiir_offset = msiir.start & MSIIR_OFFSET_MASK;
+ msi->msiir = msiir.start;
}
msi->feature = features->fsl_pic_ip;
@@ -521,6 +548,7 @@ static int fsl_of_msi_probe(struct platform_device *dev)
}
}
+ msi->bank_index = atomic_inc_return(&bank_index);
list_add_tail(&msi->list, &msi_head);
/* The multiple setting ppc_md.setup_msi_irqs will not harm things */
@@ -528,6 +556,8 @@ static int fsl_of_msi_probe(struct platform_device *dev)
ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
ppc_md.msi_check_device = fsl_msi_check_device;
+ ppc_md.msi_get_region_count = fsl_msi_get_region_count;
+ ppc_md.msi_get_region = fsl_msi_get_region;
} else if (ppc_md.setup_msi_irqs != fsl_setup_msi_irqs) {
dev_err(&dev->dev, "Different MSI driver already installed!\n");
err = -ENODEV;
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index df9aa9f..a2cc5a2 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -31,14 +31,21 @@ struct fsl_msi {
struct irq_domain *irqhost;
unsigned long cascade_irq;
-
- u32 msiir_offset; /* Offset of MSIIR, relative to start of CCSR */
+ phys_addr_t msiir; /* MSIIR Address in CCSR */
u32 ibs_shift; /* Shift of interrupt bit select */
u32 srs_shift; /* Shift of the shared interrupt register select */
void __iomem *msi_regs;
u32 feature;
int msi_virqs[NR_MSI_REG_MAX];
+ /*
+ * During probe each bank is assigned a index number.
+ * index number start from 0.
+ * Example MSI bank 1 = 0
+ * MSI bank 2 = 1, and so on.
+ */
+ int bank_index;
+
struct msi_bitmap bitmap;
struct list_head list; /* support multiple MSI banks */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/9 v2] pci/msi: interface to set an iova for a msi region
From: Bharat Bhushan @ 2013-11-19 5:17 UTC (permalink / raw)
To: alex.williamson, joro, bhelgaas, agraf, scottwood, stuart.yoder,
iommu, linux-pci, linuxppc-dev, linux-kernel
Cc: Bharat Bhushan
In-Reply-To: <1384838233-24847-1-git-send-email-Bharat.Bhushan@freescale.com>
This patch defines an interface by which a msi page
can be mapped to a specific iova page.
This is a requirement in aperture type of IOMMUs (like Freescale PAMU),
where we map msi iova page just after guest memory iova address.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v2
- new patch
drivers/pci/msi.c | 13 +++++++++++++
include/linux/pci.h | 8 ++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 2643a29..040609f 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -77,6 +77,19 @@ int __weak arch_msi_get_region(int region_num, struct msi_region *region)
return 0;
}
+int __weak arch_msi_set_iova(struct pci_dev *pdev, int region_num,
+ dma_addr_t iova, bool set)
+{
+ return 0;
+}
+
+int msi_set_iova(struct pci_dev *pdev, int region_num,
+ dma_addr_t iova, bool set)
+{
+ return arch_msi_set_iova(pdev, region_num, iova, set);
+}
+EXPORT_SYMBOL(msi_set_iova);
+
int msi_get_region_count(void)
{
return arch_msi_get_region_count();
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c587034..c6d3e58 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1195,6 +1195,12 @@ static inline int msi_get_region(int region_num, struct msi_region *region)
{
return 0;
}
+
+static inline int msi_set_iova(struct pci_dev *pdev, int region_num,
+ dma_addr_t iova, bool set)
+{
+ return 0;
+}
#else
int pci_enable_msi_block(struct pci_dev *dev, unsigned int nvec);
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *maxvec);
@@ -1209,6 +1215,8 @@ void pci_restore_msi_state(struct pci_dev *dev);
int pci_msi_enabled(void);
int msi_get_region_count(void);
int msi_get_region(int region_num, struct msi_region *region);
+int msi_set_iova(struct pci_dev *pdev, int region_num,
+ dma_addr_t iova, bool set);
#endif
#ifdef CONFIG_PCIEPORTBUS
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox