[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49EDEE93.30103@codemonkey.ws>
Date: Tue, 21 Apr 2009 11:04:35 -0500
From: Anthony Liguori <anthony@...emonkey.ws>
To: Avi Kivity <avi@...hat.com>
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
Avi Kivity wrote:
> 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.
Except cpuid, which is handled in userspace, sort of :-) I think the
same arguments apply here too.
Regards,
Anthony Liguori
--
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/
Powered by blists - more mailing lists