All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] KVM: SVM: Make stepping out of NMI handlers more robust
Date: Tue, 16 Feb 2010 10:14:56 +0100	[thread overview]
Message-ID: <4B7A6210.5060606@siemens.com> (raw)
In-Reply-To: <20100216080436.GX2995@redhat.com>

Gleb Natapov wrote:
> On Mon, Feb 15, 2010 at 07:17:18PM +0100, Jan Kiszka wrote:
>> As there is no interception on AMD on the end of an NMI handler but only
>> on its iret, we are forced to step out by setting TF in rflags. This can
>> collide with host or guest using single-step mode, and it may leak the
>> flags onto the guest stack if IRET triggers some exception.
> The code is trying to handle the case where debugger used TF flags and we
> want to single step from NMI handler simultaneously. Do you see problem with
> that code? Uf yes may be it sill be much simpler to fix it? TF leakage is real,
> but what problem it may cause? Note that your patch does not solve this problem
> too. See the comment that you've deleted:
> 	/* Something prevents NMI from been injected. Single step over
> 	   possible problem (IRET or exception injection or interrupt
> 	   shadow) */
> So the reason for single step is not necessary IRET, _any_ exception
> is possible at this point.

That is exactly what my code tries to avoid: Exceptions are all (famous
last word) caught, and single-stepping is disabled until that is
resolved. So no more leakage, and only IRET remains as reason here (thus
my deletion).

> 
>> This patch addresses the TF leakage by trapping all exceptions that may
>> show up on IRET execution and cleaning up the state again before
>> reinjecting the exception. Collisions with concurrent users are avoided
>> by carefully checking for their presence and forwarding #DB exceptions
>> whenever required.
> This patch is scary to apply without test cases.

Do you have one for the exception case? The others should have been
covered manually here, but I agree we should write a unit test, also for
the sake of VMX.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2010-02-16  9:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15 18:17 [PATCH 0/2] KVM: SVM improvements around INT3 and NMI Jan Kiszka
2010-02-15 18:17 ` [PATCH 1/2] KVM: SVM: Emulate nRIP feature when reinjecting INT3 Jan Kiszka
2010-02-16  7:52   ` Gleb Natapov
2010-02-16  8:02     ` Jan Kiszka
2010-02-16  9:50   ` [PATCH v2 " Jan Kiszka
2010-02-15 18:17 ` [PATCH 2/2] KVM: SVM: Make stepping out of NMI handlers more robust Jan Kiszka
2010-02-16  8:04   ` Gleb Natapov
2010-02-16  9:14     ` Jan Kiszka [this message]
2010-02-16  9:34       ` Gleb Natapov
2010-02-16  9:45         ` Jan Kiszka
2010-02-16  9:49           ` Gleb Natapov
2010-02-16 10:05             ` Jan Kiszka
2010-02-16 10:08               ` Gleb Natapov
2010-02-17 13:49                 ` Gleb Natapov
2010-02-17 19:16                   ` Jan Kiszka
2010-02-18  7:52                     ` Gleb Natapov

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=4B7A6210.5060606@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.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.