From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: High vm-exit latencies during kvm boot-up/shutdown Date: Tue, 23 Oct 2007 18:14:05 +0200 Message-ID: <471E1DCD.5040301@qumranet.com> References: <471D2D8C.1080202@web.de> <10EA09EFD8728347A513008B6B0DA77A02441127@pdsmsx411.ccr.corp.intel.com> <471D96DC.7070809@web.de> <10EA09EFD8728347A513008B6B0DA77A024414D9@pdsmsx411.ccr.corp.intel.com> <471DBA1A.2080108@web.de> <471DC311.2050003@qumranet.com> <471DF76B.7040001@siemens.com> <471E02F7.6080408@qumranet.com> <471E0818.6060405@siemens.com> <471E1290.2000208@qumranet.com> <471E1A77.90808@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jan Kiszka Return-path: In-Reply-To: <471E1A77.90808-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/