From: Huacai Chen <chenhuacai@kernel.org>
To: Ainux Wang <ainux.wang@gmail.com>
Cc: wangyao@lemote.com, ardb@kernel.org, wangrui@loongson.cn,
linux-efi@vger.kernel.org
Subject: Re: [PATCH] efi/loongarch: Change MMU translation mode
Date: Thu, 23 Nov 2023 15:49:27 +0800 [thread overview]
Message-ID: <CAAhV-H41aFeA4CnDii2BT4NRUMY_rT_4MYFrnP_U9vok=3wm4A@mail.gmail.com> (raw)
In-Reply-To: <CAPWE4_wx1hBmVR6Ppcia8C3xJECEKzGwvDj3hxaWXsKEpYFAsA@mail.gmail.com>
On Thu, Nov 23, 2023 at 3:06 PM Ainux Wang <ainux.wang@gmail.com> wrote:
>
> Huacai Chen <chenhuacai@kernel.org> 于2023年11月23日周四 12:05写道：
> >
> > On Thu, Nov 23, 2023 at 8:23 AM Ainux Wang <ainux.wang@gmail.com> wrote:
> > >
> > > Huacai Chen <chenhuacai@kernel.org> 于2023年11月22日周三 22:22写道：
> > > >
> > > > Hi, Yao,
> > > >
> > > > On Wed, Nov 22, 2023 at 4:50 PM <wangyao@lemote.com> wrote:
> > > > >
> > > > > From: Wang Yao <wangyao@lemote.com>
> > > > >
> > > > > Refer ot UEFI spec v2.10 section 2.3.8 LoongArch Platforms:
> > > > >
> > > > > The processor is in the following execution mode during boot service:
> > > > > ...
> > > > > The memory is in physical addressing mode. LoongArch architecture
> > > > > defines two memory access mode, namely direct address translation
> > > > > mode and mapped address translation mode.
> > > > >
> > > > > So need to change MMU translation mode before config direct mapping.
> > > > From UEFI spec v2.10 section 2.3.8, you can also see "MMU enabled", so
> > > > PG is already enabled in UEFI.
> > > >
> > > > Huacai
> > > >
> > > Hi,Huacai,
> > >
> > > From LoongArch-Vol1-v1.10-EN.pdf , DA or PG both refer to a mode enabled by MMU,
> > > Will the UEFI firmware not use DA mode?
> > > The UEFI spec did not specify the use of DA or PG mode, but the kernel
> > > must use PG.
> > In theory you are right, but "MMU" usually means "TLB", including this
> > case. EFI runtime needs TLB, so UEFI cannot be in DA mode.
> >
> > Huacai
> >
> Is it possible that set_virtual_address_map() only configures the DMW
> under PG mode
> without switching DA to PG mode?
>
> I noticed in efi_get_virtmap() that virt_addr = phys_addr +
> 0x8000_0000_0000_000,
> and I also observed in the kernel's head.S there's a PG mode switch process
> ，which could enable runtime services to use PG mode.
>
> However, this occurs after the STUB,
> so does the STUB phase really require or ensure that the UEFI firmware
> is definitely in
> PG mode?
Anything you think redundant may be not redundant, remember that UEFI
is not the only BIOS and Linux is not the only OS. So Linux kernel
cannot assume any BIOS is the same as UEFI does, UEFI cannot assume
any OS is the same as Linux does, too.
Huacai
>
> > >
> > > Best regards,
> > > Ainux Wang.
> > > > >
> > > > > Signed-off-by: Wang Yao <wangyao@lemote.com>
> > > > > ---
> > > > > drivers/firmware/efi/libstub/loongarch.c | 8 +++++++-
> > > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
> > > > > index 807cba2693fc..4c0a84c58f5b 100644
> > > > > --- a/drivers/firmware/efi/libstub/loongarch.c
> > > > > +++ b/drivers/firmware/efi/libstub/loongarch.c
> > > > > @@ -49,7 +49,7 @@ efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
> > > > > struct exit_boot_struct priv;
> > > > > unsigned long desc_size;
> > > > > efi_status_t status;
> > > > > - u32 desc_ver;
> > > > > + u32 desc_ver, val;
> > > > >
> > > > > status = efi_alloc_virtmap(&priv.runtime_map, &desc_size, &desc_ver);
> > > > > if (status != EFI_SUCCESS) {
> > > > > @@ -69,6 +69,12 @@ efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
> > > > > priv.runtime_entry_count * desc_size, desc_size,
> > > > > desc_ver, priv.runtime_map);
> > > > >
> > > > > + /* Change address translation mode */
> > > > > + val = csr_read32(LOONGARCH_CSR_CRMD);
> > > > > + val &= ~CSR_CRMD_DA;
> > > > > + val |= CSR_CRMD_PG;
> > > > > + csr_write32(val, LOONGARCH_CSR_CRMD);
> > > > > +
> > > > > /* Config Direct Mapping */
> > > > > csr_write64(CSR_DMW0_INIT, LOONGARCH_CSR_DMWIN0);
> > > > > csr_write64(CSR_DMW1_INIT, LOONGARCH_CSR_DMWIN1);
> > > > > --
> > > > > 2.27.0
> > > > >
prev parent reply other threads:[~2023-11-23 7:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 8:49 [PATCH] efi/loongarch: Change MMU translation mode wangyao
2023-11-22 14:22 ` Huacai Chen
2023-11-23 0:22 ` Ainux Wang
2023-11-23 4:05 ` Huacai Chen
2023-11-23 7:05 ` Ainux Wang
2023-11-23 7:49 ` Huacai Chen [this message]
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='CAAhV-H41aFeA4CnDii2BT4NRUMY_rT_4MYFrnP_U9vok=3wm4A@mail.gmail.com' \
--to=chenhuacai@kernel.org \
--cc=ainux.wang@gmail.com \
--cc=ardb@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=wangrui@loongson.cn \
--cc=wangyao@lemote.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).