|
|
Subscribe / Log in / New account

VMX virtualization runs afoul of split-lock detection

VMX virtualization runs afoul of split-lock detection

Posted Apr 9, 2020 19:23 UTC (Thu) by kmweber (guest, #114635)
Parent article: VMX virtualization runs afoul of split-lock detection

As someone who knows nothing about this, I have a question: does this essentially mean putting a disassembler in the kernel? Because presumably that particular sequence of bytes that constitutes the opcode could appear in other contexts, right? E.g. as initialized data, as the end of one instruction opcode followed by the beginning of another, etc. Since x86 instructions are variable in length, is there a way to reliably determine this short of disassembling the entire thing from the beginning?

Like I said, I know nothing about this, so this isn't meant as a commentary on whether it is a good solution or not, whether the benefits outweigh the costs, and so forth--I'm just teying to better understand what's going on.


to post comments

VMX virtualization runs afoul of split-lock detection

Posted Apr 10, 2020 13:06 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

I have a question: does this essentially mean putting a disassembler in the kernel?
There's been a disassembler in the kernel for ages (or actually many, for many architectures: used e.g. for kprobes and uprobes etc to analyze function prologues to drop probe points there). This is just one of many users.

VMX virtualization runs afoul of split-lock detection

Posted Apr 12, 2020 21:48 UTC (Sun) by hmh (subscriber, #3838) [Link]

Not to mention the emulators... Yes, the kernel can, and does, have to emulate (a few instructions of) the running processor sometimes...


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds