Re: [PATCH v2 14/14] Kconfig cleanup (PARPORT_PC dependencies)
* Mark Salter wrote: > Remove messy dependencies from PARPORT_PC by having it depend on one > Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures > which need it, select ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig. > New architectures are unlikely to need PARPORT_PC, so this avoids > having an ever growing list of architectures to exclude. Those > architectures which do select ARCH_MAY_HAVE_PC_PARPORT in this > patch are the ones which have an asm/parport.h (or use the generic > version). > > Signed-off-by: Mark Salter > CC: Richard Henderson > CC: linux-al...@vger.kernel.org > CC: Vineet Gupta > CC: Russell King > CC: linux-arm-ker...@lists.infradead.org > CC: Tony Luck > CC: Fenghua Yu > CC: linux-i...@vger.kernel.org > CC: Geert Uytterhoeven > CC: linux-m...@lists.linux-m68k.org > CC: Michal Simek > CC: microblaze-ucli...@itee.uq.edu.au > CC: Ralf Baechle > CC: linux-m...@linux-mips.org > CC: "James E.J. Bottomley" > CC: Helge Deller > CC: linux-par...@vger.kernel.org > CC: Benjamin Herrenschmidt > CC: Paul Mackerras > CC: linuxppc-dev@lists.ozlabs.org > CC: Paul Mundt > CC: linux...@vger.kernel.org > CC: "David S. Miller" > CC: sparcli...@vger.kernel.org > CC: Guan Xuetao > CC: Thomas Gleixner > CC: Ingo Molnar > CC: "H. Peter Anvin" > CC: x...@kernel.org > --- > drivers/parport/Kconfig | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig > index 70694ce..a079b18 100644 > --- a/drivers/parport/Kconfig > +++ b/drivers/parport/Kconfig > @@ -31,13 +31,17 @@ menuconfig PARPORT > > If unsure, say Y. > > +config ARCH_MAY_HAVE_PC_PARPORT > + bool > + help > + Select this config option from the architecture Kconfig if > + the architecture may have PC parallel port hardware. > + > if PARPORT > > config PARPORT_PC > tristate "PC-style hardware" > - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \ > - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \ > - !XTENSA && !CRIS && !H8300 > + depends on ARCH_MAY_HAVE_PC_PARPORT > > ---help--- > You should say Y here if you have a PC-style parallel port. All Since it's not a permission to have a parallel port but a possibility, I suspect the whole series needs a: s/MAY_HAVE/MIGHT_HAVE s/may have/might have Otherwise: Acked-by: Ingo Molnar Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 14/14] Kconfig cleanup (PARPORT_PC dependencies)
Remove messy dependencies from PARPORT_PC by having it depend on one Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures which need it, select ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig. New architectures are unlikely to need PARPORT_PC, so this avoids having an ever growing list of architectures to exclude. Those architectures which do select ARCH_MAY_HAVE_PC_PARPORT in this patch are the ones which have an asm/parport.h (or use the generic version). Signed-off-by: Mark Salter CC: Richard Henderson CC: linux-al...@vger.kernel.org CC: Vineet Gupta CC: Russell King CC: linux-arm-ker...@lists.infradead.org CC: Tony Luck CC: Fenghua Yu CC: linux-i...@vger.kernel.org CC: Geert Uytterhoeven CC: linux-m...@lists.linux-m68k.org CC: Michal Simek CC: microblaze-ucli...@itee.uq.edu.au CC: Ralf Baechle CC: linux-m...@linux-mips.org CC: "James E.J. Bottomley" CC: Helge Deller CC: linux-par...@vger.kernel.org CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: linuxppc-dev@lists.ozlabs.org CC: Paul Mundt CC: linux...@vger.kernel.org CC: "David S. Miller" CC: sparcli...@vger.kernel.org CC: Guan Xuetao CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: x...@kernel.org --- drivers/parport/Kconfig | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig index 70694ce..a079b18 100644 --- a/drivers/parport/Kconfig +++ b/drivers/parport/Kconfig @@ -31,13 +31,17 @@ menuconfig PARPORT If unsure, say Y. +config ARCH_MAY_HAVE_PC_PARPORT + bool + help + Select this config option from the architecture Kconfig if + the architecture may have PC parallel port hardware. + if PARPORT config PARPORT_PC tristate "PC-style hardware" - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \ - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \ - !XTENSA && !CRIS && !H8300 + depends on ARCH_MAY_HAVE_PC_PARPORT ---help--- You should say Y here if you have a PC-style parallel port. All -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 09/14] powerpc: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 38f3b7e..9211207 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -85,6 +85,7 @@ config GENERIC_HWEIGHT config PPC bool default y + select ARCH_MAY_HAVE_PC_PARPORT select BINFMT_ELF select OF select OF_EARLY_FLATTREE -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> This series is against "next" branch in Bjorn's repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
>
> Currently pci_enable_msi_block() and pci_enable_msix() interfaces
> return a error code in case of failure, 0 in case of success and a
> positive value which indicates the number of MSI-X/MSI interrupts
> that could have been allocated. The latter value should be passed
> to a repeated call to the interfaces until a failure or success:
>
>
> for (i = 0; i < FOO_DRIVER_MAXIMUM_NVEC; i++)
> adapter->msix_entries[i].entry = i;
>
> while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
> rc = pci_enable_msix(adapter->pdev,
>adapter->msix_entries, nvec);
> if (rc > 0)
> nvec = rc;
> else
> return rc;
> }
>
> return -ENOSPC;
>
>
> This technique proved to be confusing and error-prone. Vast share
> of device drivers simply fail to follow the described guidelines.
To clarify "Vast share of device drivers":
- 58 drivers call pci_enable_msix()
- 24 try a single allocation and then fallback to MSI/LSI
- 19 use the loop style allocation as above
- 14 try an allocation, and if it fails retry once
- 1 incorrectly continues when pci_enable_msix() returns > 0
So 33 drivers (> 50%) successfully make use of the "confusing and
error-prone" return value.
Another 24 happily ignore it, which is also entirely fine.
And yes, one is buggy, so obviously the interface is too complex. Thanks
drivers/ntb/ntb_hw.c
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts
On Mon, Oct 07, 2013 at 10:00:26AM +0530, Anshuman Khandual wrote: > Right now the `config_bhrb` PMU specific call happens after write_mmcr0 > which actually enables the PMU for event counting and interrupt. So > there is a small window of time where the PMU and BHRB runs without the > required HW branch filter (if any) enabled in BHRB. This can cause some > of the branch samples to be collected through BHRB without any filter > being applied and hence affecting the correctness of the results. This > patch moves the BHRB config function call before enabling the interrupts. Patch looks good. But it reminds me I have an item in my TODO list: - "Why can't config_bhrb() be done in compute_mmcr()" ? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc/kernel/sysfs: cleanup set up macros for PMC/non-PMC SPRs
On Thu, Oct 03, 2013 at 02:57:35PM +0530, Madhavan Srinivasan wrote: > Currently PMC (Performance Monitor Counter) setup macros are used > for other SPRs. Since not all SPRs are PMC related, this patch > modifies the exisiting macro and uses it to setup both PMC and > non PMC SPRs accordingly. > > V3 changes: > > 1) No logic change, just renamed generic macro and removed #define for empty > string > 2) Changes in the comment to explain better. > > V2 changes: > > 1) Modified SYSFS_PMCSETUP to a generic macro with additional parameter > 2) Added PMC and SPR macro to call the generic macro > 3) Changes in the comment to explain better. > > Signed-off-by: Madhavan Srinivasan Acked-by: Michael Ellerman Thanks for putting up with all the bike-shedding. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
On Thu, Oct 03, 2013 at 12:03:25PM -0700, Sukadev Bhattiprolu wrote: > Michael Ellerman [mich...@ellerman.id.au] wrote: > | On Tue, Oct 01, 2013 at 05:15:06PM -0700, Sukadev Bhattiprolu wrote: > | > Implement is_instr_load_store() to detect whether a given instruction > | > is one of the fixed-point or floating-point load/store instructions. > | > This function will be used in a follow-on patch to save memory hierarchy > | > information of the load/store. > | > | Anyway, I think the following logic is all we need for opcode 31: > | > | bool is_load_store(int ext_opcode) > > how about I call this is_load_store_2_06() and add a comment. Horrible > but minimizes chance of misuse. Actually it's is_opcode_31_load_store_2_06() - which is even more horrible :) But you can probably fold it in to the main routine and then call that is_load_store_2_06(). Or whatever seems best, but yeah I think we should make it very clear that it's only for 2.06. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, October 01, 2013 7:06 AM > To: Wang Dongsheng-B40534 > Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and > altivec idle > > On Sun, 2013-09-29 at 01:57 -0500, Wang Dongsheng-B40534 wrote: > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Saturday, September 28, 2013 5:33 AM > > > To: Wang Dongsheng-B40534 > > > Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- > > > d...@lists.ozlabs.org > > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state > > > and altivec idle > > > > > > On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote: > > > > cycle = div_u64(ns * tb_ticks_per_usec, 1000); It's look good. > > > > But why we need: > > > > if (ns >= 1) > > > > cycle = ((ns + 500) / 1000) * tb_ticks_per_usec; ? > > > > > > > > I think "cycle = div_u64(ns * tb_ticks_per_usec, 1000)" is good > > > > enough. :) > > > > > > It's to deal with overflow if a very large value of ns is provided > > > (and/or tb_ticks_per_usec is larger than we expect). > > > > > :), as I think, it's to deal with overflow. But you version cannot do > deal with it. > > Because ns is u64, if ns > 0x_fe0b, ns + 500 will overflow, > And if tb_ticks_per_usec > 1000 and ns > (0x_ / 10) cycle > also will overflow. > > Sigh... It significantly increases the value of ns at which you'll get > overflow problems. :-) I was more concerned with large-but-somewhat- > reasonable values of ns (e.g. than with trying to handle every possible > input. Even without that test, getting overflow is stretching the bounds > of reasonableness (e.g. a 1 GHz timebase would require a timeout of over > 7 months to overflow), but it was low-hanging fruit. And the worst case > is we go to pw20 sooner than the user wanted, so let's not go too > overboard. > > I doubt you would see > 0x_fe0b except if someone is trying > to disable it by setting 0x_ even though a separate API > is provided to cleanly disable it. > > > I think we need to do this: > > > > #define U64_LOW_MASK0xULL > > #define U64_MASK0xULL > > > > u32 tmp_rem; > > u64 ns_u_rem, ns_u, ns_l, ns_l_carry; > > u64 cycle; > > > > ns_u = ns >> 32; > > ns_l = ns & U64_LOW_MASK; > > > > ns_l *= tb_ticks_per_usec; > > ns_l_carry = ns_l >> 32; > > ns_u *= tb_ticks_per_usec; > > ns_u += ns_l_carry; > > > > ns_u = div_u64_rem(ns_u, 1000, &tmp_rem); > > ns_u_rem = tmp_rem; > > ns_l = (ns_l & U64_LOW_MASK) | ((ns_u_rem) << 32); > > ns_l = div_u64(ns_l, 1000); > > > > if (ns_u >> 32) > > cycle = U64_MASK; > > else > > cycle = (ns_u << 32) | (ns_l & U64_LOW_MASK); > > > > I has already tested this code, and works good. :) > > Ugh. I don't think we need to get this complicated (and I'd rather not > spend the time verifying the correctness of this). > > If for some reason we did need something like this in some other context > (I don't want to see it just for pw20), I'd be more inclined to see > general 128-bit mult/divide support. > I would like to use my version,:), because it can handle any situation and we do not need to restrict users. Here is a kind of special way to get the cycle. If this 128-bit situation is more and more, at that time we go to support it. -dongsheng > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/9][v5] powerpc/perf: Export Power8 generic events in sysfs
On Thu, Oct 03, 2013 at 10:57:57AM -0700, Sukadev Bhattiprolu wrote: > Michael Ellerman [mich...@ellerman.id.au] wrote: > | On Tue, Oct 01, 2013 at 05:15:03PM -0700, Sukadev Bhattiprolu wrote: > | > Export generic perf events for Power8 in sysfs. > | > > | > Signed-off-by: Sukadev Bhattiprolu > | > Reviewed-by: Anshuman Khandual > | > --- > | > arch/powerpc/perf/power8-pmu.c | 23 +++ > | > 1 file changed, 23 insertions(+) > | > > | > diff --git a/arch/powerpc/perf/power8-pmu.c > b/arch/powerpc/perf/power8-pmu.c > | > index 976c203..b991b2e 100644 > | > --- a/arch/powerpc/perf/power8-pmu.c > | > +++ b/arch/powerpc/perf/power8-pmu.c > | > @@ -510,6 +510,28 @@ static void power8_disable_pmc(unsigned int pmc, > unsigned long mmcr[]) > | > mmcr[1] &= ~(0xffUL << MMCR1_PMCSEL_SHIFT(pmc + 1)); > | > } > | > > | > +GENERIC_EVENT_ATTR(cpu-cyles,PM_CYC); > | > +GENERIC_EVENT_ATTR(stalled-cycles-frontend, PM_GCT_NOSLOT_CYC); > | > +GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL); > | > +GENERIC_EVENT_ATTR(instructions, PM_INST_CMPL); > | > +GENERIC_EVENT_ATTR(branch-instructions, PM_BRU_FIN); > | > +GENERIC_EVENT_ATTR(branch-misses,PM_BR_MPRED_CMPL); > | > | And here you use PM_ not PME_ - I'm confused. > > It is a bit confusing. The GENERIC_EVENT_ATTR() adds the PME_ prefix. So doesn't that give you PME_PM_CYC ? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
On Thu, Oct 03, 2013 at 01:51:27PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Tuesday, October 01, 2013 04:13:25 PM Michael Ellerman wrote: > > On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > __initdata tag should be placed between the variable name and equal > > > sign for the variable to be placed in the intended .init.data section. > > > > I see lots of other occurences of that in arch/powerpc. Why not send a > > single patch to update them all? > > The other occurences while not following the preferred kernel coding style > are (probably) working OK with gcc. This particular occurence just doesn't > work as it should. Why would the other occurrences work but not this one? Regardless, why don't we just do a single patch to clean them all up to match coding style and (probably) do what they're intended. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/7] iommu: add api to get iommu_domain of a device
> > > Do you really want module dependencies between vfio and your core > > > kernel MSI setup? Look at the vfio external user interface that we've > already defined. > > > That allows other components of the kernel to get a proper reference > > > to a vfio group. From there you can work out how to get what you > > > want. Another alternative is that vfio could register an MSI to > > > IOVA mapping with architecture code when the mapping is created. > > > The MSI setup path could then do a lookup in architecture code for > > > the mapping. You could even store the MSI to IOVA mapping in VFIO > > > and create an interface where SET_IRQ passes that mapping into setup code. > > > > Ok, What I want is to get IOVA associated with a physical address > > (physical address of MSI-bank). > > And currently I do not see a way to know IOVA of a physical address > > and doing all this domain get and then search through all of > > iommu-windows of that domain. > > > > What if we add an iommu-API which can return the IOVA mapping of a > > physical address. Current use case is setting up MSI's for aperture > > type of IOMMU also getting a phys_to_iova() mapping is independent of > > VFIO, your thought? > > A physical address can be mapped to multiple IOVAs, so the interface seems > flawed by design. It also has the same problem as above, it's a backdoor that > can be called asynchronous to the owner of the domain, so what reason is there > to believe the result? It just replaces an iommu_domain pointer with an IOVA. > VFIO knows this mapping, so why are we trying to go behind its back and ask > the > IOMMU? IOMMU is the final place where mapping is created, so may be today it is calling on behalf of VFIO, tomorrow it can be for normal Linux or some other interface. But I am fine to directly talk to vfio and will not try to solve a problem which does not exists today. MSI subsystem knows pdev (pci device) and physical address, then what interface it will use to get the IOVA from VFIO? Thanks -Bharat > Thanks, > > Alex > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
On Thu, 2013-10-03 at 14:52 -0500, Tom Musta wrote: > On 10/3/2013 2:03 PM, Sukadev Bhattiprolu wrote: > > Michael Ellerman [mich...@ellerman.id.au] wrote: > > > | > > | if (lower == 6) > > | if (upper <= 1) > > | return true; > > | return false; > > v > Note that this case covers the lvsl/lvsr instructions, which, despite their > names are not actually loads. So you could eliminate this check and do > just a little bit better. Yes you're right Tom, thanks for checking. I saw "Load" in the name and that was good enough for me :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
Hi Mark, Stephen and other DT maintainers?
The 1/3 had already been acked by Mark, and please have a further look
at this patch 2/3.
The DMA maintainer Vinod needs ack for the DT related patches so that
he can take all this patch set.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 70 +
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 238 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ DMA controller which has same function as EloPlus except that Elo3 has 8
+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg : contains two entries for DMA General Status Registers,
+ i.e. DGSR0 which includes status for channel 1~4, and
+ DGSR1 for channel 5~8
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg : DMA channel specific registers
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
};
-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
};
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-1.dtsi"
dma@101300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 000..3c210e0
--- /dev/null
+++ b/arch/powe
Re: [PATCH -V2 1/2] powerpc: Use HPTE constants when updating hpte bits
"Aneesh Kumar K.V" writes: > From: "Aneesh Kumar K.V" > > Even though we have same value for linux PTE bits and hash PTE pits > use the hash pte bits wen updating hash pte ... > diff --git a/arch/powerpc/platforms/pseries/lpar.c > b/arch/powerpc/platforms/pseries/lpar.c > index 02d6e21..78f2c59 100644 > --- a/arch/powerpc/platforms/pseries/lpar.c > +++ b/arch/powerpc/platforms/pseries/lpar.c > @@ -146,8 +146,9 @@ static long pSeries_lpar_hpte_insert(unsigned long > hpte_group, > flags = 0; > > /* Make pHyp happy */ > - if ((rflags & _PAGE_NO_CACHE) & !(rflags & _PAGE_WRITETHRU)) > - hpte_r &= ~_PAGE_COHERENT; > + if ((rflags & _PAGE_NO_CACHE) && !(rflags & _PAGE_WRITETHRU)) > + hpte_r &= ~HPTE_R_M; > + - if ((rflags & _PAGE_NO_CACHE) & !(rflags & _PAGE_WRITETHRU)) + if ((rflags & _PAGE_NO_CACHE) && !(rflags & _PAGE_WRITETHRU)) the if loop part of the change is already done in upstream. Since V2 was generated after moving V1 patch to a different tree (kvm tree), ended up with that additional change. Let me know if you want me respin the patch > if (firmware_has_feature(FW_FEATURE_XCMO) && !(hpte_r & HPTE_R_N)) > flags |= H_COALESCE_CAND; > -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/7] iommu: add api to get iommu_domain of a device
On Mon, 2013-10-07 at 05:46 +, Bhushan Bharat-R65777 wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, October 04, 2013 11:42 PM
> > To: Bhushan Bharat-R65777
> > Cc: j...@8bytes.org; b...@kernel.crashing.org; ga...@kernel.crashing.org;
> > linux-
> > ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > p...@vger.kernel.org; ag...@suse.de; Wood Scott-B07421; iommu@lists.linux-
> > foundation.org
> > Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain of a device
> >
> > On Fri, 2013-10-04 at 17:23 +, Bhushan Bharat-R65777 wrote:
> > >
> > > > -Original Message-
> > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > Sent: Friday, October 04, 2013 10:43 PM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: j...@8bytes.org; b...@kernel.crashing.org;
> > > > ga...@kernel.crashing.org; linux- ker...@vger.kernel.org;
> > > > linuxppc-dev@lists.ozlabs.org; linux- p...@vger.kernel.org;
> > > > ag...@suse.de; Wood Scott-B07421; iommu@lists.linux- foundation.org
> > > > Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain of a
> > > > device
> > > >
> > > > On Fri, 2013-10-04 at 16:47 +, Bhushan Bharat-R65777 wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > > Sent: Friday, October 04, 2013 9:15 PM
> > > > > > To: Bhushan Bharat-R65777
> > > > > > Cc: j...@8bytes.org; b...@kernel.crashing.org;
> > > > > > ga...@kernel.crashing.org; linux- ker...@vger.kernel.org;
> > > > > > linuxppc-dev@lists.ozlabs.org; linux- p...@vger.kernel.org;
> > > > > > ag...@suse.de; Wood Scott-B07421; iommu@lists.linux-
> > > > > > foundation.org
> > > > > > Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain of a
> > > > > > device
> > > > > >
> > > > > > On Fri, 2013-10-04 at 09:54 +, Bhushan Bharat-R65777 wrote:
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: linux-pci-ow...@vger.kernel.org
> > > > > > > > [mailto:linux-pci-ow...@vger.kernel.org]
> > > > > > > > On Behalf Of Alex Williamson
> > > > > > > > Sent: Wednesday, September 25, 2013 10:16 PM
> > > > > > > > To: Bhushan Bharat-R65777
> > > > > > > > Cc: j...@8bytes.org; b...@kernel.crashing.org;
> > > > > > > > ga...@kernel.crashing.org; linux- ker...@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org; linux- p...@vger.kernel.org;
> > > > > > > > ag...@suse.de; Wood Scott-B07421; iommu@lists.linux-
> > > > > > > > foundation.org; Bhushan Bharat-R65777
> > > > > > > > Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain
> > > > > > > > of a device
> > > > > > > >
> > > > > > > > On Thu, 2013-09-19 at 12:59 +0530, Bharat Bhushan wrote:
> > > > > > > > > This api return the iommu domain to which the device is
> > > > > > > > > attached.
> > > > > > > > > The iommu_domain is required for making API calls related to
> > iommu.
> > > > > > > > > Follow up patches which use this API to know iommu maping.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bharat Bhushan
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > > drivers/iommu/iommu.c | 10 ++
> > > > > > > > > include/linux/iommu.h |7 +++
> > > > > > > > > 2 files changed, 17 insertions(+), 0 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > > > > > > > > index
> > > > > > > > > fbe9ca7..6ac5f50 100644
> > > > > > > > > --- a/drivers/iommu/iommu.c
> > > > > > > > > +++ b/drivers/iommu/iommu.c
> > > > > > > > > @@ -696,6 +696,16 @@ void iommu_detach_device(struct
> > > > > > > > > iommu_domain *domain, struct device *dev) }
> > > > > > > > > EXPORT_SYMBOL_GPL(iommu_detach_device);
> > > > > > > > >
> > > > > > > > > +struct iommu_domain *iommu_get_dev_domain(struct device
> > > > > > > > > *dev) {
> > > > > > > > > + struct iommu_ops *ops = dev->bus->iommu_ops;
> > > > > > > > > +
> > > > > > > > > + if (unlikely(ops == NULL || ops->get_dev_iommu_domain ==
> > NULL))
> > > > > > > > > + return NULL;
> > > > > > > > > +
> > > > > > > > > + return ops->get_dev_iommu_domain(dev); }
> > > > > > > > > +EXPORT_SYMBOL_GPL(iommu_get_dev_domain);
> > > > > > > >
> > > > > > > > What prevents this from racing iommu_domain_free()? There's
> > > > > > > > no references acquired, so there's no reason for the caller
> > > > > > > > to assume the
> > > > > > pointer is valid.
> > > > > > >
> > > > > > > Sorry for late query, somehow this email went into a folder
> > > > > > > and escaped;
> > > > > > >
> > > > > > > Just to be sure, there is not lock at generic "struct
> > > > > > > iommu_domain", but IP
> > > > > > specific structure (link FSL domain) linked in
> > > > > > iommu_domain->priv have a lock, so we need to ensure this race
> > > > > > in FSL iommu code (say drivers/iommu/fsl_pamu_domain.c), right?
> > > > > >
> > > > > > No, it's not suff
Re: [PATCH] powerpc/irq: Don't switch to irq stack from softirq stack
On Mon, Oct 7, 2013 at 2:08 PM, Benjamin Herrenschmidt wrote: > > Linus, I don't have my git repo at hand right now and this is pretty > urgent, can you apply it directly please ? Done. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/irq: Don't switch to irq stack from softirq stack
irq_exit() is now called on the irq stack, which can trigger a switch
to the softirq stack from the irq stack. If an interrupt happens at
that point, we will not properly detect the re-entrancy and clobber
the original return context on the irq stack.
This fixes it. The side effect is to prevent all nesting from softirq
stack to irq stack even in the "safe" case but it's simpler that way
and matches what x86_64 does.
Reported-by: Cédric Le Goater
Tested-by: Cédric Le Goater
Signed-off-by: Benjamin Herrenschmidt
---
Linus, I don't have my git repo at hand right now and this is pretty
urgent, can you apply it directly please ?
Cheers,
Ben.
arch/powerpc/kernel/irq.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 57d286a..c7cb8c2 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -495,14 +495,15 @@ void __do_irq(struct pt_regs *regs)
void do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
- struct thread_info *curtp, *irqtp;
+ struct thread_info *curtp, *irqtp, *sirqtp;
/* Switch to the irq stack to handle this */
curtp = current_thread_info();
irqtp = hardirq_ctx[raw_smp_processor_id()];
+ sirqtp = softirq_ctx[raw_smp_processor_id()];
/* Already there ? */
- if (unlikely(curtp == irqtp)) {
+ if (unlikely(curtp == irqtp || curtp == sirqtp)) {
__do_irq(regs);
set_irq_regs(old_regs);
return;
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Sun, 2013-10-06 at 09:10 +0200, Alexander Gordeev wrote: > On Sun, Oct 06, 2013 at 05:19:46PM +1100, Benjamin Herrenschmidt wrote: > > On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote: > > > In fact, in the current design to address the quota race decently the > > > drivers would have to protect the *loop* to prevent the quota change > > > between a pci_enable_msix() returned a positive number and the the next > > > call to pci_enable_msix() with that number. Is it doable? > > > > I am not advocating for the current design, simply saying that your > > proposal doesn't address this issue while Ben's does. > > There is one major flaw in min-max approach - the generic MSI layer > will have to take decisions on exact number of MSIs to request, not > device drivers. [... No, the min-max functions should be implemented using the same loop that drivers are expected to use now. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Tue, 2013-10-08 at 07:10 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote: > > I don't think the same race condition would happen with the loop. The > > problem case is where multiple msi(x) allocation fails completely > > because the global limit went down before inquiry and allocation. In > > the loop based interface, it'd retry with the lower number. > > > > As long as the number of drivers which need this sort of adaptive > > allocation isn't too high and the common cases can be made simple, I > > don't think the "complex" part of interface is all that important. > > Maybe we can have reserve / cancel type interface or just keep the > > loop with more explicit function names (ie. try_enable or something > > like that). > > I'm thinking a better API overall might just have been to request > individual MSI-X one by one :-) > > We want to be able to request an MSI-X at runtime anyway ... if I want > to dynamically add a queue to my network interface, I want it to be able > to pop a new arbitrary MSI-X. Yes, this would be very useful. > And we don't want to lock drivers into contiguous MSI-X sets either. I don't think there's any such limitation now. The entries array passed to pci_enable_msix() specifies which MSI-X vectors the driver wants to enable. It's usually filled with 0..nvec-1 in order, but not always. And the IRQ numbers returned aren't usually contiguous either, on x86. Ben. > And for the cleanup ... well that's what the "pcim" functions are for, > we can just make MSI-X variants. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 54/77] ntb: Ensure number of MSIs on SNB is enough for the link interrupt
On Mon, Oct 07, 2013 at 08:38:45PM +0200, Alexander Gordeev wrote:
> On Mon, Oct 07, 2013 at 09:50:57AM -0700, Jon Mason wrote:
> > On Sat, Oct 05, 2013 at 11:43:04PM +0200, Alexander Gordeev wrote:
> > > On Wed, Oct 02, 2013 at 05:48:05PM -0700, Jon Mason wrote:
> > > > On Wed, Oct 02, 2013 at 12:49:10PM +0200, Alexander Gordeev wrote:
> > > > > Signed-off-by: Alexander Gordeev
> > > > > ---
> > > > > drivers/ntb/ntb_hw.c |2 +-
> > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > > > index de2062c..eccd5e5 100644
> > > > > --- a/drivers/ntb/ntb_hw.c
> > > > > +++ b/drivers/ntb/ntb_hw.c
> > > > > @@ -1066,7 +1066,7 @@ static int ntb_setup_msix(struct ntb_device
> > > > > *ndev)
> > > > > /* On SNB, the link interrupt is always tied to 4th
> > > > > vector. If
> > > > >* we can't get all 4, then we can't use MSI-X.
> > > > >*/
> > > > > - if (ndev->hw_type != BWD_HW) {
> > > > > + if ((rc < SNB_MSIX_CNT) && (ndev->hw_type != BWD_HW)) {
> > > >
> > > > Nack, this check is unnecessary.
> > >
> > > If SNB can do more than SNB_MSIX_CNT MSI-Xs then this check is needed
> > > to enable less than maximum MSI-Xs in case the maximum was not allocated.
> > > Otherwise SNB will fallback to single MSI instead of multiple MSI-Xs.
> >
> > Per the comment in the code snippet above, "If we can't get all 4,
> > then we can't use MSI-X". There is already a check to see if more
> > than 4 were acquired. So it's not possible to hit this. Even if it
> > was, don't use SNB_MSIX_CNT here (limits.msix_cnt is the preferred
> > variable). Also, the "()" are unnecessary.
>
> The changelog is definitely bogus. I meant here an improvement to the
> existing scheme, not a conversion to the new one:
>
> msix_entries = msix_table_size(val);
>
> Getting i.e. 16 vectors here.
>
> if (msix_entries > ndev->limits.msix_cnt) {
On SNB HW, limits.msix_cnt is set to SNB_MSIX_CNT (4)
http://lxr.free-electrons.com/source/drivers/ntb/ntb_hw.c#L558
> rc = -EINVAL;
> goto err;
> }
>
> Upper limit check i.e. succeeds.
>
> [...]
>
> rc = pci_enable_msix(pdev, ndev->msix_entries, msix_entries);
>
> pci_enable_msix() does not success and returns i.e. 8 here, should retry.
Per the above, since our upper bound is 4. We will either have this
return 0 for all 4 or a number between 1 and 3 (or an error, but
that's not relevant to this discussion).
> if (rc < 0)
> goto err1;
> if (rc > 0) {
> /* On SNB, the link interrupt is always tied to 4th vector. If
>* we can't get all 4, then we can't use MSI-X.
>*/
> if (ndev->hw_type != BWD_HW) {
>
> On SNB bail out here, although could have continue with 8 vectors.
> Can only use SNB_MSIX_CNT here, since limits.msix_cnt is the upper limit.
Since we can guarantee that rc is between 1 and 3 at this point (on
SNB HW), we should error out.
Thanks,
Jon
>
> rc = -EIO;
> goto err1;
> }
>
> [...]
> }
>
> --
> Regards,
> Alexander Gordeev
> agord...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote: > I don't think the same race condition would happen with the loop. The > problem case is where multiple msi(x) allocation fails completely > because the global limit went down before inquiry and allocation. In > the loop based interface, it'd retry with the lower number. > > As long as the number of drivers which need this sort of adaptive > allocation isn't too high and the common cases can be made simple, I > don't think the "complex" part of interface is all that important. > Maybe we can have reserve / cancel type interface or just keep the > loop with more explicit function names (ie. try_enable or something > like that). I'm thinking a better API overall might just have been to request individual MSI-X one by one :-) We want to be able to request an MSI-X at runtime anyway ... if I want to dynamically add a queue to my network interface, I want it to be able to pop a new arbitrary MSI-X. And we don't want to lock drivers into contiguous MSI-X sets either. And for the cleanup ... well that's what the "pcim" functions are for, we can just make MSI-X variants. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.12-rc4
On Mon, Oct 7, 2013 at 9:23 PM, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.12-rc4 to v3.12-rc3[3], the summaries are:
> - build errors: +6/-10
+ /scratch/kisskb/src/arch/powerpc/xmon/xmon.c: error: implicit
declaration of function 'dump_tlb_44x'
[-Werror=implicit-function-declaration]: => 897:4
+ /scratch/kisskb/src/drivers/tty/serial/nwpserial.c: error:
implicit declaration of function 'udelay'
[-Werror=implicit-function-declaration]: => 53:3
powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/6753/ (all 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6727/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 net-next] fix unsafe set_memory_rw from softirq
From: Eric Dumazet Date: Sun, 06 Oct 2013 09:56:32 -0700 > On Fri, 2013-10-04 at 00:14 -0700, Alexei Starovoitov wrote: >> on x86 system with net.core.bpf_jit_enable = 1 > >> cannot reuse jited filter memory, since it's readonly, >> so use original bpf insns memory to hold work_struct >> >> defer kfree of sk_filter until jit completed freeing >> >> tested on x86_64 and i386 >> >> Signed-off-by: Alexei Starovoitov > > Acked-by: Eric Dumazet I've decided to apply this to 'net', thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 54/77] ntb: Ensure number of MSIs on SNB is enough for the link interrupt
On Mon, Oct 07, 2013 at 09:50:57AM -0700, Jon Mason wrote:
> On Sat, Oct 05, 2013 at 11:43:04PM +0200, Alexander Gordeev wrote:
> > On Wed, Oct 02, 2013 at 05:48:05PM -0700, Jon Mason wrote:
> > > On Wed, Oct 02, 2013 at 12:49:10PM +0200, Alexander Gordeev wrote:
> > > > Signed-off-by: Alexander Gordeev
> > > > ---
> > > > drivers/ntb/ntb_hw.c |2 +-
> > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > > index de2062c..eccd5e5 100644
> > > > --- a/drivers/ntb/ntb_hw.c
> > > > +++ b/drivers/ntb/ntb_hw.c
> > > > @@ -1066,7 +1066,7 @@ static int ntb_setup_msix(struct ntb_device *ndev)
> > > > /* On SNB, the link interrupt is always tied to 4th
> > > > vector. If
> > > > * we can't get all 4, then we can't use MSI-X.
> > > > */
> > > > - if (ndev->hw_type != BWD_HW) {
> > > > + if ((rc < SNB_MSIX_CNT) && (ndev->hw_type != BWD_HW)) {
> > >
> > > Nack, this check is unnecessary.
> >
> > If SNB can do more than SNB_MSIX_CNT MSI-Xs then this check is needed
> > to enable less than maximum MSI-Xs in case the maximum was not allocated.
> > Otherwise SNB will fallback to single MSI instead of multiple MSI-Xs.
>
> Per the comment in the code snippet above, "If we can't get all 4,
> then we can't use MSI-X". There is already a check to see if more
> than 4 were acquired. So it's not possible to hit this. Even if it
> was, don't use SNB_MSIX_CNT here (limits.msix_cnt is the preferred
> variable). Also, the "()" are unnecessary.
The changelog is definitely bogus. I meant here an improvement to the
existing scheme, not a conversion to the new one:
msix_entries = msix_table_size(val);
Getting i.e. 16 vectors here.
if (msix_entries > ndev->limits.msix_cnt) {
rc = -EINVAL;
goto err;
}
Upper limit check i.e. succeeds.
[...]
rc = pci_enable_msix(pdev, ndev->msix_entries, msix_entries);
pci_enable_msix() does not success and returns i.e. 8 here, should retry.
if (rc < 0)
goto err1;
if (rc > 0) {
/* On SNB, the link interrupt is always tied to 4th vector. If
* we can't get all 4, then we can't use MSI-X.
*/
if (ndev->hw_type != BWD_HW) {
On SNB bail out here, although could have continue with 8 vectors.
Can only use SNB_MSIX_CNT here, since limits.msix_cnt is the upper limit.
rc = -EIO;
goto err1;
}
[...]
}
--
Regards,
Alexander Gordeev
agord...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
Hello, Alexander. On Wed, Oct 02, 2013 at 12:48:16PM +0200, Alexander Gordeev wrote: > Alexander Gordeev (77): > PCI/MSI: Fix return value when populate_msi_sysfs() failed > PCI/MSI/PPC: Fix wrong RTAS error code reporting > PCI/MSI/s390: Fix single MSI only check > PCI/MSI/s390: Remove superfluous check of MSI type > PCI/MSI: Convert pci_msix_table_size() to a public interface > PCI/MSI: Factor out pci_get_msi_cap() interface > PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern > PCI/MSI: Get rid of pci_enable_msi_block_auto() interface > ahci: Update MSI/MSI-X interrupts enablement code > ahci: Check MRSM bit when multiple MSIs enabled ... Whee that's a lot more than I expected. I was just scanning multiple msi users. Maybe we can stage the work in more manageable steps so that you don't have to go through massive conversion only to do it all over again afterwards and likewise people don't get bombarded on each iteration? Maybe we can first update pci / msi code proper, msi and then msix? Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern
Hello,
On Wed, Oct 02, 2013 at 12:48:23PM +0200, Alexander Gordeev wrote:
> +static int foo_driver_enable_msi(struct foo_adapter *adapter, int nvec)
> +{
> + rc = pci_get_msi_cap(adapter->pdev);
> + if (rc < 0)
> + return rc;
> +
> + nvec = min(nvec, rc);
> + if (nvec < FOO_DRIVER_MINIMUM_NVEC) {
> + return -ENOSPC;
> +
> + rc = pci_enable_msi_block(adapter->pdev, nvec);
> + return rc;
> +}
If there are many which duplicate the above pattern, it'd probably be
worthwhile to provide a helper? It's usually a good idea to reduce
the amount of boilerplate code in drivers.
> static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
> {
> + rc = pci_msix_table_size(adapter->pdev);
> + if (rc < 0)
> + return rc;
> +
> + nvec = min(nvec, rc);
> + if (nvec < FOO_DRIVER_MINIMUM_NVEC) {
> + return -ENOSPC;
> +
> + for (i = 0; i < nvec; i++)
> + adapter->msix_entries[i].entry = i;
> +
> + rc = pci_enable_msix(adapter->pdev, adapter->msix_entries, nvec);
> + return rc;
> }
Ditto.
> @@ -975,7 +951,7 @@ int pci_enable_msix(struct pci_dev *dev, struct
> msix_entry *entries, int nvec)
> if (nr_entries < 0)
> return nr_entries;
> if (nvec > nr_entries)
> - return nr_entries;
> + return -EINVAL;
>
> /* Check for any invalid entries */
> for (i = 0; i < nvec; i++) {
If we do things this way, it breaks all drivers using this interface
until they're converted, right? Also, it probably isn't the best idea
to flip the behavior like this as this can go completely unnoticed (no
compiler warning or anything, the same function just behaves
differently). Maybe it'd be a better idea to introduce a simpler
interface that most can be converted to?
Thanks.
--
tejun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 05/77] PCI/MSI: Convert pci_msix_table_size() to a public interface
Hello, On Wed, Oct 02, 2013 at 12:48:21PM +0200, Alexander Gordeev wrote: > Make pci_msix_table_size() to return a error code if the device > does not support MSI-X. This update is needed to facilitate a > forthcoming re-design MSI/MSI-X interrupts enabling pattern. > > Device drivers will use this interface to obtain maximum number > of MSI-X interrupts the device supports and use that value in > the following call to pci_enable_msix() interface. > > Signed-off-by: Alexander Gordeev Hmmm... I probably missed something but why is this necessary? To discern between -EINVAL and -ENOSPC? If so, does that really matter? Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
Hey, guys. On Sun, Oct 06, 2013 at 09:10:30AM +0200, Alexander Gordeev wrote: > On Sun, Oct 06, 2013 at 05:19:46PM +1100, Benjamin Herrenschmidt wrote: > > On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote: > > > In fact, in the current design to address the quota race decently the > > > drivers would have to protect the *loop* to prevent the quota change > > > between a pci_enable_msix() returned a positive number and the the next > > > call to pci_enable_msix() with that number. Is it doable? > > > > I am not advocating for the current design, simply saying that your > > proposal doesn't address this issue while Ben's does. Hmmm... yean, the race condition could be an issue as multiple msi allocation might fail even if the driver can and explicitly handle multiple allocation if the quota gets reduced inbetween. > There is one major flaw in min-max approach - the generic MSI layer > will have to take decisions on exact number of MSIs to request, not > device drivers. The min-max approach would actually be pretty nice for the users which actually care about this. > This will never work for all devices, because there might be specific > requirements which are not covered by the min-max. That is what Ben > described "...say, any even number within a certain range". Ben suggests > to leave the existing loop scheme to cover such devices, which I think is > not right. if it could work. > What about introducing pci_lock_msi() and pci_unlock_msi() and let device > drivers care about their ranges and specifics in race-safe manner? > I do not call to introduce it right now (since it appears pSeries has not > been hitting the race for years) just as a possible alternative to Ben's > proposal. I don't think the same race condition would happen with the loop. The problem case is where multiple msi(x) allocation fails completely because the global limit went down before inquiry and allocation. In the loop based interface, it'd retry with the lower number. As long as the number of drivers which need this sort of adaptive allocation isn't too high and the common cases can be made simple, I don't think the "complex" part of interface is all that important. Maybe we can have reserve / cancel type interface or just keep the loop with more explicit function names (ie. try_enable or something like that). Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 08/14] kvm: powerpc: book3s: Add is_hv_enabled to kvmppc_ops
From: "Aneesh Kumar K.V"
This help us to identify whether we are running with hypervisor mode KVM
enabled. The change is needed so that we can have both HV and PR kvm
enabled in the same kernel.
If both HV and PR KVM are included, interrupts come in to the HV version
of the kvmppc_interrupt code, which then jumps to the PR handler,
renamed to kvmppc_interrupt_pr, if the guest is a PR guest.
Allowing both PR and HV in the same kernel required some changes to
kvm_dev_ioctl_check_extension(), since the values returned now can't
be selected with #ifdefs as much as previously. We look at is_hv_enabled
to return the right value when checking for capabilities.For capabilities that
are only provided by HV KVM, we return the HV value only if
is_hv_enabled is true. For capabilities provided by PR KVM but not HV,
we return the PR value only if is_hv_enabled is false.
NOTE: in later patch we replace is_hv_enabled with a static inline
function comparing kvm_ppc_ops
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s.h | 53 --
arch/powerpc/include/asm/kvm_ppc.h| 5 ++--
arch/powerpc/kvm/book3s.c | 44
arch/powerpc/kvm/book3s_hv.c | 1 +
arch/powerpc/kvm/book3s_pr.c | 1 +
arch/powerpc/kvm/book3s_xics.c| 2 +-
arch/powerpc/kvm/powerpc.c| 54 +++
7 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 315a5d6..4a594b7 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -301,59 +301,6 @@ static inline ulong kvmppc_get_fault_dar(struct kvm_vcpu
*vcpu)
return vcpu->arch.fault_dar;
}
-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
-
-static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
-{
- return to_book3s(vcpu)->hior;
-}
-
-static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
- unsigned long pending_now, unsigned long old_pending)
-{
- if (pending_now)
- vcpu->arch.shared->int_pending = 1;
- else if (old_pending)
- vcpu->arch.shared->int_pending = 0;
-}
-
-static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
-{
- ulong crit_raw = vcpu->arch.shared->critical;
- ulong crit_r1 = kvmppc_get_gpr(vcpu, 1);
- bool crit;
-
- /* Truncate crit indicators in 32 bit mode */
- if (!(vcpu->arch.shared->msr & MSR_SF)) {
- crit_raw &= 0x;
- crit_r1 &= 0x;
- }
-
- /* Critical section when crit == r1 */
- crit = (crit_raw == crit_r1);
- /* ... and we're in supervisor mode */
- crit = crit && !(vcpu->arch.shared->msr & MSR_PR);
-
- return crit;
-}
-#else /* CONFIG_KVM_BOOK3S_PR_POSSIBLE */
-
-static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
-{
- return 0;
-}
-
-static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
- unsigned long pending_now, unsigned long old_pending)
-{
-}
-
-static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
-{
- return false;
-}
-#endif
-
/* Magic register values loaded into r3 and r4 before the 'sc' assembly
* instruction for the OSI hypercalls */
#define OSI_SC_MAGIC_R30x113724FA
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 326033c..c13f15d 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -180,6 +180,7 @@ union kvmppc_one_reg {
};
struct kvmppc_ops {
+ bool is_hv_enabled;
int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
@@ -309,10 +310,10 @@ static inline void kvmppc_set_xics_phys(int cpu, unsigned
long addr)
static inline u32 kvmppc_get_xics_latch(void)
{
- u32 xirr = get_paca()->kvm_hstate.saved_xirr;
+ u32 xirr;
+ xirr = get_paca()->kvm_hstate.saved_xirr;
get_paca()->kvm_hstate.saved_xirr = 0;
-
return xirr;
}
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 784a1d5..493aff7 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -69,6 +69,50 @@ void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
{
}
+static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
+{
+ if (!kvmppc_ops->is_hv_enabled)
+ return to_book3s(vcpu)->hior;
+ return 0;
+}
+
+static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
+ unsigned long pending_now, unsigned long old_pending)
+{
+ if (kvmppc_ops->is_hv_enabled)
+ return;
+ if (pending
Re: [PATCH RFC 54/77] ntb: Ensure number of MSIs on SNB is enough for the link interrupt
On Sat, Oct 05, 2013 at 11:43:04PM +0200, Alexander Gordeev wrote:
> On Wed, Oct 02, 2013 at 05:48:05PM -0700, Jon Mason wrote:
> > On Wed, Oct 02, 2013 at 12:49:10PM +0200, Alexander Gordeev wrote:
> > > Signed-off-by: Alexander Gordeev
> > > ---
> > > drivers/ntb/ntb_hw.c |2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > index de2062c..eccd5e5 100644
> > > --- a/drivers/ntb/ntb_hw.c
> > > +++ b/drivers/ntb/ntb_hw.c
> > > @@ -1066,7 +1066,7 @@ static int ntb_setup_msix(struct ntb_device *ndev)
> > > /* On SNB, the link interrupt is always tied to 4th vector. If
> > >* we can't get all 4, then we can't use MSI-X.
> > >*/
> > > - if (ndev->hw_type != BWD_HW) {
> > > + if ((rc < SNB_MSIX_CNT) && (ndev->hw_type != BWD_HW)) {
> >
> > Nack, this check is unnecessary.
>
> If SNB can do more than SNB_MSIX_CNT MSI-Xs then this check is needed
> to enable less than maximum MSI-Xs in case the maximum was not allocated.
> Otherwise SNB will fallback to single MSI instead of multiple MSI-Xs.
Per the comment in the code snippet above, "If we can't get all 4,
then we can't use MSI-X". There is already a check to see if more
than 4 were acquired. So it's not possible to hit this. Even if it
was, don't use SNB_MSIX_CNT here (limits.msix_cnt is the preferred
variable). Also, the "()" are unnecessary.
Thanks,
Jon
> --
> Regards,
> Alexander Gordeev
> agord...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 09/14] kvm: powerpc: book3s: pr: move PR related tracepoints to a separate header
From: "Aneesh Kumar K.V"
This patch moves PR related tracepoints to a separate header. This
enables in converting PR to a kernel module which will be done in
later patches
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_mmu_hpte.c| 2 +-
arch/powerpc/kvm/book3s_pr.c | 4 +-
arch/powerpc/kvm/trace.h | 234 +--
arch/powerpc/kvm/trace_pr.h | 297 ++
5 files changed, 309 insertions(+), 230 deletions(-)
create mode 100644 arch/powerpc/kvm/trace_pr.h
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c
b/arch/powerpc/kvm/book3s_64_mmu_host.c
index 819672c..0d513af 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -27,7 +27,7 @@
#include
#include
#include
-#include "trace.h"
+#include "trace_pr.h"
#define PTE_SIZE 12
diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c
b/arch/powerpc/kvm/book3s_mmu_hpte.c
index 6b79bfc..5a1ab12 100644
--- a/arch/powerpc/kvm/book3s_mmu_hpte.c
+++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
@@ -28,7 +28,7 @@
#include
#include
-#include "trace.h"
+#include "trace_pr.h"
#define PTE_SIZE 12
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index b6a525d..ca6c73d 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -42,7 +42,9 @@
#include
#include "book3s.h"
-#include "trace.h"
+
+#define CREATE_TRACE_POINTS
+#include "trace_pr.h"
/* #define EXIT_DEBUG */
/* #define DEBUG_EXT */
diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h
index 9e8368e..80f252a 100644
--- a/arch/powerpc/kvm/trace.h
+++ b/arch/powerpc/kvm/trace.h
@@ -85,6 +85,12 @@ TRACE_EVENT(kvm_ppc_instr,
{41, "HV_PRIV"}
#endif
+#ifndef CONFIG_KVM_BOOK3S_PR_POSSIBLE
+/*
+ * For pr we define this in trace_pr.h since it pr can be built as
+ * a module
+ */
+
TRACE_EVENT(kvm_exit,
TP_PROTO(unsigned int exit_nr, struct kvm_vcpu *vcpu),
TP_ARGS(exit_nr, vcpu),
@@ -94,9 +100,6 @@ TRACE_EVENT(kvm_exit,
__field(unsigned long, pc )
__field(unsigned long, msr )
__field(unsigned long, dar )
-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
- __field(unsigned long, srr1)
-#endif
__field(unsigned long, last_inst )
),
@@ -105,9 +108,6 @@ TRACE_EVENT(kvm_exit,
__entry->pc = kvmppc_get_pc(vcpu);
__entry->dar= kvmppc_get_fault_dar(vcpu);
__entry->msr= vcpu->arch.shared->msr;
-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
- __entry->srr1 = vcpu->arch.shadow_srr1;
-#endif
__entry->last_inst = vcpu->arch.last_inst;
),
@@ -115,18 +115,12 @@ TRACE_EVENT(kvm_exit,
" | pc=0x%lx"
" | msr=0x%lx"
" | dar=0x%lx"
-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
- " | srr1=0x%lx"
-#endif
" | last_inst=0x%lx"
,
__print_symbolic(__entry->exit_nr, kvm_trace_symbol_exit),
__entry->pc,
__entry->msr,
__entry->dar,
-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
- __entry->srr1,
-#endif
__entry->last_inst
)
);
@@ -145,6 +139,7 @@ TRACE_EVENT(kvm_unmap_hva,
TP_printk("unmap hva 0x%lx\n", __entry->hva)
);
+#endif
TRACE_EVENT(kvm_stlb_inval,
TP_PROTO(unsigned int stlb_index),
@@ -231,221 +226,6 @@ TRACE_EVENT(kvm_check_requests,
__entry->cpu_nr, __entry->requests)
);
-
-/*
- * Book3S trace points *
- */
-
-#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
-
-TRACE_EVENT(kvm_book3s_reenter,
- TP_PROTO(int r, struct kvm_vcpu *vcpu),
- TP_ARGS(r, vcpu),
-
- TP_STRUCT__entry(
- __field(unsigned int, r )
- __field(unsigned long, pc )
- ),
-
- TP_fast_assign(
- __entry->r = r;
- __entry->pc = kvmppc_get_pc(vcpu);
- ),
-
- TP_printk("reentry r=%d | pc=0x%lx", __entry->r, __entry->pc)
-);
-
-#ifdef CONFIG_PPC_BOOK3S_64
-
-TRACE_EVENT(kvm_book3s_64_mmu_map,
- TP_PROTO(int rflags, ulong hpteg, ulong va, pfn_t hpaddr,
-struct kvmppc_pte *orig_pte),
- TP_ARGS(rflags, hpteg, va, hpaddr, orig_pte),
-
- TP_STRUCT__entry(
- __field(unsigned char, flag_w )
- __field(unsigned char, flag_x
[PATCH -V2 06/14] kvm: powerpc: booke: Convert BOOKE to use kvmppc_ops callbacks
From: "Aneesh Kumar K.V"
Make required changes to get BOOKE configs to build with
the introduction of kvmppc_ops callback
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_ppc.h | 4 +--
arch/powerpc/kvm/44x.c | 55 +++---
arch/powerpc/kvm/44x_emulate.c | 8 +++---
arch/powerpc/kvm/44x_tlb.c | 2 +-
arch/powerpc/kvm/booke.c | 47 +++-
arch/powerpc/kvm/booke.h | 24 +
arch/powerpc/kvm/e500.c| 53 +---
arch/powerpc/kvm/e500_emulate.c| 8 +++---
arch/powerpc/kvm/e500_mmu.c| 2 +-
arch/powerpc/kvm/e500mc.c | 54 ++---
10 files changed, 194 insertions(+), 63 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 1d22b53..326033c 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -285,10 +285,10 @@ static inline u32 kvmppc_set_field(u64 inst, int msb, int
lsb, int value)
__v;\
})
-void kvmppc_core_get_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+int kvmppc_core_get_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int kvmppc_core_set_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
-void kvmppc_get_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+int kvmppc_get_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int kvmppc_set_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg);
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 2f5c6b6..a765bcd 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -31,13 +31,13 @@
#include "44x_tlb.h"
#include "booke.h"
-void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
+static void kvmppc_core_vcpu_load_44x(struct kvm_vcpu *vcpu, int cpu)
{
kvmppc_booke_vcpu_load(vcpu, cpu);
kvmppc_44x_tlb_load(vcpu);
}
-void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
+static void kvmppc_core_vcpu_put_44x(struct kvm_vcpu *vcpu)
{
kvmppc_44x_tlb_put(vcpu);
kvmppc_booke_vcpu_put(vcpu);
@@ -114,29 +114,32 @@ int kvmppc_core_vcpu_translate(struct kvm_vcpu *vcpu,
return 0;
}
-void kvmppc_core_get_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
+static int kvmppc_core_get_sregs_44x(struct kvm_vcpu *vcpu,
+ struct kvm_sregs *sregs)
{
- kvmppc_get_sregs_ivor(vcpu, sregs);
+ return kvmppc_get_sregs_ivor(vcpu, sregs);
}
-int kvmppc_core_set_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
+static int kvmppc_core_set_sregs_44x(struct kvm_vcpu *vcpu,
+struct kvm_sregs *sregs)
{
return kvmppc_set_sregs_ivor(vcpu, sregs);
}
-int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
- union kvmppc_one_reg *val)
+static int kvmppc_get_one_reg_44x(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
{
return -EINVAL;
}
-int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id,
- union kvmppc_one_reg *val)
+static int kvmppc_set_one_reg_44x(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
{
return -EINVAL;
}
-struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
+static struct kvm_vcpu *kvmppc_core_vcpu_create_44x(struct kvm *kvm,
+ unsigned int id)
{
struct kvmppc_vcpu_44x *vcpu_44x;
struct kvm_vcpu *vcpu;
@@ -167,7 +170,7 @@ out:
return ERR_PTR(err);
}
-void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
+static void kvmppc_core_vcpu_free_44x(struct kvm_vcpu *vcpu)
{
struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
@@ -176,24 +179,46 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
}
-int kvmppc_core_init_vm(struct kvm *kvm)
+static int kvmppc_core_init_vm_44x(struct kvm *kvm)
{
return 0;
}
-void kvmppc_core_destroy_vm(struct kvm *kvm)
+static void kvmppc_core_destroy_vm_44x(struct kvm *kvm)
{
}
+static struct kvmppc_ops kvm_ops_44x = {
+ .get_sregs = kvmppc_core_get_sregs_44x,
+ .set_sregs = kvmppc_core_set_sregs_44x,
+ .get_one_reg = kvmppc_get_one_reg_44x,
+ .set_one_reg = kvmppc_set_one_reg_44x,
+ .vcpu_load = kvmppc_core_vcpu_load_44x,
+ .vcpu_put= kvmppc_core_vcpu_put_44x,
+ .vcpu_create = kvmppc_core_vcpu_create_44x,
+ .vcpu_free = kvmppc_core_vcpu_free_44x,
+ .mmu_destroy = kvmppc_mmu_destroy_44x,
+ .init_vm = kvmppc_core_init_vm_44x,
+ .destroy_vm = kvmppc_core_destroy_vm_44x,
+ .emulate_op = kvmp
[PATCH -V2 14/14] kvm: powerpc: book3s: drop is_hv_enabled
From: "Aneesh Kumar K.V"
drop is_hv_enabled, because that should not be a callback property
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_ppc.h | 6 +-
arch/powerpc/kvm/book3s.c | 6 +++---
arch/powerpc/kvm/book3s_hv.c | 1 -
arch/powerpc/kvm/book3s_pr.c | 1 -
arch/powerpc/kvm/book3s_xics.c | 2 +-
arch/powerpc/kvm/powerpc.c | 2 +-
6 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 3069cf4..c8317fb 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -183,7 +183,6 @@ union kvmppc_one_reg {
struct kvmppc_ops {
struct module *owner;
- bool is_hv_enabled;
int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
@@ -232,6 +231,11 @@ struct kvmppc_ops {
extern struct kvmppc_ops *kvmppc_hv_ops;
extern struct kvmppc_ops *kvmppc_pr_ops;
+static inline bool is_kvmppc_hv_enabled(struct kvm *kvm)
+{
+ return kvm->arch.kvm_ops == kvmppc_hv_ops;
+}
+
/*
* Cuts out inst bits with ordering according to spec.
* That means the leftmost bit is zero. All given bits are included.
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index ad8f6ed..8912608 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -72,7 +72,7 @@ void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
{
- if (!vcpu->kvm->arch.kvm_ops->is_hv_enabled)
+ if (!is_kvmppc_hv_enabled(vcpu->kvm))
return to_book3s(vcpu)->hior;
return 0;
}
@@ -80,7 +80,7 @@ static inline unsigned long kvmppc_interrupt_offset(struct
kvm_vcpu *vcpu)
static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
unsigned long pending_now, unsigned long old_pending)
{
- if (vcpu->kvm->arch.kvm_ops->is_hv_enabled)
+ if (is_kvmppc_hv_enabled(vcpu->kvm))
return;
if (pending_now)
vcpu->arch.shared->int_pending = 1;
@@ -94,7 +94,7 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu
*vcpu)
ulong crit_r1;
bool crit;
- if (vcpu->kvm->arch.kvm_ops->is_hv_enabled)
+ if (is_kvmppc_hv_enabled(vcpu->kvm))
return false;
crit_raw = vcpu->arch.shared->critical;
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 31922d5..b5229eb 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2160,7 +2160,6 @@ static long kvm_arch_vm_ioctl_hv(struct file *filp,
}
static struct kvmppc_ops kvm_ops_hv = {
- .is_hv_enabled = true,
.get_sregs = kvm_arch_vcpu_ioctl_get_sregs_hv,
.set_sregs = kvm_arch_vcpu_ioctl_set_sregs_hv,
.get_one_reg = kvmppc_get_one_reg_hv,
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index fbd985f..df36cf2 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1526,7 +1526,6 @@ static long kvm_arch_vm_ioctl_pr(struct file *filp,
}
static struct kvmppc_ops kvm_ops_pr = {
- .is_hv_enabled = false,
.get_sregs = kvm_arch_vcpu_ioctl_get_sregs_pr,
.set_sregs = kvm_arch_vcpu_ioctl_set_sregs_pr,
.get_one_reg = kvmppc_get_one_reg_pr,
diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
index 76ef525..20d56ec 100644
--- a/arch/powerpc/kvm/book3s_xics.c
+++ b/arch/powerpc/kvm/book3s_xics.c
@@ -818,7 +818,7 @@ int kvmppc_xics_hcall(struct kvm_vcpu *vcpu, u32 req)
}
/* Check for real mode returning too hard */
- if (xics->real_mode && vcpu->kvm->arch.kvm_ops->is_hv_enabled)
+ if (xics->real_mode && is_kvmppc_hv_enabled(vcpu->kvm))
return kvmppc_xics_rm_complete(vcpu, req);
switch (req) {
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 00a995a..058f9d6 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -200,7 +200,7 @@ int kvmppc_sanity_check(struct kvm_vcpu *vcpu)
goto out;
/* HV KVM can only do PAPR mode for now */
- if (!vcpu->arch.papr_enabled && vcpu->kvm->arch.kvm_ops->is_hv_enabled)
+ if (!vcpu->arch.papr_enabled && is_kvmppc_hv_enabled(vcpu->kvm))
goto out;
#ifdef CONFIG_KVM_BOOKE_HV
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 13/14] kvm: powerpc: book3s: Allow the HV and PR selection per virtual machine
From: "Aneesh Kumar K.V"
This moves the kvmppc_ops callbacks to be a per VM entity. This
enables us to select HV and PR mode when creating a VM. We also
allow both kvm-hv and kvm-pr kernel module to be loaded. To
achieve this we move /dev/kvm ownership to kvm.ko module. Depending on
which KVM mode we select during VM creation we take a reference
count on respective module
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/include/asm/kvm_ppc.h | 7 +--
arch/powerpc/kvm/44x.c | 7 ++-
arch/powerpc/kvm/book3s.c | 89 +
arch/powerpc/kvm/book3s.h | 2 +
arch/powerpc/kvm/book3s_hv.c| 18
arch/powerpc/kvm/book3s_pr.c| 25 +++
arch/powerpc/kvm/book3s_xics.c | 2 +-
arch/powerpc/kvm/booke.c| 22 -
arch/powerpc/kvm/e500.c | 8 +++-
arch/powerpc/kvm/e500mc.c | 6 ++-
arch/powerpc/kvm/emulate.c | 11 ++---
arch/powerpc/kvm/powerpc.c | 76 ++-
include/uapi/linux/kvm.h| 4 ++
14 files changed, 187 insertions(+), 91 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index e86db97..c7a041d 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -275,6 +275,7 @@ struct kvm_arch {
#ifdef CONFIG_KVM_XICS
struct kvmppc_xics *xics;
#endif
+ struct kvmppc_ops *kvm_ops;
};
/*
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 20f4616..3069cf4 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -182,6 +182,7 @@ union kvmppc_one_reg {
};
struct kvmppc_ops {
+ struct module *owner;
bool is_hv_enabled;
int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
@@ -217,7 +218,6 @@ struct kvmppc_ops {
unsigned long npages);
int (*init_vm)(struct kvm *kvm);
void (*destroy_vm)(struct kvm *kvm);
- int (*check_processor_compat)(void);
int (*get_smmu_info)(struct kvm *kvm, struct kvm_ppc_smmu_info *info);
int (*emulate_op)(struct kvm_run *run, struct kvm_vcpu *vcpu,
unsigned int inst, int *advance);
@@ -229,7 +229,8 @@ struct kvmppc_ops {
};
-extern struct kvmppc_ops *kvmppc_ops;
+extern struct kvmppc_ops *kvmppc_hv_ops;
+extern struct kvmppc_ops *kvmppc_pr_ops;
/*
* Cuts out inst bits with ordering according to spec.
@@ -326,7 +327,7 @@ static inline void kvmppc_set_host_ipi(int cpu, u8 host_ipi)
static inline void kvmppc_fast_vcpu_kick(struct kvm_vcpu *vcpu)
{
- kvmppc_ops->fast_vcpu_kick(vcpu);
+ vcpu->kvm->arch.kvm_ops->fast_vcpu_kick(vcpu);
}
#else
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index a765bcd..93221e8 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -213,16 +213,19 @@ static int __init kvmppc_44x_init(void)
if (r)
goto err_out;
- r = kvm_init(&kvm_ops_44x, sizeof(struct kvmppc_vcpu_44x),
-0, THIS_MODULE);
+ r = kvm_init(NULL, sizeof(struct kvmppc_vcpu_44x), 0, THIS_MODULE);
if (r)
goto err_out;
+ kvm_ops_44x.owner = THIS_MODULE;
+ kvmppc_pr_ops = &kvm_ops_44x;
+
err_out:
return r;
}
static void __exit kvmppc_44x_exit(void)
{
+ kvmppc_pr_ops = NULL;
kvmppc_booke_exit();
}
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 130fe1d..ad8f6ed 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -34,6 +34,7 @@
#include
#include
+#include "book3s.h"
#include "trace.h"
#define VCPU_STAT(x) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU
@@ -71,7 +72,7 @@ void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
{
- if (!kvmppc_ops->is_hv_enabled)
+ if (!vcpu->kvm->arch.kvm_ops->is_hv_enabled)
return to_book3s(vcpu)->hior;
return 0;
}
@@ -79,7 +80,7 @@ static inline unsigned long kvmppc_interrupt_offset(struct
kvm_vcpu *vcpu)
static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
unsigned long pending_now, unsigned long old_pending)
{
- if (kvmppc_ops->is_hv_enabled)
+ if (vcpu->kvm->arch.kvm_ops->is_hv_enabled)
return;
if (pending_now)
vcpu->arch.shared->int_pending = 1;
@@ -93,7 +94,7 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu
*vcpu)
ulong crit_r1;
bool crit;
- if (kvmppc_ops->is_hv_enabled)
+ if (vcpu->kvm->arch.kvm_ops->is_hv_enabled)
return false;
crit_raw = vcp
[PATCH -V2 12/14] kvm: Add struct kvm arg to memslot APIs
From: "Aneesh Kumar K.V"
We will use that in the later patch to find the kvm ops handler
Signed-off-by: Aneesh Kumar K.V
---
arch/arm/kvm/arm.c | 5 +++--
arch/ia64/kvm/kvm-ia64.c | 5 +++--
arch/mips/kvm/kvm_mips.c | 5 +++--
arch/powerpc/include/asm/kvm_ppc.h | 6 --
arch/powerpc/kvm/book3s.c | 4 ++--
arch/powerpc/kvm/booke.c | 4 ++--
arch/powerpc/kvm/powerpc.c | 9 +
arch/s390/kvm/kvm-s390.c | 5 +++--
arch/x86/kvm/x86.c | 5 +++--
include/linux/kvm_host.h | 5 +++--
virt/kvm/kvm_main.c| 12 ++--
11 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9c697db..e96c48f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -152,12 +152,13 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
-void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
}
-int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+int kvm_arch_create_memslot(struct kvm *kvm, struct kvm_memory_slot *slot,
+ unsigned long npages)
{
return 0;
}
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index bdfd878..985bf80 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1550,12 +1550,13 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
-void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
}
-int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+int kvm_arch_create_memslot(struct kvm *kvm, struct kvm_memory_slot *slot,
+ unsigned long npages)
{
return 0;
}
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index a7b0445..73b3482 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -198,12 +198,13 @@ kvm_arch_dev_ioctl(struct file *filp, unsigned int ioctl,
unsigned long arg)
return -ENOIOCTLCMD;
}
-void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
}
-int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+int kvm_arch_create_memslot(struct kvm *kvm, struct kvm_memory_slot *slot,
+ unsigned long npages)
{
return 0;
}
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index c13f15d..20f4616 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -134,9 +134,11 @@ extern struct page *kvm_alloc_hpt(unsigned long nr_pages);
extern void kvm_release_hpt(struct page *page, unsigned long nr_pages);
extern int kvmppc_core_init_vm(struct kvm *kvm);
extern void kvmppc_core_destroy_vm(struct kvm *kvm);
-extern void kvmppc_core_free_memslot(struct kvm_memory_slot *free,
+extern void kvmppc_core_free_memslot(struct kvm *kvm,
+struct kvm_memory_slot *free,
struct kvm_memory_slot *dont);
-extern int kvmppc_core_create_memslot(struct kvm_memory_slot *slot,
+extern int kvmppc_core_create_memslot(struct kvm *kvm,
+ struct kvm_memory_slot *slot,
unsigned long npages);
extern int kvmppc_core_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 39d2994..130fe1d 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -761,13 +761,13 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct
kvm_dirty_log *log)
return kvmppc_ops->get_dirty_log(kvm, log);
}
-void kvmppc_core_free_memslot(struct kvm_memory_slot *free,
+void kvmppc_core_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
kvmppc_ops->free_memslot(free, dont);
}
-int kvmppc_core_create_memslot(struct kvm_memory_slot *slot,
+int kvmppc_core_create_memslot(struct kvm *kvm, struct kvm_memory_slot *slot,
unsigned long npages)
{
return kvmppc_ops->create_memslot(slot, npages);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1769354..cb2d986 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1662,12 +1662,12 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct
kvm_di
[PATCH -V2 11/14] kvm: powerpc: book3s: Support building HV and PR KVM as module
From: "Aneesh Kumar K.V"
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/Kconfig | 6 +++---
arch/powerpc/kvm/Makefile | 11 ---
arch/powerpc/kvm/book3s.c | 12 +++-
arch/powerpc/kvm/book3s_emulate.c | 2 +-
arch/powerpc/kvm/book3s_hv.c | 2 ++
arch/powerpc/kvm/book3s_pr.c | 5 -
arch/powerpc/kvm/book3s_rtas.c| 1 +
arch/powerpc/kvm/emulate.c| 1 +
arch/powerpc/kvm/powerpc.c| 10 ++
virt/kvm/kvm_main.c | 4
10 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index a96d7c3..8aeeda1 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -73,7 +73,7 @@ config KVM_BOOK3S_64
If unsure, say N.
config KVM_BOOK3S_64_HV
- bool "KVM support for POWER7 and PPC970 using hypervisor mode in host"
+ tristate "KVM support for POWER7 and PPC970 using hypervisor mode in
host"
depends on KVM_BOOK3S_64
select KVM_BOOK3S_HV_POSSIBLE
select MMU_NOTIFIER
@@ -94,8 +94,8 @@ config KVM_BOOK3S_64_HV
If unsure, say N.
config KVM_BOOK3S_64_PR
- bool "KVM support without using hypervisor mode in host"
- depends on KVM_BOOK3S_64 && !KVM_BOOK3S_64_HV
+ tristate "KVM support without using hypervisor mode in host"
+ depends on KVM_BOOK3S_64
select KVM_BOOK3S_PR_POSSIBLE
---help---
Support running guest kernels in virtual machines on processors
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index fa17b33..ce569b6 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -56,7 +56,7 @@ kvm-objs-$(CONFIG_KVM_E500MC) := $(kvm-e500mc-objs)
kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) := \
book3s_64_vio_hv.o
-kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
+kvm-pr-y := \
fpu.o \
book3s_paired_singles.o \
book3s_pr.o \
@@ -76,7 +76,7 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) +=
\
book3s_rmhandlers.o
endif
-kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \
+kvm-hv-y += \
book3s_hv.o \
book3s_hv_interrupts.o \
book3s_64_mmu_hv.o
@@ -84,13 +84,15 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \
kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \
book3s_hv_rm_xics.o
-kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \
+ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
book3s_hv_rmhandlers.o \
book3s_hv_rm_mmu.o \
book3s_hv_ras.o \
book3s_hv_builtin.o \
book3s_hv_cma.o \
$(kvm-book3s_64-builtin-xics-objs-y)
+endif
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
@@ -131,4 +133,7 @@ obj-$(CONFIG_KVM_E500MC) += kvm.o
obj-$(CONFIG_KVM_BOOK3S_64) += kvm.o
obj-$(CONFIG_KVM_BOOK3S_32) += kvm.o
+obj-$(CONFIG_KVM_BOOK3S_64_PR) += kvm-pr.o
+obj-$(CONFIG_KVM_BOOK3S_64_HV) += kvm-hv.o
+
obj-y += $(kvm-book3s_64-builtin-objs-y)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 493aff7..39d2994 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -170,28 +170,32 @@ void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu,
unsigned int vec)
printk(KERN_INFO "Queueing interrupt %x\n", vec);
#endif
}
-
+EXPORT_SYMBOL_GPL(kvmppc_book3s_queue_irqprio);
void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
{
/* might as well deliver this straight away */
kvmppc_inject_interrupt(vcpu, BOOK3S_INTERRUPT_PROGRAM, flags);
}
+EXPORT_SYMBOL_GPL(kvmppc_core_queue_program);
void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu)
{
kvmppc_book3s_queue_irqprio(vcpu, BOOK3S_INTERRUPT_DECREMENTER);
}
+EXPORT_SYMBOL_GPL(kvmppc_core_queue_dec);
int kvmppc_core_pending_dec(struct kvm_vcpu *vcpu)
{
return test_bit(BOOK3S_IRQPRIO_DECREMENTER,
&vcpu->arch.pending_exceptions);
}
+EXPORT_SYMBOL_GPL(kvmppc_core_pending_dec);
void kvmppc_core_dequeue_dec(struct kvm_vcpu *vcpu)
{
kvmppc_book3s_dequeue_irqprio(vcpu, BOOK3S_INTERRUPT_DECREMENTER);
}
+EXPORT_SYMBOL_GPL(kvmppc_core_dequeue_dec);
void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
struct kvm_interrupt *irq)
@@ -329,6 +333,7 @@ int kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
return 0;
}
+EXPORT_SYMBOL_GPL(kvmppc_core_prepare_to_enter);
pfn_t kvmppc_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn, bool writing,
bool *writable)
@@ -354,6 +359,7 @@ pfn_t kvmppc_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
bool writing,
return gfn_to_pfn_prot(vcpu->kvm, gfn, writing, writable);
}
+EXPORT_SYMBOL_GPL(kvmppc_gfn_to_pfn);
static int kvmppc_xlate(struct kvm_vcpu *vcpu, ulong eaddr, bool data,
bool iswrite,
[PATCH -V2 00/14] Allow PR and HV KVM to coexist in one kernel
Hi All, This patch series support enabling HV and PR KVM together in the same kernel. We extend machine property with new property "kvm_type". A value of "HV" will force HV KVM and "PR" PR KVM. If we don't specify kvm_type we will select the fastest KVM mode. ie, HV if that is supported otherwise PR. With Qemu command line having -machine pseries,accel=kvm,kvm_type=HV [root@llmp24l02 qemu]# bash ../qemu failed to initialize KVM: Invalid argument [root@llmp24l02 qemu]# modprobe kvm-pr [root@llmp24l02 qemu]# bash ../qemu failed to initialize KVM: Invalid argument [root@llmp24l02 qemu]# modprobe kvm-hv [root@llmp24l02 qemu]# bash ../qemu now with -machine pseries,accel=kvm,kvm_type=PR [root@llmp24l02 qemu]# rmmod kvm-pr [root@llmp24l02 qemu]# bash ../qemu failed to initialize KVM: Invalid argument [root@llmp24l02 qemu]# [root@llmp24l02 qemu]# modprobe kvm-pr [root@llmp24l02 qemu]# bash ../qemu Changes from V1: * Build fixes for BOOKE (only compile tested) * Address review feedback -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 10/14] kvm: powerpc: booke: Move booke related tracepoints to separate header
From: "Aneesh Kumar K.V"
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/booke.c | 4 +-
arch/powerpc/kvm/e500_mmu.c | 2 +-
arch/powerpc/kvm/e500_mmu_host.c | 3 +-
arch/powerpc/kvm/trace.h | 204 ---
arch/powerpc/kvm/trace_booke.h | 177 +
5 files changed, 183 insertions(+), 207 deletions(-)
create mode 100644 arch/powerpc/kvm/trace_booke.h
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index e5f8ba7..1769354 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -40,7 +40,9 @@
#include "timing.h"
#include "booke.h"
-#include "trace.h"
+
+#define CREATE_TRACE_POINTS
+#include "trace_booke.h"
unsigned long kvmppc_booke_handlers;
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index d25bb75..ebca6b8 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -32,7 +32,7 @@
#include
#include "e500.h"
-#include "trace.h"
+#include "trace_booke.h"
#include "timing.h"
#include "e500_mmu_host.h"
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 8f0d532..e7dde4b 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -32,10 +32,11 @@
#include
#include "e500.h"
-#include "trace.h"
#include "timing.h"
#include "e500_mmu_host.h"
+#include "trace_booke.h"
+
#define to_htlb1_esel(esel) (host_tlb_params[1].entries - (esel) - 1)
static struct kvmppc_e500_tlb_params host_tlb_params[E500_TLB_NUM];
diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h
index 80f252a..2e0e67e 100644
--- a/arch/powerpc/kvm/trace.h
+++ b/arch/powerpc/kvm/trace.h
@@ -31,116 +31,6 @@ TRACE_EVENT(kvm_ppc_instr,
__entry->inst, __entry->pc, __entry->emulate)
);
-#ifdef CONFIG_PPC_BOOK3S
-#define kvm_trace_symbol_exit \
- {0x100, "SYSTEM_RESET"}, \
- {0x200, "MACHINE_CHECK"}, \
- {0x300, "DATA_STORAGE"}, \
- {0x380, "DATA_SEGMENT"}, \
- {0x400, "INST_STORAGE"}, \
- {0x480, "INST_SEGMENT"}, \
- {0x500, "EXTERNAL"}, \
- {0x501, "EXTERNAL_LEVEL"}, \
- {0x502, "EXTERNAL_HV"}, \
- {0x600, "ALIGNMENT"}, \
- {0x700, "PROGRAM"}, \
- {0x800, "FP_UNAVAIL"}, \
- {0x900, "DECREMENTER"}, \
- {0x980, "HV_DECREMENTER"}, \
- {0xc00, "SYSCALL"}, \
- {0xd00, "TRACE"}, \
- {0xe00, "H_DATA_STORAGE"}, \
- {0xe20, "H_INST_STORAGE"}, \
- {0xe40, "H_EMUL_ASSIST"}, \
- {0xf00, "PERFMON"}, \
- {0xf20, "ALTIVEC"}, \
- {0xf40, "VSX"}
-#else
-#define kvm_trace_symbol_exit \
- {0, "CRITICAL"}, \
- {1, "MACHINE_CHECK"}, \
- {2, "DATA_STORAGE"}, \
- {3, "INST_STORAGE"}, \
- {4, "EXTERNAL"}, \
- {5, "ALIGNMENT"}, \
- {6, "PROGRAM"}, \
- {7, "FP_UNAVAIL"}, \
- {8, "SYSCALL"}, \
- {9, "AP_UNAVAIL"}, \
- {10, "DECREMENTER"}, \
- {11, "FIT"}, \
- {12, "WATCHDOG"}, \
- {13, "DTLB_MISS"}, \
- {14, "ITLB_MISS"}, \
- {15, "DEBUG"}, \
- {32, "SPE_UNAVAIL"}, \
- {33, "SPE_FP_DATA"}, \
- {34, "SPE_FP_ROUND"}, \
- {35, "PERFORMANCE_MONITOR"}, \
- {36, "DOORBELL"}, \
- {37, "DOORBELL_CRITICAL"}, \
- {38, "GUEST_DBELL"}, \
- {39, "GUEST_DBELL_CRIT"}, \
- {40, "HV_SYSCALL"}, \
- {41, "HV_PRIV"}
-#endif
-
-#ifndef CONFIG_KVM_BOOK3S_PR_POSSIBLE
-/*
- * For pr we define this in trace_pr.h since it pr can be built as
- * a module
- */
-
-TRACE_EVENT(kvm_exit,
- TP_PROTO(unsigned int exit_nr, struct kvm_vcpu *vcpu),
- TP_ARGS(exit_nr, vcpu),
-
- TP_STRUCT__entry(
- __field(unsigned int, exit_nr )
- __field(unsigned long, pc )
- __field(unsigned long, msr )
- __field(unsigned long, dar )
- __field(unsigned long, last_inst )
- ),
-
- TP_fast_assign(
- __entry->exit_nr= exit_nr;
- __entry->pc = kvmppc_get_pc(vcpu);
- __entry->dar= kvmppc_get_fault_dar(vcpu);
- __entry->msr= vcpu->arch.shared->msr;
- __entry->last_inst = vcpu->arch.last_inst;
- ),
-
- TP_printk("exit=%s"
- " | pc=0x%lx"
- " | msr=0x%lx"
- " | dar=0x%lx"
- " | last_inst=0x%lx"
- ,
- __print_symbolic(__entry->exit_nr, kvm_trace_symbol_exit),
- __entry->pc,
- __entry->msr,
- __entry->dar,
- __entry->last_inst
- )
-);
-
-TRACE_EVENT(kvm_unmap_hva,
- TP_PROTO(unsigned long hva),
- TP_ARGS(hva),
-
- TP_STRUCT__entry(
- __field(unsigned lon
[PATCH -V2 07/14] kvm: powerpc: book3s: Cleanup interrupt handling code
From: "Aneesh Kumar K.V" With this patch if HV is included, interrupts come in to the HV version of the kvmppc_interrupt code, which then jumps to the PR handler, renamed to kvmppc_interrupt_pr, if the guest is a PR guest. This helps in enabling both HV and PR, which we do in later patch Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/exception-64s.h | 11 +++ arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 +++-- arch/powerpc/kvm/book3s_segment.S| 4 ++-- 3 files changed, 20 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index fe1c62d..76d326e 100644 --- a/arch/powerpc/include/asm/exception-64s.h +++ b/arch/powerpc/include/asm/exception-64s.h @@ -197,6 +197,17 @@ END_FTR_SECTION_NESTED(ftr,ftr,943) cmpwi r10,0; \ bne do_kvm_##n +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE +/* + * If hv is possible, interrupts come into to the hv version + * of the kvmppc_interrupt code, which then jumps to the PR handler, + * kvmppc_interrupt_pr, if the guest is a PR guest. + */ +#define kvmppc_interrupt kvmppc_interrupt_hv +#else +#define kvmppc_interrupt kvmppc_interrupt_pr +#endif + #define __KVM_HANDLER(area, h, n) \ do_kvm_##n:\ BEGIN_FTR_SECTION_NESTED(947) \ diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index f1f1bf3..55e4a01 100644 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -734,8 +734,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR) /* * We come here from the first-level interrupt handlers. */ - .globl kvmppc_interrupt -kvmppc_interrupt: + .globl kvmppc_interrupt_hv +kvmppc_interrupt_hv: /* * Register contents: * R12 = interrupt vector @@ -749,6 +749,11 @@ kvmppc_interrupt: lbz r9, HSTATE_IN_GUEST(r13) cmpwi r9, KVM_GUEST_MODE_HOST_HV beq kvmppc_bad_host_intr +#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE + cmpwi r9, KVM_GUEST_MODE_GUEST + ld r9, HSTATE_HOST_R2(r13) + beq kvmppc_interrupt_pr +#endif /* We're now back in the host but in guest MMU context */ li r9, KVM_GUEST_MODE_HOST_HV stb r9, HSTATE_IN_GUEST(r13) diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S index 1abe478..bc50c97 100644 --- a/arch/powerpc/kvm/book3s_segment.S +++ b/arch/powerpc/kvm/book3s_segment.S @@ -161,8 +161,8 @@ kvmppc_handler_trampoline_enter_end: .global kvmppc_handler_trampoline_exit kvmppc_handler_trampoline_exit: -.global kvmppc_interrupt -kvmppc_interrupt: +.global kvmppc_interrupt_pr +kvmppc_interrupt_pr: /* Register usage at this point: * -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 04/14] kvm: powerpc: book3s: Add a new config variable CONFIG_KVM_BOOK3S_HV_POSSIBLE
From: "Aneesh Kumar K.V"
This help ups to select the relevant code in the kernel code
when we later move HV and PR bits as seperate modules. The patch
also makes the config options for PR KVM selectable
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s.h | 2 --
arch/powerpc/include/asm/kvm_book3s_64.h | 6 +++---
arch/powerpc/include/asm/kvm_book3s_asm.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 10 +-
arch/powerpc/include/asm/kvm_ppc.h| 2 +-
arch/powerpc/kernel/asm-offsets.c | 8
arch/powerpc/kernel/idle_power7.S | 2 +-
arch/powerpc/kvm/Kconfig | 18 +-
arch/powerpc/kvm/Makefile | 12
arch/powerpc/kvm/book3s_exports.c | 5 +++--
10 files changed, 43 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 5c07d10..99ef871 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -199,8 +199,6 @@ static inline struct kvmppc_vcpu_book3s *to_book3s(struct
kvm_vcpu *vcpu)
return vcpu->arch.book3s;
}
-extern void kvm_return_point(void);
-
/* Also add subarch specific defines */
#ifdef CONFIG_KVM_BOOK3S_32_HANDLER
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index e6ee7fd..bf0fa8b 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -35,7 +35,7 @@ static inline void svcpu_put(struct kvmppc_book3s_shadow_vcpu
*svcpu)
#define SPAPR_TCE_SHIFT12
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
#define KVM_DEFAULT_HPT_ORDER 24 /* 16MB HPT by default */
extern unsigned long kvm_rma_pages;
#endif
@@ -278,7 +278,7 @@ static inline int is_vrma_hpte(unsigned long hpte_v)
(HPTE_V_1TB_SEG | (VRMA_VSID << (40 - 16)));
}
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
/*
* Note modification of an HPTE; set the HPTE modified bit
* if anyone is interested.
@@ -289,6 +289,6 @@ static inline void note_hpte_modification(struct kvm *kvm,
if (atomic_read(&kvm->arch.hpte_mod_interest))
rev->guest_rpte |= HPTE_GR_MODIFIED;
}
-#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#endif /* __ASM_KVM_BOOK3S_64_H__ */
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 6273711..0bd9348 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -83,7 +83,7 @@ struct kvmppc_host_state {
u8 restore_hid5;
u8 napping;
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
u8 hwthread_req;
u8 hwthread_state;
u8 host_ipi;
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index a0ca1f4..e86db97 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -229,15 +229,15 @@ struct revmap_entry {
#define KVMPPC_GOT_PAGE0x80
struct kvm_arch_memory_slot {
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
unsigned long *rmap;
unsigned long *slot_phys;
-#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
};
struct kvm_arch {
unsigned int lpid;
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
unsigned long hpt_virt;
struct revmap_entry *revmap;
unsigned int host_lpid;
@@ -261,7 +261,7 @@ struct kvm_arch {
cpumask_t need_tlb_flush;
struct kvmppc_vcore *vcores[KVM_MAX_VCORES];
int hpt_cma_alloc;
-#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
struct mutex hpt_mutex;
#endif
@@ -597,7 +597,7 @@ struct kvm_vcpu_arch {
struct kvmppc_icp *icp; /* XICS presentation controller */
#endif
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
struct kvm_vcpu_arch_shared shregs;
unsigned long pgfault_addr;
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index b15554a..1823f38 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -260,7 +260,7 @@ void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 pid);
struct openpic;
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
extern void kvm_cma_reserve(void) __init;
static inline void kvmppc_set_xics_phys(int cpu, unsigned long addr)
{
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index c6c8675..3edce7b 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -442,7 +442,7 @@ int main(void)
DEFINE(
[PATCH -V2 05/14] kvm: powerpc: book3s: Add kvmppc_ops callback
From: "Aneesh Kumar K.V"
This patch add a new callback kvmppc_ops. This will help us in enabling
both HV and PR KVM together in the same kernel. The actual change to
enable them together is done in the later patch in the series.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s.h | 1 -
arch/powerpc/include/asm/kvm_ppc.h| 85 +
arch/powerpc/kernel/exceptions-64s.S | 2 +-
arch/powerpc/kvm/book3s.c | 145 +-
arch/powerpc/kvm/book3s.h | 32 +
arch/powerpc/kvm/book3s_32_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 17 ++-
arch/powerpc/kvm/book3s_emulate.c | 8 +-
arch/powerpc/kvm/book3s_hv.c | 220 --
arch/powerpc/kvm/book3s_interrupts.S | 2 +-
arch/powerpc/kvm/book3s_pr.c | 194 +++---
arch/powerpc/kvm/book3s_xics.c| 4 +-
arch/powerpc/kvm/emulate.c| 6 +-
arch/powerpc/kvm/powerpc.c| 58 +++--
15 files changed, 554 insertions(+), 224 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s.h
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 99ef871..315a5d6 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -124,7 +124,6 @@ extern void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu,
ulong ea, ulong ea_mask)
extern void kvmppc_mmu_pte_vflush(struct kvm_vcpu *vcpu, u64 vp, u64 vp_mask);
extern void kvmppc_mmu_pte_pflush(struct kvm_vcpu *vcpu, ulong pa_start, ulong
pa_end);
extern void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 new_msr);
-extern void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr);
extern void kvmppc_mmu_book3s_64_init(struct kvm_vcpu *vcpu);
extern void kvmppc_mmu_book3s_32_init(struct kvm_vcpu *vcpu);
extern void kvmppc_mmu_book3s_hv_init(struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 1823f38..1d22b53 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -106,13 +106,6 @@ extern void kvmppc_core_queue_external(struct kvm_vcpu
*vcpu,
struct kvm_interrupt *irq);
extern void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu);
extern void kvmppc_core_flush_tlb(struct kvm_vcpu *vcpu);
-
-extern int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
- unsigned int op, int *advance);
-extern int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn,
-ulong val);
-extern int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn,
-ulong *val);
extern int kvmppc_core_check_requests(struct kvm_vcpu *vcpu);
extern int kvmppc_booke_init(void);
@@ -135,8 +128,6 @@ extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args);
extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
unsigned long ioba, unsigned long tce);
-extern long kvm_vm_ioctl_allocate_rma(struct kvm *kvm,
- struct kvm_allocate_rma *rma);
extern struct kvm_rma_info *kvm_alloc_rma(void);
extern void kvm_release_rma(struct kvm_rma_info *ri);
extern struct page *kvm_alloc_hpt(unsigned long nr_pages);
@@ -177,6 +168,66 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq,
u32 *server,
extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
+union kvmppc_one_reg {
+ u32 wval;
+ u64 dval;
+ vector128 vval;
+ u64 vsxval[2];
+ struct {
+ u64 addr;
+ u64 length;
+ } vpaval;
+};
+
+struct kvmppc_ops {
+ int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+ int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+ int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val);
+ int (*set_one_reg)(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val);
+ void (*vcpu_load)(struct kvm_vcpu *vcpu, int cpu);
+ void (*vcpu_put)(struct kvm_vcpu *vcpu);
+ void (*set_msr)(struct kvm_vcpu *vcpu, u64 msr);
+ int (*vcpu_run)(struct kvm_run *run, struct kvm_vcpu *vcpu);
+ struct kvm_vcpu *(*vcpu_create)(struct kvm *kvm, unsigned int id);
+ void (*vcpu_free)(struct kvm_vcpu *vcpu);
+ int (*check_requests)(struct kvm_vcpu *vcpu);
+ int (*get_dirty_log)(struct kvm *kvm, struct kvm_dirty_log *log);
+ void (*flush_memslot)(struct kvm *kvm, struct kvm_memory_slot *memslot);
+ int (*prepare_memory_region)(struct kvm *kvm,
+
[PATCH -V2 03/14] kvm: powerpc: book3s: pr: Rename KVM_BOOK3S_PR to KVM_BOOK3S_PR_POSSIBLE
From: "Aneesh Kumar K.V"
With later patches supporting PR kvm as a kernel module, the changes
that has to be built into the main kernel binary to enable PR KVM module
is now selected via KVM_BOOK3S_PR_POSSIBLE
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/kvm_book3s.h| 4 ++--
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/include/asm/paca.h | 2 +-
arch/powerpc/kernel/asm-offsets.c| 2 +-
arch/powerpc/kernel/exceptions-64s.S | 2 +-
arch/powerpc/kvm/Kconfig | 6 +++---
arch/powerpc/kvm/trace.h | 10 +-
9 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index b86c4db..fe1c62d 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -243,7 +243,7 @@ do_kvm_##n:
\
#define KVM_HANDLER_SKIP(area, h, n)
#endif
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
#define KVMTEST_PR(n) __KVMTEST(n)
#define KVM_HANDLER_PR(area, h, n) __KVM_HANDLER(area, h, n)
#define KVM_HANDLER_PR_SKIP(area, h, n)__KVM_HANDLER_SKIP(area, h, n)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 0ec00f4..5c07d10 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -304,7 +304,7 @@ static inline ulong kvmppc_get_fault_dar(struct kvm_vcpu
*vcpu)
return vcpu->arch.fault_dar;
}
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
{
@@ -339,7 +339,7 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu
*vcpu)
return crit;
}
-#else /* CONFIG_KVM_BOOK3S_PR */
+#else /* CONFIG_KVM_BOOK3S_PR_POSSIBLE */
static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
{
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 86d638a..e6ee7fd 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -20,7 +20,7 @@
#ifndef __ASM_KVM_BOOK3S_64_H__
#define __ASM_KVM_BOOK3S_64_H__
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
static inline struct kvmppc_book3s_shadow_vcpu *svcpu_get(struct kvm_vcpu
*vcpu)
{
preempt_disable();
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index ac40013..a0ca1f4 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -262,7 +262,7 @@ struct kvm_arch {
struct kvmppc_vcore *vcores[KVM_MAX_VCORES];
int hpt_cma_alloc;
#endif /* CONFIG_KVM_BOOK3S_64_HV */
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
struct mutex hpt_mutex;
#endif
#ifdef CONFIG_PPC_BOOK3S_64
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 77c91e7..aefe187 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -161,7 +161,7 @@ struct paca_struct {
struct dtl_entry *dtl_curr; /* pointer corresponding to dtl_ridx */
#ifdef CONFIG_KVM_BOOK3S_HANDLER
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
/* We use this to store guest state in */
struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
#endif
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index aae7b54..c6c8675 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -530,7 +530,7 @@ int main(void)
DEFINE(VCPU_SLB_SIZE, sizeof(struct kvmppc_slb));
#ifdef CONFIG_PPC_BOOK3S_64
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
DEFINE(PACA_SVCPU, offsetof(struct paca_struct, shadow_vcpu));
# define SVCPU_FIELD(x, f) DEFINE(x, offsetof(struct paca_struct,
shadow_vcpu.f))
#else
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 580d97a..7b75008 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -424,7 +424,7 @@ data_access_check_stab:
mfspr r9,SPRN_DSISR
srdir10,r10,60
rlwimi r10,r9,16,0x20
-#ifdef CONFIG_KVM_BOOK3S_PR
+#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
lbz r9,HSTATE_IN_GUEST(r13)
rlwimi r10,r9,8,0x300
#endif
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index ffaef2c..d0665f2 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -34,7 +34,7 @@ config KVM_BOOK3S_64_HANDLER
bool
select KVM_BOOK3S_HANDLER
-config KVM_BOOK3S_PR
+config KVM_BOOK3S_PR_POSSIBLE
[PATCH -V2 02/14] kvm: powerpc: book3s: move book3s_64_vio_hv.c into the main kernel binary
From: Paul Mackerras Since the code in book3s_64_vio_hv.c is called from real mode with HV KVM, and therefore has to be built into the main kernel binary, this makes it always built-in rather than part of the KVM module. It gets called from the KVM module by PR KVM, so this adds an EXPORT_SYMBOL_GPL(). Signed-off-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/kvm/Makefile | 12 arch/powerpc/kvm/book3s_64_vio_hv.c | 1 + 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile index 6646c95..104e8dc 100644 --- a/arch/powerpc/kvm/Makefile +++ b/arch/powerpc/kvm/Makefile @@ -53,32 +53,36 @@ kvm-e500mc-objs := \ e500_emulate.o kvm-objs-$(CONFIG_KVM_E500MC) := $(kvm-e500mc-objs) +kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) := \ + book3s_64_vio_hv.o + kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \ $(KVM)/coalesced_mmio.o \ fpu.o \ book3s_paired_singles.o \ book3s_pr.o \ book3s_pr_papr.o \ - book3s_64_vio_hv.o \ book3s_emulate.o \ book3s_interrupts.o \ book3s_mmu_hpte.o \ book3s_64_mmu_host.o \ book3s_64_mmu.o \ book3s_32_mmu.o -kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \ + +kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_PR) += \ book3s_rmhandlers.o kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \ book3s_hv.o \ book3s_hv_interrupts.o \ book3s_64_mmu_hv.o + kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \ book3s_hv_rm_xics.o -kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \ + +kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \ book3s_hv_rmhandlers.o \ book3s_hv_rm_mmu.o \ - book3s_64_vio_hv.o \ book3s_hv_ras.o \ book3s_hv_builtin.o \ book3s_hv_cma.o \ diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c index 30c2f3b..2c25f54 100644 --- a/arch/powerpc/kvm/book3s_64_vio_hv.c +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c @@ -74,3 +74,4 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn, /* Didn't find the liobn, punt it to userspace */ return H_TOO_HARD; } +EXPORT_SYMBOL_GPL(kvmppc_h_put_tce); -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 01/14] kvm: powerpc: book3s: remove kvmppc_handler_highmem label
From: Paul Mackerras This label is not used now. Signed-off-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/kvm/book3s_hv_interrupts.S | 3 --- arch/powerpc/kvm/book3s_interrupts.S| 3 --- 2 files changed, 6 deletions(-) diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S index 37f1cc4..928142c 100644 --- a/arch/powerpc/kvm/book3s_hv_interrupts.S +++ b/arch/powerpc/kvm/book3s_hv_interrupts.S @@ -158,9 +158,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201) * Interrupts are enabled again at this point. */ -.global kvmppc_handler_highmem -kvmppc_handler_highmem: - /* * Register usage at this point: * diff --git a/arch/powerpc/kvm/book3s_interrupts.S b/arch/powerpc/kvm/book3s_interrupts.S index d4e30d8..38166ab 100644 --- a/arch/powerpc/kvm/book3s_interrupts.S +++ b/arch/powerpc/kvm/book3s_interrupts.S @@ -121,9 +121,6 @@ kvm_start_lightweight: * */ -.global kvmppc_handler_highmem -kvmppc_handler_highmem: - /* * Register usage at this point: * -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] hwrng: Use KBUILD_MODNAME in pseries-rng.c
On Wed, Sep 25, 2013 at 07:24:16PM +1000, Michael Ellerman wrote: > Signed-off-by: Michael Ellerman Both patches applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
