Re: [Qemu-devel] Re: Breakage with local APIC routing

[Juergen Lock]

On Mon, Aug 31, 2009 at 11:27:23PM +0200, Juergen Lock wrote:
> On Mon, Aug 31, 2009 at 09:47:27AM +0200, Jan Kiszka wrote:
> > Juergen Lock wrote:
> > > On Thu, Aug 27, 2009 at 07:56:41PM +0200, Jan Kiszka wrote:
> > >> Juergen Lock wrote:
> > >>> On Tue, Aug 25, 2009 at 12:38:04PM +0200, Jan Kiszka wrote:
> > >>>> Mohammed Gamal wrote:
> > >>>>> On Tue, Aug 25, 2009 at 1:16 PM, Mohammed Gamal<address@hidden> wrote:
> > >>>>>> On Tue, Aug 25, 2009 at 12:33 PM, Jan Kiszka<address@hidden> wrote:
> > >>>>>>> Mohammed Gamal wrote:
> > >>>>>>>> qemu-system-x86_64 -hda /dev/null -cdrom <path_to_ubuntu_iso_image>
> > >>>>>>>>
> > >>>>>>> I only have kubuntu-9.04-alternate-amd64.iso at hand ATM, and with 
> > >>>>>>> that
> > >>>>>>> image I'm unable to reproduce. Will download and check standard 
> > >>>>>>> ubuntu
> > >>>>>>> later today.
> > >>>>>>>
> > >>>>>>>> I was using qemu-kvm, but I assume that using -no-kvm would be
> > >>>>>>>> equivalent to using plain qemu, no?
> > >>>>>>> Generally yes, but not necessarily (e.g. the BIOSes are different). 
> > >>>>>>> So
> > >>>>>>> it's better to check such issues also against "clean" qemu, 
> > >>>>>>> specifically
> > >>>>>>> as we are on qemu-devel here.
> > >>>>>>>
> > >>>>>>> Jan
> > >>>>>>>
> > >>>>>>>
> > >>>>>> Just tested this now on a vanilla qemu, I am still able to reproduce
> > >>>>>> the same issue.
> > >>>>>>
> > >>>>> This bug might be related to the same problem
> > >>>>> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/379000
> > >>>> I think at least those issues should be solved with recent qemu and
> > >>>> bioses. Note that this report refers to a fairly old qemu version
> > >>>> (0.10.0-derived).
> > >>> Btw I had reported the same symptom as in that ubuntu ticket for 
> > >>> FreeBSD 8
> > >>> hosts both with 0.10.6 and 0.11.0rc1 before:
> > >>>         
> > >>> http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg00396.html
> > >>> As mentioned in that post I was able to work around the issue by passig
> > >>> the linux guest kernels `no_timer_check' after which they seemed to 
> > >>> boot up
> > >>> just fine, so I suspect in that case its not actually an apic routing
> > >>> problem but just guest timer irqs arriving late/irregularly which cause
> > >>> the guest kernel timer checks to time out and fail.
> > >> Does this happen with git head and its corresponding bios, too? I cannot
> > >> imagine that the FreeBSD platform is so irregularly generating timer
> > >> events for qemu that Linux gets unhappy during this test loop (I think
> > >> to remember it needs 3 out of 10 ticks or so to be satisfied).
> > > 
> > > Alright so I testwise updated the FreeBSD qemu-devel port to git head
> > > (db3c9e08e0d6eaf83f9d7a2c87dc45af3ac8f4dd, update at
> > >   http://people.freebsd.org/~nox/qemu/qemu-devel-20090829.patch
> > 
> > You will have to help me isolating the reason as I don't have any BSD
> > host. And running recent qemu/-kvm on Linux hosts does not trigger
> > problems around booting ubuntu here.
> 
> Well I don't quite know where to start looking, of course I'd be
> happy to test patches... :)

Ok I now found the #if 0 in vl.c:host_alarm_handler(), enabled it and got
this with a FreeBSD 7.2 iso (which defaults to HZ=1000) and -clock dynticks:

timer: min=2555 us max=32004 us avg=5150 us avg_freq=194.149 Hz
timer: min=2451 us max=7205 us avg=3012 us avg_freq=331.960 Hz
timer: min=2855 us max=7994 us avg=3019 us avg_freq=331.191 Hz
timer: min=2099 us max=20003 us avg=3057 us avg_freq=327.073 Hz
timer: min=2143 us max=11897 us avg=3081 us avg_freq=324.527 Hz
timer: min=2110 us max=80014 us avg=3165 us avg_freq=315.913 Hz
timer: min=2088 us max=51999 us avg=3206 us avg_freq=311.873 Hz

and this with the same guest and -clock unix:

timer: min=1614 us max=7121 us avg=2009 us avg_freq=497.692 Hz
timer: min=876 us max=11134 us avg=2016 us avg_freq=495.967 Hz
timer: min=753 us max=9245 us avg=2014 us avg_freq=496.455 Hz
timer: min=1798 us max=6211 us avg=2008 us avg_freq=497.941 Hz
timer: min=1772 us max=6142 us avg=2008 us avg_freq=497.943 Hz
timer: min=1767 us max=6157 us avg=2008 us avg_freq=497.942 Hz
timer: min=14 us max=6139 us avg=2008 us avg_freq=497.939 Hz
timer: min=736 us max=9969 us avg=2016 us avg_freq=495.962 Hz
timer: min=176 us max=11427 us avg=2076 us avg_freq=481.631 Hz
timer: min=229 us max=9827 us avg=2030 us avg_freq=492.546 Hz
timer: min=430 us max=11082 us avg=2078 us avg_freq=481.166 Hz
timer: min=226 us max=9871 us avg=2026 us avg_freq=493.517 Hz
timer: min=605 us max=10829 us avg=2082 us avg_freq=480.243 Hz
timer: min=57 us max=10976 us avg=2028 us avg_freq=493.031 Hz
timer: min=398 us max=11036 us avg=2080 us avg_freq=480.704 Hz

 `vmstat -i' in the guest (available e.g. from the fixit->cdrom/dvd shell
on a livefs or dvd1 iso) gives similar values as avg_freq above for the
`cpu0: timer' irq rate.  (Btw, FreeBSD 8 reduces its HZ to 100 when
running in a vm so the `vmstat -i' values will be a little lower if you
try that as a guest.)

 And `vmstat -i' on the host (also running with HZ=1000) reports a
rate of 1999 for each cpu's timer irq, so there are clearly quite a few
irqs missing there...

 (Btw I'm wondering if the poor usb performance I reported a long time
ago already could be related to this also...)

        Juergen