From: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
To: Jim Shu <jim.shu@sifive.com>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
"Richard Henderson" <richard.henderson@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Bin Meng" <bmeng.cn@gmail.com>,
"Weiwei Li" <liwei1518@gmail.com>,
"Daniel Henrique Barboza" <dbarboza@ventanamicro.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Peter Xu" <peterx@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Michael Rolnik" <mrolnik@gmail.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
"Song Gao" <gaosong@loongson.cn>,
"Laurent Vivier" <laurent@vivier.eu>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Aleksandar Rikalo" <arikalo@gmail.com>,
"Stafford Horne" <shorne@gmail.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Yoshinori Sato" <ysato@users.sourceforge.jp>,
"Ilya Leoshkevich" <iii@linux.ibm.com>,
"Thomas Huth" <thuth@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
"Max Filippov" <jcmvbkbc@gmail.com>,
"open list:ARM TCG CPUs" <qemu-arm@nongnu.org>,
"open list:PowerPC TCG CPUs" <qemu-ppc@nongnu.org>,
"open list:S390 TCG CPUs" <qemu-s390x@nongnu.org>
Subject: Re: [RFC PATCH 01/16] accel/tcg: Store section pointer in CPUTLBEntryFull
Date: Fri, 14 Jun 2024 21:28:22 +0800 [thread overview]
Message-ID: <c48aabc6-f5da-4e71-b65a-1fc35603e6e5@linux.alibaba.com> (raw)
In-Reply-To: <CALw707r1-94NOZ6CYV-aE-buXCh8v3mOQjUSm=wQrpLf0Pro9g@mail.gmail.com>
On 2024/6/13 18:37, Jim Shu wrote:
> Hi Zhiwei,
>
> Common IOMMU devices will not have IOMMUMemoryRegion in the path of
> CPU access since It only affects DMA access.
> In QEMU, it usually places this IOMMU MR as the parent of
> "system_memory", and changes the target_mr of DMA from "system_memory"
> to IOMMU MR.
>
> For the wgChecker, it is in front of memory or device MMIO and
> protects both CPU/DMA access to memory or device MMIO.
> In QEMU, wgChecker re-use IOMMUMemoryRegion to implement the memory
> protection inside the translate() function of IOMMU MR.
> In the machine code, wgChecker replaces the MemoryRegion of protected
> resources with the checker's IOMMU MR in the MemoryRegion tree of
> "system_memory".
> Both CPU/DMA access will go through the "system_memory". They will go
> through the checker's IOMMU MR when accessing the protected resources.
Thanks. It is clear and very helpful.
Zhiwei
>
> This mechanism is used by Cortex-M MPC devices (hw/misc/tz-mpc.c)
> originally. I have leveraged it and extended it little (in patch 2) as
> MPC doesn't support RO/WO permission.
> If we'd like to have a device to do the memory protection of both CPU
> & DMA access, we could implement it in this mechanism.
> (p.s. Cortex-A TZASC is not supported in QEMU, which is similar to MPC
> or wgChecker device.)
>
> Thanks,
> Jim Shu
>
>
>
>
>
> On Thu, Jun 13, 2024 at 2:23 PM LIU Zhiwei <zhiwei_liu@linux.alibaba.com> wrote:
>> On 2024/6/12 16:14, Jim Shu wrote:
>>> 'CPUTLBEntryFull.xlat_section' stores section_index in last 12 bits to
>>> find the correct section when CPU access the IO region over the IOTLB
>>> (iotlb_to_section()).
>>>
>>> However, section_index is only unique inside single AddressSpace. If
>>> address space translation is over IOMMUMemoryRegion, it could return
>>> section from other AddressSpace. 'iotlb_to_section()' API only finds the
>>> sections from CPU's AddressSpace so that it couldn't find section in
>>> other AddressSpace. Thus, using 'iotlb_to_section()' API will find the
>>> wrong section and QEMU will have wrong load/store access.
>>>
>>> To fix this bug, store complete MemoryRegionSection pointer in
>>> CPUTLBEntryFull instead of section_index.
>>>
>>> This bug occurs only when
>>> (1) IOMMUMemoryRegion is in the path of CPU access.
>> Hi Jim,
>>
>> Can you explain a little more on when IOMMUMemoryRegion is in the path
>> of CPU access?
>>
>> Thanks,
>> Zhiwei
>>
>>> (2) IOMMUMemoryRegion returns different target_as and the section is in
>>> the IO region.
>>>
>>> Common IOMMU devices don't have this issue since they are only in the
>>> path of DMA access. Currently, the bug only occurs when ARM MPC device
>>> (hw/misc/tz-mpc.c) returns 'blocked_io_as' to emulate blocked access
>>> handling. Upcoming RISC-V wgChecker device is also affected by this bug.
>>>
>>> Signed-off-by: Jim Shu <jim.shu@sifive.com>
>>> ---
>>> accel/tcg/cputlb.c | 19 +++++++++----------
>>> include/hw/core/cpu.h | 3 +++
>>> 2 files changed, 12 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
>>> index 117b516739..8cf124b760 100644
>>> --- a/accel/tcg/cputlb.c
>>> +++ b/accel/tcg/cputlb.c
>>> @@ -1169,6 +1169,7 @@ void tlb_set_page_full(CPUState *cpu, int mmu_idx,
>>> desc->fulltlb[index] = *full;
>>> full = &desc->fulltlb[index];
>>> full->xlat_section = iotlb - addr_page;
>>> + full->section = section;
>>> full->phys_addr = paddr_page;
>>>
>>> /* Now calculate the new entry */
>>> @@ -1248,14 +1249,14 @@ static inline void cpu_unaligned_access(CPUState *cpu, vaddr addr,
>>> }
>>>
>>> static MemoryRegionSection *
>>> -io_prepare(hwaddr *out_offset, CPUState *cpu, hwaddr xlat,
>>> +io_prepare(hwaddr *out_offset, CPUState *cpu, CPUTLBEntryFull *full,
>>> MemTxAttrs attrs, vaddr addr, uintptr_t retaddr)
>>> {
>>> MemoryRegionSection *section;
>>> hwaddr mr_offset;
>>>
>>> - section = iotlb_to_section(cpu, xlat, attrs);
>>> - mr_offset = (xlat & TARGET_PAGE_MASK) + addr;
>>> + section = full->section;
>>> + mr_offset = (full->xlat_section & TARGET_PAGE_MASK) + addr;
>>> cpu->mem_io_pc = retaddr;
>>> if (!cpu->neg.can_do_io) {
>>> cpu_io_recompile(cpu, retaddr);
>>> @@ -1571,9 +1572,7 @@ bool tlb_plugin_lookup(CPUState *cpu, vaddr addr, int mmu_idx,
>>>
>>> /* We must have an iotlb entry for MMIO */
>>> if (tlb_addr & TLB_MMIO) {
>>> - MemoryRegionSection *section =
>>> - iotlb_to_section(cpu, full->xlat_section & ~TARGET_PAGE_MASK,
>>> - full->attrs);
>>> + MemoryRegionSection *section = full->section;
>>> data->is_io = true;
>>> data->mr = section->mr;
>>> } else {
>>> @@ -1972,7 +1971,7 @@ static uint64_t do_ld_mmio_beN(CPUState *cpu, CPUTLBEntryFull *full,
>>> tcg_debug_assert(size > 0 && size <= 8);
>>>
>>> attrs = full->attrs;
>>> - section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
>>> + section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
>>> mr = section->mr;
>>>
>>> BQL_LOCK_GUARD();
>>> @@ -1993,7 +1992,7 @@ static Int128 do_ld16_mmio_beN(CPUState *cpu, CPUTLBEntryFull *full,
>>> tcg_debug_assert(size > 8 && size <= 16);
>>>
>>> attrs = full->attrs;
>>> - section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
>>> + section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
>>> mr = section->mr;
>>>
>>> BQL_LOCK_GUARD();
>>> @@ -2513,7 +2512,7 @@ static uint64_t do_st_mmio_leN(CPUState *cpu, CPUTLBEntryFull *full,
>>> tcg_debug_assert(size > 0 && size <= 8);
>>>
>>> attrs = full->attrs;
>>> - section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
>>> + section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
>>> mr = section->mr;
>>>
>>> BQL_LOCK_GUARD();
>>> @@ -2533,7 +2532,7 @@ static uint64_t do_st16_mmio_leN(CPUState *cpu, CPUTLBEntryFull *full,
>>> tcg_debug_assert(size > 8 && size <= 16);
>>>
>>> attrs = full->attrs;
>>> - section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
>>> + section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
>>> mr = section->mr;
>>>
>>> BQL_LOCK_GUARD();
>>> diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
>>> index a2c8536943..3f6c10897b 100644
>>> --- a/include/hw/core/cpu.h
>>> +++ b/include/hw/core/cpu.h
>>> @@ -217,6 +217,9 @@ typedef struct CPUTLBEntryFull {
>>> */
>>> hwaddr xlat_section;
>>>
>>> + /* @section contains physical section. */
>>> + MemoryRegionSection *section;
>>> +
>>> /*
>>> * @phys_addr contains the physical address in the address space
>>> * given by cpu_asidx_from_attrs(cpu, @attrs).
next prev parent reply other threads:[~2024-06-14 13:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 8:14 [RFC PATCH 00/16] Implements RISC-V WorldGuard extension v0.4 Jim Shu
2024-06-12 8:14 ` [RFC PATCH 01/16] accel/tcg: Store section pointer in CPUTLBEntryFull Jim Shu
2024-06-13 6:22 ` LIU Zhiwei
2024-06-13 10:37 ` Jim Shu
2024-06-14 13:28 ` LIU Zhiwei [this message]
2024-06-12 8:14 ` [RFC PATCH 02/16] accel/tcg: memory access from CPU will pass access_type to IOMMU Jim Shu
2024-06-13 5:34 ` Ethan Chen via
2024-06-13 9:52 ` Jim Shu
2024-06-12 8:14 ` [RFC PATCH 03/16] exec: Add RISC-V WorldGuard WID to MemTxAttrs Jim Shu
2024-07-12 1:38 ` Alistair Francis
2024-06-12 8:14 ` [RFC PATCH 04/16] hw/misc: riscv_worldguard: Add RISC-V WorldGuard global config Jim Shu
2024-07-12 1:41 ` Alistair Francis
2024-06-12 8:14 ` [RFC PATCH 05/16] target/riscv: Add CPU options of WorldGuard CPU extension Jim Shu
2024-07-12 1:42 ` Alistair Francis
2024-06-12 8:14 ` [RFC PATCH 06/16] target/riscv: Add hard-coded CPU state of WG extension Jim Shu
2024-07-12 1:44 ` Alistair Francis
2024-06-12 8:14 ` [RFC PATCH 07/16] target/riscv: Add defines for WorldGuard CSRs Jim Shu
2024-06-12 8:14 ` [RFC PATCH 08/16] target/riscv: Allow global WG config to set WG CPU callbacks Jim Shu
2024-06-12 8:14 ` [RFC PATCH 09/16] target/riscv: Implement WorldGuard CSRs Jim Shu
2024-06-12 8:14 ` [RFC PATCH 10/16] target/riscv: Add WID to MemTxAttrs of CPU memory transactions Jim Shu
2024-06-12 8:14 ` [RFC PATCH 11/16] hw/misc: riscv_worldguard: Add API to enable WG extension of CPU Jim Shu
2024-06-12 8:14 ` [RFC PATCH 12/16] hw/misc: riscv_wgchecker: Implement RISC-V WorldGuard Checker Jim Shu
2024-06-12 8:14 ` [RFC PATCH 13/16] hw/misc: riscv_wgchecker: Implement wgchecker slot registers Jim Shu
2024-06-12 8:14 ` [RFC PATCH 14/16] hw/misc: riscv_wgchecker: Implement correct block-access behavior Jim Shu
2024-06-12 8:14 ` [RFC PATCH 15/16] hw/misc: riscv_wgchecker: Check the slot settings in translate Jim Shu
2024-06-12 8:14 ` [RFC PATCH 16/16] hw/riscv: virt: Add WorldGuard support Jim Shu
2024-07-12 2:02 ` Alistair Francis
2024-09-07 18:06 ` [RFC PATCH 00/16] Implements RISC-V WorldGuard extension v0.4 Pavel Skripkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c48aabc6-f5da-4e71-b65a-1fc35603e6e5@linux.alibaba.com \
--to=zhiwei_liu@linux.alibaba.com \
--cc=alistair.francis@wdc.com \
--cc=arikalo@gmail.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=bmeng.cn@gmail.com \
--cc=david@redhat.com \
--cc=dbarboza@ventanamicro.com \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=gaosong@loongson.cn \
--cc=iii@linux.ibm.com \
--cc=jcmvbkbc@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=jim.shu@sifive.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=laurent@vivier.eu \
--cc=liwei1518@gmail.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mrolnik@gmail.com \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shorne@gmail.com \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).