qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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).


  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).