On Tue, Aug 15, 2017 at 05:54:34PM +0200, Stefan Fritsch wrote:
> On Tue, 15 Aug 2017, Mike Larkin wrote:
> 
> > On Tue, Aug 15, 2017 at 08:46:59AM -0700, Mike Larkin wrote:
> > > On Tue, Aug 15, 2017 at 05:39:29PM +0200, Stefan Fritsch wrote:
> > > > I have got a report that openbsd panics on boot with qemu -cpu 
> > > > Opteron_G3 
> > > > (but Opteron_G2 works).
> > > > 
> > > >     kernel: protection fault trap, code=0
> > > >     Stopped at      amd64_errata_setmsr+0x14:       rdmsr
> > > >     ddb{0}> >> OpenBSD/amd64 BOOT 3.33
> > > >     boot>
> > > > 
> > > > Qemu does not implement all the secret errata MSRs. Does it make sense 
> > > > to 
> > > > simply skip all errata processing if we detect a hypervisor?
> > > > 
> > > > 
> > > > diff --git a/sys/arch/amd64/amd64/identcpu.c 
> > > > b/sys/arch/amd64/amd64/identcpu.c
> > > > index a448b885ba7..371c0c8ff48 100644
> > > > --- a/sys/arch/amd64/amd64/identcpu.c
> > > > +++ b/sys/arch/amd64/amd64/identcpu.c
> > > > @@ -708,7 +708,7 @@ identifycpu(struct cpu_info *ci)
> > > >         }
> > > >  #endif
> > > >  
> > > > -       if (!strcmp(cpu_vendor, "AuthenticAMD"))
> > > > +       if (!strcmp(cpu_vendor, "AuthenticAMD") && 
> > > > !ISSET(cpu_ecxfeature, CPUIDECX_HV))
> > > >                 amd64_errata(ci);
> > > >  
> > > >         if (CPU_IS_PRIMARY(ci) && !strcmp(cpu_vendor, "CentaurHauls")) {
> > > > 
> > > 
> > > I think this is an upstream bug. If they claim to emulate a G3 Opteron, 
> > > they
> > > should be faithfully emulating it.
> 
> True. But I could imagine that this is difficult if there is no hint that 
> a specific MSR exists until AMD releases an erratum that uses it as a 
> work-around. At the very least, there will be old qemu/kvm versions around 
> that don't implement it, yet. Not sure if that is the problem, here, 
> though.
> 
> > Also, is this only an error in TCG?
> 
> The panic above is from qemu+kvm+linux. Not sure what happens with TCG.

I'm still not convinced we should be working around this. It can be fixed by
a 1 character change to the user's launch script/profile (G3->2) and unless
there is evidence we are applying the errata incorrectly, we should press
upstream to fix it. "But what about old kvm" doesn't really make a convincing
argument. We could be saying "but what about VMware workstation from 1999",
too. Should we be working around their bugs also?

-ml

Reply via email to