POPF bug discovered on AMD Ryzen

[Gigasoft]

I found out that my Ryzen CPU (Family 17h, Model 01h, Stepping 01h) has a little quirk with its POPF instruction:

If POPF is executed while EFLAGS.TF is 1, EFLAGS.IOPL < 3, EFLAGS.VM is 1 and CR4.VME is 1, and bit 8 (TF) of the popped value is 0, TF will mistakenly be set in the EFLAGS image pushed on the Debug exception handler stack.

Another VME related bug, with the INT instruction, has already been known and fixed in later revisions. Looks like they did not test VME mode very well. Shouldn't they have unit tests for a feature that has been around for decades?

[nullplan]

They probably didn't care about 8086 mode anymore, because nobody should be using that. Either use real mode, or join us on the 64-bit mode side, where 16-bit real mode is naught but a horrid memory.

Wait... did you execute the right instruction? Don't you need to use POPFD?

[xeyes]

virtual 8086 mode is probably not that high on the priority list but they should have more than a few tests for something like popf in various stages of the project.

Maybe you should provide them with the repro and if confirmed you might get a latest threadripper or 5950x as a token of appreciation

[rdos]

Actually, it's possible to run both 64-bit code and V86 (DOS) code on the same processor. Just switch one core (temporarily) to protected mode.

Neither 64-bit Windows nor 64-bit Linux can do it, but then their design is too limited.

[Ethin]

How would you go about switching individual cores like that, though? Do they just appear as separate processors under ACPI?

[Octocontrabass]

Actually, it's possible to run both 64-bit code and V86 (DOS) code on the same processor. Just switch one core (temporarily) to protected mode.

Or run it in an emulator. Modern 64-bit CPUs are fast enough that most 16-bit software won't notice the difference, and then you don't have to add complexity to your kernel and risk tripping over SMM or SMT bugs.

How would you go about switching individual cores like that, though? Do they just appear as separate processors under ACPI?

Each hardware thread appears as a separate CPU, and for most purposes (including mode switching and the MADT in ACPI) you can treat them that way. The architecture manuals will specify when you need to pay attention to how hardware threads map to cores and how cores map to sockets.

[rdos]

How would you go about switching individual cores like that, though? Do they just appear as separate processors under ACPI?

Each core can operate in different modes. One can be in long mode, another in protected mode and the third in real-mode. Actually, when you boot additional cores they start up in real mode.

[rdos]

Actually, it's possible to run both 64-bit code and V86 (DOS) code on the same processor. Just switch one core (temporarily) to protected mode.

Or run it in an emulator. Modern 64-bit CPUs are fast enough that most 16-bit software won't notice the difference, and then you don't have to add complexity to your kernel and risk tripping over SMM or SMT bugs.

Actually, running in protected mode with PAE paging uses one less paging level, and so should perform better in regards to paging. 32-bit paging would be even better, but this cannot be shared with long mode given incompatible layouts.

Also, protected mode allows using callgates instead of a shared entrypoint into kernel which is faster at least on older CPUs.

[bloodline]

Actually, it's possible to run both 64-bit code and V86 (DOS) code on the same processor. Just switch one core (temporarily) to protected mode.

Or run it in an emulator. Modern 64-bit CPUs are fast enough that most 16-bit software won't notice the difference, and then you don't have to add complexity to your kernel and risk tripping over SMM or SMT bugs.

I 100% agree with Octocontrabass, run a software realmode emulator in your OS, this will give you far more control and flexibility.

I'm planning to add something like this one to my OS, so I can get better control over the graphics:
https://opensource.apple.com/source/X11 ... .auto.html

[rdos]

Actually, it's possible to run both 64-bit code and V86 (DOS) code on the same processor. Just switch one core (temporarily) to protected mode.

Or run it in an emulator. Modern 64-bit CPUs are fast enough that most 16-bit software won't notice the difference, and then you don't have to add complexity to your kernel and risk tripping over SMM or SMT bugs.

I 100% agree with Octocontrabass, run a software realmode emulator in your OS, this will give you far more control and flexibility.

I'm planning to add something like this one to my OS, so I can get better control over the graphics:
https://opensource.apple.com/source/X11 ... .auto.html

You cannot run things like video mode setting or VBE inquiry with an emulator. It clearly requires that you reference the correct locations, that real IO-ports are accessed and that interrupts happen like the BIOS is expecting. OTOH, I wonder if Intel has not let their VBE code become completely broken and so now you need a real GPU interface to run anything significant on an Intel system. Still, it works reasonably well with AMD, with good performance, and so an alternative approach is to dump support for Intel completely.

Emulating old software is a completely different thing, and that can use an emulator. Although, I currently have no desire to support DOS or DOS extender applications again.

[pvc]

You cannot run things like video mode setting or VBE inquiry with an emulator. It clearly requires that you reference the correct locations, that real IO-ports are accessed and that interrupts happen like the BIOS is expecting.

Of course you can. Been there, done that. Nothing stops your CPU emulator from accessing real IO ports and memory locations. There is a little bit of complexity involved if you want hardware interrupts, but it can be done as well. You are supposed to emulate CPU only, not the whole machine. Even in virtual 8086 mode you are doing software emulation of some instructions. Virtual 8086 mode is just like hardware assisted CPU emulator.

[rdos]

You cannot run things like video mode setting or VBE inquiry with an emulator. It clearly requires that you reference the correct locations, that real IO-ports are accessed and that interrupts happen like the BIOS is expecting.

Of course you can. Been there, done that. Nothing stops your CPU emulator from accessing real IO ports and memory locations. There is a little bit of complexity involved if you want hardware interrupts, but it can be done as well. You are supposed to emulate CPU only, not the whole machine. Even in virtual 8086 mode you are doing software emulation of some instructions. Virtual 8086 mode is just like hardware assisted CPU emulator.

Sure, and there is an intermediate alternative too that I used when I virtualized DOS applications. I transformed the instructions so they could run using native instructions but changed the operating modes in combination with reading & writing memory or IO ports. This is a lot faster and easier to do than having a complete emulator written in C or other higher-level language. It can also be mixed with using virtual 8086 mode, and then only instructions that couldn't be executed would need emulation. At that time, I had no support for C in kernel anyway, so a full-featured emulator based on C would not have worked.

Besides, it's this method that I use in the panic debugger too which allows executing code past a severe fault. I see no reason why a C emulator would be useful here either. The whole panic debugger runs in a completed isolated context and certainly doesn't support C.

[feryno]

Emulators can use unrestricted guest mode (Intel VMX) / Paged real mode (AMD SVM) so the 16 bit code runs natively.