Add MCE support to KVM. The related MSRs are emulated. A new vcpu
ioctl command KVM_X86_SETUP_MCE is used to setup MCE emulation such as
the mcg_cap. MCE is injected via vcpu ioctl command
KVM_X86_SET_MCE. Extended machine-check state (MCG_EXT_P) and CMCI are
not implemented.
Signed-off-by: Huang
Huang Ying wrote:
Add MCE support to KVM. The related MSRs are emulated. A new vcpu
ioctl command KVM_X86_SETUP_MCE is used to setup MCE emulation such as
the mcg_cap. MCE is injected via vcpu ioctl command
KVM_X86_SET_MCE. Extended machine-check state (MCG_EXT_P) and CMCI are
not implemented.
S
On Thu, 2009-04-09 at 23:50 +0800, Avi Kivity wrote:
> Huang Ying wrote:
> > +int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> > +{
> > + switch (msr) {
> > + case MSR_EFER:
> > + set_efer(vcpu, data);
> > break;
> > case MSR_IA32_DEBUGCTLMSR:
> >
Huang Ying wrote:
On Thu, 2009-04-09 at 23:50 +0800, Avi Kivity wrote:
Huang Ying wrote:
+int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+{
+ switch (msr) {
+ case MSR_EFER:
+ set_efer(vcpu, data);
break;
case MSR_IA32_
> Right, but we can allocate the maximum number, no? it's a fairly small
> amount of memory.
There are 255 banks worst case which need upto 4 (in theory 5) MSRs each
-Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
Mor
Andi Kleen wrote:
Right, but we can allocate the maximum number, no? it's a fairly small
amount of memory.
There are 255 banks worst case which need upto 4 (in theory 5) MSRs each
That's 8KB, which would normally not be allocated. But I think we can
live with it.
Do we actually
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 o
On Sat, Apr 11, 2009 at 03:25:19PM +0300, Avi Kivity wrote:
> Andi Kleen wrote:
> >>Right, but we can allocate the maximum number, no? it's a fairly small
> >>amount of memory.
> >>
> >
> >There are 255 banks worst case which need upto 4 (in theory 5) MSRs each
> >
> >
>
> That's 8KB, whic
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
On Mon, 2009-04-13 at 21:02 +0800, Avi Kivity wrote:
> 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
> >>> use
Huang Ying wrote:
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 fo
On Tue, 2009-04-14 at 18:45 +0800, Avi Kivity wrote:
> Huang Ying wrote:
> >> 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
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 publis
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
On 04/19/09 10:33, Avi Kivity wrote:
Anthony Liguori wrote:
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.
Yes, please.
Right now everything in the vcp
Gerd Hoffmann wrote:
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 no
Gerd Hoffmann wrote:
On 04/20/09 10:26, Avi Kivity wrote:
Gerd Hoffmann wrote:
The xen pv-on-hvm drivers use an msr to indicate "please place the
hypercall page here". Handling that in kernel isn't an option IMHO.
The contents of the hypercall page are vendor specific. This can be
handled fro
On 04/20/09 10:26, Avi Kivity wrote:
Gerd Hoffmann wrote:
The xen pv-on-hvm drivers use an msr to indicate "please place the
hypercall page here". Handling that in kernel isn't an option IMHO.
The contents of the hypercall page are vendor specific. This can be
handled from userspace (though id
> It depends if the MSR may be considered global, or is required to be
> per-cpu. Need to refresh my memory on this, but I remember reading this
Machine Check MSRs need to be per CPU. The latest kernels have some support
for "shared banks" (between CPUs) but it's better to not have it and
older
Andi Kleen wrote:
It depends if the MSR may be considered global, or is required to be
per-cpu. Need to refresh my memory on this, but I remember reading this
Machine Check MSRs need to be per CPU. The latest kernels have some support
for "shared banks" (between CPUs) but it's better to
On 04/20/09 11:05, Avi Kivity wrote:
Gerd Hoffmann wrote:
On 04/20/09 10:26, Avi Kivity wrote:
Gerd Hoffmann wrote:
The xen pv-on-hvm drivers use an msr to indicate "please place the
hypercall page here". Handling that in kernel isn't an option IMHO.
The contents of the hypercall page are ve
Gerd Hoffmann wrote:
Well, xenner doesn't do vmcalls, so the page isn't vendor specific.
Well, for true pv (not pv-on-hvm) it wouldn't use the MSR, would it?
Yes, the MSR is used for pv-on-hvm only.
So it isn't relevant for Xenner?
That said, I'd like to be able to emulate the Xen HVM hype
On 04/20/09 13:27, Avi Kivity wrote:
Gerd Hoffmann wrote:
Well, xenner doesn't do vmcalls, so the page isn't vendor specific.
Well, for true pv (not pv-on-hvm) it wouldn't use the MSR, would it?
Yes, the MSR is used for pv-on-hvm only.
So it isn't relevant for Xenner?
It is. I still pla
Gerd Hoffmann wrote:
That said, I'd like to be able to emulate the Xen HVM hypercalls. But in
any case, they hypercall implementation has to be in the kernel,
No. With Xenner the xen hypercall emulation code lives in guest
address space.
In this case the guest ring-0 code should trap the #G
On 04/20/09 14:43, Avi Kivity wrote:
Gerd Hoffmann wrote:
That said, I'd like to be able to emulate the Xen HVM hypercalls. But in
any case, they hypercall implementation has to be in the kernel,
No. With Xenner the xen hypercall emulation code lives in guest
address space.
In this case the
Gerd Hoffmann wrote:
On 04/20/09 14:43, Avi Kivity wrote:
Gerd Hoffmann wrote:
That said, I'd like to be able to emulate the Xen HVM hypercalls.
But in
any case, they hypercall implementation has to be in the kernel,
No. With Xenner the xen hypercall emulation code lives in guest
address spa
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-a
Anthony Liguori wrote:
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 cp
28 matches
Mail list logo
