Virtualization wrote:
Hi list, >From the Intel® Virtualization Technology Specification for the IA-32 Intel® Architecture (2005): "2.9.2 Information for VM Exits Due to Vectored Events Event-specific information is provided for VM exits due to the following vectored events: exceptions (including those generated by the instructions INT3, INTO, BOUND, and UD2); external interrupts that occur while the “acknowledge interrupt on exit” VM-exit control is 1; and non-maskable interrupts (NMIs). This information is provided in the following fields:" .... The <0f> 0b in the "Code:" section are the UD2 instruction. Checking through the OpCode map for the Xeon processor, this is an invalid op code. In VT processors the software guide indicates that a program can communicate various events and state information to the underlying virtualization supervisor by executing a UD2 (and some others ops like it). I think that in a non-VT cpu it's actually a "real" invalid op code. The stuff (hardware) which flips over to the supervisor with all the needed info from the virtual machine isn't there. KVM uses this, from the patches I've seen Googling around for UD2 (if I understand correctly). So why a UD2 in the code? It's highly unlikely that it's just some random bytes that happen to be a UD2. Possibly the kernel thinks it's in fully virt mode at some point? The image notes do seem to indicate this.
The guest kernel uses UD2 as part of the implementation of an assertion. In this case, UD2 is used by the guest to communicate with itself. Every BUG: report you see will have the code containing 0f 0b.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
