All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, X86 ML <x86@kernel.org>,
	kvm list <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH RFC 4/6] KVM: x86: acknowledgment mechanism for async pf page ready notifications
Date: Thu, 30 Apr 2020 08:46:18 +0200	[thread overview]
Message-ID: <2be99d33-7b5d-bf2f-a34f-b841cd5c1936@redhat.com> (raw)
In-Reply-To: <CALCETrWQBmmVODuSXac965o29Oxqo6uo4Ujm2AN2FUMztwCnzA@mail.gmail.com>

On 30/04/20 02:45, Andy Lutomirski wrote:
>> That's a very bad idea since one is synchronous and one is asynchronous.
>>  Part of the proposal we agreed upon was to keep "page not ready"
>> synchronous while making "page ready" an interrupt.  The data structure
>> for "page not ready" will be #VE.
>
> #VE on SVM will be interesting, to say the least, and I think that a
> solution that is VMX specific doesn't make much sense.

You can always inject it manually.  The same is true of Haswell and
earlier processors.

> #VE also has
> unpleasant issues involving the contexts in which it can occur.  You
> will have quite a hard time convincing me to ack the addition of a #VE
> entry handler for this.  I think a brand new vector is the right
> solution.

I need --verbose. :)  For #VE I liked the idea of re-enabling it from an
IPI, at least in the case where we cannot move out of the IST stack.
And any other vector that behaves like an exception would have the same
issue, wouldn't it (especially re-entrancy)?

Paolo


  reply	other threads:[~2020-04-30  6:46 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29  9:36 [PATCH RFC 0/6] KVM: x86: Interrupt-based mechanism for async_pf 'page present' notifications Vitaly Kuznetsov
2020-04-29  9:36 ` [PATCH RFC 1/6] Revert "KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously" Vitaly Kuznetsov
2020-05-05  1:22   ` Gavin Shan
2020-05-05 14:16   ` Vivek Goyal
2020-05-06 15:17     ` Vitaly Kuznetsov
2020-05-11 19:17       ` Vivek Goyal
2020-04-29  9:36 ` [PATCH RFC 2/6] KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info Vitaly Kuznetsov
2020-05-04 23:52   ` Gavin Shan
2020-05-05  8:08     ` Vitaly Kuznetsov
2020-04-29  9:36 ` [PATCH RFC 3/6] KVM: x86: interrupt based APF page-ready event delivery Vitaly Kuznetsov
2020-04-29 10:54   ` Paolo Bonzini
2020-04-29 12:40     ` Vitaly Kuznetsov
2020-04-29 13:21       ` Paolo Bonzini
2020-04-29 21:27   ` Peter Xu
2020-04-30  8:31     ` Vitaly Kuznetsov
2020-04-30 13:28       ` Peter Xu
2020-04-30 13:49         ` Vitaly Kuznetsov
2020-05-05 15:22   ` Vivek Goyal
2020-04-29  9:36 ` [PATCH RFC 4/6] KVM: x86: acknowledgment mechanism for async pf page ready notifications Vitaly Kuznetsov
2020-04-29 17:28   ` Andy Lutomirski
2020-04-29 17:40     ` Paolo Bonzini
2020-04-30  0:45       ` Andy Lutomirski
2020-04-30  6:46         ` Paolo Bonzini [this message]
2020-04-30  6:49   ` Paolo Bonzini
2020-04-30  8:40     ` Vitaly Kuznetsov
2020-04-30  9:27       ` Paolo Bonzini
2020-04-30 11:33         ` Vitaly Kuznetsov
2020-04-30 11:43           ` Paolo Bonzini
2020-05-05  0:36   ` Gavin Shan
2020-05-05  8:16     ` Vitaly Kuznetsov
2020-05-05  8:51       ` Gavin Shan
2020-05-05  9:54         ` Paolo Bonzini
2020-04-29  9:36 ` [PATCH RFC 5/6] KVM: x86: announce KVM_FEATURE_ASYNC_PF_INT Vitaly Kuznetsov
2020-04-29 10:40   ` Peter Zijlstra
2020-04-29  9:36 ` [PATCH RFC 6/6] KVM: x86: Switch KVM guest to using interrupts for page ready APF delivery Vitaly Kuznetsov
2020-04-29 10:53   ` Paolo Bonzini
2020-04-29 12:44     ` Vitaly Kuznetsov
2020-04-29 13:19       ` Paolo Bonzini
2020-04-29 14:34         ` Vitaly Kuznetsov
2020-05-05 18:59     ` Vivek Goyal
2020-05-05  0:42   ` Gavin Shan

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=2be99d33-7b5d-bf2f-a34f-b841cd5c1936@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.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.