[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V3 1/1] target/loongarch: Fixed tlb huge page loading issue
|
From: |
Richard Henderson |
|
Subject: |
Re: [PATCH V3 1/1] target/loongarch: Fixed tlb huge page loading issue |
|
Date: |
Thu, 7 Mar 2024 09:28:52 -1000 |
|
User-agent: |
Mozilla Thunderbird |
On 3/6/24 21:37, Xianglai Li wrote:
When we use qemu tcg simulation, the page size of bios is 4KB.
When using the level 2 super large page (page size is 1G) to create the page
table,
it is found that the content of the corresponding address space is abnormal,
resulting in the bios can not start the operating system and graphical
interface normally.
The lddir and ldpte instruction emulation has
a problem with the use of super large page processing above level 2.
The page size is not correctly calculated,
resulting in the wrong page size of the table entry found by tlb.
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Cc: maobibo@loongson.cn
Cc: Song Gao <gaosong@loongson.cn>
Cc: Xiaojuan Yang <yangxiaojuan@loongson.cn>
Cc: zhaotianrui@loongson.cn
---
target/loongarch/internals.h | 8 +++
target/loongarch/tcg/tlb_helper.c | 92 +++++++++++++++++++++++--------
2 files changed, 76 insertions(+), 24 deletions(-)
diff --git a/target/loongarch/internals.h b/target/loongarch/internals.h
index a2fc54c8a7..55ceb4c079 100644
--- a/target/loongarch/internals.h
+++ b/target/loongarch/internals.h
@@ -16,6 +16,14 @@
#define TARGET_PHYS_MASK MAKE_64BIT_MASK(0, TARGET_PHYS_ADDR_SPACE_BITS)
#define TARGET_VIRT_MASK MAKE_64BIT_MASK(0, TARGET_VIRT_ADDR_SPACE_BITS)
+/*
+ * The [13..14]bits of the entry base address of the lddir/ldpte
+ * directive are used to represent the level of the large page
+ * when processing the huge page entry
+ */
+#define HUGE_PAGE_LEVEL_SHIFT 13
+#define HUGE_PAGE_LEVEL_MASK MAKE_64BIT_MASK(HUGE_PAGE_LEVEL_SHIFT, 2)
This would be cleaner using <hw/registerfields.h>, e.g.
FIELD(LDDIR, HUGE, 6, 1)
FIELD(LDDIR, LEVEL, 13, 2)
+static int get_dir_base_width(CPULoongArchState *env, uint64_t *dir_base,
+ uint64_t *dir_width, target_ulong level);
Very often you can place the new function just before its first use so that no prior
declaration is required.
Returning a bool with true for success and false for failure is preferred over
0/-1.
@@ -487,6 +490,16 @@ target_ulong helper_lddir(CPULoongArchState *env,
target_ulong base,
int shift;
uint64_t dir_base, dir_width;
bool huge = (base >> LOONGARCH_PAGE_HUGE_SHIFT) & 0x1;
+ uint64_t huge_page_level = base & HUGE_PAGE_LEVEL_MASK;
+
+ if (huge) {
if (FIELD_EX64(base, LDDIR, HUGE))
+ if (huge_page_level) {
if (FIELD_EX64(base, LDDIR, LEVEL))
+ } else {
+ huge_page_level = (level & 0x3) << HUGE_PAGE_LEVEL_SHIFT;
+ return base | huge_page_level;
return FIELD_DP64(base, LDDIR, LEVEL, level);
I suppose setting bit [6] with level == 4 is a "don't do that" sort of programming error.
You could log the error here, perhaps:
if (unlikely(level == 4)) {
qemu_log_mask(LOG_GUEST_ERROR, "Attempted use of level 4 huge page\n");
}
@@ -495,30 +508,10 @@ target_ulong helper_lddir(CPULoongArchState *env,
target_ulong base,
shift = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, PTEWIDTH);
shift = (shift + 1) * 3;
- if (huge) {
- return base;
- }
- switch (level) {
- case 1:
- dir_base = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, DIR1_BASE);
- dir_width = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, DIR1_WIDTH);
- break;
- case 2:
- dir_base = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, DIR2_BASE);
- dir_width = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, DIR2_WIDTH);
- break;
- case 3:
- dir_base = FIELD_EX64(env->CSR_PWCH, CSR_PWCH, DIR3_BASE);
- dir_width = FIELD_EX64(env->CSR_PWCH, CSR_PWCH, DIR3_WIDTH);
- break;
- case 4:
- dir_base = FIELD_EX64(env->CSR_PWCH, CSR_PWCH, DIR4_BASE);
- dir_width = FIELD_EX64(env->CSR_PWCH, CSR_PWCH, DIR4_WIDTH);
- break;
- default:
- do_raise_exception(env, EXCCODE_INE, GETPC());
+ if (get_dir_base_width(env, &dir_base, &dir_width, level) != 0) {
return 0;
}
I believe that we should not raise an exception here at all. This illegal instruction
exception is based on the LDDIR immediate operand, so we should have diagnosed this error
and raised an exception in trans_lddir().
Therefore the default label should use only g_assert_not_reached(), and there need not be
a error return from get_dir_base_width at all.
@@ -534,17 +527,38 @@ void helper_ldpte(CPULoongArchState *env, target_ulong
base, target_ulong odd,
bool huge = (base >> LOONGARCH_PAGE_HUGE_SHIFT) & 0x1;
uint64_t ptbase = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, PTBASE);
uint64_t ptwidth = FIELD_EX64(env->CSR_PWCL, CSR_PWCL, PTWIDTH);
+ uint64_t dir_base, dir_width;
+ uint64_t huge_page_level;
base = base & TARGET_PHYS_MASK;
if (huge) {
- /* Huge Page. base is paddr */
+ /*
+ * Gets the huge page level
+ * Clears the huge page level information in the address
+ * Clears huge page bit
+ * Gets huge page size
+ */
+ huge_page_level = (base & HUGE_PAGE_LEVEL_MASK) >>
+ HUGE_PAGE_LEVEL_SHIFT;
+
+ base &= ~HUGE_PAGE_LEVEL_MASK;
+
tmp0 = base ^ (1 << LOONGARCH_PAGE_HUGE_SHIFT);
/* Move Global bit */
tmp0 = ((tmp0 & (1 << LOONGARCH_HGLOBAL_SHIFT)) >>
LOONGARCH_HGLOBAL_SHIFT) << R_TLBENTRY_G_SHIFT |
(tmp0 & (~(1 << LOONGARCH_HGLOBAL_SHIFT)));
- ps = ptbase + ptwidth - 1;
+
+ huge_page_level++;
Why are you incrementing the level?
I think you want
level = MIN(level, 1);
Google translates the documentation for LDPTE as "bits [14:13] ... should be a non-zero
value". I don't know if "should" is precisely correct here (english technical documents
prefer "shall" or "may" to indicate a hard requirement vs optional behaviour). The
document does not appear to say what happens if the value is zero.
Since an earlier version of the specification did not have bits [14:13], my suspicion is
that the the current version of the specification is intended to be compatible, which
would map [14:13] == 0 to level == 1.
In any case, incrementing the level such that [14:13] == 1 -> level == 2 definitely seems
wrong.
r~