From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: nmi is broken? Date: Tue, 03 May 2011 16:31:43 +0300 Message-ID: <4DC003BF.9060204@redhat.com> References: <87sjtbe7fz.fsf@devron.myhome.or.jp> <877hak1t1s.fsf@devron.myhome.or.jp> <4DB3C6D3.9040703@redhat.com> <4DB42EC3.3090002@web.de> <4DBFCE25.2060603@redhat.com> <4DBFDAE1.3030104@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OGAWA Hirofumi , kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:63640 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751039Ab1ECNbu (ORCPT ); Tue, 3 May 2011 09:31:50 -0400 In-Reply-To: <4DBFDAE1.3030104@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/03/2011 01:37 PM, Jan Kiszka wrote: > > > > Yes. Unfortunately that is very vendor and model specific. The > > architectural PMU is supported, but that is only available on Intel. > > Is it supposed to have any practical value already? I did not yet find a > magic -cpu switch to let Linux detect anything, not to speak of perf or > watchdog support. On the guest side it is supported for the watchdog (arch/x86/kernel/cpu/perfctr-watchdog.c, look for X86_FEATURE_ARCH_PERFMON). It's also mentioned in perf_event_intel.c, but I don't know if it will work without the other PMU features being present. > > > > Perhaps we could emulate the architectural PMU on AMD as well, and make > > the detection code in the guest vendor agnostic. Since it's based on a > > cpuid bit, it should be safe. > > > > We may only make Linux happy this way, no? I would argue that if a feature is discoverable by a cpuid bit it shouldn't need to be qualified by vendor. No idea how other OSes work this out (or even if they make use of the architectural PMU). -- error compiling committee.c: too many arguments to function