I have one more question. Actually I am using Arch Linux 64 bit so finding dependencies took some time and in the documentation it says "Arch Linux is not officially supported or tested by the edk2

Thank you Nate. I installed edkrepo using the instructions you gave. I ran edkrepo clone min Intel-MinPlatform and it setup my workspace. Since I had already setup the EDK2 build environment and

Hi Ayush, Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! Sorry it has taken me a while to get back to you. I completely agree that the codebase is rather

Nate, Yes it is close to VT_UTF8, but not quite the same. I was looking back through the driver and I’d forgotten how similar it really is. Symbols used in table

Sorry for the typo. Yes I meant use CR3 to walk the page tables to find the CR2 address. I was not sure if QEMU had a tool for that? I know for our internal lldb scripts I wrote a debugger command

Hi Andrew, I tested VT_UTF8 on the macOs Terminal software and I can confirm that VT_UTF8 renders nicely. See the attached screenshot. Thanks, Nate On 3/17/21, 9:02 AM, "Andrew Fish"

Ah, thanks for the clarification. Thanks Annie

CR2 is the address whose access faulted; I mentioned CR3 because Andrew wrote "points the 1st level of the page tables". I understood that expression as the point where you'd start walking the page

Hello I added log into the code to dump the page info, and also run QMP command "xp" to walk through the page manually. The result shows the corresponding page table entry doesn't exist. I updated

Hi, I have just completed a fork of the GPLv2 ntfs-3g project [1], that enables compiling it as a UEFI driver. The project, as well as binary releases (for X64, IA32, AARCH64 and ARM), can be found

Never mind, please ignore my previous email. The QMP command 'xp' can dump the memory, I'll try to reproduce this issue and dump the memory. Thanks Annie

CC Nate

Hello Laszlo, I was thinking of CR2 because it has the address that causes this exception, and we suppose to find out the information of the page in which the address locates. no? Thanks Annie

Hello Laszlo, "click "Reboot" with Shift held down " works properly for me too, the Windows can boot into recovery mode in my environment. I just updated the bug with an another simpler way to

I think that's a typo: it should be CR3. But, I agree -- you can use QEMU monitor commands to read RAM words, and walk the page tables manually. (I figured I could help with this, but I couldn't

Annie, I’ve never used it, but I assume there is a way to dump page tables from the QEMU console. Maybe something like `info mem` ? Thanks, Andrew Fish

Annie, CR2 points the 1st level of the page tables. Those entries point to other page tables, so you kind of have to walk it by hand. https://wiki.osdev.org/Paging Thanks, Andrew Fish

Hi Jiewen, In DumpCpuContext function in ArchExceptionHandler.c, the exception details are gotten from either "SystemContextX64->ExceptionData" or "SystemContextX64.xxx". I am wondering how I can

Yes it is very strange.

Good question. The CR0.WP is set. But the page table protection may be turn OFF/ON again, if CPU driver need update it to protect an EFI image. Maybe it a bug somewhere. I just read the final debug