From: Avi Kivity <avi@qumranet.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: "Yang, Sheng" <sheng.yang@intel.com>, kvm-devel <kvm@vger.kernel.org>
Subject: Re: VMX: NMI injection without virtual NMI support
Date: Sat, 13 Sep 2008 11:58:33 +0300 [thread overview]
Message-ID: <48CB80B9.10201@qumranet.com> (raw)
In-Reply-To: <48CB5D3E.1000505@web.de>
Jan Kiszka wrote:
>> In some cases misbehaving NMIs are worse than no NMIs. For example, a
>> software watchdog may use NMIs to monitor a system. But if the guest
>> spins with interrupts disabled, the irq window will never open, and NMIs
>> will never be delivered, so the watchdog will deliver a false negative.
>>
>>
>
> I fail to see the regression. Currently that watchdog would _always_
> deliver false positives and pull the trigger immediately (in fact, this
> is precisely the situation we face @work with some special board
> emulation where we have to provide an NMI-based watchdog).
>
>
Linux checks whether nmi works and enables it only if it does (I think
-- not sure). So for Linux, there would be a regression.
> Moreover, only the second and succeeding NMIs under the same
> interrupts-disabled window need to get lost: Along with injecting the
> first NMI we could request the IRQ window unconditionally, using it to
> reset the virtual NMI-blocked state.
>
But the interrupt window would never open. Consider a spin_lock()
executing with interrupts disabled, on a spin lock that is already
locked by the current cpu.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
prev parent reply other threads:[~2008-09-13 9:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-11 15:11 VMX: NMI injection without virtual NMI support Jan Kiszka
2008-09-12 6:29 ` Yang, Sheng
2008-09-12 8:34 ` Jan Kiszka
2008-09-13 5:14 ` Avi Kivity
2008-09-13 6:27 ` Jan Kiszka
2008-09-13 8:58 ` Avi Kivity [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=48CB80B9.10201@qumranet.com \
--to=avi@qumranet.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=sheng.yang@intel.com \
/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.