linux-kernel - Re: [PATCH] Add MCE support to KVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49E337D7.5050502@redhat.com>
Date:	Mon, 13 Apr 2009 16:02:15 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Huang Ying <ying.huang@...el.com>
CC:	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH] Add MCE support to KVM

Huang Ying wrote:
> On Sat, 2009-04-11 at 20:04 +0800, Avi Kivity wrote:
>   
>>>> Why not always allocate it on vcpu setup?
>>>>     
>>>>         
>>> Because the MCE bank number is not fixed, it is based on mcg_cap from
>>> user space.
>>>   
>>>       
>> Right, but we can allocate the maximum number, no?  it's a fairly small 
>> amount of memory.
>>     
>
> OK. If you are OK with 8k extra memory usage.
>   

Let's make it 64 banks like Andi suggests.  Return the number in the 
KVM_CHECK_EXTENSION call (we do the same for memory slots) so userspace 
can adjust.

>>
>> kvm does feature negotiation (really, feature advertising) using 
>> KVM_CAP_... and KVM_CHECK_EXTENSION.  So there's no need for this.
>>     
>
> It is not only feature advertising, but also something like CPUID. Based
> on CPU type specified in command line (qemu -cpu ?), different mcg_cap
> can be used to determine number of MCE banks and various features of MCE
> (MCG_CTL_P, MCG_TES_P, MCG_CMCI, etc) for specified CPU type. With KVM
> feature advertising, we can only check whether MCE simulation is
> supported, but can not set parameters of MCE simulation.
>
> Maybe this interface can be changed to KVM_SET_MSRS, with
> MSR_IA32_MCG_CAP be set by kvm-qemu. But MSR_IA32_MCG_CAP is read-only
> by spec, and current interface can not distinguishes between MSR set
> from guest system and MSR setup from kvm-qemu. I think there should be
> other read-only MSRs need to be setup during guest system
> creation/setup. How about add a interface such as KVM_SETUP_MSRS to
> setup the value of read-only MSRs?
>   

Then we would need to tell which read-only MSRs are setup writeable and 
which aren't...

I'm okay with an ioctl to setup MCE, but just make sure userspace has 
all the information to know what the kernel can do rather than the 
try-and-see-if-it-works approach.  We can publish this information via 
KVM_CAP things, or via another ioctl (see KVM_GET_SUPPORTED_CPUID2 for 
an example).

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/