All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Philipp Hahn <hahn@univention.de>
Cc: Laszlo Ersek <lersek@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFH: difference in read-only mapped bios.bin - memory corruption?
Date: Fri, 18 Aug 2017 09:59:09 +0100	[thread overview]
Message-ID: <20170818085908.GB2222@work-vm> (raw)
In-Reply-To: <410b3398-470f-4434-7488-890054b4921b@univention.de>

* Philipp Hahn (hahn@univention.de) wrote:
> Hello,
> 
> Am 15.08.2017 um 13:25 schrieb Laszlo Ersek:
> > On 08/14/17 20:39, Dr. David Alan Gilbert wrote:
> >> * Philipp Hahn (hahn@univention.de) wrote:
> >>> I'm currently investigating a problem, were a Linux VM does not reboot
> >>> and gets stuck in the SeaBIOS reboot code:
> >>>
> >>> I'm using SeaBIOS-1.7 from Debian with a more modern qemu-2.8
> ...>>> If I dump both regions and compare them, I get a difference:
> ...>> You might want seabios commit c68aff5 and b837e6 that got fixed after
> >> I tracked down some reboot hangs - although they were rare, not every
> >> time.  c68aff5 did certainly cause a corruption, and the address of that
> >> corruption was determined at link time and could overlay random useful
> >> bits of code if you were unlucky.
> 
> Thanks you for the commit IDs - to me this looks like they fixed the
> problem. Testing with seabios-1.10 does not show any reboot problem so far.
> 
> >>> 1. How can it be, that the low-mem ROM mapping is modified?
> >>
> >> I can't remember all the details, but PC ROM is shadowed and mapped over
> >> with RAM at various times,
> > 
> > Right. I don't remember for sure, but I believe the state of the PAM
> > registers doesn't only affect what the VCPUs see in that address range,
> > but also what your monitor commands will dump. (This would be the
> > logical choice -- make the monitor output what the VCPUs see anyway, at
> > the moment, dependent on the PAM settings.)
> 
> That makes sense.
> Do you know by change what change in Qemu triggered that bug, as I've
> never seen any reboot problem with qemu-1.1.2, but only since switching
> to qemu-2.8?

I didn't go back as far as 1.1.2, but I tried bisecting around 2.4/2.6
before I understood the failure and the bisect was very flaky;  I think
in the end it's a timing race where it comes down to the exact corrupt
value;  going back to ancient qemu might be taking some other path
through seabios but I ddin't investigate.

Dave

> Thanks again for your excellent help.
> 
> Philipp
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

      reply	other threads:[~2017-08-18  8:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14 14:28 [Qemu-devel] RFH: difference in read-only mapped bios.bin - memory corruption? Philipp Hahn
2017-08-14 18:39 ` Dr. David Alan Gilbert
2017-08-15 11:25   ` Laszlo Ersek
2017-08-18  8:41     ` Philipp Hahn
2017-08-18  8:59       ` Dr. David Alan Gilbert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170818085908.GB2222@work-vm \
    --to=dgilbert@redhat.com \
    --cc=hahn@univention.de \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.