All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Liran Alon <liran.alon@oracle.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org, jmattson@google.com,
	wanpeng.li@hotmail.com, idan.brown@oracle.com,
	Krish Sadhukhan <krish.sadhukhan@oracle.com>
Subject: Re: [PATCH v2 3/8] KVM: x86: set/get_events ioctl should consider only injected exceptions
Date: Wed, 22 Nov 2017 21:25:04 +0100	[thread overview]
Message-ID: <20171122202503.GB21279@flask> (raw)
In-Reply-To: <1511278211-12257-4-git-send-email-liran.alon@oracle.com>

2017-11-21 17:30+0200, Liran Alon:
> Do not consider pending exception when return injected exception
> to user-mode. A "pending" exception means it's side-effect have not
> been applied yet. In contrast, an "injected" exception means it's
> side-effect have been already applied.
> Therefore, we only need to report of injected exceptions to user-mode.
> This is aligned with how interrupts are reported in same ioctl.

Pending interrupts are stored in IRR, but we don't have anything for
exceptions -- we would lose a trap exception that was made pending after
handling inject_pending_event() if the VCPU got a userspace signal and
save+restored before starting the next vcpu_enter_guest() cycle.
(Non-trap exceptions should be generated again when re-executing, so
 losing them isn't that bad.)

I think we should add state for pending exceptions in kvm_vcpu_events,
like the FIXME says.  Pending and injected are actually exclusive (for
now?), so maybe we can use only one bit for that,

thanks.

An alternative, probably unattainable, would be to process the
side-effects as we hit the exception.  Using IRR to store pending
interrupts also seems possible, but I'd expect more problems down the
road.

  reply	other threads:[~2017-11-22 20:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21 15:30 [PATCH v2 0/8] KVM: Fix multiple issues in handling pending/injected events Liran Alon
2017-11-21 15:30 ` [PATCH v2 1/8] KVM: VMX: No need to clear pending NMI/interrupt on inject realmode interrupt Liran Alon
2017-12-01 23:45   ` Jim Mattson
2017-12-02  0:19     ` Liran Alon
2017-11-21 15:30 ` [PATCH v2 2/8] KVM: x86: Rename interrupt.pending to interrupt.injected Liran Alon
2017-11-28 17:02   ` Jim Mattson
2017-11-21 15:30 ` [PATCH v2 3/8] KVM: x86: set/get_events ioctl should consider only injected exceptions Liran Alon
2017-11-22 20:25   ` Radim Krčmář [this message]
2017-11-23 18:20     ` Liran Alon
2017-11-22 21:00   ` Jim Mattson
2017-11-23 18:45     ` Liran Alon
2017-11-23 23:05       ` Paolo Bonzini
2017-11-27 17:26       ` Jim Mattson
2017-11-27 18:30         ` Liran Alon
2017-11-21 15:30 ` [PATCH v2 4/8] KVM: x86: Warn if userspace overrides existing injected exception/interrupt Liran Alon
2017-11-22 20:34   ` Radim Krčmář
2017-11-22 22:27     ` Liran Alon
2017-11-21 15:30 ` [PATCH v2 5/8] Revert "kvm: nVMX: Disallow userspace-injected exceptions in guest mode" Liran Alon
2017-11-21 15:30 ` [PATCH v2 6/8] KVM: x86: Fix misleading comments on handling pending exceptions Liran Alon
2017-11-21 15:30 ` [PATCH v2 7/8] KVM: nVMX: Require immediate-exit when event reinjected to L2 and L1 event pending Liran Alon
2017-11-27 20:48   ` Jim Mattson
2017-11-27 22:42     ` Liran Alon
2017-11-28  4:55       ` Jim Mattson
2017-11-28 11:14         ` Paolo Bonzini
2017-11-28 13:59           ` Liran Alon
2017-11-28 11:36         ` Liran Alon
2017-11-28  6:39   ` Jim Mattson
2017-11-28 18:26     ` Jim Mattson
2017-11-28 19:45       ` Liran Alon
2017-11-28 21:04         ` Jim Mattson
2017-11-28 19:33     ` Liran Alon
2017-11-21 15:30 ` [PATCH v2 8/8] KVM: nVMX: Optimization: Dont set KVM_REQ_EVENT when VMExit with nested_run_pending Liran Alon

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=20171122202503.GB21279@flask \
    --to=rkrcmar@redhat.com \
    --cc=idan.brown@oracle.com \
    --cc=jmattson@google.com \
    --cc=krish.sadhukhan@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=wanpeng.li@hotmail.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.