* Re: [PATCH 10/13] ocxl: Add Makefile and Kconfig
From: Michael Ellerman @ 2018-01-09 23:21 UTC (permalink / raw)
To: Frederic Barrat, Andrew Donnellan, linuxppc-dev, linux-kernel
Cc: arnd, gregkh, mpe, alastair
In-Reply-To: <c61dd248-4564-5290-d803-4131278f9383@linux.vnet.ibm.com>
On 10 January 2018 2:45:56 am AEDT, Frederic Barrat <fbarrat@linux=2Evnet=
=2Eibm=2Ecom> wrote:
>
>
>Le 03/01/2018 =C3=A0 06:48, Andrew Donnellan a =C3=A9crit=C2=A0:
>> On 19/12/17 02:21, Frederic Barrat wrote:
>>> OCXL_BASE triggers the platform support needed by the driver=2E
>>>
>>> Signed-off-by: Frederic Barrat <fbarrat@linux=2Evnet=2Eibm=2Ecom>
>>> ---
>>> =C2=A0 drivers/misc/Kconfig=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0 1 +
>>> =C2=A0 drivers/misc/Makefile=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 1 +
>>> =C2=A0 drivers/misc/ocxl/Kconfig=C2=A0 | 25 +++++++++++++++++++++++++
>>> =C2=A0 drivers/misc/ocxl/Makefile | 10 ++++++++++
>>> =C2=A0 4 files changed, 37 insertions(+)
>>> =C2=A0 create mode 100644 drivers/misc/ocxl/Kconfig
>>> =C2=A0 create mode 100644 drivers/misc/ocxl/Makefile
>>>
>>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>>> index f1a5c2357b14=2E=2E0534f338c84a 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -508,4 +508,5 @@ source "drivers/misc/mic/Kconfig"
>>> =C2=A0 source "drivers/misc/genwqe/Kconfig"
>>> =C2=A0 source "drivers/misc/echo/Kconfig"
>>> =C2=A0 source "drivers/misc/cxl/Kconfig"
>>> +source "drivers/misc/ocxl/Kconfig"
>>> =C2=A0 endmenu
>>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>>> index 5ca5f64df478=2E=2E73326d54e246 100644
>>> --- a/drivers/misc/Makefile
>>> +++ b/drivers/misc/Makefile
>>> @@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +=3D cxl/
>>> =C2=A0 obj-$(CONFIG_ASPEED_LPC_CTRL)=C2=A0=C2=A0=C2=A0 +=3D aspeed-lpc=
-ctrl=2Eo
>>> =C2=A0 obj-$(CONFIG_ASPEED_LPC_SNOOP)=C2=A0=C2=A0=C2=A0 +=3D aspeed-lp=
c-snoop=2Eo
>>> =C2=A0 obj-$(CONFIG_PCI_ENDPOINT_TEST)=C2=A0=C2=A0=C2=A0 +=3D pci_endp=
oint_test=2Eo
>>> +obj-$(CONFIG_OCXL)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=3D ocx=
l/
>>>
>>> =C2=A0 lkdtm-$(CONFIG_LKDTM)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
+=3D lkdtm_core=2Eo
>>> =C2=A0 lkdtm-$(CONFIG_LKDTM)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
+=3D lkdtm_bugs=2Eo
>>> diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig
>>> new file mode 100644
>>> index 000000000000=2E=2E4496b61f48db
>>> --- /dev/null
>>> +++ b/drivers/misc/ocxl/Kconfig
>>> @@ -0,0 +1,25 @@
>>> +#
>>> +# Open Coherent Accelerator (OCXL) compatible devices
>>> +#
>>> +
>>> +config OCXL_BASE
>>> +=C2=A0=C2=A0=C2=A0 bool
>>> +=C2=A0=C2=A0=C2=A0 default n
>>> +=C2=A0=C2=A0=C2=A0 select PPC_COPRO_BASE
>>> +
>>> +config OCXL
>>> +=C2=A0=C2=A0=C2=A0 tristate "Support for Open Coherent Accelerators (=
OCXL)"
>>> +=C2=A0=C2=A0=C2=A0 depends on PPC_POWERNV && PCI && EEH
>>> +=C2=A0=C2=A0=C2=A0 select OCXL_BASE
>>> +=C2=A0=C2=A0=C2=A0 default m
>>> +=C2=A0=C2=A0=C2=A0 help
>>> +
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Select this option to enable driver su=
pport for Open
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Coherent Accelerators (OCXL)=2E=C2=A0 =
OCXL is otherwise known as
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Open Coherent Accelerator Processor In=
terface (OCAPI)=2E
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OCAPI allows accelerators in FPGAs to =
be coherently attached
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to a CPU through a Open CAPI link=2E=
=C2=A0 This driver enables
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 userspace programs to access these acc=
elerators through
>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 devices found in /dev/ocxl/
>>=20
>> I'd prefer more consistency in how we refer to OpenCAPI=2E "ocxl" is a=
=20
>> driver name that we have purely for historical reasons, it's not
>really=20
>> the name of anything else=2E I know throughout the various specs and
>code,=20
>> we use "OCAPI" a lot, but that's not really an abbreviation that
>should=20
>> be "user-facing"=2E
>>=20
>> Something like:
>>=20
>> config OCXL
>> =C2=A0=C2=A0=C2=A0=C2=A0 tristate "OpenCAPI coherent accelerator suppo=
rt"
>> =C2=A0=C2=A0=C2=A0=C2=A0 help
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Select this option to enable the =
ocxl driver for Open
>Coherent
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Accelerator Processor Interface (=
OpenCAPI) devices=2E
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OpenCAPI allows FPGA and ASIC acc=
elerators to be coherently
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attached to a CPU over an OpenCAP=
I link=2E
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The ocxl driver enables userspace=
programs to access these
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 accelerators through devices in /=
dev/ocxl/=2E
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For more information, see http://=
opencapi=2Eorg=2E
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If unsure, say N=2E
>>=20
>
>Agreed, and stolen=2E
Would also be great to add something describing the relationship to CAPI a=
nd cxl=2E Otherwise people will be confused about whether they need this on=
e or the other one or both=2E
cheers
--=20
Sent from my Android phone with K-9 Mail=2E Please excuse my brevity=2E
^ permalink raw reply
* Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!
From: Madhani, Himanshu @ 2018-01-09 18:09 UTC (permalink / raw)
To: Bart Van Assche, abdhalee@linux.vnet.ibm.com
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, keescook@chromium.org,
sim@linux.vnet.ibm.com, linux-scsi@vger.kernel.org,
sfr@canb.auug.org.au, linux-next@vger.kernel.org,
sachinp@linux.vnet.ibm.com, mpe@ellerman.id.au
In-Reply-To: <1515513297.2721.2.camel@wdc.com>
Hello Abdul,=20
> On Jan 9, 2018, at 7:54 AM, Bart Van Assche <bart.vanassche@wdc.com> wrot=
e:
>=20
> On Tue, 2018-01-09 at 14:44 +0530, Abdul Haleem wrote:
>> Greeting's,=20
>>=20
>> Linux next kernel panics on powerpc when module qla2xxx is load/unload.
>>=20
>> Machine Type: Power 8 PowerVM LPAR
>> Kernel : 4.15.0-rc2-next-20171211
>> gcc : version 4.8.5
>> Test type: module load/unload few times
>>=20
>> Trace messages:
>> ---------------
>> qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00=
.03-k.
>> qla2xxx [0106:a0:00.0]-001a: : MSI-X vector count: 32.
>> qla2xxx [0106:a0:00.0]-001d: : Found an ISP2532 irq 505 iobase 0x0000000=
0aeb324e6.
>> qla2xxx [0106:a0:00.0]-00c6:1: MSI-X: Failed to enable support with 32 v=
ectors, using 16 vectors.
>> qla2xxx [0106:a0:00.0]-00fb:1: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapt=
er.
>> qla2xxx [0106:a0:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.0=
hdma- host#=3D1 fw=3D8.06.00 (90d5).
>> qla2xxx [0106:a0:00.1]-001a: : MSI-X vector count: 32.
>> qla2xxx [0106:a0:00.1]-001d: : Found an ISP2532 irq 506 iobase 0x0000000=
0a46f1774.
>> qla2xxx [0106:a0:00.1]-00c6:2: MSI-X: Failed to enable support with 32 v=
ectors, using 16 vectors.
>> 2xxx
>> qla2xxx [0106:a0:00.1]-00fb:2: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapt=
er.
>> qla2xxx [0106:a0:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.1=
hdma- host#=3D2 fw=3D8.06.00 (90d5).
>> 0:00.0]-500a:1: LOOP UP detected (8 Gbps).=20
>> qla2xxx [0106:a0:00.1]-500a:2: LOOP UP detected (8 Gbps).
>> list_add double add: new=3D000000008d33e594, prev=3D000000008d33e594, ne=
xt=3D00000000adef1df4.
>> ------------[ cut here ]------------
>> kernel BUG at lib/list_debug.c:31!=20
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> LE SMP NR_CPUS=3D2048 NUMA pSeries=20
>> Dumping ftrace buffer:=20
>> (ftrace buffer empty)
>> Modules linked in: qla2xxx(E) tg3(E) ibmveth(E) xt_CHECKSUM(E)
>> iptable_mangle(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E)
>> iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
>> nf_defrag_ipv4(E) xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E)
>> nf_reject_ipv4(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E) kvm(E)
>> sctp_diag(E) sctp(E) libcrc32c(E) tcp_diag(E) udp_diag(E)
>> ebtable_filter(E) ebtables(E) dccp_diag(E) ip6table_filter(E) dccp(E)
>> ip6_tables(E) iptable_filter(E) inet_diag(E) unix_diag(E)
>> af_packet_diag(E) netlink_diag(E) xts(E) sg(E) vmx_crypto(E)
>> pseries_rng(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E)
>> sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E)
>> fscrypto(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) nvme_fc(E)
>> nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E)
>> ptp(E) pps_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
>> [last unloaded: qla2xxx]
>> CPU: 7 PID: 22230 Comm: qla2xxx_1_dpc Tainted: G E 4.15.0-=
rc2-next-20171211-autotest-autotest #1
>> NIP: c000000000511040 LR: c00000000051103c CTR: 0000000000655170 =
=20
>> REGS: 000000009b7356fa TRAP: 0700 Tainted: G E (4.15.0-=
rc2-next-20171211-autotest-autotest)
>> MSR: 800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 2200=
0022 XER: 00000009 =20
>> CFAR: c000000000170594 SOFTE: 0=20
>> GPR00: c00000000051103c c0000000fc293ac0 c0000000010f1d00 00000000000000=
58=20
>> GPR04: c00000028fcccdd0 c00000028fce3798 80000000374060b8 ffffffffffffff=
ff=20
>> GPR08: 0000000000000000 c000000000d435ec 000000028ef90000 00000000000027=
17=20
>> GPR12: 0000000000000000 c00000000e734980 c0000000001215d8 c0000002886996=
c0=20
>> GPR16: 0000000000000000 0000000000000020 c0000002813d83f8 00000000000000=
01=20
>> GPR20: 0000000020000000 0000000000002000 0000000000000002 c0000002813dc8=
08=20
>> GPR24: 0000000000000003 0000000000000001 c00000027f5a5c20 c0000002813dce=
d0=20
>> GPR28: c00000027f5a5d90 c00000027f5a5d90 c00000027f5a5c00 c0000002813dc7=
f8=20
>> NIP [c000000000511040] __list_add_valid+0x70/0xb0
>> LR [c00000000051103c] __list_add_valid+0x6c/0xb0
>> Call Trace:
>> [c0000000fc293ac0] [c00000000051103c] __list_add_valid+0x6c/0xb0 (unreli=
able)
>> [c0000000fc293b20] [d0000000051f1a08] qla24xx_async_gnl+0x108/0x420 [qla=
2xxx]
>> [c0000000fc293bc0] [d0000000051e762c] qla2x00_do_work+0x18c/0x8c0 [qla2x=
xx]
>> [c0000000fc293ce0] [d0000000051e8180] qla2x00_relogin+0x420/0xff0 [qla2x=
xx]
>> [c0000000fc293dc0] [c00000000012172c] kthread+0x15c/0x1a0
>> [c0000000fc293e30] [c00000000000b4e8] ret_from_kernel_thread+0x5c/0x74
>> Instruction dump:
>> 41de0018 38210060 38600001 e8010010 7c0803a6 4e800020 3c62ffae 7d445378=
=20
>> 38631748 7d254b78 4bc5f51d 60000000 <0fe00000> 3c62ffae 7cc43378 386316f=
8=20
>> ---[ end trace a41bc8bd434657f1 ]---
>>=20
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:=20
>> (ftrace buffer empty)
>> Rebooting in 10 seconds..
>>=20
>> This trace back to the below code path:
>>=20
>> # gdb -batch vmlinux -ex 'list *(0xc000000000511040)'
>> 0xc000000000511040 is in __list_add_valid (lib/list_debug.c:29).
>> 24 "list_add corruption. next->prev should be prev (%p), but was %p. =
(next=3D%p).\n",
>> 25 prev, next->prev, next) ||
>> 26 CHECK_DATA_CORRUPTION(prev->next !=3D next,
>> 27 "list_add corruption. prev->next should be next (%p), but was %p. =
(prev=3D%p).\n",
>> 28 next, prev->next, prev) ||
>> 29 CHECK_DATA_CORRUPTION(new =3D=3D prev || new =3D=3D next,
>> 30 "list_add double add: new=3D%p, prev=3D%p, next=3D%p.\n",
>> 31 new, prev, next))
>> 32 return false;
>> 33=09
>=20
> (+linux-scsi)
>=20
> Hello Abdul,
>=20
> Please report SCSI LLD issues on the linux-scsi mailing list.
>=20
> Bart.
We have fixed this issue with following patch
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=3D4.=
16/scsi-queue&id=3D5d3300a9b8b122b4743aed5a178bf12c87e2b8c9
Can you apply this on your setup and retry your test.=20
Thanks,
- Himanshu
^ permalink raw reply
* Re: [PATCH 07/11] powerpc/64s: Add support for RFI flush of L1-D cache
From: Michael Ellerman @ 2018-01-09 16:05 UTC (permalink / raw)
To: Joel Stanley
Cc: linuxppc-dev, Michael Neuling, peterz, Linux Kernel Mailing List,
npiggin, Oliver O'Halloran, Anton Blanchard, Paul Mackerras,
Thomas Gleixner
In-Reply-To: <CACPK8XfOyB8t+d9ALr38=akc9BKuxeA-b4jU5FqYPGPzGX4qjw@mail.gmail.com>
Joel Stanley <joel@jms.id.au> writes:
> On Mon, Jan 8, 2018 at 8:54 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> On some CPUs we can prevent the Meltdown vulnerability by flushing the
>> L1-D cache on exit from kernel to user mode, and from hypervisor to
>> guest.
>
> Super minor nitpicks below. Don't let this hold up your work.
>
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -1449,6 +1449,88 @@ masked_##_H##interrupt: \
>> b .; \
>> MASKED_DEC_HANDLER(_H)
>>
>> +TRAMP_REAL_BEGIN(rfi_flush_fallback)
>> + SET_SCRATCH0(r13);
>> + GET_PACA(r13);
>> + std r9,PACA_EXRFI+EX_R9(r13)
>> + std r10,PACA_EXRFI+EX_R10(r13)
>> + std r11,PACA_EXRFI+EX_R11(r13)
>> + std r12,PACA_EXRFI+EX_R12(r13)
>> + std r8,PACA_EXRFI+EX_R13(r13)
>> + mfctr r9
>> + ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
>> + ld r11,PACA_L1D_FLUSH_SETS(r13)
>> + ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
>> + /*
>> + * The load adresses are at staggered offsets within cachelines,
>> + * which suits some pipelines better (on others it should not
>> + * hurt.
>
> Nit: missing ) on the last line.
Thanks.
>> --- a/arch/powerpc/lib/feature-fixups.c
>> +++ b/arch/powerpc/lib/feature-fixups.c
>> @@ -116,6 +116,47 @@ void do_feature_fixups(unsigned long value, void *fixup_start, void *fixup_end)
>> }
>> }
>>
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +void do_rfi_flush_fixups(enum l1d_flush_type types)
>> +{
>> + unsigned int instrs[3], *dest;
>> + long *start, *end;
>> + int i;
>> +
>> + start = PTRRELOC(&__start___rfi_flush_fixup),
>> + end = PTRRELOC(&__stop___rfi_flush_fixup);
>> +
>> + instrs[0] = 0x60000000; /* nop */
>> + instrs[1] = 0x60000000; /* nop */
>> + instrs[2] = 0x60000000; /* nop */
>> +
>> + if (types & L1D_FLUSH_FALLBACK)
>
> This looked a bit confusing on first read. Do we ever get
> L1D_FLUSH_FALLBACK and the other types? If not, could it be made
> clearer?
>
> if ( types & L1D_FLUSH_FALLBACK)
> /* stuff */
> else
> /* other types */
Yeah that would make more sense.
I'm going to merge it as-is because that's whats been tested, and given
the time of day I'm likely to break it if I try and refactor it. So we
can clean it up once it's merged.
cheers
^ permalink raw reply
* Re: [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
From: Jesper Nilsson @ 2018-01-09 15:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, linux-mips, linux-ia64, linux-sh, sparclinux, Guan Xuetao,
linux-arch, linux-s390, linux-c6x-dev, linux-hexagon, x86,
linux-snps-arc, adi-buildroot-devel, linux-m68k, patches,
linux-metag, linux-arm-kernel, Michal Simek, linux-parisc,
linux-cris-kernel, linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <20171229081911.2802-6-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:09AM +0100, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and can map any address (that includes virtual iommus like
> swiotlb). The problem with this scheme is that it is per-architecture and
> not per dma_ops instance, and we are growing more and more setups that
> have multiple different dma operations in use on a single system, for
> which this scheme can't provide a correct answer. Depending on the
> architecture that means we either get a false positive or false negative
> at the moment.
>
> This patch instead extents the is_phys flag in struct dma_map_ops that
> is currently only used by a few architectures to be used tree wide.
>
> Note that this means that we now need a struct device parent in the
> Scsi_Host or netdevice. Every modern driver has these, but there might
> still be a few outdated legacy drivers out there, which now won't make
> an intelligent decision.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
For the CRIS part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 1 +
> arch/cris/include/asm/pci.h | 6 ------
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
From: Jesper Nilsson @ 2018-01-09 15:54 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, linux-mips, linux-ia64, linux-sh, sparclinux, Guan Xuetao,
linux-arch, linux-s390, linux-c6x-dev, linux-hexagon, x86,
linux-snps-arc, adi-buildroot-devel, linux-m68k, patches,
linux-metag, linux-arm-kernel, Michal Simek, linux-parisc,
linux-cris-kernel, linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <20171229081911.2802-23-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:26AM +0100, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 3 ---
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!
From: Bart Van Assche @ 2018-01-09 15:54 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, abdhalee@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
keescook@chromium.org, himanshu.madhani@cavium.com,
sim@linux.vnet.ibm.com, linux-scsi@vger.kernel.org,
sfr@canb.auug.org.au, linux-next@vger.kernel.org,
sachinp@linux.vnet.ibm.com, mpe@ellerman.id.au
In-Reply-To: <1515489264.3648.18.camel@abdul.in.ibm.com>
T24gVHVlLCAyMDE4LTAxLTA5IGF0IDE0OjQ0ICswNTMwLCBBYmR1bCBIYWxlZW0gd3JvdGU6DQo+
IEdyZWV0aW5nJ3MsIA0KPiANCj4gTGludXggbmV4dCBrZXJuZWwgcGFuaWNzIG9uIHBvd2VycGMg
d2hlbiBtb2R1bGUgcWxhMnh4eCBpcyBsb2FkL3VubG9hZC4NCj4gDQo+IE1hY2hpbmUgVHlwZTog
UG93ZXIgOCBQb3dlclZNIExQQVINCj4gS2VybmVsIDogNC4xNS4wLXJjMi1uZXh0LTIwMTcxMjEx
DQo+IGdjYyA6IHZlcnNpb24gNC44LjUNCj4gVGVzdCB0eXBlOiBtb2R1bGUgbG9hZC91bmxvYWQg
ZmV3IHRpbWVzDQo+IA0KPiBUcmFjZSBtZXNzYWdlczoNCj4gLS0tLS0tLS0tLS0tLS0tDQo+IHFs
YTJ4eHggWzAwMDA6MDA6MDAuMF0tMDAwNTogOiBRTG9naWMgRmlicmUgQ2hhbm5lbCBIQkEgRHJp
dmVyOiAxMC4wMC4wMC4wMy1rLg0KPiBxbGEyeHh4IFswMTA2OmEwOjAwLjBdLTAwMWE6IDogTVNJ
LVggdmVjdG9yIGNvdW50OiAzMi4NCj4gcWxhMnh4eCBbMDEwNjphMDowMC4wXS0wMDFkOiA6IEZv
dW5kIGFuIElTUDI1MzIgaXJxIDUwNSBpb2Jhc2UgMHgwMDAwMDAwMGFlYjMyNGU2Lg0KPiBxbGEy
eHh4IFswMTA2OmEwOjAwLjBdLTAwYzY6MTogTVNJLVg6IEZhaWxlZCB0byBlbmFibGUgc3VwcG9y
dCB3aXRoIDMyIHZlY3RvcnMsIHVzaW5nIDE2IHZlY3RvcnMuDQo+IHFsYTJ4eHggWzAxMDY6YTA6
MDAuMF0tMDBmYjoxOiBRTG9naWMgUUxFMjU2MiAtIFBDSWUgMi1wb3J0IDhHYiBGQyBBZGFwdGVy
Lg0KPiBxbGEyeHh4IFswMTA2OmEwOjAwLjBdLTAwZmM6MTogSVNQMjUzMjogUENJZSAoNS4wR1Qv
cyB4OCkgQCAwMTA2OmEwOjAwLjAgaGRtYS0gaG9zdCM9MSBmdz04LjA2LjAwICg5MGQ1KS4NCj4g
cWxhMnh4eCBbMDEwNjphMDowMC4xXS0wMDFhOiA6IE1TSS1YIHZlY3RvciBjb3VudDogMzIuDQo+
IHFsYTJ4eHggWzAxMDY6YTA6MDAuMV0tMDAxZDogOiBGb3VuZCBhbiBJU1AyNTMyIGlycSA1MDYg
aW9iYXNlIDB4MDAwMDAwMDBhNDZmMTc3NC4NCj4gcWxhMnh4eCBbMDEwNjphMDowMC4xXS0wMGM2
OjI6IE1TSS1YOiBGYWlsZWQgdG8gZW5hYmxlIHN1cHBvcnQgd2l0aCAzMiB2ZWN0b3JzLCB1c2lu
ZyAxNiB2ZWN0b3JzLg0KPiAyeHh4DQo+IHFsYTJ4eHggWzAxMDY6YTA6MDAuMV0tMDBmYjoyOiBR
TG9naWMgUUxFMjU2MiAtIFBDSWUgMi1wb3J0IDhHYiBGQyBBZGFwdGVyLg0KPiBxbGEyeHh4IFsw
MTA2OmEwOjAwLjFdLTAwZmM6MjogSVNQMjUzMjogUENJZSAoNS4wR1QvcyB4OCkgQCAwMTA2OmEw
OjAwLjEgaGRtYS0gaG9zdCM9MiBmdz04LjA2LjAwICg5MGQ1KS4NCj4gMDowMC4wXS01MDBhOjE6
IExPT1AgVVAgZGV0ZWN0ZWQgKDggR2JwcykuIA0KPiBxbGEyeHh4IFswMTA2OmEwOjAwLjFdLTUw
MGE6MjogTE9PUCBVUCBkZXRlY3RlZCAoOCBHYnBzKS4NCj4gbGlzdF9hZGQgZG91YmxlIGFkZDog
bmV3PTAwMDAwMDAwOGQzM2U1OTQsIHByZXY9MDAwMDAwMDA4ZDMzZTU5NCwgbmV4dD0wMDAwMDAw
MGFkZWYxZGY0Lg0KPiAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NCj4ga2Vy
bmVsIEJVRyBhdCBsaWIvbGlzdF9kZWJ1Zy5jOjMxISANCj4gT29wczogRXhjZXB0aW9uIGluIGtl
cm5lbCBtb2RlLCBzaWc6IDUgWyMxXQ0KPiBMRSBTTVAgTlJfQ1BVUz0yMDQ4IE5VTUEgcFNlcmll
cyANCj4gRHVtcGluZyBmdHJhY2UgYnVmZmVyOiANCj4gICAgKGZ0cmFjZSBidWZmZXIgZW1wdHkp
DQo+IE1vZHVsZXMgbGlua2VkIGluOiBxbGEyeHh4KEUpIHRnMyhFKSBpYm12ZXRoKEUpIHh0X0NI
RUNLU1VNKEUpDQo+IGlwdGFibGVfbWFuZ2xlKEUpIGlwdF9NQVNRVUVSQURFKEUpIG5mX25hdF9t
YXNxdWVyYWRlX2lwdjQoRSkNCj4gaXB0YWJsZV9uYXQoRSkgbmZfbmF0X2lwdjQoRSkgbmZfbmF0
KEUpIG5mX2Nvbm50cmFja19pcHY0KEUpDQo+IG5mX2RlZnJhZ19pcHY0KEUpIHh0X2Nvbm50cmFj
ayhFKSBuZl9jb25udHJhY2soRSkgaXB0X1JFSkVDVChFKQ0KPiBuZl9yZWplY3RfaXB2NChFKSB0
dW4oRSkgYnJpZGdlKEUpIHN0cChFKSBsbGMoRSkga3ZtX3ByKEUpIGt2bShFKQ0KPiBzY3RwX2Rp
YWcoRSkgc2N0cChFKSBsaWJjcmMzMmMoRSkgdGNwX2RpYWcoRSkgdWRwX2RpYWcoRSkNCj4gZWJ0
YWJsZV9maWx0ZXIoRSkgZWJ0YWJsZXMoRSkgZGNjcF9kaWFnKEUpIGlwNnRhYmxlX2ZpbHRlcihF
KSBkY2NwKEUpDQo+IGlwNl90YWJsZXMoRSkgaXB0YWJsZV9maWx0ZXIoRSkgaW5ldF9kaWFnKEUp
IHVuaXhfZGlhZyhFKQ0KPiBhZl9wYWNrZXRfZGlhZyhFKSBuZXRsaW5rX2RpYWcoRSkgeHRzKEUp
IHNnKEUpIHZteF9jcnlwdG8oRSkNCj4gcHNlcmllc19ybmcoRSkgbmZzZChFKSBhdXRoX3JwY2dz
cyhFKSBuZnNfYWNsKEUpIGxvY2tkKEUpIGdyYWNlKEUpDQo+IHN1bnJwYyhFKSBiaW5mbXRfbWlz
YyhFKSBpcF90YWJsZXMoRSkgZXh0NChFKSBtYmNhY2hlKEUpIGpiZDIoRSkNCj4gZnNjcnlwdG8o
RSkgc2RfbW9kKEUpIGlibXZzY3NpKEUpIHNjc2lfdHJhbnNwb3J0X3NycChFKSBudm1lX2ZjKEUp
DQo+IG52bWVfZmFicmljcyhFKSBudm1lX2NvcmUoRSkgc2NzaV90cmFuc3BvcnRfZmMoRSkNCj4g
IHB0cChFKSBwcHNfY29yZShFKSBkbV9taXJyb3IoRSkgZG1fcmVnaW9uX2hhc2goRSkgZG1fbG9n
KEUpIGRtX21vZChFKQ0KPiBbbGFzdCB1bmxvYWRlZDogcWxhMnh4eF0NCj4gQ1BVOiA3IFBJRDog
MjIyMzAgQ29tbTogcWxhMnh4eF8xX2RwYyBUYWludGVkOiBHICAgICAgICAgICAgRSAgICA0LjE1
LjAtcmMyLW5leHQtMjAxNzEyMTEtYXV0b3Rlc3QtYXV0b3Rlc3QgIzENCj4gTklQOiAgYzAwMDAw
MDAwMDUxMTA0MCBMUjogYzAwMDAwMDAwMDUxMTAzYyBDVFI6IDAwMDAwMDAwMDA2NTUxNzAgICAg
ICAgIA0KPiBSRUdTOiAwMDAwMDAwMDliNzM1NmZhIFRSQVA6IDA3MDAgICBUYWludGVkOiBHICAg
ICAgICAgICAgRSAgICAgKDQuMTUuMC1yYzItbmV4dC0yMDE3MTIxMS1hdXRvdGVzdC1hdXRvdGVz
dCkNCj4gTVNSOiAgODAwMDAwMDEwMjgyYjAzMyA8U0YsVkVDLFZTWCxFRSxGUCxNRSxJUixEUixS
SSxMRSxUTVtFXT4gIENSOiAyMjAwMDAyMiAgWEVSOiAwMDAwMDAwOSAgDQo+IENGQVI6IGMwMDAw
MDAwMDAxNzA1OTQgU09GVEU6IDAgDQo+IEdQUjAwOiBjMDAwMDAwMDAwNTExMDNjIGMwMDAwMDAw
ZmMyOTNhYzAgYzAwMDAwMDAwMTBmMWQwMCAwMDAwMDAwMDAwMDAwMDU4IA0KPiBHUFIwNDogYzAw
MDAwMDI4ZmNjY2RkMCBjMDAwMDAwMjhmY2UzNzk4IDgwMDAwMDAwMzc0MDYwYjggZmZmZmZmZmZm
ZmZmZmZmZiANCj4gR1BSMDg6IDAwMDAwMDAwMDAwMDAwMDAgYzAwMDAwMDAwMGQ0MzVlYyAwMDAw
MDAwMjhlZjkwMDAwIDAwMDAwMDAwMDAwMDI3MTcgDQo+IEdQUjEyOiAwMDAwMDAwMDAwMDAwMDAw
IGMwMDAwMDAwMGU3MzQ5ODAgYzAwMDAwMDAwMDEyMTVkOCBjMDAwMDAwMjg4Njk5NmMwIA0KPiBH
UFIxNjogMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDIwIGMwMDAwMDAyODEzZDgzZjgg
MDAwMDAwMDAwMDAwMDAwMSANCj4gR1BSMjA6IDAwMDAwMDAwMjAwMDAwMDAgMDAwMDAwMDAwMDAw
MjAwMCAwMDAwMDAwMDAwMDAwMDAyIGMwMDAwMDAyODEzZGM4MDggDQo+IEdQUjI0OiAwMDAwMDAw
MDAwMDAwMDAzIDAwMDAwMDAwMDAwMDAwMDEgYzAwMDAwMDI3ZjVhNWMyMCBjMDAwMDAwMjgxM2Rj
ZWQwIA0KPiBHUFIyODogYzAwMDAwMDI3ZjVhNWQ5MCBjMDAwMDAwMjdmNWE1ZDkwIGMwMDAwMDAy
N2Y1YTVjMDAgYzAwMDAwMDI4MTNkYzdmOCANCj4gTklQIFtjMDAwMDAwMDAwNTExMDQwXSBfX2xp
c3RfYWRkX3ZhbGlkKzB4NzAvMHhiMA0KPiBMUiBbYzAwMDAwMDAwMDUxMTAzY10gX19saXN0X2Fk
ZF92YWxpZCsweDZjLzB4YjANCj4gQ2FsbCBUcmFjZToNCj4gW2MwMDAwMDAwZmMyOTNhYzBdIFtj
MDAwMDAwMDAwNTExMDNjXSBfX2xpc3RfYWRkX3ZhbGlkKzB4NmMvMHhiMCAodW5yZWxpYWJsZSkN
Cj4gW2MwMDAwMDAwZmMyOTNiMjBdIFtkMDAwMDAwMDA1MWYxYTA4XSBxbGEyNHh4X2FzeW5jX2du
bCsweDEwOC8weDQyMCBbcWxhMnh4eF0NCj4gW2MwMDAwMDAwZmMyOTNiYzBdIFtkMDAwMDAwMDA1
MWU3NjJjXSBxbGEyeDAwX2RvX3dvcmsrMHgxOGMvMHg4YzAgW3FsYTJ4eHhdDQo+IFtjMDAwMDAw
MGZjMjkzY2UwXSBbZDAwMDAwMDAwNTFlODE4MF0gcWxhMngwMF9yZWxvZ2luKzB4NDIwLzB4ZmYw
IFtxbGEyeHh4XQ0KPiBbYzAwMDAwMDBmYzI5M2RjMF0gW2MwMDAwMDAwMDAxMjE3MmNdIGt0aHJl
YWQrMHgxNWMvMHgxYTANCj4gW2MwMDAwMDAwZmMyOTNlMzBdIFtjMDAwMDAwMDAwMDBiNGU4XSBy
ZXRfZnJvbV9rZXJuZWxfdGhyZWFkKzB4NWMvMHg3NA0KPiBJbnN0cnVjdGlvbiBkdW1wOg0KPiA0
MWRlMDAxOCAzODIxMDA2MCAzODYwMDAwMSBlODAxMDAxMCA3YzA4MDNhNiA0ZTgwMDAyMCAzYzYy
ZmZhZSA3ZDQ0NTM3OCANCj4gMzg2MzE3NDggN2QyNTRiNzggNGJjNWY1MWQgNjAwMDAwMDAgPDBm
ZTAwMDAwPiAzYzYyZmZhZSA3Y2M0MzM3OCAzODYzMTZmOCANCj4gLS0tWyBlbmQgdHJhY2UgYTQx
YmM4YmQ0MzQ2NTdmMSBdLS0tDQo+IA0KPiBLZXJuZWwgcGFuaWMgLSBub3Qgc3luY2luZzogRmF0
YWwgZXhjZXB0aW9uDQo+IER1bXBpbmcgZnRyYWNlIGJ1ZmZlcjogDQo+ICAgIChmdHJhY2UgYnVm
ZmVyIGVtcHR5KQ0KPiBSZWJvb3RpbmcgaW4gMTAgc2Vjb25kcy4uDQo+IA0KPiBUaGlzIHRyYWNl
IGJhY2sgdG8gdGhlIGJlbG93IGNvZGUgcGF0aDoNCj4gDQo+ICMgZ2RiIC1iYXRjaCB2bWxpbnV4
IC1leCAnbGlzdCAqKDB4YzAwMDAwMDAwMDUxMTA0MCknDQo+IDB4YzAwMDAwMDAwMDUxMTA0MCBp
cyBpbiBfX2xpc3RfYWRkX3ZhbGlkIChsaWIvbGlzdF9kZWJ1Zy5jOjI5KS4NCj4gMjQJCQkJImxp
c3RfYWRkIGNvcnJ1cHRpb24uIG5leHQtPnByZXYgc2hvdWxkIGJlIHByZXYgKCVwKSwgYnV0IHdh
cyAlcC4gKG5leHQ9JXApLlxuIiwNCj4gMjUJCQkJcHJldiwgbmV4dC0+cHJldiwgbmV4dCkgfHwN
Cj4gMjYJCSAgICBDSEVDS19EQVRBX0NPUlJVUFRJT04ocHJldi0+bmV4dCAhPSBuZXh0LA0KPiAy
NwkJCQkibGlzdF9hZGQgY29ycnVwdGlvbi4gcHJldi0+bmV4dCBzaG91bGQgYmUgbmV4dCAoJXAp
LCBidXQgd2FzICVwLiAocHJldj0lcCkuXG4iLA0KPiAyOAkJCQluZXh0LCBwcmV2LT5uZXh0LCBw
cmV2KSB8fA0KPiAyOQkJICAgIENIRUNLX0RBVEFfQ09SUlVQVElPTihuZXcgPT0gcHJldiB8fCBu
ZXcgPT0gbmV4dCwNCj4gMzAJCQkJImxpc3RfYWRkIGRvdWJsZSBhZGQ6IG5ldz0lcCwgcHJldj0l
cCwgbmV4dD0lcC5cbiIsDQo+IDMxCQkJCW5ldywgcHJldiwgbmV4dCkpDQo+IDMyCQkJcmV0dXJu
IGZhbHNlOw0KPiAzMwkNCg0KKCtsaW51eC1zY3NpKQ0KDQpIZWxsbyBBYmR1bCwNCg0KUGxlYXNl
IHJlcG9ydCBTQ1NJIExMRCBpc3N1ZXMgb24gdGhlIGxpbnV4LXNjc2kgbWFpbGluZyBsaXN0Lg0K
DQpCYXJ0Lg==
^ permalink raw reply
* Re: [PATCH 34/67] cris: use dma-direct
From: Jesper Nilsson @ 2018-01-09 15:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, linux-mips, linux-ia64, linux-sh, sparclinux, Guan Xuetao,
linux-arch, linux-s390, linux-c6x-dev, linux-hexagon, x86,
linux-snps-arc, adi-buildroot-devel, linux-m68k, patches,
linux-metag, linux-arm-kernel, Michal Simek, linux-parisc,
linux-cris-kernel, linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <20171229081911.2802-35-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:38AM +0100, Christoph Hellwig wrote:
> cris currently has an incomplete direct mapping dma_map_ops implementation
> is PCI support is enabled. Replace it with the fully feature generic
> dma-direct implementation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
For CRIS:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/Kconfig | 4 ++
> arch/cris/arch-v32/drivers/pci/Makefile | 2 +-
> arch/cris/arch-v32/drivers/pci/dma.c | 78 ---------------------------------
> arch/cris/include/asm/Kbuild | 1 +
> arch/cris/include/asm/dma-mapping.h | 20 ---------
> 5 files changed, 6 insertions(+), 99 deletions(-)
> delete mode 100644 arch/cris/arch-v32/drivers/pci/dma.c
> delete mode 100644 arch/cris/include/asm/dma-mapping.h
>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* [PATCH V6] cxl: Add support for ASB_Notify on POWER9
From: Christophe Lombard @ 2018-01-09 15:57 UTC (permalink / raw)
To: linuxppc-dev, fbarrat, vaibhav, andrew.donnellan
The POWER9 core supports a new feature: ASB_Notify which requires the
support of the Special Purpose Register: TIDR.
The ASB_Notify command, generated by the AFU, will attempt to
wake-up the host thread identified by the particular LPID:PID:TID.
This patch assign a unique TIDR (thread id) for the current thread which
will be used in the process element entry.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
---
Changelog[v6]
- Rebased to latest upstream.
- Updated the ioctl interface.
- Removed the updated ptrace.
- Assigned a unique TIDR for the current thread at a lower level.
Changelog[v5]
- Rebased to latest upstream.
- Updated the ioctl interface.
- Returned the tid in the ioctl structure.
Changelog[v4]
- Rebased to latest upstream.
- Updated the ioctl interface.
- Removed the field tid in the context structure.
Changelog[v3]
- Rebased to latest upstream.
- Updated attr->tid field in cxllib_get_PE_attributes().
Changelog[v2]
- Rebased to latest upstream.
- Updated the ioctl interface.
- Added a checking to allow updating the TIDR if a P9 chip is present.
---
arch/powerpc/kernel/process.c | 1 +
drivers/misc/cxl/context.c | 1 +
drivers/misc/cxl/cxl.h | 3 +++
drivers/misc/cxl/cxllib.c | 3 ++-
drivers/misc/cxl/file.c | 10 +++++++++-
drivers/misc/cxl/native.c | 13 ++++++++++++-
include/uapi/misc/cxl.h | 10 ++++++----
7 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 72be0c3..1dc39dd 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1589,6 +1589,7 @@ int set_thread_tidr(struct task_struct *t)
return 0;
}
+EXPORT_SYMBOL_GPL(set_thread_tidr);
#endif /* CONFIG_PPC64 */
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 12a41b2..9a1c6b9 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -45,6 +45,7 @@ int cxl_context_init(struct cxl_context *ctx, struct cxl_afu *afu, bool master)
ctx->pid = NULL; /* Set in start work ioctl */
mutex_init(&ctx->mapping_lock);
ctx->mapping = NULL;
+ ctx->tidr = 0;
if (cxl_is_power8()) {
spin_lock_init(&ctx->sste_lock);
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index e46a406..86ae215 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -630,6 +630,9 @@ struct cxl_context {
struct list_head extra_irq_contexts;
struct mm_struct *mm;
+
+ u16 tidr;
+ u64 wflags;
};
struct cxl_irq_info;
diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
index dc9bc18..30ccba4 100644
--- a/drivers/misc/cxl/cxllib.c
+++ b/drivers/misc/cxl/cxllib.c
@@ -199,10 +199,11 @@ int cxllib_get_PE_attributes(struct task_struct *task,
*/
attr->pid = mm->context.id;
mmput(mm);
+ attr->tid = task->thread.tidr;
} else {
attr->pid = 0;
+ attr->tid = 0;
}
- attr->tid = 0;
return 0;
}
EXPORT_SYMBOL_GPL(cxllib_get_PE_attributes);
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index 76c0b0c..e28aefb 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers/misc/cxl/file.c
@@ -173,7 +173,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
* flags are set it's invalid
*/
if (work.reserved1 || work.reserved2 || work.reserved3 ||
- work.reserved4 || work.reserved5 || work.reserved6 ||
+ work.reserved4 || work.reserved5 ||
(work.flags & ~CXL_START_WORK_ALL)) {
rc = -EINVAL;
goto out;
@@ -186,6 +186,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
rc = -EINVAL;
goto out;
}
+
if ((rc = afu_register_irqs(ctx, work.num_interrupts)))
goto out;
@@ -193,6 +194,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
amr = work.amr & mfspr(SPRN_UAMOR);
ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF);
+ ctx->wflags = work.flags;
/*
* Increment the mapped context count for adapter. This also checks
@@ -263,6 +265,12 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
goto out;
}
+ if (work.flags & CXL_START_WORK_TID) {
+ work.tid = ctx->tidr;
+ if (copy_to_user(uwork, &work, sizeof(work)))
+ return -EFAULT;
+ }
+
ctx->status = STARTED;
rc = 0;
out:
diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
index 02b6b45..0cccf27 100644
--- a/drivers/misc/cxl/native.c
+++ b/drivers/misc/cxl/native.c
@@ -16,6 +16,7 @@
#include <linux/uaccess.h>
#include <linux/delay.h>
#include <asm/synch.h>
+#include <asm/switch_to.h>
#include <misc/cxl-base.h>
#include "cxl.h"
@@ -655,6 +656,7 @@ static void update_ivtes_directed(struct cxl_context *ctx)
static int process_element_entry_psl9(struct cxl_context *ctx, u64 wed, u64 amr)
{
u32 pid;
+ int rc;
cxl_assign_psn_space(ctx);
@@ -673,7 +675,16 @@ static int process_element_entry_psl9(struct cxl_context *ctx, u64 wed, u64 amr)
pid = ctx->mm->context.id;
}
- ctx->elem->common.tid = 0;
+ /* Assign a unique TIDR (thread id) for the current thread */
+ if (!(ctx->tidr) && (ctx->wflags & CXL_START_WORK_TID)) {
+ rc = set_thread_tidr(current);
+ if (rc)
+ return -ENODEV;
+ ctx->tidr = current->thread.tidr;
+ pr_devel("%s: current tidr: %d\n", __func__, ctx->tidr);
+ }
+
+ ctx->elem->common.tid = cpu_to_be32(ctx->tidr);
ctx->elem->common.pid = cpu_to_be32(pid);
ctx->elem->sr = cpu_to_be64(calculate_sr(ctx));
diff --git a/include/uapi/misc/cxl.h b/include/uapi/misc/cxl.h
index 49e8fd0..56376d3 100644
--- a/include/uapi/misc/cxl.h
+++ b/include/uapi/misc/cxl.h
@@ -20,20 +20,22 @@ struct cxl_ioctl_start_work {
__u64 work_element_descriptor;
__u64 amr;
__s16 num_interrupts;
- __s16 reserved1;
- __s32 reserved2;
+ __u16 tid;
+ __s32 reserved1;
+ __u64 reserved2;
__u64 reserved3;
__u64 reserved4;
__u64 reserved5;
- __u64 reserved6;
};
#define CXL_START_WORK_AMR 0x0000000000000001ULL
#define CXL_START_WORK_NUM_IRQS 0x0000000000000002ULL
#define CXL_START_WORK_ERR_FF 0x0000000000000004ULL
+#define CXL_START_WORK_TID 0x0000000000000008ULL
#define CXL_START_WORK_ALL (CXL_START_WORK_AMR |\
CXL_START_WORK_NUM_IRQS |\
- CXL_START_WORK_ERR_FF)
+ CXL_START_WORK_ERR_FF |\
+ CXL_START_WORK_TID)
/* Possible modes that an afu can be in */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 10/13] ocxl: Add Makefile and Kconfig
From: Frederic Barrat @ 2018-01-09 15:45 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev, linux-kernel; +Cc: arnd, gregkh, mpe, alastair
In-Reply-To: <9cf29972-8995-949f-1435-70f0e11071cf@au1.ibm.com>
Le 03/01/2018 à 06:48, Andrew Donnellan a écrit :
> On 19/12/17 02:21, Frederic Barrat wrote:
>> OCXL_BASE triggers the platform support needed by the driver.
>>
>> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
>> ---
>> drivers/misc/Kconfig | 1 +
>> drivers/misc/Makefile | 1 +
>> drivers/misc/ocxl/Kconfig | 25 +++++++++++++++++++++++++
>> drivers/misc/ocxl/Makefile | 10 ++++++++++
>> 4 files changed, 37 insertions(+)
>> create mode 100644 drivers/misc/ocxl/Kconfig
>> create mode 100644 drivers/misc/ocxl/Makefile
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index f1a5c2357b14..0534f338c84a 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -508,4 +508,5 @@ source "drivers/misc/mic/Kconfig"
>> source "drivers/misc/genwqe/Kconfig"
>> source "drivers/misc/echo/Kconfig"
>> source "drivers/misc/cxl/Kconfig"
>> +source "drivers/misc/ocxl/Kconfig"
>> endmenu
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 5ca5f64df478..73326d54e246 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE) += cxl/
>> obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
>> obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
>> obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
>> +obj-$(CONFIG_OCXL) += ocxl/
>>
>> lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
>> lkdtm-$(CONFIG_LKDTM) += lkdtm_bugs.o
>> diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig
>> new file mode 100644
>> index 000000000000..4496b61f48db
>> --- /dev/null
>> +++ b/drivers/misc/ocxl/Kconfig
>> @@ -0,0 +1,25 @@
>> +#
>> +# Open Coherent Accelerator (OCXL) compatible devices
>> +#
>> +
>> +config OCXL_BASE
>> + bool
>> + default n
>> + select PPC_COPRO_BASE
>> +
>> +config OCXL
>> + tristate "Support for Open Coherent Accelerators (OCXL)"
>> + depends on PPC_POWERNV && PCI && EEH
>> + select OCXL_BASE
>> + default m
>> + help
>> +
>> + Select this option to enable driver support for Open
>> + Coherent Accelerators (OCXL). OCXL is otherwise known as
>> + Open Coherent Accelerator Processor Interface (OCAPI).
>> + OCAPI allows accelerators in FPGAs to be coherently attached
>> + to a CPU through a Open CAPI link. This driver enables
>> + userspace programs to access these accelerators through
>> + devices found in /dev/ocxl/
>
> I'd prefer more consistency in how we refer to OpenCAPI. "ocxl" is a
> driver name that we have purely for historical reasons, it's not really
> the name of anything else. I know throughout the various specs and code,
> we use "OCAPI" a lot, but that's not really an abbreviation that should
> be "user-facing".
>
> Something like:
>
> config OCXL
> tristate "OpenCAPI coherent accelerator support"
> help
>
> Select this option to enable the ocxl driver for Open Coherent
> Accelerator Processor Interface (OpenCAPI) devices.
>
> OpenCAPI allows FPGA and ASIC accelerators to be coherently
> attached to a CPU over an OpenCAPI link.
>
> The ocxl driver enables userspace programs to access these
> accelerators through devices in /dev/ocxl/.
>
> For more information, see http://opencapi.org.
>
> If unsure, say N.
>
Agreed, and stolen.
Fred
>> +
>> + If unsure, say N.
>> diff --git a/drivers/misc/ocxl/Makefile b/drivers/misc/ocxl/Makefile
>> new file mode 100644
>> index 000000000000..f75853411cfd
>> --- /dev/null
>> +++ b/drivers/misc/ocxl/Makefile
>> @@ -0,0 +1,10 @@
>> +ccflags-$(CONFIG_PPC_WERROR) += -Werror
>> +
>> +ocxl-y += main.o pci.o config.o file.o pasid.o
>> +ocxl-y += link.o context.o afu_irq.o sysfs.o trace.o
>> +obj-$(CONFIG_OCXL) += ocxl.o
>> +
>> +# For tracepoints to include our trace.h from tracepoint infrastructure:
>> +CFLAGS_trace.o := -I$(src)
>> +
>> +# ccflags-y += -DDEBUG
>>
>
^ permalink raw reply
* Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Christoph Hellwig @ 2018-01-09 15:38 UTC (permalink / raw)
To: Michael Ellerman
Cc: Christoph Hellwig, iommu, linux-mips, linux-ia64, linux-sh,
sparclinux, Guan Xuetao, linux-arch, linux-s390, linux-c6x-dev,
linux-hexagon, x86, linux-snps-arc, adi-buildroot-devel,
linux-m68k, patches, linux-metag, linux-arm-kernel, Michal Simek,
linux-parisc, linux-cris-kernel, linux-kernel, linux-alpha,
linuxppc-dev
In-Reply-To: <20180104084930.GB3251@lst.de>
On Thu, Jan 04, 2018 at 09:49:30AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > We want to use the dma_direct_ namespace for a generic implementation,
> > > so rename powerpc to the second best choice: dma_nommu_.
> >
> > I'm not a fan of "nommu". Some of the users of direct ops *are* using an
> > IOMMU, they're just setting up a 1:1 mapping once at init time, rather
> > than mapping dynamically.
> >
> > Though I don't have a good idea for a better name, maybe "1to1",
> > "linear", "premapped" ?
>
> It seems like a nice counter part to the dma_iommu_ops used just about
> anywhere else in ppc.
>
> But I'll happily take any maintainer bike shed decision for the next
> series. Remember that in a merge window or two it will hopefully
> go away in favor of the new generic dma_direct ops.
Michael, please suggest what name you want for the next iteration,
I don't want to hold up the series on a naming bikeshed.
^ permalink raw reply
* Re: Sleep in preempt_disable on powernv with 'cat /proc/cpuinfo' on v4.15
From: Michael Ellerman @ 2018-01-09 15:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, John Sperbeck, Shriya, linuxppc-dev
In-Reply-To: <1515483825.541.40.camel@kernel.crashing.org>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Mon, 2018-01-08 at 21:30 -0800, John Sperbeck wrote:
>> The pnv_get_proc_freq() function was recently changed to call
>> cpufreq_get(), instead of cpufreq_quick_get(), in order to fetch
>> a more up-to-date value for the CPU frequency:
>>
>> cd77b5ce208c153260ed7882d8910f2395bfaabd
>> powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
>>
>> Unfortunately, this function is called from show_cpuinfo() in
>> arch/powerpc/kernel/setup-common.c with preemption disabled. The
>> cpufreq_get() function might do a down_read(), which can sleep.
>>
>> With CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_ATOMIC_SLEEP set, a warning
>> like the following is generated when running 'cat /proc/cpuinfo':
This was reported by Nick back in November just a few days after the
patch went in, so it's a little disappointing that it's still broken.
> We could just either remove the preempt_disable completely like
> x86 and keep it racy, or stick a cpus_read_lock around it. I dont think
> we need that preempt_disable, it's definitely overkill.
>
> Michael, what do you think ? I'm keen on sync'ing with x86 here...
Yeah I think we can drop it. The cpufreq seems to have some locking that
looks like it'll probably work - famous last words.
Who's writing the patch?
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Michael Ellerman @ 2018-01-09 14:36 UTC (permalink / raw)
To: Greg Kurz, Alexey Kardashevskiy
Cc: kvm, kvm-ppc, linuxppc-dev, Suraj Jitindar Singh, David Gibson
In-Reply-To: <20180109135453.28b36153@bahia.lan>
Greg Kurz <groug@kaod.org> writes:
> On Tue, 9 Jan 2018 23:44:56 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
>> On 09/01/18 19:39, Suraj Jitindar Singh wrote:
> [...]
>> >> + rc = plpar_get_cpu_characteristics(&c);
>> >> + if (rc == H_SUCCESS) {
>> >> + if (!(c.behavior &
>> >
>> > s/behavior/behaviour
>>
>> Why?
>> https://dictionary.cambridge.org/dictionary/english/behavior
>>
>
> Behavior is US English while behaviour is UK (and US)... Matter of taste ? :)
Straya mate!
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: kbuild test robot @ 2018-01-09 13:48 UTC (permalink / raw)
To: Paul Mackerras
Cc: kbuild-all, kvm, linuxppc-dev, kvm-ppc, David Gibson,
Suraj Jitindar Singh
In-Reply-To: <20180109044815.GA19326@fergus.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6461 bytes --]
Hi Paul,
I love your patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.15-rc7 next-20180109]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Paul-Mackerras/KVM-PPC-Book3S-Add-capabilities-for-Meltdown-Spectre-workarounds/20180109-165503
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_cache':
>> arch/powerpc/kvm/powerpc.c:527:27: error: storage size of 'c' isn't known
struct h_cpu_char_result c;
^
>> arch/powerpc/kvm/powerpc.c:534:7: error: implicit declaration of function 'plpar_get_cpu_characteristics' [-Werror=implicit-function-declaration]
rc = plpar_get_cpu_characteristics(&c);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kvm/powerpc.c:536:22: error: 'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV' undeclared (first use in this function)
if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/powerpc.c:536:22: note: each undeclared identifier is reported only once for each function it appears in
>> arch/powerpc/kvm/powerpc.c:538:27: error: 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV'?
else if ((c.character & H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV
>> arch/powerpc/kvm/powerpc.c:539:21: error: 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE'?
((c.character & H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_CHAR_L1D_PRIVATE
>> arch/powerpc/kvm/powerpc.c:540:21: error: 'H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH'?
(c.character & H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH
arch/powerpc/kvm/powerpc.c:527:27: warning: unused variable 'c' [-Wunused-variable]
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_bounds_check':
arch/powerpc/kvm/powerpc.c:549:27: error: storage size of 'c' isn't known
struct h_cpu_char_result c;
^
>> arch/powerpc/kvm/powerpc.c:558:22: error: 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK' undeclared (first use in this function)
if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kvm/powerpc.c:560:26: error: 'H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK'?
else if (c.character & H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK
arch/powerpc/kvm/powerpc.c:549:27: warning: unused variable 'c' [-Wunused-variable]
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_indirect_branch':
arch/powerpc/kvm/powerpc.c:569:27: error: storage size of 'c' isn't known
struct h_cpu_char_result c;
^
>> arch/powerpc/kvm/powerpc.c:578:21: error: 'H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL' undeclared (first use in this function)
if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/powerpc.c:569:27: warning: unused variable 'c' [-Wunused-variable]
struct h_cpu_char_result c;
^
cc1: some warnings being treated as errors
vim +527 arch/powerpc/kvm/powerpc.c
523
524 #ifdef CONFIG_PPC_PSERIES
525 static bool check_pseries_safe_cache(int *rp)
526 {
> 527 struct h_cpu_char_result c;
528 unsigned long rc;
529 int r = 0;
530
531 if (!machine_is(pseries))
532 return false;
533
> 534 rc = plpar_get_cpu_characteristics(&c);
535 if (rc == H_SUCCESS) {
> 536 if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
537 r = 2;
> 538 else if ((c.character & H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
> 539 ((c.character & H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
> 540 (c.character & H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
541 r = 1;
542 }
543 *rp = r;
544 return true;
545 }
546
547 static bool check_pseries_safe_bounds_check(int *rp)
548 {
> 549 struct h_cpu_char_result c;
550 unsigned long rc;
551 int r = 0;
552
553 if (!machine_is(pseries))
554 return false;
555
556 rc = plpar_get_cpu_characteristics(&c);
557 if (rc == H_SUCCESS) {
> 558 if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
559 r = 2;
> 560 else if (c.character & H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
561 r = 1;
562 }
563 *rp = r;
564 return true;
565 }
566
567 static bool check_pseries_safe_indirect_branch(int *rp)
568 {
569 struct h_cpu_char_result c;
570 unsigned long rc;
571 int r = 0;
572
573 if (!machine_is(pseries))
574 return false;
575
576 rc = plpar_get_cpu_characteristics(&c);
577 if (rc == H_SUCCESS) {
> 578 if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
579 r = 2;
580 }
581 *rp = r;
582 return true;
583 }
584
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56071 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Greg Kurz @ 2018-01-09 12:54 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Suraj Jitindar Singh, Paul Mackerras, kvm, linuxppc-dev, kvm-ppc,
David Gibson
In-Reply-To: <2b9c6453-c56f-ac4d-daa9-16d9ffa6cebe@ozlabs.ru>
On Tue, 9 Jan 2018 23:44:56 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 09/01/18 19:39, Suraj Jitindar Singh wrote:
[...]
> >> + rc = plpar_get_cpu_characteristics(&c);
> >> + if (rc == H_SUCCESS) {
> >> + if (!(c.behavior &
> >
> > s/behavior/behaviour
>
> Why?
> https://dictionary.cambridge.org/dictionary/english/behavior
>
Behavior is US English while behaviour is UK (and US)... Matter of taste ? :)
>
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Alexey Kardashevskiy @ 2018-01-09 12:44 UTC (permalink / raw)
To: Suraj Jitindar Singh, Paul Mackerras, kvm, linuxppc-dev
Cc: kvm-ppc, David Gibson
In-Reply-To: <1515487154.1993.3.camel@gmail.com>
On 09/01/18 19:39, Suraj Jitindar Singh wrote:
> On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
>> This adds three new capabilities that give userspace information
>> about
>> the underlying machine's level of vulnerability to the Meltdown and
>> Spectre attacks, and what instructions the hardware implements to
>> assist software to work around the vulnerabilities.
>>
>> Each capability is a tri-state, where 0 indicates that the machine is
>> vulnerable and no workarounds are implement, 1 indicates that the
>> machine is vulnerable but workaround assist instructions are
>> available, and 2 indicates that the machine is not vulnerable.
>>
>> The capabilities are:
>>
>> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
>> attacks based on using speculative loads to data in L1 cache which
>> should not be addressable. The workaround provided by hardware is an
>> instruction to invalidate the entire L1 data cache.
>>
>> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
>> machine
>> to attacks based on using speculative loads behind mispredicted
>> bounds
>> checks. The workaround provided by hardware is an instruction that
>> acts as a speculation barrier.
>>
>> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
>> machine to attacks based on poisoning the indirect branch predictor.
>> No workaround that requires software changes is provided; the current
>> hardware fix is to prevent speculation past indirect branches.
>>
>> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
>> ---
>> Note: This patch depends on the patch "powerpc/pseries: Add
>> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
>> available at http://patchwork.ozlabs.org/patch/856914/ .
>>
>> Documentation/virtual/kvm/api.txt | 36 +++++++
>> arch/powerpc/kvm/powerpc.c | 202
>> ++++++++++++++++++++++++++++++++++++++
>> include/uapi/linux/kvm.h | 3 +
>> 3 files changed, 241 insertions(+)
>>
>> diff --git a/Documentation/virtual/kvm/api.txt
>> b/Documentation/virtual/kvm/api.txt
>> index 57d3ee9..8d76260 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -4369,3 +4369,39 @@ Parameters: none
>> This capability indicates if the flic device will be able to get/set
>> the
>> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
>> allows
>> to discover this without having to create a flic device.
>> +
>> +8.14 KVM_CAP_PPC_SAFE_CACHE
>> +
>> +Architectures: ppc
>> +
>> +This capability gives information about the underlying machine's
>> +vulnerability or otherwise to the Meltdown attack. Its value is a
>> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
>> the
>> +hardware is vulnerable but provides assistance to work around the
>> +vulnerability (specifically by providing a fast L1 data cache flush
>> +facility), and 2 indicates that the machine is not vulnerable.
>> +
>> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
>> +
>> +Architectures: ppc
>> +
>> +This capability gives information about the underlying machine's
>> +vulnerability or otherwise to the bounds-check variant of the
>> Spectre
>> +attack. Its value is a tristate, where 0 indicates the machine is
>> +vulnerable, 1 indicates the hardware is vulnerable but provides
>> +assistance to work around the vulnerability (specifically by
>> providing
>> +an instruction that acts as a speculation barrier), and 2 indicates
>> +that the machine is not vulnerable.
>> +
>> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
>> +
>> +Architectures: ppc
>> +
>> +This capability gives information about the underlying machine's
>> +vulnerability or otherwise to the indirect branch variant of the
>> Spectre
>> +attack. Its value is a tristate, where 0 indicates the machine is
>> +vulnerable and 2 indicates that the machine is not vulnerable.
>> +(1 would indicate the availability of a workaround that software
>> +needs to implement, but there is currently no workaround that needs
>> +software changes.)
>> +
>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index 1915e86..58e863b 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -39,6 +39,10 @@
>> #include <asm/iommu.h>
>> #include <asm/switch_to.h>
>> #include <asm/xive.h>
>> +#ifdef CONFIG_PPC_PSERIES
>> +#include <asm/hvcall.h>
>> +#include <asm/plpar_wrappers.h>
>> +#endif
>>
>> #include "timing.h"
>> #include "irq.h"
>> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>> module_put(kvm->arch.kvm_ops->owner);
>> }
>>
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +/*
>> + * These functions check whether the underlying hardware is safe
>> + * against the Meltdown/Spectre attacks and whether it supplies
>> + * instructions for use in workarounds. The information comes from
>> + * firmware, either via the device tree on powernv platforms or
>> + * from an hcall on pseries platforms.
>> + *
>> + * For check_safe_cache() and check_safe_bounds_check(), a return
>> + * value of 0 means vulnerable, 1 means vulnerable but workaround
>> + * instructions are provided, and 2 means not vulnerable (no
>> workaround
>> + * is needed).
>> + * For check_safe_indirect_branch(), 0 means vulnerable and 2 means
>> + * not vulnerable.
>> + */
>> +static inline bool have_fw_feat(struct device_node *fw_features,
>> + const char *state, const char *name)
>> +{
>> + struct device_node *np;
>> + bool r = false;
>> +
>> + np = of_get_child_by_name(fw_features, name);
>> + if (np) {
>> + r = of_property_read_bool(np, state);
>> + of_node_put(np);
>> + }
>> + return r;
>> +}
>> +
>> +#ifdef CONFIG_PPC_PSERIES
>> +static bool check_pseries_safe_cache(int *rp)
>> +{
>> + struct h_cpu_char_result c;
>> + unsigned long rc;
>> + int r = 0;
>> +
>> + if (!machine_is(pseries))
>> + return false;
>> +
>> + rc = plpar_get_cpu_characteristics(&c);
>> + if (rc == H_SUCCESS) {
>> + if (!(c.behavior &
>
> s/behavior/behaviour
Why?
https://dictionary.cambridge.org/dictionary/english/behavior
--
Alexey
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds^[
From: joserz @ 2018-01-09 12:20 UTC (permalink / raw)
To: Michal Suchánek; +Cc: linuxppc-dev
In-Reply-To: <20180109125726.39687794@kitsune.suse.cz>
On Tue, Jan 09, 2018 at 12:57:26PM +0100, Michal Suchánek wrote:
> On Tue, 09 Jan 2018 19:39:14 +1100
> Suraj Jitindar Singh <sjitindarsingh@gmail.com> wrote:
>
> >
> > s/behavior/behaviour
>
> Nope. Either is valid and the shorter American spelling is actually
> more common.
>
> If you must nickpick choose something actually broken :p
Suraj is right:
struct h_cpu_char_result {
u64 character;
u64 behaviour;
};
>
> Thanks
>
> Michal
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Michal Suchánek @ 2018-01-09 11:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1515487154.1993.3.camel@gmail.com>
On Tue, 09 Jan 2018 19:39:14 +1100
Suraj Jitindar Singh <sjitindarsingh@gmail.com> wrote:
>
> s/behavior/behaviour
Nope. Either is valid and the shorter American spelling is actually
more common.
If you must nickpick choose something actually broken :p
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: kbuild test robot @ 2018-01-09 11:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: kbuild-all, kvm, linuxppc-dev, kvm-ppc, David Gibson,
Suraj Jitindar Singh
In-Reply-To: <20180109044815.GA19326@fergus.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5487 bytes --]
Hi Paul,
I love your patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.15-rc7 next-20180109]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Paul-Mackerras/KVM-PPC-Book3S-Add-capabilities-for-Meltdown-Spectre-workarounds/20180109-165503
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_cache':
arch/powerpc/kvm/powerpc.c:527:27: error: storage size of 'c' isn't known
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c:534:7: error: implicit declaration of function 'plpar_get_cpu_characteristics' [-Werror=implicit-function-declaration]
rc = plpar_get_cpu_characteristics(&c);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/powerpc.c:536:22: error: 'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV' undeclared (first use in this function)
if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/powerpc.c:536:22: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/kvm/powerpc.c:538:27: error: 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV'?
else if ((c.character & H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV
arch/powerpc/kvm/powerpc.c:539:21: error: 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE'?
((c.character & H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_CHAR_L1D_PRIVATE
arch/powerpc/kvm/powerpc.c:540:21: error: 'H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH'?
(c.character & H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH
>> arch/powerpc/kvm/powerpc.c:527:27: error: unused variable 'c' [-Werror=unused-variable]
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_bounds_check':
arch/powerpc/kvm/powerpc.c:549:27: error: storage size of 'c' isn't known
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c:558:22: error: 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK' undeclared (first use in this function)
if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/powerpc.c:560:26: error: 'H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR' undeclared (first use in this function); did you mean 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK'?
else if (c.character & H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK
arch/powerpc/kvm/powerpc.c:549:27: error: unused variable 'c' [-Werror=unused-variable]
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_indirect_branch':
arch/powerpc/kvm/powerpc.c:569:27: error: storage size of 'c' isn't known
struct h_cpu_char_result c;
^
arch/powerpc/kvm/powerpc.c:578:21: error: 'H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL' undeclared (first use in this function)
if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/powerpc.c:569:27: error: unused variable 'c' [-Werror=unused-variable]
struct h_cpu_char_result c;
^
cc1: all warnings being treated as errors
vim +/c +527 arch/powerpc/kvm/powerpc.c
523
524 #ifdef CONFIG_PPC_PSERIES
525 static bool check_pseries_safe_cache(int *rp)
526 {
> 527 struct h_cpu_char_result c;
528 unsigned long rc;
529 int r = 0;
530
531 if (!machine_is(pseries))
532 return false;
533
534 rc = plpar_get_cpu_characteristics(&c);
535 if (rc == H_SUCCESS) {
536 if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
537 r = 2;
538 else if ((c.character & H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
> 539 ((c.character & H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
540 (c.character & H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
541 r = 1;
542 }
543 *rp = r;
544 return true;
545 }
546
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24050 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice
From: Christophe Leroy @ 2018-01-09 10:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev
An application running with libhugetlbfs fails to allocate
additional pages to HEAP due to the hugemap being done
inconditionally as topdown mapping:
mmap(0x10080000, 1572864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x73e80000
[...]
mmap(0x74000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d80000
munmap(0x73d80000, 1048576) = 0
[...]
mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000
munmap(0x73d00000, 1572864) = 0
[...]
mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000
munmap(0x73d00000, 1572864) = 0
[...]
As one can see from the above strace log, mmap() allocates further
pages below the initial one.
This patch fixes it by taking into account MAP_GROWSDOWN flag.
Fixes: d0f13e3c20b6f ("[POWERPC] Introduce address space "slices" ")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: Added missing include
arch/powerpc/mm/hugetlbpage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 79e1378ee303..0eadf9f199de 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -19,6 +19,7 @@
#include <linux/moduleparam.h>
#include <linux/swap.h>
#include <linux/swapops.h>
+#include <linux/mman.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/tlb.h>
@@ -558,7 +559,8 @@ unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
return radix__hugetlb_get_unmapped_area(file, addr, len,
pgoff, flags);
#endif
- return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1);
+ return slice_get_unmapped_area(addr, len, flags, mmu_psize,
+ flags & MAP_GROWSDOWN);
}
#endif
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v2] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Suraj Jitindar Singh @ 2018-01-09 9:31 UTC (permalink / raw)
To: Paul Mackerras, kvm, linuxppc-dev; +Cc: kvm-ppc, David Gibson
In-Reply-To: <20180109092120.GC19326@fergus.ozlabs.ibm.com>
On Tue, 2018-01-09 at 20:21 +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information
> about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
>
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
>
> The capabilities are:
>
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable. The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
>
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> machine
> to attacks based on using speculative loads behind mispredicted
> bounds
> checks. The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
>
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
>
Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
>
> Documentation/virtual/kvm/api.txt | 35 +++++++
> arch/powerpc/kvm/powerpc.c | 202
> ++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 3 +
> 3 files changed, 240 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..7107e52 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,38 @@ Parameters: none
> This capability indicates if the flic device will be able to get/set
> the
> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
> allows
> to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack. Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
> the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the
> Spectre
> +attack. Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by
> providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the
> Spectre
> +attack. Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..bef76f8 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
> #include <asm/iommu.h>
> #include <asm/switch_to.h>
> #include <asm/xive.h>
> +#ifdef CONFIG_PPC_PSERIES
> +#include <asm/hvcall.h>
> +#include <asm/plpar_wrappers.h>
> +#endif
>
> #include "timing.h"
> #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> module_put(kvm->arch.kvm_ops->owner);
> }
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds. The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no
> workaround
> + * is needed).
> + * For check_safe_indirect_branch(), 0 means vulnerable and 2 means
> + * not vulnerable.
> + */
> +static inline bool have_fw_feat(struct device_node *fw_features,
> + const char *state, const char *name)
> +{
> + struct device_node *np;
> + bool r = false;
> +
> + np = of_get_child_by_name(fw_features, name);
> + if (np) {
> + r = of_property_read_bool(np, state);
> + of_node_put(np);
> + }
> + return r;
> +}
> +
> +#ifdef CONFIG_PPC_PSERIES
> +static bool check_pseries_safe_cache(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (!(c.behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
> + r = 2;
> + else if ((c.character & H_CPU_CHAR_L1D_THREAD_PRIV)
> &&
> + ((c.character & H_CPU_CHAR_L1D_FLUSH_ORI30)
> ||
> + (c.character &
> H_CPU_CHAR_L1D_FLUSH_TRIG2)))
> + r = 1;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +static bool check_pseries_safe_bounds_check(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (!(c.behaviour & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
> + r = 2;
> + else if (c.character & H_CPU_CHAR_SPEC_BAR_ORI31)
> + r = 1;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +static bool check_pseries_safe_indirect_branch(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (c.character & H_CPU_CHAR_BCCTRL_SERIALISED)
> + r = 2;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +#else
> +static bool check_pseries_safe_cache(int *rp)
> +{
> + return false;
> +}
> +
> +static bool check_pseries_safe_bounds_check(int *rp)
> +{
> + return false;
> +}
> +
> +static bool check_pseries_safe_indirect_branch(int *rp)
> +{
> + return false;
> +}
> +#endif
> +
> +static int check_safe_cache(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_cache(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "disabled",
> + "needs-l1d-flush-msr-pr-0-to-1"))
> + r = 2;
> + else if (have_fw_feat(fw_features, "enabled",
> + "fw-l1d-thread-split") &&
> + (have_fw_feat(fw_features, "enabled",
> + "inst-l1d-flush-trig2") ||
> + have_fw_feat(fw_features, "enabled",
> + "inst-l1d-flush-
> ori30,30,0")))
> + r = 1;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +
> +static int check_safe_bounds_check(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_bounds_check(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "disabled",
> + "needs-spec-barrier-for-bound-
> checks"))
> + r = 2;
> + else if (have_fw_feat(fw_features, "enabled",
> + "inst-spec-barrier-
> ori31,31,0"))
> + r = 1;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +
> +static int check_safe_indirect_branch(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_indirect_branch(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "enabled",
> + "fw-bcctrl-serialized"))
> + r = 2;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +#endif
> +
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> {
> int r;
> @@ -646,6 +837,17 @@ int kvm_vm_ioctl_check_extension(struct kvm
> *kvm, long ext)
> r = hv_enabled &&
> (cur_cpu_spec->cpu_user_features2 &
> PPC_FEATURE2_HTM_COMP);
> break;
> +#ifdef CONFIG_PPC_BOOK3S_64
> + case KVM_CAP_PPC_SAFE_CACHE:
> + r = check_safe_cache();
> + break;
> + case KVM_CAP_PPC_SAFE_BOUNDS_CHECK:
> + r = check_safe_bounds_check();
> + break;
> + case KVM_CAP_PPC_SAFE_INDIRECT_BRANCH:
> + r = check_safe_indirect_branch();
> + break;
> +#endif
> default:
> r = 0;
> break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 496e59a..0a480e9 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -932,6 +932,9 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_HYPERV_SYNIC2 148
> #define KVM_CAP_HYPERV_VP_INDEX 149
> #define KVM_CAP_S390_AIS_MIGRATION 150
> +#define KVM_CAP_PPC_SAFE_CACHE 151
> +#define KVM_CAP_PPC_SAFE_BOUNDS_CHECK 152
> +#define KVM_CAP_PPC_SAFE_INDIRECT_BRANCH 153
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Paul Mackerras @ 2018-01-09 9:18 UTC (permalink / raw)
To: Suraj Jitindar Singh; +Cc: kvm, linuxppc-dev, kvm-ppc, David Gibson
In-Reply-To: <1515486515.1993.2.camel@gmail.com>
On Tue, Jan 09, 2018 at 07:28:35PM +1100, Suraj Jitindar Singh wrote:
[snip]
> > + rc = plpar_get_cpu_characteristics(&c);
> > + if (rc == H_SUCCESS) {
> > + if (!(c.behavior &
> > H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
>
> s/H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV/H_CPU_BEHAV_L1D_FLUSH_PR
Yes, somehow I managed to post an old version of the patch. New
version coming.
Paul.
^ permalink raw reply
* [PATCH v2] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Paul Mackerras @ 2018-01-09 9:21 UTC (permalink / raw)
To: kvm, linuxppc-dev; +Cc: kvm-ppc, David Gibson, Suraj Jitindar Singh
This adds three new capabilities that give userspace information about
the underlying machine's level of vulnerability to the Meltdown and
Spectre attacks, and what instructions the hardware implements to
assist software to work around the vulnerabilities.
Each capability is a tri-state, where 0 indicates that the machine is
vulnerable and no workarounds are implement, 1 indicates that the
machine is vulnerable but workaround assist instructions are
available, and 2 indicates that the machine is not vulnerable.
The capabilities are:
KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
attacks based on using speculative loads to data in L1 cache which
should not be addressable. The workaround provided by hardware is an
instruction to invalidate the entire L1 data cache.
KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the machine
to attacks based on using speculative loads behind mispredicted bounds
checks. The workaround provided by hardware is an instruction that
acts as a speculation barrier.
KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
machine to attacks based on poisoning the indirect branch predictor.
No workaround that requires software changes is provided; the current
hardware fix is to prevent speculation past indirect branches.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
Note: This patch depends on the patch "powerpc/pseries: Add
H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
available at http://patchwork.ozlabs.org/patch/856914/ .
Documentation/virtual/kvm/api.txt | 35 +++++++
arch/powerpc/kvm/powerpc.c | 202 ++++++++++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 3 +
3 files changed, 240 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 57d3ee9..7107e52 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4369,3 +4369,38 @@ Parameters: none
This capability indicates if the flic device will be able to get/set the
AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
to discover this without having to create a flic device.
+
+8.14 KVM_CAP_PPC_SAFE_CACHE
+
+Architectures: ppc
+
+This capability gives information about the underlying machine's
+vulnerability or otherwise to the Meltdown attack. Its value is a
+tristate, where 0 indicates the machine is vulnerable, 1 indicates the
+hardware is vulnerable but provides assistance to work around the
+vulnerability (specifically by providing a fast L1 data cache flush
+facility), and 2 indicates that the machine is not vulnerable.
+
+8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
+
+Architectures: ppc
+
+This capability gives information about the underlying machine's
+vulnerability or otherwise to the bounds-check variant of the Spectre
+attack. Its value is a tristate, where 0 indicates the machine is
+vulnerable, 1 indicates the hardware is vulnerable but provides
+assistance to work around the vulnerability (specifically by providing
+an instruction that acts as a speculation barrier), and 2 indicates
+that the machine is not vulnerable.
+
+8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
+
+Architectures: ppc
+
+This capability gives information about the underlying machine's
+vulnerability or otherwise to the indirect branch variant of the Spectre
+attack. Its value is a tristate, where 0 indicates the machine is
+vulnerable and 2 indicates that the machine is not vulnerable.
+(1 would indicate the availability of a workaround that software
+needs to implement, but there is currently no workaround that needs
+software changes.)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 1915e86..bef76f8 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -39,6 +39,10 @@
#include <asm/iommu.h>
#include <asm/switch_to.h>
#include <asm/xive.h>
+#ifdef CONFIG_PPC_PSERIES
+#include <asm/hvcall.h>
+#include <asm/plpar_wrappers.h>
+#endif
#include "timing.h"
#include "irq.h"
@@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
module_put(kvm->arch.kvm_ops->owner);
}
+#ifdef CONFIG_PPC_BOOK3S_64
+/*
+ * These functions check whether the underlying hardware is safe
+ * against the Meltdown/Spectre attacks and whether it supplies
+ * instructions for use in workarounds. The information comes from
+ * firmware, either via the device tree on powernv platforms or
+ * from an hcall on pseries platforms.
+ *
+ * For check_safe_cache() and check_safe_bounds_check(), a return
+ * value of 0 means vulnerable, 1 means vulnerable but workaround
+ * instructions are provided, and 2 means not vulnerable (no workaround
+ * is needed).
+ * For check_safe_indirect_branch(), 0 means vulnerable and 2 means
+ * not vulnerable.
+ */
+static inline bool have_fw_feat(struct device_node *fw_features,
+ const char *state, const char *name)
+{
+ struct device_node *np;
+ bool r = false;
+
+ np = of_get_child_by_name(fw_features, name);
+ if (np) {
+ r = of_property_read_bool(np, state);
+ of_node_put(np);
+ }
+ return r;
+}
+
+#ifdef CONFIG_PPC_PSERIES
+static bool check_pseries_safe_cache(int *rp)
+{
+ struct h_cpu_char_result c;
+ unsigned long rc;
+ int r = 0;
+
+ if (!machine_is(pseries))
+ return false;
+
+ rc = plpar_get_cpu_characteristics(&c);
+ if (rc == H_SUCCESS) {
+ if (!(c.behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
+ r = 2;
+ else if ((c.character & H_CPU_CHAR_L1D_THREAD_PRIV) &&
+ ((c.character & H_CPU_CHAR_L1D_FLUSH_ORI30) ||
+ (c.character & H_CPU_CHAR_L1D_FLUSH_TRIG2)))
+ r = 1;
+ }
+ *rp = r;
+ return true;
+}
+
+static bool check_pseries_safe_bounds_check(int *rp)
+{
+ struct h_cpu_char_result c;
+ unsigned long rc;
+ int r = 0;
+
+ if (!machine_is(pseries))
+ return false;
+
+ rc = plpar_get_cpu_characteristics(&c);
+ if (rc == H_SUCCESS) {
+ if (!(c.behaviour & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
+ r = 2;
+ else if (c.character & H_CPU_CHAR_SPEC_BAR_ORI31)
+ r = 1;
+ }
+ *rp = r;
+ return true;
+}
+
+static bool check_pseries_safe_indirect_branch(int *rp)
+{
+ struct h_cpu_char_result c;
+ unsigned long rc;
+ int r = 0;
+
+ if (!machine_is(pseries))
+ return false;
+
+ rc = plpar_get_cpu_characteristics(&c);
+ if (rc == H_SUCCESS) {
+ if (c.character & H_CPU_CHAR_BCCTRL_SERIALISED)
+ r = 2;
+ }
+ *rp = r;
+ return true;
+}
+
+#else
+static bool check_pseries_safe_cache(int *rp)
+{
+ return false;
+}
+
+static bool check_pseries_safe_bounds_check(int *rp)
+{
+ return false;
+}
+
+static bool check_pseries_safe_indirect_branch(int *rp)
+{
+ return false;
+}
+#endif
+
+static int check_safe_cache(void)
+{
+ struct device_node *np, *fw_features;
+ int r = 0;
+
+ if (check_pseries_safe_cache(&r))
+ return r;
+
+ np = of_find_node_by_name(NULL, "ibm,opal");
+ if (np) {
+ fw_features = of_get_child_by_name(np, "fw-features");
+ of_node_put(np);
+ if (!fw_features)
+ return 0;
+ if (have_fw_feat(fw_features, "disabled",
+ "needs-l1d-flush-msr-pr-0-to-1"))
+ r = 2;
+ else if (have_fw_feat(fw_features, "enabled",
+ "fw-l1d-thread-split") &&
+ (have_fw_feat(fw_features, "enabled",
+ "inst-l1d-flush-trig2") ||
+ have_fw_feat(fw_features, "enabled",
+ "inst-l1d-flush-ori30,30,0")))
+ r = 1;
+ of_node_put(fw_features);
+ }
+
+ return r;
+}
+
+static int check_safe_bounds_check(void)
+{
+ struct device_node *np, *fw_features;
+ int r = 0;
+
+ if (check_pseries_safe_bounds_check(&r))
+ return r;
+
+ np = of_find_node_by_name(NULL, "ibm,opal");
+ if (np) {
+ fw_features = of_get_child_by_name(np, "fw-features");
+ of_node_put(np);
+ if (!fw_features)
+ return 0;
+ if (have_fw_feat(fw_features, "disabled",
+ "needs-spec-barrier-for-bound-checks"))
+ r = 2;
+ else if (have_fw_feat(fw_features, "enabled",
+ "inst-spec-barrier-ori31,31,0"))
+ r = 1;
+ of_node_put(fw_features);
+ }
+
+ return r;
+}
+
+static int check_safe_indirect_branch(void)
+{
+ struct device_node *np, *fw_features;
+ int r = 0;
+
+ if (check_pseries_safe_indirect_branch(&r))
+ return r;
+
+ np = of_find_node_by_name(NULL, "ibm,opal");
+ if (np) {
+ fw_features = of_get_child_by_name(np, "fw-features");
+ of_node_put(np);
+ if (!fw_features)
+ return 0;
+ if (have_fw_feat(fw_features, "enabled",
+ "fw-bcctrl-serialized"))
+ r = 2;
+ of_node_put(fw_features);
+ }
+
+ return r;
+}
+#endif
+
int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
{
int r;
@@ -646,6 +837,17 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = hv_enabled &&
(cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_HTM_COMP);
break;
+#ifdef CONFIG_PPC_BOOK3S_64
+ case KVM_CAP_PPC_SAFE_CACHE:
+ r = check_safe_cache();
+ break;
+ case KVM_CAP_PPC_SAFE_BOUNDS_CHECK:
+ r = check_safe_bounds_check();
+ break;
+ case KVM_CAP_PPC_SAFE_INDIRECT_BRANCH:
+ r = check_safe_indirect_branch();
+ break;
+#endif
default:
r = 0;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 496e59a..0a480e9 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -932,6 +932,9 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_HYPERV_SYNIC2 148
#define KVM_CAP_HYPERV_VP_INDEX 149
#define KVM_CAP_S390_AIS_MIGRATION 150
+#define KVM_CAP_PPC_SAFE_CACHE 151
+#define KVM_CAP_PPC_SAFE_BOUNDS_CHECK 152
+#define KVM_CAP_PPC_SAFE_INDIRECT_BRANCH 153
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ permalink raw reply related
* [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!
From: Abdul Haleem @ 2018-01-09 9:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, linux-next, mpe, Stephen Rothwell, Kees Cook,
sachinp, sim, linux-block
Greeting's,
Linux next kernel panics on powerpc when module qla2xxx is load/unload.
Machine Type: Power 8 PowerVM LPAR
Kernel : 4.15.0-rc2-next-20171211
gcc : version 4.8.5
Test type: module load/unload few times
Trace messages:
---------------
qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.03-k.
qla2xxx [0106:a0:00.0]-001a: : MSI-X vector count: 32.
qla2xxx [0106:a0:00.0]-001d: : Found an ISP2532 irq 505 iobase 0x00000000aeb324e6.
qla2xxx [0106:a0:00.0]-00c6:1: MSI-X: Failed to enable support with 32 vectors, using 16 vectors.
qla2xxx [0106:a0:00.0]-00fb:1: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
qla2xxx [0106:a0:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.0 hdma- host#=1 fw=8.06.00 (90d5).
qla2xxx [0106:a0:00.1]-001a: : MSI-X vector count: 32.
qla2xxx [0106:a0:00.1]-001d: : Found an ISP2532 irq 506 iobase 0x00000000a46f1774.
qla2xxx [0106:a0:00.1]-00c6:2: MSI-X: Failed to enable support with 32 vectors, using 16 vectors.
2xxx
qla2xxx [0106:a0:00.1]-00fb:2: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
qla2xxx [0106:a0:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.1 hdma- host#=2 fw=8.06.00 (90d5).
0:00.0]-500a:1: LOOP UP detected (8 Gbps).
qla2xxx [0106:a0:00.1]-500a:2: LOOP UP detected (8 Gbps).
list_add double add: new=000000008d33e594, prev=000000008d33e594, next=00000000adef1df4.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:31!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in: qla2xxx(E) tg3(E) ibmveth(E) xt_CHECKSUM(E)
iptable_mangle(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E)
iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
nf_defrag_ipv4(E) xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E)
nf_reject_ipv4(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E) kvm(E)
sctp_diag(E) sctp(E) libcrc32c(E) tcp_diag(E) udp_diag(E)
ebtable_filter(E) ebtables(E) dccp_diag(E) ip6table_filter(E) dccp(E)
ip6_tables(E) iptable_filter(E) inet_diag(E) unix_diag(E)
af_packet_diag(E) netlink_diag(E) xts(E) sg(E) vmx_crypto(E)
pseries_rng(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E)
sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E)
fscrypto(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) nvme_fc(E)
nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E)
ptp(E) pps_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
[last unloaded: qla2xxx]
CPU: 7 PID: 22230 Comm: qla2xxx_1_dpc Tainted: G E 4.15.0-rc2-next-20171211-autotest-autotest #1
NIP: c000000000511040 LR: c00000000051103c CTR: 0000000000655170
REGS: 000000009b7356fa TRAP: 0700 Tainted: G E (4.15.0-rc2-next-20171211-autotest-autotest)
MSR: 800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 22000022 XER: 00000009
CFAR: c000000000170594 SOFTE: 0
GPR00: c00000000051103c c0000000fc293ac0 c0000000010f1d00 0000000000000058
GPR04: c00000028fcccdd0 c00000028fce3798 80000000374060b8 ffffffffffffffff
GPR08: 0000000000000000 c000000000d435ec 000000028ef90000 0000000000002717
GPR12: 0000000000000000 c00000000e734980 c0000000001215d8 c0000002886996c0
GPR16: 0000000000000000 0000000000000020 c0000002813d83f8 0000000000000001
GPR20: 0000000020000000 0000000000002000 0000000000000002 c0000002813dc808
GPR24: 0000000000000003 0000000000000001 c00000027f5a5c20 c0000002813dced0
GPR28: c00000027f5a5d90 c00000027f5a5d90 c00000027f5a5c00 c0000002813dc7f8
NIP [c000000000511040] __list_add_valid+0x70/0xb0
LR [c00000000051103c] __list_add_valid+0x6c/0xb0
Call Trace:
[c0000000fc293ac0] [c00000000051103c] __list_add_valid+0x6c/0xb0 (unreliable)
[c0000000fc293b20] [d0000000051f1a08] qla24xx_async_gnl+0x108/0x420 [qla2xxx]
[c0000000fc293bc0] [d0000000051e762c] qla2x00_do_work+0x18c/0x8c0 [qla2xxx]
[c0000000fc293ce0] [d0000000051e8180] qla2x00_relogin+0x420/0xff0 [qla2xxx]
[c0000000fc293dc0] [c00000000012172c] kthread+0x15c/0x1a0
[c0000000fc293e30] [c00000000000b4e8] ret_from_kernel_thread+0x5c/0x74
Instruction dump:
41de0018 38210060 38600001 e8010010 7c0803a6 4e800020 3c62ffae 7d445378
38631748 7d254b78 4bc5f51d 60000000 <0fe00000> 3c62ffae 7cc43378 386316f8
---[ end trace a41bc8bd434657f1 ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
(ftrace buffer empty)
Rebooting in 10 seconds..
This trace back to the below code path:
# gdb -batch vmlinux -ex 'list *(0xc000000000511040)'
0xc000000000511040 is in __list_add_valid (lib/list_debug.c:29).
24 "list_add corruption. next->prev should be prev (%p), but was %p. (next=%p).\n",
25 prev, next->prev, next) ||
26 CHECK_DATA_CORRUPTION(prev->next != next,
27 "list_add corruption. prev->next should be next (%p), but was %p. (prev=%p).\n",
28 next, prev->next, prev) ||
29 CHECK_DATA_CORRUPTION(new == prev || new == next,
30 "list_add double add: new=%p, prev=%p, next=%p.\n",
31 new, prev, next))
32 return false;
33
--
Regard's
Abdul Haleem
IBM Linux Technology Centre
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Suraj Jitindar Singh @ 2018-01-09 8:39 UTC (permalink / raw)
To: Paul Mackerras, kvm, linuxppc-dev; +Cc: kvm-ppc, David Gibson
In-Reply-To: <20180109044815.GA19326@fergus.ozlabs.ibm.com>
On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information
> about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
>
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
>
> The capabilities are:
>
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable. The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
>
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> machine
> to attacks based on using speculative loads behind mispredicted
> bounds
> checks. The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
>
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
>
> Documentation/virtual/kvm/api.txt | 36 +++++++
> arch/powerpc/kvm/powerpc.c | 202
> ++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 3 +
> 3 files changed, 241 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..8d76260 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,39 @@ Parameters: none
> This capability indicates if the flic device will be able to get/set
> the
> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
> allows
> to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack. Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
> the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the
> Spectre
> +attack. Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by
> providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the
> Spectre
> +attack. Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> +
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..58e863b 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
> #include <asm/iommu.h>
> #include <asm/switch_to.h>
> #include <asm/xive.h>
> +#ifdef CONFIG_PPC_PSERIES
> +#include <asm/hvcall.h>
> +#include <asm/plpar_wrappers.h>
> +#endif
>
> #include "timing.h"
> #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> module_put(kvm->arch.kvm_ops->owner);
> }
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds. The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no
> workaround
> + * is needed).
> + * For check_safe_indirect_branch(), 0 means vulnerable and 2 means
> + * not vulnerable.
> + */
> +static inline bool have_fw_feat(struct device_node *fw_features,
> + const char *state, const char *name)
> +{
> + struct device_node *np;
> + bool r = false;
> +
> + np = of_get_child_by_name(fw_features, name);
> + if (np) {
> + r = of_property_read_bool(np, state);
> + of_node_put(np);
> + }
> + return r;
> +}
> +
> +#ifdef CONFIG_PPC_PSERIES
> +static bool check_pseries_safe_cache(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (!(c.behavior &
s/behavior/behaviour
> H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
> + r = 2;
> + else if ((c.character &
> H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
> + ((c.character &
> H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
> + (c.character &
> H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
> + r = 1;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +static bool check_pseries_safe_bounds_check(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (!(c.behavior &
s/behavior/behaviour
> H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
> + r = 2;
> + else if (c.character &
> H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
> + r = 1;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +static bool check_pseries_safe_indirect_branch(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
> + r = 2;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +#else
> +static bool check_pseries_safe_cache(int *rp)
> +{
> + return false;
> +}
> +
> +static bool check_pseries_safe_bounds_check(int *rp)
> +{
> + return false;
> +}
> +
> +static bool check_pseries_safe_indirect_branch(int *rp)
> +{
> + return false;
> +}
> +#endif
> +
> +static int check_safe_cache(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_cache(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "disabled",
> + "needs-l1d-flush-msr-pr-0-to-1"))
> + r = 2;
> + else if (have_fw_feat(fw_features, "enabled",
> + "fw-l1d-thread-split") &&
> + (have_fw_feat(fw_features, "enabled",
> + "inst-l1d-flush-trig2") ||
> + have_fw_feat(fw_features, "enabled",
> + "inst-l1d-flush-
> ori30,30,0")))
> + r = 1;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +
> +static int check_safe_bounds_check(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_bounds_check(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "disabled",
> + "needs-spec-barrier-for-bound-
> checks"))
> + r = 2;
> + else if (have_fw_feat(fw_features, "enabled",
> + "inst-spec-barrier-
> ori31,31,0"))
> + r = 1;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +
> +static int check_safe_indirect_branch(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_indirect_branch(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "enabled",
> + "fw-bcctrl-serialized"))
> + r = 2;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +#endif
> +
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> {
> int r;
> @@ -646,6 +837,17 @@ int kvm_vm_ioctl_check_extension(struct kvm
> *kvm, long ext)
> r = hv_enabled &&
> (cur_cpu_spec->cpu_user_features2 &
> PPC_FEATURE2_HTM_COMP);
> break;
> +#ifdef CONFIG_PPC_BOOK3S_64
> + case KVM_CAP_PPC_SAFE_CACHE:
> + r = check_safe_cache();
> + break;
> + case KVM_CAP_PPC_SAFE_BOUNDS_CHECK:
> + r = check_safe_bounds_check();
> + break;
> + case KVM_CAP_PPC_SAFE_INDIRECT_BRANCH:
> + r = check_safe_indirect_branch();
> + break;
> +#endif
> default:
> r = 0;
> break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 496e59a..0a480e9 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -932,6 +932,9 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_HYPERV_SYNIC2 148
> #define KVM_CAP_HYPERV_VP_INDEX 149
> #define KVM_CAP_S390_AIS_MIGRATION 150
> +#define KVM_CAP_PPC_SAFE_CACHE 151
> +#define KVM_CAP_PPC_SAFE_BOUNDS_CHECK 152
> +#define KVM_CAP_PPC_SAFE_INDIRECT_BRANCH 153
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds
From: Suraj Jitindar Singh @ 2018-01-09 8:28 UTC (permalink / raw)
To: Paul Mackerras, kvm, linuxppc-dev; +Cc: kvm-ppc, David Gibson
In-Reply-To: <20180109044815.GA19326@fergus.ozlabs.ibm.com>
On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information
> about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
>
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
>
> The capabilities are:
>
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable. The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
>
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> machine
> to attacks based on using speculative loads behind mispredicted
> bounds
> checks. The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
>
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
>
> Documentation/virtual/kvm/api.txt | 36 +++++++
> arch/powerpc/kvm/powerpc.c | 202
> ++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 3 +
> 3 files changed, 241 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..8d76260 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,39 @@ Parameters: none
> This capability indicates if the flic device will be able to get/set
> the
> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
> allows
> to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack. Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
> the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the
> Spectre
> +attack. Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by
> providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the
> Spectre
> +attack. Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> +
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..58e863b 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
> #include <asm/iommu.h>
> #include <asm/switch_to.h>
> #include <asm/xive.h>
> +#ifdef CONFIG_PPC_PSERIES
> +#include <asm/hvcall.h>
> +#include <asm/plpar_wrappers.h>
> +#endif
>
> #include "timing.h"
> #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> module_put(kvm->arch.kvm_ops->owner);
> }
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds. The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no
> workaround
> + * is needed).
> + * For check_safe_indirect_branch(), 0 means vulnerable and 2 means
> + * not vulnerable.
> + */
> +static inline bool have_fw_feat(struct device_node *fw_features,
> + const char *state, const char *name)
> +{
> + struct device_node *np;
> + bool r = false;
> +
> + np = of_get_child_by_name(fw_features, name);
> + if (np) {
> + r = of_property_read_bool(np, state);
> + of_node_put(np);
> + }
> + return r;
> +}
> +
> +#ifdef CONFIG_PPC_PSERIES
> +static bool check_pseries_safe_cache(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (!(c.behavior &
> H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
s/H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV/H_CPU_BEHAV_L1D_FLUSH_PR
> + r = 2;
> + else if ((c.character &
> H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
s/H_GET_CPU_CHAR_CHAR_L1D_PRIVATE/H_CPU_CHAR_L1D_THREAD_PRIV
> + ((c.character &
> H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
s/H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH/H_CPU_CHAR_L1D_FLUSH_ORI30
> + (c.character &
> H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
s/H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH/H_CPU_CHAR_L1D_FLUSH_TRIG2
etc.
> + r = 1;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +static bool check_pseries_safe_bounds_check(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (!(c.behavior &
> H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
> + r = 2;
> + else if (c.character &
> H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
> + r = 1;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +static bool check_pseries_safe_indirect_branch(int *rp)
> +{
> + struct h_cpu_char_result c;
> + unsigned long rc;
> + int r = 0;
> +
> + if (!machine_is(pseries))
> + return false;
> +
> + rc = plpar_get_cpu_characteristics(&c);
> + if (rc == H_SUCCESS) {
> + if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
> + r = 2;
> + }
> + *rp = r;
> + return true;
> +}
> +
> +#else
> +static bool check_pseries_safe_cache(int *rp)
> +{
> + return false;
> +}
> +
> +static bool check_pseries_safe_bounds_check(int *rp)
> +{
> + return false;
> +}
> +
> +static bool check_pseries_safe_indirect_branch(int *rp)
> +{
> + return false;
> +}
> +#endif
> +
> +static int check_safe_cache(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_cache(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "disabled",
> + "needs-l1d-flush-msr-pr-0-to-1"))
> + r = 2;
> + else if (have_fw_feat(fw_features, "enabled",
> + "fw-l1d-thread-split") &&
> + (have_fw_feat(fw_features, "enabled",
> + "inst-l1d-flush-trig2") ||
> + have_fw_feat(fw_features, "enabled",
> + "inst-l1d-flush-
> ori30,30,0")))
> + r = 1;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +
> +static int check_safe_bounds_check(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_bounds_check(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "disabled",
> + "needs-spec-barrier-for-bound-
> checks"))
> + r = 2;
> + else if (have_fw_feat(fw_features, "enabled",
> + "inst-spec-barrier-
> ori31,31,0"))
> + r = 1;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +
> +static int check_safe_indirect_branch(void)
> +{
> + struct device_node *np, *fw_features;
> + int r = 0;
> +
> + if (check_pseries_safe_indirect_branch(&r))
> + return r;
> +
> + np = of_find_node_by_name(NULL, "ibm,opal");
> + if (np) {
> + fw_features = of_get_child_by_name(np, "fw-
> features");
> + of_node_put(np);
> + if (!fw_features)
> + return 0;
> + if (have_fw_feat(fw_features, "enabled",
> + "fw-bcctrl-serialized"))
> + r = 2;
> + of_node_put(fw_features);
> + }
> +
> + return r;
> +}
> +#endif
> +
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> {
> int r;
> @@ -646,6 +837,17 @@ int kvm_vm_ioctl_check_extension(struct kvm
> *kvm, long ext)
> r = hv_enabled &&
> (cur_cpu_spec->cpu_user_features2 &
> PPC_FEATURE2_HTM_COMP);
> break;
> +#ifdef CONFIG_PPC_BOOK3S_64
> + case KVM_CAP_PPC_SAFE_CACHE:
> + r = check_safe_cache();
> + break;
> + case KVM_CAP_PPC_SAFE_BOUNDS_CHECK:
> + r = check_safe_bounds_check();
> + break;
> + case KVM_CAP_PPC_SAFE_INDIRECT_BRANCH:
> + r = check_safe_indirect_branch();
> + break;
> +#endif
> default:
> r = 0;
> break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 496e59a..0a480e9 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -932,6 +932,9 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_HYPERV_SYNIC2 148
> #define KVM_CAP_HYPERV_VP_INDEX 149
> #define KVM_CAP_S390_AIS_MIGRATION 150
> +#define KVM_CAP_PPC_SAFE_CACHE 151
> +#define KVM_CAP_PPC_SAFE_BOUNDS_CHECK 152
> +#define KVM_CAP_PPC_SAFE_INDIRECT_BRANCH 153
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox