[Qemu-devel] kqemu processor feature question

[Qemu-devel] kqemu processor feature question

[Brad Campbell]

G'day all,

I have a disk image here of Win2k-SP4 with AutoCAD installed.
It's a 4G QCOW filesystem. I have burned it on a DVD with QEMU and a few other bits and I carry it 
around with me alongside a Knoppix disk so I always have my CAD system with me wherever I go.

Now this has worked great for a while, until today where I tried to run it on a P-IIIM Laptop.

The system was installed on an AMD Sempron with kqemu, and it *refuses* to boot past the Win2k 
splash screen on the laptop.
It occurs to me that every system I have run it on to date has been an AMD, and I'm wondering as it 
was installed with kqemu, if win2k might use/detect some instruction present on the Althon and then 
depend on it. I can see no other reason for the image refusing to run on a P-III.

I'm in the process of installing another image completely with -no-kqemu to test my theory (but that 
is about 5 hours work), and I thought I'd ask here in addition just in case I'm doing something silly.

I have tried the image with and without kqemu on all machines, and it runs great on any Athlon, but 
refuses to boot on my only Intel box (P-III Laptop).

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu processor feature question

[Francois Rioux]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

As far as I remember, kquemu will work only if all conditions are met, that is if the service can start successfully.
 
I don`t know what the result will be regarding you problem, but you should be able to copy and update your startup batch file on the laptop local disk not to start the service, without reburning everything.
 
HTH.

Brad Campbell <brad@wasp.net.au> wrote:
G'day all,

I have a disk image here of Win2k-SP4 with AutoCAD installed.
It's a 4G QCOW filesystem. I have burned it on a DVD with QEMU and a few other bits and I carry it 
around with me alongside a Knoppix disk so I always have my CAD system with me wherever I go.

Now this has worked great for a while, until today where I tried to run it on a P-IIIM Laptop.

The system was installed on an AMD Sempron with kqemu, and it *refuses* to boot past the Win2k 
splash screen on the laptop.
It occurs to me that every system I have run it on to date has been an AMD, and I'm wondering as it 
was installed with kqemu, if win2k might use/detect some instruction present on the Althon and then 
depend on it. I can see no other reason for the image refusing to run on a P-III.

I'm in the process of installing another image completely with -no-kqemu to test my theory (but that 
is about 5 hours work), and I thought I'd ask here in addition just in case I'm doing something silly.

I have tried the image with and without kqemu on all machines, and it runs great on any Athlon, but 
refuses to boot on my only Intel box (P-III Laptop).

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

		
---------------------------------
 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

[-- Attachment #2: Type: text/html, Size: 2347 bytes --]

Re: [Qemu-devel] kqemu processor feature question

[Brad Campbell]

Francois Rioux wrote:
> As far as I remember, kquemu will work only if all conditions are met, 
> that is if the service can start successfully.
>  
> I don`t know what the result will be regarding you problem, but you 
> should be able to copy and update your startup batch file on the laptop 
> local disk not to start the service, without reburning everything.
>  

Thanks, all my hosts are Linux. My guests are Windows..

After re-installing windows 2000 SP3 & SP4 about 25 times on different machines, its looking wierd..
SP4 has a problem when configuring COM+ with no kqemu, but works fine with kqemu on all 3 machines 
(PIII, Sempron 2400+ Athlon XP 2800+).
Any Win2k SP3 or SP4 image created on the Athlons will not boot on the PIII, but an image created on 
the PIII seems to boot fine on all the machines..
Now to top it off, I have actually used identical qemu binaries on all the machines. Compiled on the 
PIII and copied to the Athlons, in addition to locally compiled copies... I'm using a vanilla qemu 
CVS with the DMA and Concurrent IO Patches. I have yet to remove those patches and try again.. it 
just keeps on getting stranger.

Problem has been worked around by creating the whole image on the laptop. Now it works anywhere, but 
I'm baffled as to why the images created on the Athlons won't boot on the laptop.

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu processor feature question

[John R. Hogerhuis]

On Wed, 2005-10-19 at 00:34 +0400, Brad Campbell wrote:

> After re-installing windows 2000 SP3 & SP4 about 25 times on different machines, its looking wierd..
> SP4 has a problem when configuring COM+ with no kqemu, but works fine with kqemu on all 3 machines 
> (PIII, Sempron 2400+ Athlon XP 2800+).

kqemu avoids emulating instructions, so the instructions run natively.
So, this would seem to imply an issue in the (software) cpu emulation
(that is, in the situation with no kqemu).

It would rule out the system emulation (ancillary hardware) since the
system emulation is the same in both cases w/ and w/out kqemu.

> Any Win2k SP3 or SP4 image created on the Athlons will not boot on the PIII, but an image created on 
> the PIII seems to boot fine on all the machines..

AFAIK qemu doesn't implement Athlon extensions. So this is not
surprising if your theory is true. W/ kqemu would not work since it will
try to run Athlon instructions natively on a Pentium. w/out kqemu would
not work assuming qemu doesn't implement Athlon extensions in the cpu
emulation.

> Now to top it off, I have actually used identical qemu binaries on all the machines. Compiled on the 
> PIII and copied to the Athlons, in addition to locally compiled copies... I'm using a vanilla qemu 
> CVS with the DMA and Concurrent IO Patches. I have yet to remove those patches and try again.. it 
> just keeps on getting stranger.
> 

Strange? I'm not surprised that Athlon-only intructions do not run on
Pentium machines. It would be nice if qemu+kqemu could detect this
circumstance, but you've determined the obvious workaround: install OSes
that optimize themselves for specific x86 variant on install to a
lowest-common-denominator host under kqemu, or on an arbitrary host
under no-kqemu.

> Problem has been worked around by creating the whole image on the laptop. Now it works anywhere, but 
> I'm baffled as to why the images created on the Athlons won't boot on the laptop.
> 

Anyway everything seems to be fitting your theory about Athlon
extensions. It would be nice to catch it in the act of trying to run an
Athlon instruction on a Pentium.

-- John.

Re: [Qemu-devel] kqemu processor feature question

[Brad Campbell]

John R. Hogerhuis wrote:

> Anyway everything seems to be fitting your theory about Athlon
> extensions. It would be nice to catch it in the act of trying to run an
> Athlon instruction on a Pentium.

And it was all a bogus trail.. It's *timer* related!
I made start_rtc_timer() fail (return -1) unconditionally, and voila it boots first time every time, 
and any Image I throw at it..
So something in the win2k loader appears to be timing sensitive. I did try the -win2k-hack for a 
lark, but that only had random results..
So there is an issue with the RTC handler on this machine by the looks..
RTC max freq is 1024, so it's not that.. further debugging required

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

[Qemu-devel] Timing.. was : kqemu processor feature question

[Brad Campbell]

Brad Campbell wrote:
> John R. Hogerhuis wrote:
> 
>> Anyway everything seems to be fitting your theory about Athlon
>> extensions. It would be nice to catch it in the act of trying to run an
>> Athlon instruction on a Pentium.
> 
> And it was all a bogus trail.. It's *timer* related!
> I made start_rtc_timer() fail (return -1) unconditionally, and voila it 
> boots first time every time, and any Image I throw at it..
> So something in the win2k loader appears to be timing sensitive. I did 
> try the -win2k-hack for a lark, but that only had random results..
> So there is an issue with the RTC handler on this machine by the looks..
> RTC max freq is 1024, so it's not that.. further debugging required


There is something bogus happening in cpu_calibrate_ticks() on this machine

When it boots windows ok I get this..

bklaptop:/tracks>qemu -hda w2k.img -m 512 -user-net -localtime -enable-audio
timer: min=450 us max=50188 us avg=2424 us avg_freq=412.523 Hz
timer: min=243 us max=53085 us avg=2435 us avg_freq=410.534 Hz
timer: min=80 us max=24302 us avg=2416 us avg_freq=413.747 Hz
timer: min=20 us max=60886 us avg=2837 us avg_freq=352.417 Hz

When it fails to start I get this..

bklaptop:/tracks>qemu -hda w2k.img -m 512 -user-net -localtime -enable-audio
timer: min=194 us max=226993 us avg=21626 us avg_freq=46.239 Hz
timer: min=646 us max=550679 us avg=21923 us avg_freq=45.613 Hz
timer: min=939 us max=203745 us avg=21966 us avg_freq=45.525 Hz
timer: min=171 us max=540720 us avg=28920 us avg_freq=34.577 Hz
timer: min=4641 us max=80171 us avg=21372 us avg_freq=46.789 Hz

I might start qemu 30 times, and get 1 boot from 30 starts..

If the machine is loaded when I start qemu it will start every time. (while true ; do echo -n . ; 
done) in the shell is enough to load it up..
It *almost* looks like the tsc is stopping while the machine is in hlt state and cpu_calibrate_ticks 
is getting bogus figures somewhere..

This machine has SpeedStep, but according to the info in /sys/devices/system/cpu/cpu0/cpufreq/
It has not changed state since boot and the governor is set to max_freq..

<Cue swimmy visual wipe effect> "Some time later......"

By changing cpu_calibrate_ticks to do something silly and keep busy while waiting instead of 
sleeping, I get dead reliable results every time.. (Yes, it's horridly ugly, I know it's ugly but it 
works here)

void cpu_calibrate_ticks(void)
{
     int64_t usec, ticks;

     usec = get_clock();
     ticks = cpu_get_real_ticks();
#ifdef _WIN32
     Sleep(50);
#else
     while (get_clock()-usec < 50000) {
         get_clock();
     }
#endif
     usec = get_clock() - usec;
     ticks = cpu_get_real_ticks() - ticks;
     ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec;
     printf("Ticks_per_sec = %lld\n",ticks_per_sec);
}

bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
timer: min=90 us max=10628 us avg=994 us avg_freq=1005.900 Hz
timer: min=33 us max=22670 us avg=1003 us avg_freq=996.085 Hz
timer: min=305 us max=2995 us avg=980 us avg_freq=1019.897 Hz
timer: min=220 us max=25093 us avg=1020 us avg_freq=979.883 Hz
timer: min=27 us max=9872 us avg=701 us avg_freq=1425.036 Hz

So it appears to give a much more accurate idea of tics_per_sec. (which is where all my timer 
problems on this laptop are coming from)

For testing I run cpu_calibrate_tics 8 times in the init sequence..
This is just changing the above routine only.. no other machine modification or restart...

Before
bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
Ticks_per_sec = 47720193
Ticks_per_sec = 32508223
Ticks_per_sec = 34422776
Ticks_per_sec = 51535607
Ticks_per_sec = 29776765
Ticks_per_sec = 29481406
Ticks_per_sec = 26230393
Ticks_per_sec = 26133451
Winner - RTC enabled
timer: min=2568 us max=850100 us avg=38857 us avg_freq=25.735 Hz
timer: min=5607 us max=153629 us avg=37663 us avg_freq=26.551 Hz

After
bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
Ticks_per_sec = 999800944
Ticks_per_sec = 999876102
Ticks_per_sec = 999892940
Ticks_per_sec = 999842403
Ticks_per_sec = 999893360
Ticks_per_sec = 999882080
Ticks_per_sec = 999877682
Ticks_per_sec = 999871643
Winner - RTC enabled
timer: min=90 us max=10628 us avg=994 us avg_freq=1005.900 Hz
timer: min=33 us max=22670 us avg=1003 us avg_freq=996.085 Hz

It's got me.. I'm off to try and find the processor datasheet on this PIII-M to check the tsc info..

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] Timing.. was : kqemu processor feature question

[Sven Zenker]

Had the same problem on my SpeedStep machine, am using an ugly patch
currently that replaces the CPU tick based timing with calls to the
realtime clock (see my previous mails on this list). Runs XP as guest
quite reliably under Suse 9.3 (using it every day to run Windows only
software). Performance isn't the best, though, although I'm lacking
comparisons.
-Sven

Am Mittwoch, den 19.10.2005, 10:18 +0400 schrieb Brad Campbell:
> Brad Campbell wrote:
> > John R. Hogerhuis wrote:
> > 
> >> Anyway everything seems to be fitting your theory about Athlon
> >> extensions. It would be nice to catch it in the act of trying to run an
> >> Athlon instruction on a Pentium.
> > 
> > And it was all a bogus trail.. It's *timer* related!
> > I made start_rtc_timer() fail (return -1) unconditionally, and voila it 
> > boots first time every time, and any Image I throw at it..
> > So something in the win2k loader appears to be timing sensitive. I did 
> > try the -win2k-hack for a lark, but that only had random results..
> > So there is an issue with the RTC handler on this machine by the looks..
> > RTC max freq is 1024, so it's not that.. further debugging required
> 
> 
> There is something bogus happening in cpu_calibrate_ticks() on this machine
> 
> When it boots windows ok I get this..
> 
> bklaptop:/tracks>qemu -hda w2k.img -m 512 -user-net -localtime -enable-audio
> timer: min=450 us max=50188 us avg=2424 us avg_freq=412.523 Hz
> timer: min=243 us max=53085 us avg=2435 us avg_freq=410.534 Hz
> timer: min=80 us max=24302 us avg=2416 us avg_freq=413.747 Hz
> timer: min=20 us max=60886 us avg=2837 us avg_freq=352.417 Hz
> 
> When it fails to start I get this..
> 
> bklaptop:/tracks>qemu -hda w2k.img -m 512 -user-net -localtime -enable-audio
> timer: min=194 us max=226993 us avg=21626 us avg_freq=46.239 Hz
> timer: min=646 us max=550679 us avg=21923 us avg_freq=45.613 Hz
> timer: min=939 us max=203745 us avg=21966 us avg_freq=45.525 Hz
> timer: min=171 us max=540720 us avg=28920 us avg_freq=34.577 Hz
> timer: min=4641 us max=80171 us avg=21372 us avg_freq=46.789 Hz
> 
> I might start qemu 30 times, and get 1 boot from 30 starts..
> 
> If the machine is loaded when I start qemu it will start every time. (while true ; do echo -n . ; 
> done) in the shell is enough to load it up..
> It *almost* looks like the tsc is stopping while the machine is in hlt state and cpu_calibrate_ticks 
> is getting bogus figures somewhere..
> 
> This machine has SpeedStep, but according to the info in /sys/devices/system/cpu/cpu0/cpufreq/
> It has not changed state since boot and the governor is set to max_freq..
> 
> <Cue swimmy visual wipe effect> "Some time later......"
> 
> By changing cpu_calibrate_ticks to do something silly and keep busy while waiting instead of 
> sleeping, I get dead reliable results every time.. (Yes, it's horridly ugly, I know it's ugly but it 
> works here)
> 
> void cpu_calibrate_ticks(void)
> {
>      int64_t usec, ticks;
> 
>      usec = get_clock();
>      ticks = cpu_get_real_ticks();
> #ifdef _WIN32
>      Sleep(50);
> #else
>      while (get_clock()-usec < 50000) {
>          get_clock();
>      }
> #endif
>      usec = get_clock() - usec;
>      ticks = cpu_get_real_ticks() - ticks;
>      ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec;
>      printf("Ticks_per_sec = %lld\n",ticks_per_sec);
> }
> 
> bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
> timer: min=90 us max=10628 us avg=994 us avg_freq=1005.900 Hz
> timer: min=33 us max=22670 us avg=1003 us avg_freq=996.085 Hz
> timer: min=305 us max=2995 us avg=980 us avg_freq=1019.897 Hz
> timer: min=220 us max=25093 us avg=1020 us avg_freq=979.883 Hz
> timer: min=27 us max=9872 us avg=701 us avg_freq=1425.036 Hz
> 
> So it appears to give a much more accurate idea of tics_per_sec. (which is where all my timer 
> problems on this laptop are coming from)
> 
> For testing I run cpu_calibrate_tics 8 times in the init sequence..
> This is just changing the above routine only.. no other machine modification or restart...
> 
> Before
> bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
> Ticks_per_sec = 47720193
> Ticks_per_sec = 32508223
> Ticks_per_sec = 34422776
> Ticks_per_sec = 51535607
> Ticks_per_sec = 29776765
> Ticks_per_sec = 29481406
> Ticks_per_sec = 26230393
> Ticks_per_sec = 26133451
> Winner - RTC enabled
> timer: min=2568 us max=850100 us avg=38857 us avg_freq=25.735 Hz
> timer: min=5607 us max=153629 us avg=37663 us avg_freq=26.551 Hz
> 
> After
> bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
> Ticks_per_sec = 999800944
> Ticks_per_sec = 999876102
> Ticks_per_sec = 999892940
> Ticks_per_sec = 999842403
> Ticks_per_sec = 999893360
> Ticks_per_sec = 999882080
> Ticks_per_sec = 999877682
> Ticks_per_sec = 999871643
> Winner - RTC enabled
> timer: min=90 us max=10628 us avg=994 us avg_freq=1005.900 Hz
> timer: min=33 us max=22670 us avg=1003 us avg_freq=996.085 Hz
> 
> It's got me.. I'm off to try and find the processor datasheet on this PIII-M to check the tsc info..
> 
> Regards,
> Brad

Re: [Qemu-devel] kqemu processor feature question

[Emmanuel Pellereau]

Le Mardi 18 Octobre 2005 23:17, Brad Campbell a écrit :
> John R. Hogerhuis wrote:
> And it was all a bogus trail.. It's *timer* related!
> I made start_rtc_timer() fail (return -1) unconditionally, and voila it
> boots first time every time, and any Image I throw at it..
> So something in the win2k loader appears to be timing sensitive. I did try
> the -win2k-hack for a lark, but that only had random results..
> So there is an issue with the RTC handler on this machine by the looks..
> RTC max freq is 1024, so it's not that.. further debugging required

If I remember correctly, issues have been raised in qemu about speedstep 
enabled processors.
Could you could try to turn it off on your PIII-M ?

Keep us informed.

Regards

Emmanuel P.


>
> Regards,
> Brad

Re: [Qemu-devel] kqemu processor feature question

[Brad Campbell]

Emmanuel Pellereau wrote:
> Le Mardi 18 Octobre 2005 23:17, Brad Campbell a écrit :
>> John R. Hogerhuis wrote:
>> And it was all a bogus trail.. It's *timer* related!
>> I made start_rtc_timer() fail (return -1) unconditionally, and voila it
>> boots first time every time, and any Image I throw at it..
>> So something in the win2k loader appears to be timing sensitive. I did try
>> the -win2k-hack for a lark, but that only had random results..
>> So there is an issue with the RTC handler on this machine by the looks..
>> RTC max freq is 1024, so it's not that.. further debugging required
>
> If I remember correctly, issues have been raised in qemu about speedstep
> enabled processors.
> Could you could try to turn it off on your PIII-M ?

It is off.. that is my issue.. Not quite sure what is going on ..
Anyway.. the -no-tsc patch works around my issue, but there is still something wierd going on with
my tsc.

Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu processor feature question

[Jim C. Brown]

On Wed, Oct 19, 2005 at 11:11:43PM +0400, Brad Campbell wrote:
> It is off.. that is my issue.. Not quite sure what is going on ..
> Anyway.. the -no-tsc patch works around my issue, but there is still 
> something wierd going on with
> my tsc.
> 
> Regards,
> Brad
> --
> "Human beings, who are almost unique in having the ability
> to learn from the experience of others, are also remarkable
> for their apparent disinclination to do so." -- Douglas Adams

qemu uses an unreliable timesource, the rdtsc instruction. That works most of
the time but is not a good idea when CPU usage varies a lot. I'm not suprised
at the difference across cpus either.

I'm not sure if kqemu has an effect on this or not (but if it does, kernel code
would probably have slower ticks that user mode code).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.