qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Artyom Tarasenko <atar4qemu@googlemail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] NMI handling
Date: Mon, 21 Jun 2010 20:20:35 +0200	[thread overview]
Message-ID: <AANLkTils0SaGZqE6HTInrzWFX85Z1awfphLbHmPWwENl@mail.gmail.com> (raw)

2010/5/25 Blue Swirl <blauwirbel@gmail.com>:
>>> About bugs, IIRC NetBSD 3.x crash could be related to IOMMU.
>>
>> What does indicate it? It happens where the disk sizes are normally
>> reported, so it could be a scsi/dma/irq/fpu issue as well.
>
> IIRC the DVMA address was 0xfc004000, but the mapped entries were for
> 0xfc000000 to 0xfc003fff.

Hmm. It happens in all NetBSD versions from 1.6 to 3.1 inclusive.
Which is probably a sign that the problem resides in qemu and not in
NetBSD.

It looks like we have multiple problems here: they start with
0xfc004000 access (which can theoretically be expected on the real
hardware too) as you pointed out, but what happens afterwards is
strange too:

- In the current qemu implementation we have a screaming NMI which
NetBSD can not clear. This happens cause NMI in qemu is literally
non-maskable, while on the real hardware it can be masked with the
'mask all' flag. I'll send a patch for it.

- with the masking patch, the NMI is not screaming but still is
percepted as spurious. This may be ok if NetBSD (1.6-3.1) doesn't have
a moduleerr_handler set. I don't see it set, although there is a
moduleerr_handler variable is defined. Would be nice if someone with
NetBSD kernel knowledge would comment on this.

- the current implementation of NMI pending clearing in qemu may be
incomplete: if the source is not cleared, the pending NMI bit can be
set right after the user wrote to the clear pending register. If I
read the page 39 of the Sun4m System Architecture correctly, the
points (2) and (6) suggest that once pending NMI is cleared in a CPU,
the CPU doesn't see the NMI till the next one comes. Whereas it makes
sense, specially in SMP configurations, I don't see how is it
level-sensitive in this case. If 'another broadcast' means a new
external event, the NMI behavior seems mixed: turned on by edge, and
off by level. But the documentation says 'level-sensitive' everywhere.
Ideas?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

             reply	other threads:[~2010-06-21 18:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-21 18:20 Artyom Tarasenko [this message]
2010-07-26 16:53 ` [Qemu-devel] Re: NMI handling Artyom Tarasenko
2010-07-26 17:57   ` Blue Swirl

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=AANLkTils0SaGZqE6HTInrzWFX85Z1awfphLbHmPWwENl@mail.gmail.com \
    --to=atar4qemu@googlemail.com \
    --cc=blauwirbel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).