Jan Kiszka wrote: > >> Exiting on a pending interrupt is controlled by the vmcs word >> PIN_BASED_EXEC_CONTROL, bit PIN_BASED_EXT_INTR_MASK. Can you check (via >> vmcs_read32()) that the bit is indeed set? >> >> [if not, a guest can just enter a busy loop and kill a processor] >> >> > > I traced it right before and after the asm block, and in all cases > (including those with low latency exits) it's just 0x1f, which should be > fine. > >
Yes. > Earlier, I also checked GUEST_INTERRUPTIBILITY_INFO and > GUEST_ACTIVITY_STATE, but found neither some suspicious state nor a > difference compared to fast exits. > GUEST_* things are unrelated; these talk about whether the guest is ready to receive an interrupt, but we don't really care, do we? I don't have any idea why this is happening. This is completely unrelated to -rt issues -- this is between kvm and the hardware. Is this on a uniprocessor system? If not, can you try nosmp? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
