public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Roman Kagan <rkagan@virtuozzo.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	kvm@vger.kernel.org, "Denis Lunev" <den@virtuozzo.com>
Subject: Re: [PATCH 5/5] kvm/svm: kick L2 guest to L1 by ready async_pf
Date: Fri, 2 Dec 2016 15:33:03 +0300	[thread overview]
Message-ID: <20161202123302.GD18706@rkaganb.sw.ru> (raw)
In-Reply-To: <788012052.1167895.1480671324974.JavaMail.zimbra@redhat.com>

On Fri, Dec 02, 2016 at 04:35:24AM -0500, Paolo Bonzini wrote:
> 
> 
> ----- Original Message -----
> > From: "Roman Kagan" <rkagan@virtuozzo.com>
> > To: "Radim Krčmář" <rkrcmar@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>, kvm@vger.kernel.org
> > Cc: "Denis Lunev" <den@virtuozzo.com>, "Roman Kagan" <rkagan@virtuozzo.com>
> > Sent: Friday, December 2, 2016 9:47:54 AM
> > Subject: [PATCH 5/5] kvm/svm: kick L2 guest to L1 by ready async_pf
> > 
> > When async pagefault is resolved vCPU may be executing L2 guest.
> > 
> > In order to allow L1 take better scheduling decisions in such cases,
> > make L2 exit to L1 on a fake external interupt, without actually
> > injecting it (unless L2 has other reasons to vmexit).
> > 
> > This patch does that for x86/AMD.
> > 
> > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
> > ---
> > Note 1: I didn't have a chance to test this; I'll do when I get access to an
> > AMD machine and let you know if anything goes wrong
> > 
> > Note 2: I mostly modelled this patch after the one for vmx but is looks not
> > very appealing for svm.  I'd appreciate being pointed at a better location
> > where to stick the fake external interrupt vmexit.
> 
> This should not be necessary, SVM has a different mechanism (which
> requires L1 cooperation) to handle async page faults.

Hmm, I didn't realize that...  I'm afraid we have a problem then: my
patch that triggered all this, "kvm/x86: skip async_pf when in guest
mode", makes async_pf's not delivered if the vcpu is executing L2 on
all x86, so that mechanism will stop working.

I'm also curious what L1 cooperation is assumed here.  E.g. would L1
running linux (which would set up async_pf) and a non-KVM hypervisor
cooperate as expected?  Looks like I need another dive into svm.c...

Roman.

  reply	other threads:[~2016-12-02 12:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  8:47 [PATCH 0/5] kvm: avoid delaying async_pf ready delivery Roman Kagan
2016-12-02  8:47 ` [PATCH 1/5] kvm/x86: fix inversed check for async_pf MSR Roman Kagan
2016-12-02  8:47 ` [PATCH 2/5] kvm: add helper for testing ready async_pf's Roman Kagan
2016-12-02  8:47 ` [PATCH 3/5] kvm: kick vcpu when async_pf is resolved Roman Kagan
2016-12-02  9:35   ` Christian Borntraeger
2016-12-02  9:40     ` Paolo Bonzini
2016-12-02 10:00       ` Christian Borntraeger
2016-12-02 11:34         ` Roman Kagan
2016-12-05  8:08           ` Christian Borntraeger
2016-12-02 11:28     ` Roman Kagan
2016-12-03  4:02   ` kbuild test robot
2016-12-06 11:05   ` kbuild test robot
2016-12-02  8:47 ` [PATCH 4/5] kvm/vmx: kick L2 guest to L1 by ready async_pf Roman Kagan
2016-12-02  8:47 ` [PATCH 5/5] kvm/svm: " Roman Kagan
2016-12-02  9:35   ` Paolo Bonzini
2016-12-02 12:33     ` Roman Kagan [this message]
2016-12-12 12:40       ` Roman Kagan

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=20161202123302.GD18706@rkaganb.sw.ru \
    --to=rkagan@virtuozzo.com \
    --cc=den@virtuozzo.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox