* Re: [PATCH v5 1/7] kvmppc: HMM backend driver to manage pages of secure guest
From: Christoph Hellwig @ 2019-07-19 6:46 UTC (permalink / raw)
To: Bharata B Rao
Cc: Jason Gunthorpe, linuxram, cclaudio, kvm-ppc, Linuxppc-dev,
linux-mm, jglisse, janani, aneesh.kumar, paulus, sukadev,
linuxppc-dev
In-Reply-To: <20190711050848.GB12321@in.ibm.com>
On Thu, Jul 11, 2019 at 10:38:48AM +0530, Bharata B Rao wrote:
> Hmmm... I still find it in upstream, guess it will be removed soon?
>
> I find the below commit in mmotm.
Please take a look at the latest hmm code in mainline, there have
also been other significant changes as well.
^ permalink raw reply
* Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior
From: Christoph Hellwig @ 2019-07-19 7:06 UTC (permalink / raw)
To: Shawn Anastasio
Cc: Alexey Kardashevskiy, Sam Bobroff, iommu, Oliver O'Halloran,
linuxppc-dev, Christoph Hellwig, Marek Szyprowski
In-Reply-To: <2da4fafe-93f2-4bf1-62e1-180a3ac800fa@anastas.io>
On Thu, Jul 18, 2019 at 02:46:00PM -0500, Shawn Anastasio wrote:
> Personally, I'm not a huge fan of an implicit default for something
> inherently architecture-dependent like this at all.
What is inherently architecture specific here over the fact that
the pgprot_* expand to architecture specific bits?
> What I'd like to
> see is a mechanism that forces architecture code to explicitly
> opt in to the default pgprot settings if they don't provide an
> implementation of arch_dma_mmap_pgprot. This could perhaps be done
> by reversing ARCH_HAS_DMA_MMAP_PGPROT to something like
> ARCH_USE_DEFAULT_DMA_MMAP_PGPROT.
I'd rather not create boilerplate code where we don't have to it. Note
that arch_dma_mmap_pgprot is a little misnamed now, as we also use it
for the in-kernel remapping in kernel/dma/remap.c, which I'm slowly
switching a lot of architectures to. powerpc will follow soon once
I get the ppc44x that was given to me to actually boot with a recent
kernel (not that I've tried much so far).
>
> This way as more systems are moved to use the common mmap code instead
> of their ops->mmap, the people doing the refactoring have to make an
> explicit decision about the pgprot settings to use. Such a configuration
> would have likely prevented this situation with powerpc from happening.
Every arch except for arm32 now uses dma direct for the direct mapping,
and thus the common code without the indeed odd default. I also have
a series to remove the default fallback, which is inherently a bad idea:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-no-defaults
> That being said, if the default behavior doesn't make sense in the
> general case it should probably be fixed as well.
>
> Curious to hear some thoughts on this.
I think your patch that started this thread is fine for 5.3 and -stable:
Reviewed-by: Christoph Hellwig <hch@lst.de>
But going forward I'd rather have a sane default.
^ permalink raw reply
* Re: Crash in kvmppc_xive_release()
From: Michael Ellerman @ 2019-07-19 7:08 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev, Greg Kurz,
Satheesh Rajendran, Paul Mackerras
In-Reply-To: <6ea6998b-a890-2511-01d1-747d7621eb19@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> On 18/07/2019 15:14, Cédric Le Goater wrote:
>> On 18/07/2019 14:49, Michael Ellerman wrote:
>>> Anyone else seen this?
>>>
>>> This is running ~176 VMs on a Power9 (1 per thread), host crashes:
>>
>> This is beyond the underlying limits of XIVE.
>>
>> As we allocate 2K vCPUs per VM, that is 16K EQs for interrupt events. The overall
>> EQ count is 1M. I let you calculate what is our max number of VMs ...
>>
>>> [ 66.403750][ T6423] xive: OPAL failed to allocate VCPUs order 11, err -10
>>
>> Hence, the OPAL XIVE driver fails which is good but ...
>>
>>> [188523.080935670,4] Spent 1783 msecs in OPAL call 135!
>>> [ 66.484965][ T6250] BUG: Kernel NULL pointer dereference at 0x000042e8
>>> [ 66.485558][ T6250] Faulting instruction address: 0xc008000011a33fcc
>>> [ 66.485990][ T6250] Oops: Kernel access of bad area, sig: 7 [#1]
>>> [ 66.486405][ T6250] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>> [ 66.486967][ T6250] Modules linked in: kvm_hv kvm
>>> [ 66.487275][ T6250] CPU: 107 PID: 6250 Comm: qemu-system-ppc Not tainted 5.2.0-rc2-gcc9x-gf5a9e488d623 #1
>>> [ 66.487902][ T6250] NIP: c008000011a33fcc LR: c008000011a33fc4 CTR: c0000000005d5970
>>> [ 66.488383][ T6250] REGS: c000001fabebb900 TRAP: 0300 Not tainted (5.2.0-rc2-gcc9x-gf5a9e488d623)
>>> [ 66.488933][ T6250] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24028224 XER: 00000000
>>> [ 66.489724][ T6250] CFAR: c0000000005d6a4c DAR: 00000000000042e8 DSISR: 00080000 IRQMASK: 0
>>> [ 66.489724][ T6250] GPR00: c008000011a33fc4 c000001fabebbb90 c008000011a5a200 c000000001399928
>>> [ 66.489724][ T6250] GPR04: 0000000000000001 c00000000047b8d0 0000000000000000 0000000000000001
>>> [ 66.489724][ T6250] GPR08: 0000000000000000 0000000000000000 c000001fa8c42f00 c008000011a3af20
>>> [ 66.489724][ T6250] GPR12: 0000000000008000 c0002023ff65a880 000000013a1b4000 0000000000000002
>>> [ 66.489724][ T6250] GPR16: 0000000010000000 0000000000000002 0000000000000001 000000012b194cc0
>>> [ 66.489724][ T6250] GPR20: 00007fffb1645250 0000000000000001 0000000000000031 0000000000000000
>>> [ 66.489724][ T6250] GPR24: 00007fffb16408d8 c000001ffafb62e0 c000001f78699360 c000001ff35d0620
>>> [ 66.489724][ T6250] GPR28: c000001ed0ed0000 c000001ecd900000 0000000000000000 c000001ed0ed0000
>>> [ 66.495211][ T6250] NIP [c008000011a33fcc] kvmppc_xive_release+0x54/0x1b0 [kvm]
>>> [ 66.495642][ T6250] LR [c008000011a33fc4] kvmppc_xive_release+0x4c/0x1b0 [kvm]
>>> [ 66.496101][ T6250] Call Trace:
>>> [ 66.496314][ T6250] [c000001fabebbb90] [c008000011a33fc4] kvmppc_xive_release+0x4c/0x1b0 [kvm] (unreliable)
>>> [ 66.496893][ T6250] [c000001fabebbbf0] [c008000011a18d54] kvm_device_release+0xac/0xf0 [kvm]
>>> [ 66.497399][ T6250] [c000001fabebbc30] [c000000000442f8c] __fput+0xec/0x310
>>> [ 66.497815][ T6250] [c000001fabebbc90] [c000000000145f94] task_work_run+0x114/0x170
>>> [ 66.498296][ T6250] [c000001fabebbce0] [c000000000115274] do_exit+0x454/0xee0
>>> [ 66.498743][ T6250] [c000001fabebbdc0] [c000000000115dd0] do_group_exit+0x60/0xe0
>>> [ 66.499201][ T6250] [c000001fabebbe00] [c000000000115e74] sys_exit_group+0x24/0x40
>>> [ 66.499747][ T6250] [c000001fabebbe20] [c00000000000b83c] system_call+0x5c/0x70
>>> [ 66.500261][ T6250] Instruction dump:
>>> [ 66.500484][ T6250] fbe1fff8 fba1ffe8 fbc1fff0 7c7c1b78 f8010010 f821ffa1 eba30010 e87d0010
>>> [ 66.501006][ T6250] ebdd0000 48006f61 e8410018 39200000 <eb7e42ea> 913e42e8 48007f3d e8410018
>>> [ 66.501529][ T6250] ---[ end trace c021a6ca03594ec3 ]---
>>> [ 66.513119][ T6150] xive: OPAL failed to allocate VCPUs order 11, err -10
>>
>>
>> ... the rollback code in case of such error must be bogus. It was never tested
>> clearly :/
>
> Here is a fix. Could you give it a try on your system ?
Yeah that fixes it, thanks.
Will apply it to my fixes branch.
cheers
> From b6f728ca19a9540c8bf4f5a56991c4e3dab4cf56 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
> Date: Thu, 18 Jul 2019 22:15:31 +0200
> Subject: [PATCH] KVM: PPC: Book3S HV: XIVE: fix rollback when
> kvmppc_xive_create fails
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The XIVE device structure is now allocated in kvmppc_xive_get_device()
> and kfree'd in kvmppc_core_destroy_vm(). In case of an OPAL error when
> allocating the XIVE VPs, the kfree() call in kvmppc_xive_*create()
> will result in a double free and corrupt the host memory.
>
> Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' method")
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/kvm/book3s_xive.c | 4 +---
> arch/powerpc/kvm/book3s_xive_native.c | 4 ++--
> 2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 6ca0d7376a9f..e3ba67095895 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -1986,10 +1986,8 @@ static int kvmppc_xive_create(struct kvm_device *dev, u32 type)
>
> xive->single_escalation = xive_native_has_single_escalation();
>
> - if (ret) {
> - kfree(xive);
> + if (ret)
> return ret;
> - }
>
> return 0;
> }
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index c7c7e3d4c031..45b0c143280c 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -1090,9 +1090,9 @@ static int kvmppc_xive_native_create(struct kvm_device *dev, u32 type)
> xive->ops = &kvmppc_xive_native_ops;
>
> if (ret)
> - kfree(xive);
> + return ret;
>
> - return ret;
> + return 0;
> }
>
> /*
> --
> 2.21.0
^ permalink raw reply
* question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Christoph Hellwig @ 2019-07-19 7:10 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev
Hey Alexey,
what is the use case for the above commit? Shouldn't we handle all
addressing limits using the iommu?
^ permalink raw reply
* Re: [PATCH v3 5/6] fs/core/vmcore: Move sev_active() reference to x86 arch code
From: lijiang @ 2019-07-19 4:59 UTC (permalink / raw)
To: Lendacky, Thomas, Thiago Jung Bauermann, x86@kernel.org
Cc: linux-s390@vger.kernel.org, Baoquan He, Konrad Rzeszutek Wilk,
Robin Murphy, Mike Anderson, Ram Pai,
linux-kernel@vger.kernel.org, Alexey Dobriyan, Halil Pasic,
iommu@lists.linux-foundation.org, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-fsdevel@vger.kernel.org, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <4a07bf75-b516-c81b-da7a-4b323e6d7e52@amd.com>
在 2019年07月19日 01:47, Lendacky, Thomas 写道:
> On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
>> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
>> appear in generic kernel code because it forces non-x86 architectures to
>> define the sev_active() function, which doesn't make a lot of sense.
>>
>> To solve this problem, add an x86 elfcorehdr_read() function to override
>> the generic weak implementation. To do that, it's necessary to make
>> read_from_oldmem() public so that it can be used outside of vmcore.c.
>>
>> Also, remove the export for sev_active() since it's only used in files that
>> won't be built as modules.
>>
>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>
> Adding Lianbo and Baoquan, who recently worked on this, for their review.
>
This change looks good to me.
Reviewed-by: Lianbo Jiang <lijiang@redhat.com>
Thanks.
Lianbo
> Thanks,
> Tom
>
>> ---
>> arch/x86/kernel/crash_dump_64.c | 5 +++++
>> arch/x86/mm/mem_encrypt.c | 1 -
>> fs/proc/vmcore.c | 8 ++++----
>> include/linux/crash_dump.h | 14 ++++++++++++++
>> include/linux/mem_encrypt.h | 1 -
>> 5 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
>> index 22369dd5de3b..045e82e8945b 100644
>> --- a/arch/x86/kernel/crash_dump_64.c
>> +++ b/arch/x86/kernel/crash_dump_64.c
>> @@ -70,3 +70,8 @@ ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
>> {
>> return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, true);
>> }
>> +
>> +ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
>> +{
>> + return read_from_oldmem(buf, count, ppos, 0, sev_active());
>> +}
>> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
>> index 7139f2f43955..b1e823441093 100644
>> --- a/arch/x86/mm/mem_encrypt.c
>> +++ b/arch/x86/mm/mem_encrypt.c
>> @@ -349,7 +349,6 @@ bool sev_active(void)
>> {
>> return sme_me_mask && sev_enabled;
>> }
>> -EXPORT_SYMBOL(sev_active);
>>
>> /* Override for DMA direct allocation check - ARCH_HAS_FORCE_DMA_UNENCRYPTED */
>> bool force_dma_unencrypted(struct device *dev)
>> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
>> index 57957c91c6df..ca1f20bedd8c 100644
>> --- a/fs/proc/vmcore.c
>> +++ b/fs/proc/vmcore.c
>> @@ -100,9 +100,9 @@ static int pfn_is_ram(unsigned long pfn)
>> }
>>
>> /* Reads a page from the oldmem device from given offset. */
>> -static ssize_t read_from_oldmem(char *buf, size_t count,
>> - u64 *ppos, int userbuf,
>> - bool encrypted)
>> +ssize_t read_from_oldmem(char *buf, size_t count,
>> + u64 *ppos, int userbuf,
>> + bool encrypted)
>> {
>> unsigned long pfn, offset;
>> size_t nr_bytes;
>> @@ -166,7 +166,7 @@ void __weak elfcorehdr_free(unsigned long long addr)
>> */
>> ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
>> {
>> - return read_from_oldmem(buf, count, ppos, 0, sev_active());
>> + return read_from_oldmem(buf, count, ppos, 0, false);
>> }
>>
>> /*
>> diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
>> index f774c5eb9e3c..4664fc1871de 100644
>> --- a/include/linux/crash_dump.h
>> +++ b/include/linux/crash_dump.h
>> @@ -115,4 +115,18 @@ static inline int vmcore_add_device_dump(struct vmcoredd_data *data)
>> return -EOPNOTSUPP;
>> }
>> #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
>> +
>> +#ifdef CONFIG_PROC_VMCORE
>> +ssize_t read_from_oldmem(char *buf, size_t count,
>> + u64 *ppos, int userbuf,
>> + bool encrypted);
>> +#else
>> +static inline ssize_t read_from_oldmem(char *buf, size_t count,
>> + u64 *ppos, int userbuf,
>> + bool encrypted)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +#endif /* CONFIG_PROC_VMCORE */
>> +
>> #endif /* LINUX_CRASHDUMP_H */
>> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
>> index 0c5b0ff9eb29..5c4a18a91f89 100644
>> --- a/include/linux/mem_encrypt.h
>> +++ b/include/linux/mem_encrypt.h
>> @@ -19,7 +19,6 @@
>> #else /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */
>>
>> static inline bool mem_encrypt_active(void) { return false; }
>> -static inline bool sev_active(void) { return false; }
>>
>> #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
>>
>>
^ permalink raw reply
* Re: [PATCH v4 00/25] Add FADump support on PowerNV platform
From: Hari Bathini @ 2019-07-19 6:19 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ananth N Mavinakayanahalli, Mahesh J Salgaonkar, Nicholas Piggin,
Oliver, Vasant Hegde, Stewart Smith, Daniel Axtens
In-Reply-To: <156327668777.27462.5297279227799429100.stgit@hbathini.in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4947 bytes --]
Sorry, I missed mentioning that this patchset is based on top of upstream kernel
plus the below patches:
https://patchwork.ozlabs.org/patch/1123582/
https://patchwork.ozlabs.org/patch/1123583/ <https://patchwork.ozlabs.org/patch/1123583/>
On 16/07/19 5:01 PM, Hari Bathini wrote:
> Firmware-Assisted Dump (FADump) is currently supported only on pSeries
> platform. This patch series adds support for PowerNV platform too.
>
> The first few patches refactor the FADump code to make use of common
> code across multiple platforms. Then basic FADump support is added for
> PowerNV platform. Followed by patches to honour reserved-ranges DT node
> while reserving/releasing memory used by FADump. The subsequent patch
> processes CPU state data provided by firmware to create and append core
> notes to the ELF core file and the next patch adds support to preserve
> crash data for subsequent boots (useful in cases like petitboot). The
> subsequent patches add support to export opalcore. opalcore makes
> debugging of failures in OPAL code easier. Firmware-Assisted Dump
> documentation is also updated appropriately.
>
> The patch series is tested with the latest firmware plus the below skiboot
> changes for MPIPL support:
>
> https://patchwork.ozlabs.org/project/skiboot/list/?series=119169
> ("MPIPL support")
>
>
> Changes in v4:
> * Split the patches.
> * Rebased to latest upstream kernel version.
> * Updated according to latest OPAL changes.
>
> ---
>
> Hari Bathini (25):
> powerpc/fadump: move internal macros/definitions to a new header
> powerpc/fadump: move internal code to a new file
> powerpc/fadump: Improve fadump documentation
> pseries/fadump: move rtas specific definitions to platform code
> pseries/fadump: introduce callbacks for platform specific operations
> pseries/fadump: define register/un-register callback functions
> pseries/fadump: move out platform specific support from generic code
> powerpc/fadump: use FADump instead of fadump for how it is pronounced
> opal: add MPIPL interface definitions
> powernv/fadump: add fadump support on powernv
> powernv/fadump: register kernel metadata address with opal
> powernv/fadump: define register/un-register callback functions
> powernv/fadump: support copying multiple kernel memory regions
> powernv/fadump: process the crashdump by exporting it as /proc/vmcore
> powerpc/fadump: Update documentation about OPAL platform support
> powerpc/fadump: consider reserved ranges while reserving memory
> powerpc/fadump: consider reserved ranges while releasing memory
> powernv/fadump: process architected register state data provided by firmware
> powernv/fadump: add support to preserve crash data on FADUMP disabled kernel
> powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP
> powernv/opalcore: export /sys/firmware/opal/core for analysing opal crashes
> powernv/fadump: Warn before processing partial crashdump
> powernv/opalcore: provide an option to invalidate /sys/firmware/opal/core file
> powernv/fadump: consider f/w load area
> powernv/fadump: update documentation about option to release opalcore
>
>
> Documentation/powerpc/firmware-assisted-dump.txt | 224 +++-
> arch/powerpc/Kconfig | 23
> arch/powerpc/include/asm/fadump.h | 190 ----
> arch/powerpc/include/asm/opal-api.h | 50 +
> arch/powerpc/include/asm/opal.h | 6
> arch/powerpc/kernel/Makefile | 6
> arch/powerpc/kernel/fadump-common.c | 153 +++
> arch/powerpc/kernel/fadump-common.h | 203 ++++
> arch/powerpc/kernel/fadump.c | 1181 ++++++++--------------
> arch/powerpc/kernel/prom.c | 4
> arch/powerpc/platforms/powernv/Makefile | 3
> arch/powerpc/platforms/powernv/opal-call.c | 3
> arch/powerpc/platforms/powernv/opal-core.c | 637 ++++++++++++
> arch/powerpc/platforms/powernv/opal-fadump.c | 671 ++++++++++++
> arch/powerpc/platforms/powernv/opal-fadump.h | 154 +++
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/rtas-fadump.c | 595 +++++++++++
> arch/powerpc/platforms/pseries/rtas-fadump.h | 123 ++
> 18 files changed, 3231 insertions(+), 996 deletions(-)
> create mode 100644 arch/powerpc/kernel/fadump-common.c
> create mode 100644 arch/powerpc/kernel/fadump-common.h
> create mode 100644 arch/powerpc/platforms/powernv/opal-core.c
> create mode 100644 arch/powerpc/platforms/powernv/opal-fadump.c
> create mode 100644 arch/powerpc/platforms/powernv/opal-fadump.h
> create mode 100644 arch/powerpc/platforms/pseries/rtas-fadump.c
> create mode 100644 arch/powerpc/platforms/pseries/rtas-fadump.h
>
[-- Attachment #2: Type: text/html, Size: 6361 bytes --]
^ permalink raw reply
* List etiquette
From: Stephen Rothwell @ 2019-07-19 7:32 UTC (permalink / raw)
To: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Hi all,
Just a short note to mention a couple of things:
- please do *not* post html formatted emails. I may start just
rejecting them soon.
- please cut down the quoting in replies to what is needed for
context.
Thanks
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior
From: Shawn Anastasio @ 2019-07-19 7:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alexey Kardashevskiy, Sam Bobroff, iommu, Oliver O'Halloran,
linuxppc-dev, Marek Szyprowski
In-Reply-To: <20190719070659.GA19555@lst.de>
On 7/19/19 2:06 AM, Christoph Hellwig wrote:
> What is inherently architecture specific here over the fact that
> the pgprot_* expand to architecture specific bits?
What I meant is that different architectures seem to have different
criteria for setting the different pgprot_ bits. i.e. ppc checks
for cache coherency, arm64 checks for cache coherency and
writecombine, mips just checks for writecombine, etc.
That being said, I'm no expert here and there is probably some behavior
here that would make for a much more sane default.
> I'd rather not create boilerplate code where we don't have to it. Note
> that arch_dma_mmap_pgprot is a little misnamed now, as we also use it
> for the in-kernel remapping in kernel/dma/remap.c, which I'm slowly
> switching a lot of architectures to. powerpc will follow soon once
> I get the ppc44x that was given to me to actually boot with a recent
> kernel (not that I've tried much so far).
Fair enough. I didn't realize that most of the other architectures
don't use the common code anyways as you mention below.
> Every arch except for arm32 now uses dma direct for the direct mapping,
> and thus the common code without the indeed odd default. I also have
> a series to remove the default fallback, which is inherently a bad idea:
>
>
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-no-defaults
Awesome. This is great to hear.
> I think your patch that started this thread is fine for 5.3 and -stable:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Thanks!
> But going forward I'd rather have a sane default.
Agreed.
^ permalink raw reply
* Re: question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Alexey Kardashevskiy @ 2019-07-19 7:52 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20190719071014.GA1922@infradead.org>
On 19/07/2019 17:10, Christoph Hellwig wrote:
> Hey Alexey,
>
> what is the use case for the above commit? Shouldn't we handle all
> addressing limits using the iommu?
Our secure VMs is the use case, when only a fraction of system memory is
available for DMA.
--
Alexey
^ permalink raw reply
* Re: question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Christoph Hellwig @ 2019-07-19 7:53 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Christoph Hellwig, linuxppc-dev
In-Reply-To: <0f969485-a3fe-4436-a448-5f4c4f875cb2@ozlabs.ru>
On Fri, Jul 19, 2019 at 05:52:37PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 19/07/2019 17:10, Christoph Hellwig wrote:
> > Hey Alexey,
> >
> > what is the use case for the above commit? Shouldn't we handle all
> > addressing limits using the iommu?
>
> Our secure VMs is the use case, when only a fraction of system memory is
> available for DMA.
But shouldn't we force usage of the direct ops in that case as the
IOMMU is not neededed at all? Also isn't that support non-upstream so
far?
^ permalink raw reply
* Re: question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Alexey Kardashevskiy @ 2019-07-19 8:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20190719075348.GA2892@infradead.org>
On 19/07/2019 17:53, Christoph Hellwig wrote:
> On Fri, Jul 19, 2019 at 05:52:37PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 19/07/2019 17:10, Christoph Hellwig wrote:
>>> Hey Alexey,
>>>
>>> what is the use case for the above commit? Shouldn't we handle all
>>> addressing limits using the iommu?
>>
>> Our secure VMs is the use case, when only a fraction of system memory is
>> available for DMA.
>
> But shouldn't we force usage of the direct ops in that case as the
> IOMMU is not neededed at all?
We do, for mappings, but not unmappings and syncing.
> Also isn't that support non-upstream so far?
How is this relevant? I expect the existing "swiotlb=force" just work.
--
Alexey
^ permalink raw reply
* Re: question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Christoph Hellwig @ 2019-07-19 8:05 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Christoph Hellwig, linuxppc-dev
In-Reply-To: <33ba562c-1a87-58e2-4105-520834d5b969@ozlabs.ru>
On Fri, Jul 19, 2019 at 06:00:25PM +1000, Alexey Kardashevskiy wrote:
> > But shouldn't we force usage of the direct ops in that case as the
> > IOMMU is not neededed at all?
>
> We do, for mappings, but not unmappings and syncing.
Well, I mean as in literally not setting a dma_ops so that the
dma_direct code is used without the indirection through the iommu ops.
This is not only more obvious, but also faster as you avoid the
indirect call (although that probably doesn't matter much if you
are bounce buffering anyway).
> > Also isn't that support non-upstream so far?
>
> How is this relevant? I expect the existing "swiotlb=force" just work.
I though the whole secure VM support was still not upstream.
^ permalink raw reply
* Re: [PATCH v5 1/7] kvmppc: HMM backend driver to manage pages of secure guest
From: Bharata B Rao @ 2019-07-19 8:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, linuxram, cclaudio, kvm-ppc, Linuxppc-dev,
linux-mm, jglisse, janani, aneesh.kumar, paulus, sukadev,
linuxppc-dev
In-Reply-To: <20190719064641.GA29238@infradead.org>
On Thu, Jul 18, 2019 at 11:46:41PM -0700, Christoph Hellwig wrote:
> On Thu, Jul 11, 2019 at 10:38:48AM +0530, Bharata B Rao wrote:
> > Hmmm... I still find it in upstream, guess it will be removed soon?
> >
> > I find the below commit in mmotm.
>
> Please take a look at the latest hmm code in mainline, there have
> also been other significant changes as well.
Yes, my next version of this patchset will be based on those recent
HMM related changes.
Regards,
Bharata.
^ permalink raw reply
* Re: question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Alexey Kardashevskiy @ 2019-07-19 8:23 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20190719080532.GA3861@infradead.org>
On 19/07/2019 18:05, Christoph Hellwig wrote:
> On Fri, Jul 19, 2019 at 06:00:25PM +1000, Alexey Kardashevskiy wrote:
>>> But shouldn't we force usage of the direct ops in that case as the
>>> IOMMU is not neededed at all?
>>
>> We do, for mappings, but not unmappings and syncing.
>
> Well, I mean as in literally not setting a dma_ops so that the
> dma_direct code is used without the indirection through the iommu ops.
> This is not only more obvious, but also faster as you avoid the
> indirect call (although that probably doesn't matter much if you
> are bounce buffering anyway).
I was not precise. We cannot avoid IOMMU in the guest for passed through
devices.
>>> Also isn't that support non-upstream so far?
>>
>> How is this relevant? I expect the existing "swiotlb=force" just work.
>
> I though the whole secure VM support was still not upstream.
It is getting there and I still do not see why "swiotlb=force" should
not work if chosed in the cmdline.
--
Alexey
^ permalink raw reply
* Re: [PATCH 2/3] DMA mapping: Move SME handling to x86-specific files
From: kbuild test robot @ 2019-07-19 9:05 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linux-s390, Mike Anderson, Konrad Rzeszutek Wilk, Robin Murphy,
x86, Ram Pai, linux-kernel, Alexey Dobriyan, Halil Pasic, iommu,
Ingo Molnar, Borislav Petkov, kbuild-all, H. Peter Anvin,
linux-fsdevel, Thomas Gleixner, linuxppc-dev, Christoph Hellwig,
Thiago Jung Bauermann, Marek Szyprowski
In-Reply-To: <20190712053631.9814-3-bauerman@linux.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 30295 bytes --]
Hi Thiago,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.2 next-20190718]
[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/Thiago-Jung-Bauermann/Remove-x86-specific-code-from-generic-headers/20190715-063006
config: s390-allnoconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.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
GCC_VERSION=7.4.0 make.cross ARCH=s390
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
kernel/dma/swiotlb.c: In function 'swiotlb_tbl_map_single':
>> kernel/dma/swiotlb.c:461:6: error: implicit declaration of function 'mem_encrypt_active'; did you mean 'set_cpu_active'? [-Werror=implicit-function-declaration]
if (mem_encrypt_active())
^~~~~~~~~~~~~~~~~~
set_cpu_active
cc1: some warnings being treated as errors
vim +461 kernel/dma/swiotlb.c
1b548f667c1487d lib/swiotlb.c Jeremy Fitzhardinge 2008-12-16 442
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 443 phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 444 dma_addr_t tbl_dma_addr,
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 445 phys_addr_t orig_addr, size_t size,
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 446 enum dma_data_direction dir,
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 447 unsigned long attrs)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 448 {
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 449 unsigned long flags;
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 450 phys_addr_t tlb_addr;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 451 unsigned int nslots, stride, index, wrap;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 452 int i;
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 453 unsigned long mask;
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 454 unsigned long offset_slots;
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 455 unsigned long max_slots;
53b29c336830db4 kernel/dma/swiotlb.c Dongli Zhang 2019-04-12 456 unsigned long tmp_io_tlb_used;
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 457
ac2cbab21f318e1 lib/swiotlb.c Yinghai Lu 2013-01-24 458 if (no_iotlb_memory)
ac2cbab21f318e1 lib/swiotlb.c Yinghai Lu 2013-01-24 459 panic("Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer");
ac2cbab21f318e1 lib/swiotlb.c Yinghai Lu 2013-01-24 460
d7b417fa08d1187 lib/swiotlb.c Tom Lendacky 2017-10-20 @461 if (mem_encrypt_active())
aa4d0dc3e029b79 kernel/dma/swiotlb.c Thiago Jung Bauermann 2019-07-12 462 pr_warn_once("Memory encryption is active and system is using DMA bounce buffers\n");
648babb7078c631 lib/swiotlb.c Tom Lendacky 2017-07-17 463
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 464 mask = dma_get_seg_boundary(hwdev);
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 465
eb605a5754d050a lib/swiotlb.c FUJITA Tomonori 2010-05-10 466 tbl_dma_addr &= mask;
eb605a5754d050a lib/swiotlb.c FUJITA Tomonori 2010-05-10 467
eb605a5754d050a lib/swiotlb.c FUJITA Tomonori 2010-05-10 468 offset_slots = ALIGN(tbl_dma_addr, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT;
a5ddde4a558b3bd lib/swiotlb.c Ian Campbell 2008-12-16 469
a5ddde4a558b3bd lib/swiotlb.c Ian Campbell 2008-12-16 470 /*
a5ddde4a558b3bd lib/swiotlb.c Ian Campbell 2008-12-16 471 * Carefully handle integer overflow which can occur when mask == ~0UL.
a5ddde4a558b3bd lib/swiotlb.c Ian Campbell 2008-12-16 472 */
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 473 max_slots = mask + 1
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 474 ? ALIGN(mask + 1, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 475 : 1UL << (BITS_PER_LONG - IO_TLB_SHIFT);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 476
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 477 /*
602d9858f07c72e lib/swiotlb.c Nikita Yushchenko 2017-01-11 478 * For mappings greater than or equal to a page, we limit the stride
602d9858f07c72e lib/swiotlb.c Nikita Yushchenko 2017-01-11 479 * (and hence alignment) to a page size.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 480 */
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 481 nslots = ALIGN(size, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT;
602d9858f07c72e lib/swiotlb.c Nikita Yushchenko 2017-01-11 482 if (size >= PAGE_SIZE)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 483 stride = (1 << (PAGE_SHIFT - IO_TLB_SHIFT));
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 484 else
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 485 stride = 1;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 486
34814545890db60 lib/swiotlb.c Eric Sesterhenn 2006-03-24 487 BUG_ON(!nslots);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 488
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 489 /*
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 490 * Find suitable number of IO TLB entries size that will fit this
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 491 * request and allocate a buffer from that IO TLB pool.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 492 */
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 493 spin_lock_irqsave(&io_tlb_lock, flags);
60513ed06a41049 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 494
60513ed06a41049 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 495 if (unlikely(nslots > io_tlb_nslabs - io_tlb_used))
60513ed06a41049 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 496 goto not_found;
60513ed06a41049 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 497
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 498 index = ALIGN(io_tlb_index, stride);
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 499 if (index >= io_tlb_nslabs)
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 500 index = 0;
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 501 wrap = index;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 502
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 503 do {
a8522509200b460 lib/swiotlb.c FUJITA Tomonori 2008-04-29 504 while (iommu_is_span_boundary(index, nslots, offset_slots,
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 505 max_slots)) {
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 506 index += stride;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 507 if (index >= io_tlb_nslabs)
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 508 index = 0;
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 509 if (index == wrap)
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 510 goto not_found;
681cc5cd3efbeaf lib/swiotlb.c FUJITA Tomonori 2008-02-04 511 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 512
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 513 /*
a7133a15587b892 lib/swiotlb.c Andrew Morton 2008-04-29 514 * If we find a slot that indicates we have 'nslots' number of
a7133a15587b892 lib/swiotlb.c Andrew Morton 2008-04-29 515 * contiguous buffers, we allocate the buffers from that slot
a7133a15587b892 lib/swiotlb.c Andrew Morton 2008-04-29 516 * and mark the entries as '0' indicating unavailable.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 517 */
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 518 if (io_tlb_list[index] >= nslots) {
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 519 int count = 0;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 520
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 521 for (i = index; i < (int) (index + nslots); i++)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 522 io_tlb_list[i] = 0;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 523 for (i = index - 1; (OFFSET(i, IO_TLB_SEGSIZE) != IO_TLB_SEGSIZE - 1) && io_tlb_list[i]; i--)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 524 io_tlb_list[i] = ++count;
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 525 tlb_addr = io_tlb_start + (index << IO_TLB_SHIFT);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 526
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 527 /*
a7133a15587b892 lib/swiotlb.c Andrew Morton 2008-04-29 528 * Update the indices to avoid searching in the next
a7133a15587b892 lib/swiotlb.c Andrew Morton 2008-04-29 529 * round.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 530 */
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 531 io_tlb_index = ((index + nslots) < io_tlb_nslabs
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 532 ? (index + nslots) : 0);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 533
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 534 goto found;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 535 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 536 index += stride;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 537 if (index >= io_tlb_nslabs)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 538 index = 0;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 539 } while (index != wrap);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 540
b15a3891c916f32 lib/swiotlb.c Jan Beulich 2008-03-13 541 not_found:
53b29c336830db4 kernel/dma/swiotlb.c Dongli Zhang 2019-04-12 542 tmp_io_tlb_used = io_tlb_used;
53b29c336830db4 kernel/dma/swiotlb.c Dongli Zhang 2019-04-12 543
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 544 spin_unlock_irqrestore(&io_tlb_lock, flags);
d0bc0c2a31c9500 lib/swiotlb.c Christian König 2018-01-04 545 if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit())
53b29c336830db4 kernel/dma/swiotlb.c Dongli Zhang 2019-04-12 546 dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes), total %lu (slots), used %lu (slots)\n",
53b29c336830db4 kernel/dma/swiotlb.c Dongli Zhang 2019-04-12 547 size, io_tlb_nslabs, tmp_io_tlb_used);
b907e20508d0246 kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 548 return DMA_MAPPING_ERROR;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 549 found:
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 550 io_tlb_used += nslots;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 551 spin_unlock_irqrestore(&io_tlb_lock, flags);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 552
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 553 /*
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 554 * Save away the mapping from the original address to the DMA address.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 555 * This is needed when we sync the memory. Then we sync the buffer if
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 556 * needed.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 557 */
bc40ac66988a772 lib/swiotlb.c Becky Bruce 2008-12-22 558 for (i = 0; i < nslots; i++)
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 559 io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT);
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 560 if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 561 (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
af51a9f1848ff50 lib/swiotlb.c Alexander Duyck 2012-10-15 562 swiotlb_bounce(orig_addr, tlb_addr, size, DMA_TO_DEVICE);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 563
e05ed4d1fad9e73 lib/swiotlb.c Alexander Duyck 2012-10-15 564 return tlb_addr;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 565 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 566
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 567 /*
d0c8ba40c6cc0fe lib/swiotlb.c Yisheng Xie 2018-05-07 568 * tlb_addr is the physical address of the bounce buffer to unmap.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 569 */
61ca08c3220032d lib/swiotlb.c Alexander Duyck 2012-10-15 570 void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 571 size_t size, enum dma_data_direction dir,
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 572 unsigned long attrs)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 573 {
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 574 unsigned long flags;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 575 int i, count, nslots = ALIGN(size, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT;
61ca08c3220032d lib/swiotlb.c Alexander Duyck 2012-10-15 576 int index = (tlb_addr - io_tlb_start) >> IO_TLB_SHIFT;
61ca08c3220032d lib/swiotlb.c Alexander Duyck 2012-10-15 577 phys_addr_t orig_addr = io_tlb_orig_addr[index];
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 578
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 579 /*
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 580 * First, sync the memory before unmapping the entry
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 581 */
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 582 if (orig_addr != INVALID_PHYS_ADDR &&
0443fa003fa199f lib/swiotlb.c Alexander Duyck 2016-11-02 583 !(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 584 ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
af51a9f1848ff50 lib/swiotlb.c Alexander Duyck 2012-10-15 585 swiotlb_bounce(orig_addr, tlb_addr, size, DMA_FROM_DEVICE);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 586
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 587 /*
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 588 * Return the buffer to the free list by setting the corresponding
af901ca181d92aa lib/swiotlb.c André Goddard Rosa 2009-11-14 589 * entries to indicate the number of contiguous entries available.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 590 * While returning the entries to the free list, we merge the entries
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 591 * with slots below and above the pool being returned.
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 592 */
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 593 spin_lock_irqsave(&io_tlb_lock, flags);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 594 {
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 595 count = ((index + nslots) < ALIGN(index + 1, IO_TLB_SEGSIZE) ?
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 596 io_tlb_list[index + nslots] : 0);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 597 /*
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 598 * Step 1: return the slots to the free list, merging the
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 599 * slots with superceeding slots
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 600 */
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 601 for (i = index + nslots - 1; i >= index; i--) {
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 602 io_tlb_list[i] = ++count;
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 603 io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 604 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 605 /*
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 606 * Step 2: merge the returned slots with the preceding slots,
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 607 * if available (non zero)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 608 */
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 609 for (i = index - 1; (OFFSET(i, IO_TLB_SEGSIZE) != IO_TLB_SEGSIZE -1) && io_tlb_list[i]; i--)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 610 io_tlb_list[i] = ++count;
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 611
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 612 io_tlb_used -= nslots;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 613 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 614 spin_unlock_irqrestore(&io_tlb_lock, flags);
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 615 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 616
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 617 void swiotlb_tbl_sync_single(struct device *hwdev, phys_addr_t tlb_addr,
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 618 size_t size, enum dma_data_direction dir,
d7ef1533a90f432 lib/swiotlb.c Konrad Rzeszutek Wilk 2010-05-28 619 enum dma_sync_target target)
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 620 {
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 621 int index = (tlb_addr - io_tlb_start) >> IO_TLB_SHIFT;
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 622 phys_addr_t orig_addr = io_tlb_orig_addr[index];
bc40ac66988a772 lib/swiotlb.c Becky Bruce 2008-12-22 623
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 624 if (orig_addr == INVALID_PHYS_ADDR)
8e0629c1d4ce86c lib/swiotlb.c Jan Beulich 2014-06-02 625 return;
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 626 orig_addr += (unsigned long)tlb_addr & ((1 << IO_TLB_SHIFT) - 1);
df336d1c7b6fd51 lib/swiotlb.c Keir Fraser 2007-07-21 627
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 628 switch (target) {
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 629 case SYNC_FOR_CPU:
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 630 if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
af51a9f1848ff50 lib/swiotlb.c Alexander Duyck 2012-10-15 631 swiotlb_bounce(orig_addr, tlb_addr,
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 632 size, DMA_FROM_DEVICE);
34814545890db60 lib/swiotlb.c Eric Sesterhenn 2006-03-24 633 else
34814545890db60 lib/swiotlb.c Eric Sesterhenn 2006-03-24 634 BUG_ON(dir != DMA_TO_DEVICE);
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 635 break;
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 636 case SYNC_FOR_DEVICE:
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 637 if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
af51a9f1848ff50 lib/swiotlb.c Alexander Duyck 2012-10-15 638 swiotlb_bounce(orig_addr, tlb_addr,
fbfda893eb570bb lib/swiotlb.c Alexander Duyck 2012-10-15 639 size, DMA_TO_DEVICE);
34814545890db60 lib/swiotlb.c Eric Sesterhenn 2006-03-24 640 else
34814545890db60 lib/swiotlb.c Eric Sesterhenn 2006-03-24 641 BUG_ON(dir != DMA_FROM_DEVICE);
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 642 break;
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 643 default:
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 644 BUG();
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 645 }
de69e0f0b38a467 lib/swiotlb.c John W. Linville 2005-09-29 646 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 647
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 648 /*
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 649 * Create a swiotlb mapping for the buffer at @phys, and in case of DMAing
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 650 * to the device copy the data into it as well.
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 651 */
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 652 bool swiotlb_map(struct device *dev, phys_addr_t *phys, dma_addr_t *dma_addr,
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 653 size_t size, enum dma_data_direction dir, unsigned long attrs)
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 654 {
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 655 trace_swiotlb_bounced(dev, *dma_addr, size, swiotlb_force);
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 656
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 657 if (unlikely(swiotlb_force == SWIOTLB_NO_FORCE)) {
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 658 dev_warn_ratelimited(dev,
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 659 "Cannot do DMA to address %pa\n", phys);
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 660 return false;
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 661 }
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 662
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 663 /* Oh well, have to allocate and map a bounce buffer. */
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 664 *phys = swiotlb_tbl_map_single(dev, __phys_to_dma(dev, io_tlb_start),
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 665 *phys, size, dir, attrs);
b907e20508d0246 kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 666 if (*phys == DMA_MAPPING_ERROR)
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 667 return false;
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 668
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 669 /* Ensure that the address returned is DMA'ble */
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 670 *dma_addr = __phys_to_dma(dev, *phys);
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 671 if (unlikely(!dma_capable(dev, *dma_addr, size))) {
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 672 swiotlb_tbl_unmap_single(dev, *phys, size, dir,
c4dae366925f929 kernel/dma/swiotlb.c Christoph Hellwig 2018-08-20 673 attrs | DMA_ATTR_SKIP_CPU_SYNC);
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 674 return false;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 675 }
309df0c503c35fb lib/swiotlb.c Arthur Kepner 2008-04-29 676
55897af63091ebc kernel/dma/swiotlb.c Christoph Hellwig 2018-12-03 677 return true;
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 678 }
^1da177e4c3f415 arch/ia64/lib/swiotlb.c Linus Torvalds 2005-04-16 679
abe420bfae528c9 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 680 size_t swiotlb_max_mapping_size(struct device *dev)
abe420bfae528c9 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 681 {
abe420bfae528c9 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 682 return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
abe420bfae528c9 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 683 }
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 684
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 685 bool is_swiotlb_active(void)
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 686 {
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 687 /*
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 688 * When SWIOTLB is initialized, even if io_tlb_start points to physical
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 689 * address zero, io_tlb_end surely doesn't.
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 690 */
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 691 return io_tlb_end != 0;
492366f7b423725 kernel/dma/swiotlb.c Joerg Roedel 2019-02-07 692 }
45ba8d5d061b134 kernel/dma/swiotlb.c Linus Torvalds 2019-03-10 693
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 694 #ifdef CONFIG_DEBUG_FS
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 695
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 696 static int __init swiotlb_create_debugfs(void)
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 697 {
1be51474f99bcfd kernel/dma/swiotlb.c Greg Kroah-Hartman 2019-06-12 698 struct dentry *root;
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 699
1be51474f99bcfd kernel/dma/swiotlb.c Greg Kroah-Hartman 2019-06-12 700 root = debugfs_create_dir("swiotlb", NULL);
1be51474f99bcfd kernel/dma/swiotlb.c Greg Kroah-Hartman 2019-06-12 701 debugfs_create_ulong("io_tlb_nslabs", 0400, root, &io_tlb_nslabs);
1be51474f99bcfd kernel/dma/swiotlb.c Greg Kroah-Hartman 2019-06-12 702 debugfs_create_ulong("io_tlb_used", 0400, root, &io_tlb_used);
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 703 return 0;
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 704 }
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 705
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 706 late_initcall(swiotlb_create_debugfs);
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 707
71602fe6d4e9291 kernel/dma/swiotlb.c Dongli Zhang 2019-01-18 708 #endif
:::::: The code at line 461 was first introduced by commit
:::::: d7b417fa08d1187923c270bc33a3555c2fcff8b9 x86/mm: Add DMA support for SEV memory encryption
:::::: TO: Tom Lendacky <thomas.lendacky@amd.com>
:::::: CC: Thomas Gleixner <tglx@linutronix.de>
---
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: 5848 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3
From: Michael Ellerman @ 2019-07-19 10:18 UTC (permalink / raw)
To: Christian Brauner, Christian Borntraeger
Cc: linux-arch, linux-s390, linux-ia64, linux-parisc, arnd, linux-sh,
Heiko Carstens, linux-kernel, linux-mips, linux-m68k, linux-alpha,
sparclinux, linuxppc-dev, Vasily Gorbik
In-Reply-To: <20190716130631.tohj4ub54md25dys@brauner.io>
Christian Brauner <christian@brauner.io> writes:
> On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
>> I think Vasily already has a clone3 patch for s390x with 435.
>
> A quick follow-up on this. Helge and Michael have asked whether there
> are any tests for clone3. Yes, there will be and I try to have them
> ready by the end of the this or next week for review. In the meantime I
> hope the following minimalistic test program that just verifies very
> very basic functionality (It's not pretty.) will help you test:
Hi Christian,
Thanks for the test.
This actually oopses on powerpc, it hits the BUG_ON in CHECK_FULL_REGS
in process.c around line 1633:
} else {
/* user thread */
struct pt_regs *regs = current_pt_regs();
CHECK_FULL_REGS(regs);
*childregs = *regs;
if (usp)
So I'll have to dig into how we fix that before we wire up clone3.
Turns out testing is good! :)
cheers
^ permalink raw reply
* Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3
From: Christian Brauner @ 2019-07-19 10:25 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, linux-s390, linux-ia64, linux-parisc, arnd, linux-sh,
Heiko Carstens, linux-kernel, linux-mips, Christian Borntraeger,
linux-m68k, linux-alpha, sparclinux, linuxppc-dev, Vasily Gorbik
In-Reply-To: <874l3i8h0l.fsf@concordia.ellerman.id.au>
On Fri, Jul 19, 2019 at 08:18:02PM +1000, Michael Ellerman wrote:
> Christian Brauner <christian@brauner.io> writes:
> > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
> >> I think Vasily already has a clone3 patch for s390x with 435.
> >
> > A quick follow-up on this. Helge and Michael have asked whether there
> > are any tests for clone3. Yes, there will be and I try to have them
> > ready by the end of the this or next week for review. In the meantime I
> > hope the following minimalistic test program that just verifies very
> > very basic functionality (It's not pretty.) will help you test:
>
> Hi Christian,
>
> Thanks for the test.
>
> This actually oopses on powerpc, it hits the BUG_ON in CHECK_FULL_REGS
> in process.c around line 1633:
>
> } else {
> /* user thread */
> struct pt_regs *regs = current_pt_regs();
> CHECK_FULL_REGS(regs);
> *childregs = *regs;
> if (usp)
>
>
> So I'll have to dig into how we fix that before we wire up clone3.
>
> Turns out testing is good! :)
Indeed. I have a test-suite for clone3 in mind and I hope to have it
ready by the end of next week. It's just always the finding the time
part that is annoying. :)
Thanks for digging into this, Michael!
Christian
^ permalink raw reply
* Re: [PATCH v9 08/10] open: openat2(2) syscall
From: Christian Brauner @ 2019-07-19 10:29 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: linux-ia64, Linux-sh list, Alexei Starovoitov,
Linux Kernel Mailing List, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, linuxppc-dev,
Aleksa Sarai, Al Viro, Andy Lutomirski, Shuah Khan,
David Drysdale, Linux ARM, J. Bruce Fields, Parisc List,
linux-m68k, Linux API, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, alpha, Linux FS-devel Mailing List, Andrew Morton,
Linus Torvalds, containers
In-Reply-To: <20190719021218.GB18022@altlinux.org>
On Fri, Jul 19, 2019 at 05:12:18AM +0300, Dmitry V. Levin wrote:
> On Thu, Jul 18, 2019 at 11:29:50PM +0200, Arnd Bergmann wrote:
> [...]
> > 5. you get the same problem with seccomp and strace that
> > clone3() has -- these and others only track the register
> > arguments by default.
>
> Just for the record, this is definitely not the case for strace:
> it decodes arrays, structures, netlink messages, and so on by default.
There sure is value in trying to design syscalls that can be handled
nicely by seccomp but that shouldn't become a burden on designing
extensible syscalls.
I suggested a session for Ksummit where we can discuss if and how we can
make seccomp more compatible with pointer-args in syscalls.
Christian
^ permalink raw reply
* Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3
From: Michael Ellerman @ 2019-07-19 11:13 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-arch, linux-s390, linux-ia64, linux-parisc, arnd, linux-sh,
Heiko Carstens, linux-kernel, linux-mips, Christian Borntraeger,
linux-m68k, linux-alpha, sparclinux, linuxppc-dev, Vasily Gorbik
In-Reply-To: <20190719102503.tm3ahvkh4rwykmws@brauner.io>
Christian Brauner <christian@brauner.io> writes:
> On Fri, Jul 19, 2019 at 08:18:02PM +1000, Michael Ellerman wrote:
>> Christian Brauner <christian@brauner.io> writes:
>> > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
>> >> I think Vasily already has a clone3 patch for s390x with 435.
>> >
>> > A quick follow-up on this. Helge and Michael have asked whether there
>> > are any tests for clone3. Yes, there will be and I try to have them
>> > ready by the end of the this or next week for review. In the meantime I
>> > hope the following minimalistic test program that just verifies very
>> > very basic functionality (It's not pretty.) will help you test:
>>
>> Hi Christian,
>>
>> Thanks for the test.
>>
>> This actually oopses on powerpc, it hits the BUG_ON in CHECK_FULL_REGS
>> in process.c around line 1633:
>>
>> } else {
>> /* user thread */
>> struct pt_regs *regs = current_pt_regs();
>> CHECK_FULL_REGS(regs);
>> *childregs = *regs;
>> if (usp)
>>
>>
>> So I'll have to dig into how we fix that before we wire up clone3.
>>
>> Turns out testing is good! :)
>
> Indeed. I have a test-suite for clone3 in mind and I hope to have it
> ready by the end of next week. It's just always the finding the time
> part that is annoying. :)
I know the feeling!
> Thanks for digging into this, Michael!
No worries, happy to help where I can.
In the intervening five minutes I remembered how we handle this, we just
need a little wrapper to save the non-volatile regs:
_GLOBAL(ppc_clone3)
bl save_nvgprs
bl sys_clone3
b .Lsyscall_exit
A while back I meant to make it generate those automatically based on a
flag in the syscall.tbl but of course haven't got around to it :)
So with the above it seems all good:
$ ./clone3 ; echo $?
Parent process received child's pid 4204 as return value
Parent process received child's pidfd 3
Parent process received child's pid 4204 as return argument
Child process with pid 4204
0
I'll send a patch to wire it up on Monday.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior
From: Arnd Bergmann @ 2019-07-19 11:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, Alexey Kardashevskiy, Sam Bobroff,
open list:IOMMU DRIVERS, Oliver O'Halloran, linuxppc-dev,
Marek Szyprowski
In-Reply-To: <20190718095200.GA25744@lst.de>
On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
> > On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > > > Other than m68k, mips, and arm64, everybody else that doesn't have
> > > > ARCH_NO_COHERENT_DMA_MMAP set uses this default implementation, so
> > > > I assume this behavior is acceptable on those architectures.
> > >
> > > It might be acceptable, but there's no reason to use pgport_noncached
> > > if the platform supports cache-coherent DMA.
> > >
> > > Christoph (+cc) made the change so maybe he saw something we're missing.
> >
> > I always found the forcing of noncached access even for coherent
> > devices a little odd, but this was inherited from the previous
> > implementation, which surprised me a bit as the different attributes
> > are usually problematic even on x86. Let me dig into the history a
> > bit more, but I suspect the righ fix is to default to cached mappings
> > for coherent devices.
>
> Ok, some history:
>
> The generic dma mmap implementation, which we are effectively still
> using today was added by:
>
> commit 64ccc9c033c6089b2d426dad3c56477ab066c999
> Author: Marek Szyprowski <m.szyprowski@samsung.com>
> Date: Thu Jun 14 13:03:04 2012 +0200
>
> common: dma-mapping: add support for generic dma_mmap_* calls
>
> and unconditionally uses pgprot_noncached in dma_common_mmap, which is
> then used as the fallback by dma_mmap_attrs if no ->mmap method is
> present. At that point we already had the powerpc implementation
> that only uses pgprot_noncached for non-coherent mappings, and
> the arm one, which uses pgprot_writecombine if DMA_ATTR_WRITE_COMBINE
> is set and otherwise pgprot_dmacoherent, which seems to be uncached.
> Arm did support coherent platforms at that time, but they might have
> been an afterthought and not handled properly.
Cache-coherent devices are still very rare on 32-bit ARM.
Among the callers of dma_mmap_coherent(), almost all are in platform
specific device drivers that only ever run on noncoherent ARM SoCs,
which explains why nobody would have noticed problems.
There is also a difference in behavior between ARM and PowerPC
when dealing with mismatched cacheability attributes: If the same
page is mapped as both cached and uncached to, this may
cause silent undefined behavior on ARM, while PowerPC should
enter a checkstop as soon as it notices.
Arnd
^ permalink raw reply
* Re: Crash in kvmppc_xive_release()
From: Michael Ellerman @ 2019-07-19 11:20 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
In-Reply-To: <3c152700-81de-9b34-e8a7-70b341a92197@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> On 18/07/2019 14:49, Michael Ellerman wrote:
>> Anyone else seen this?
>>
>> This is running ~176 VMs on a Power9 (1 per thread), host crashes:
>
> This is beyond the underlying limits of XIVE.
>
> As we allocate 2K vCPUs per VM, that is 16K EQs for interrupt events. The overall
> EQ count is 1M. I let you calculate what is our max number of VMs ...
We need to fix it somehow, people will expect to be able to run a VM per
thread.
cheers
^ permalink raw reply
* Re: Crash in kvmppc_xive_release()
From: Cédric Le Goater @ 2019-07-19 12:05 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Greg Kurz
In-Reply-To: <87woge6zj9.fsf@concordia.ellerman.id.au>
On 19/07/2019 13:20, Michael Ellerman wrote:
> Cédric Le Goater <clg@kaod.org> writes:
>> On 18/07/2019 14:49, Michael Ellerman wrote:
>>> Anyone else seen this?
>>>
>>> This is running ~176 VMs on a Power9 (1 per thread), host crashes:
>>
>> This is beyond the underlying limits of XIVE.
>>
>> As we allocate 2K vCPUs per VM, that is 16K EQs for interrupt events. The overall
>> EQ count is 1M. I let you calculate what is our max number of VMs ...
>
> We need to fix it somehow, people will expect to be able to run a VM per
> thread.
we are limited by two spaces : VP space (1 << 19) system overall and
EQ space (1 << 20 per chip, this one we could increase). But one of
the big issue is the way we allocate the XIVE VPs in the XIVE devices.
As we have no idea of how much vCPUs we should provision for, we take
the max: 2048 ...
If we had the maxcpu of the VM (from QEMU) or at least some hints on
a rough figure, lets say a power of 2 [ 32 - 4096 ] CPUs, we would
fragment less our VP space and increase a lot our #VMs per system.
It could be a kernel global, sysfs or what ever, a new KVM PPC control
on the VM to tune maxcpu, or a KVM device creation parameter. we
could also register multiple KVM devices each having its maximum :
tiny (5), small (6), normal (8), big (11, default legacy), huge (12),
and create from QEMU the one we think fits the best.
I have to think this over.
Nevertheless, I am trying to increase by 2 or 4 the XIVE spaces for
POWER10.
C.
^ permalink raw reply
* Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3
From: Christian Brauner @ 2019-07-19 12:20 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, linux-s390, linux-ia64, linux-parisc, arnd, linux-sh,
Heiko Carstens, linux-kernel, linux-mips, Christian Borntraeger,
linux-m68k, linux-alpha, sparclinux, linuxppc-dev, Vasily Gorbik
In-Reply-To: <871rym8egj.fsf@concordia.ellerman.id.au>
On Fri, Jul 19, 2019 at 09:13:16PM +1000, Michael Ellerman wrote:
> Christian Brauner <christian@brauner.io> writes:
> > On Fri, Jul 19, 2019 at 08:18:02PM +1000, Michael Ellerman wrote:
> >> Christian Brauner <christian@brauner.io> writes:
> >> > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:
> >> >> I think Vasily already has a clone3 patch for s390x with 435.
> >> >
> >> > A quick follow-up on this. Helge and Michael have asked whether there
> >> > are any tests for clone3. Yes, there will be and I try to have them
> >> > ready by the end of the this or next week for review. In the meantime I
> >> > hope the following minimalistic test program that just verifies very
> >> > very basic functionality (It's not pretty.) will help you test:
> >>
> >> Hi Christian,
> >>
> >> Thanks for the test.
> >>
> >> This actually oopses on powerpc, it hits the BUG_ON in CHECK_FULL_REGS
> >> in process.c around line 1633:
> >>
> >> } else {
> >> /* user thread */
> >> struct pt_regs *regs = current_pt_regs();
> >> CHECK_FULL_REGS(regs);
> >> *childregs = *regs;
> >> if (usp)
> >>
> >>
> >> So I'll have to dig into how we fix that before we wire up clone3.
> >>
> >> Turns out testing is good! :)
> >
> > Indeed. I have a test-suite for clone3 in mind and I hope to have it
> > ready by the end of next week. It's just always the finding the time
> > part that is annoying. :)
>
> I know the feeling!
>
> > Thanks for digging into this, Michael!
>
> No worries, happy to help where I can.
>
> In the intervening five minutes I remembered how we handle this, we just
> need a little wrapper to save the non-volatile regs:
>
> _GLOBAL(ppc_clone3)
> bl save_nvgprs
> bl sys_clone3
> b .Lsyscall_exit
Sounds good.
>
>
> A while back I meant to make it generate those automatically based on a
> flag in the syscall.tbl but of course haven't got around to it :)
>
> So with the above it seems all good:
>
> $ ./clone3 ; echo $?
> Parent process received child's pid 4204 as return value
> Parent process received child's pidfd 3
> Parent process received child's pid 4204 as return argument
> Child process with pid 4204
> 0
>
> I'll send a patch to wire it up on Monday.
Excellent! Thank you!
Christian
^ permalink raw reply
* Re: question on "powerpc/pseries/dma: Allow SWIOTLB"
From: Christoph Hellwig @ 2019-07-19 12:25 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Christoph Hellwig, linuxppc-dev
In-Reply-To: <14c9591a-5c8d-12a5-ed25-b7a41e0b1ad7@ozlabs.ru>
On Fri, Jul 19, 2019 at 06:23:59PM +1000, Alexey Kardashevskiy wrote:
> It is getting there and I still do not see why "swiotlb=force" should not
> work if chosed in the cmdline.
Ok, makes sense. But that means we also have the issue in a few
other places..
^ permalink raw reply
* Re: [PATCH v3 0/6] Remove x86-specific code from generic headers
From: Lendacky, Thomas @ 2019-07-19 13:12 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linux-s390@vger.kernel.org, Mike Anderson, Konrad Rzeszutek Wilk,
Robin Murphy, x86@kernel.org, Ram Pai,
linux-kernel@vger.kernel.org, Alexey Dobriyan, Halil Pasic,
iommu@lists.linux-foundation.org, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-fsdevel@vger.kernel.org, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <87a7db3z68.fsf@morokweng.localdomain>
On 7/18/19 2:44 PM, Thiago Jung Bauermann wrote:
>
> Lendacky, Thomas <Thomas.Lendacky@amd.com> writes:
>
>> On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
>>> Hello,
>>>
>>> This version is mostly about splitting up patch 2/3 into three separate
>>> patches, as suggested by Christoph Hellwig. Two other changes are a fix in
>>> patch 1 which wasn't selecting ARCH_HAS_MEM_ENCRYPT for s390 spotted by
>>> Janani and removal of sme_active and sev_active symbol exports as suggested
>>> by Christoph Hellwig.
>>>
>>> These patches are applied on top of today's dma-mapping/for-next.
>>>
>>> I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
>>> been build tested.
>>
>> I'll try and get this tested quickly to be sure everything works for SME
>> and SEV.
Built and tested both SME and SEV and everything appears to be working
well (not extensive testing, but should be good enough).
Thanks,
Tom
>
> Thanks! And thanks for reviewing the patches.
>
^ 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