bytefire

Main problem with regular (forward-only time) debugging is a state -- memory, CPU, cache etc -- which is contributed to the bug but is completely lost. With time travel debugging that can be saved which is great but now you have a bunch of data that you need to sift through as you trace the bug. Seems like AI is the right tool to save you this drudgery and get to the root cause sooner (or let AI work on it while you do other things in parallel).

This is new. Something that couldn't have been possible without either of time travel debugging or latest AI tech (MCP, code LLMs).

It will be interesting to know what challenges came up in nudging the model to work better with time travel debug data, since this data is novel and the models today might not be well trained for making use of it.

It's interesting how little known this exception handling mechanism is: https://stackoverflow.com/questions/51761688/linux-driver-tr...

Thanks. I am actually using this inside a kernel module whose job is to inspect Intel's virtualisation state: https://github.com/bytefire/vmtool

i see, makes sense. may be a different team from V86 worked on it? Conways law :)

good point. may be the central idea of how it's implemented isn't too bad: i see hypervisor as a sort of OS kernel for VMs and the transitions from VM to hypervisor - VM exits - akin to syscalls. of course there is more but the above analogy is the basic idea and other things get added along the way

hi userbinator :) isn't the purpose of virtual 8086 mode somewhat different? i.e. to run real mode applications while the cpu is in protected mode? or did you mean that virtual 8086 could be generalised into a wider virtualisation system?

very good, thank you. i'll try to tidy it up

very interesting and creative use if EPT, will read the link. thanks for sharing

thank you that means a lot! please do add any information you think is relevant :)

no you didn't overlook. the article doesn't discuss actual mechanics of DRAM init, so thank you for adding this info :) i know there is a process of memory training whose aim is to arrive at the right parameters for that DRAM. the way i see it, it is sort of in-field caliberation. boot firmware can then store those parameters inside BIOS chip and then on next reboot just use those parameters, because memory training is a time-consuming process.

you're right, MRC is a major part of FSP but i think FSP does more work than just initialise memory. it also performs some CPU init and also ICH.

@userbinator thanks for clarification! this is indeed useful and helps understand contradictions.

> The instruction pointer is the IP register. It is zero.

it is 0xfff0, at least according to Intel Software Developer's Manual Volume 3, section 9.1.4 "First Instruction Executed". regarding 12 address lines being asserted, that is just a way of thinking about it. actual implementation might be different but what happens on reset is akin to 12 most significant bits being set. CS is 0xf000.

indeed a debugger would give the right answer.

this is interesting! i am not aware of how this logic is implemented, i.e. the logic of initial state where 12 most significant bits but thanks for enlightening

@burfog i have updated the post with explanation of how the reset vector address is calculated. thanks for pointing out :)

ah i see your point. here asserted defines a state and not a way of ensuring a certain condition is met (as in higher level languages). yes "initialised to 1" would also convey same meaning. i hope it's clearer now. the term asserted is often used in electronics and i can see how it can be misleading.

sorry could you explain what pinned or fixed mean in this context. by asserted, i mean the corresponding bits being set. similar thing to when one says an interrupt line is asserted, or gpio is asserted :)

yes CS not SS. i should fix that.

regarding how the CPU addresses 0xffff.fff0 is not exactly specified in the post. actually CS register is loaded with 0xf000 and normally this would yield a segment selector address of 0x000f.0000 (CS left-shifted by 4 bits). but on a reset, like the post mentions, first 12 address lines are asserted so the base address ends up being 0xffff.0000. these address lines remain asserted until a long jump is made, after which the first 12 address lines are de-asserted and normal CS segment selector calculation resumes.

instruction pointer contains -16 as you mentioned, the resulting address is:

base address + IP = 0xffff.0000 + 0xfff0 = 0xffff.fff0

i am not sure if this is worth adding to the post but it is definitely useful.

yes true. the article deliberately focuses on reset-vector onwards steps. perhaps it should make that clear in the beginning. the ME mention is just to create a context for the starting point. of course ME is a huge topic in itself

it's a good point. the article doesn't say classic BIOS hands off to bootloader in 32-bit mode. most systems now-a-days leave off the system in 32-bit mode and that's the point this article makes. the only mention to classic BIOS is as an example of boot firmware.

having said that it is perhaps worth clarifying in the article that classic BIOS would hand off in 16-bit mode :)