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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 19 Apr 2009 11:33:58 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	Huang Ying <ying.huang@...el.com>,
	"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

Anthony Liguori wrote:
> Avi Kivity wrote:
>>
>> 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).
>
> Why not introduce a new exit type for MSR reads/writes that aren't 
> handled by the kernel?  You just need a bit on the return that 
> indicates whether to GPF because of an invalid MSR access.
>
> KVM_SET_MSRs should be reserved for MSRs that are performance 
> sensitive.  Not all of them will be.
>

Right now everything in the vcpu is emulated in the kernel.  Everything 
else is emulated either in the kernel (irqchip) or in userspace.  This 
makes things easier to understand, and is more future friendly if more 
cpu features become virtualized by hardware.

While these are not compelling reasons, they at least lean the balance 
in favour of a kernel implementation.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
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/