qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] problems with freeBSD


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [SeaBIOS] problems with freeBSD
Date: Fri, 08 Mar 2013 12:30:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130216 Thunderbird/17.0.3

On 03/08/13 04:35, Kevin O'Connor wrote:
> On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
>> On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
>>> That change is definitely just build related - I don't see how it
>>> could impact the final SeaBIOS binary.  How did you conclude that this
>>> commit is what fixes the issue?
>>>
>>
>> I did a git bisect to find the commit fixing the issue. Then, as I was
>> not believing the result, I tried the following sequence a dozen of
>> times (for some unknown reasons the FreeBSD install CD doesn't exhibit
>> the issue, so I used the Debian GNU/kFreeBSD installer):
> [...]
> 
> Thanks for the detailed bug report.  Here's what I see going on:
> 
> - the SeaBIOS 4219149a commit does change the resulting binary ever so
>   slightly - the src/virtio_ring.c code has a reference to __FILE__
>   (the only code in SeaBIOS that does that), and due to slightly
>   different build rules in this commit it evaluates to a slightly
>   different string.
> 
> - the freebsd crash has nothing to do with 4219149a or
>   src/virtio_ring.c - instead, random changes in the seabios binary
>   layout can cause (or avoid) the crash.  You can see this in action
>   by modifying seabios to have higher debug levels, commenting out
>   code, adding dprintf statements, etc.
> 
> - the crash happens when freebsd attempts to emulate the bios code (!)
>   in order to determine the keyboard typematic rate (!).  (See
>   sys/dev/atkbdc/atkbd.c.) Since SeaBIOS doesn't support the typematic
>   callback rate (int 0x16 ax=0x0306) this doesn't actually achieve
>   anything in practice were the call to not crash.  However, a crash
>   does (sometimes) result.
> 
> - the freebsd x86bios_get_pages() code is buggy (See
>   sys/compat/x86bios/x86bios.c).  It attempts to check that its x86
>   emulater (!) doesn't access a page it hasn't mapped.  However, it
>   does not check for the case where a two byte access spans two pages.
>   If the first page is mapped, but the second is not - splat.  The
>   crash I've seen in QEMU had a two byte access to 0xffffff8000015fff
>   with the fault at 0xffffff8000016000.
> 
> - I have not been able to determine why an attempt was made to access
>   a non-mapped page.  My best guess is that the x86emu code (!) goes
>   off the deep-end in all cases - just some cases lead it to the bug
>   above and other cases lead it to a more friendly termination.
>   (Recall that SeaBIOS doesn't support the typematic call anyway.)  It
>   should be possible to track this down by adding debug statements to
>   the freebsd code if anyone is familiar with the freebsd kernel
>   compile-deploy-run cycle.

Great analysis!

Laszlo
(sorry for the noise)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]