On 11/09/2011 12:39 PM, Avi Kivity wrote:
> > More from misc@xxxxxxxxxxx:
> > > OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011
> > > deraadt@xxxxxxxxxxxxxxxx:/usr/src/sys/arch/i386/compile/GENERIC
> > > cpu0: AMD Phenom(tm) II X6 1100T Processor ("AuthenticAMD" 686-class, 512KB L2 cache) 3.31 GHz
> > > ...
> > > kernel: protection fault trap, code=0
> > > Stopped at k1x_init+0x56: rdmsr
> > > k1x_init(d0ad7540,d09ae620,d0b8ce58,d059ce20,30000002) at k1x_init+0x56
> >
> > k1x_init() is not related to vmt, it is from k1x-pstate.c, which
> > is cpu power state driver for K10 processors.
> >
> > Thread on misc@xxxxxxxxxxx with full OpenBSD dmesg:
> > http://marc.info/?l=openbsd-misc&m=132067866208188&w=2
> >
> > Since both qemu-kvm 0.14.1 and 0.15.1 show identical
> > symptoms, I assume this is in deed a KVM kernel bug.
>
> It doesn't actually follow, but happens to be correct.
>
> > Can somebody reproduce this?
>
> I'll try it out and see.
>
Actually, it looks like an OpenBSD bug. According to the AMD documentation:
"The current P-state value can be read using the P-State Status
Register. The P-State Current Limit
Register and the P-State Status Register are read-only registers. Writes
to these registers cause a #GP
exception. Support for hardware P-state control is indicated by EDX bit
7 as returned by CPUID
function 8000_0007h. Figure 18-1 shows the format of the P-State Current
Limit register."
Can you check what cpuid 80000007 returns by running 'x86info -r | grep
80000007' in a Linux guest with the same command line? if edx returns
zero, then it's OpenBSD not checking cpuid correctly.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
