Re: port-amd64/47967: DTrace does not work while running under QEMU

[Jeff Rizzo <riz%NetBSD.org@localhost>]

The following reply was made to PR port-amd64/47967; it has been noted by GNATS.

From: Jeff Rizzo <riz%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-amd64/47967: DTrace does not work while running under QEMU
Date: Wed, 26 Jun 2013 11:00:18 -0700

 On 6/26/13 10:50 AM, Jukka Ruohonen wrote:
 > The following reply was made to PR port-amd64/47967; it has been noted by 
 > GNATS.
 >
 >   On Wed, Jun 26, 2013 at 05:35:00PM +0000, riz%NetBSD.org@localhost wrote:
 >   > +       if (memcmp("QEMU Virtual CPU", cpu_brand_string, 16) != 0)
 >   > +               return;
 >   
 >   Wouldn't it be better to patch Qemu? Vague string matching in the kernel
 >   does not seem like a good approach. As our test setup shows, trying match
 >   Qemu is a bog...
 >
 
 Patch QEMU to do what, exactly?  Implement MSR_TSC?  Sure - if you want 
 to dig into QEMU and do that, go ahead, but this is a workaround for a 
 known problem in a known "cpu".  The brand string also includes a 
 version number, should qemu ever fix this issue, so it will be possible 
 to support multiple versions. It doesn't seem to me to be any different 
 from any other CPU we work around in that file.
 
 My only concern was, does turning off CPUID_MSR have any other side 
 effects that I'm missing, and should we be using a different test 
 altogether?