public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: pbonzini@redhat.com (Paolo Bonzini)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] KVM: Only register preempt notifiers and load arch cpu state as needed
Date: Thu, 23 Nov 2017 18:12:41 +0100	[thread overview]
Message-ID: <62ae4eb1-fd57-c525-cd73-e3f646d340e1@redhat.com> (raw)
In-Reply-To: <20171123170642.GA28855@cbox>

On 23/11/2017 18:06, Christoffer Dall wrote:
> On Thu, Nov 23, 2017 at 05:17:00PM +0100, Paolo Bonzini wrote:
>> On 23/11/2017 17:05, Christoffer Dall wrote:
>>> For example,
>>> arm64 is about to do significant work in vcpu load/put when running a
>>> vcpu, but not when doing things like KVM_SET_ONE_REG or
>>> KVM_SET_MP_STATE.
>>
>> Out of curiosity, in what circumstances are these ioctls a hot path?
>> Especially KVM_SET_MP_STATE.
> 
> Perhaps my commit message was misleading; we only want to do that for
> KVM_RUN, and not for anything else.  We're already doing things like
> potentially jumping to hyp mode and flushing VMIDs which really
> shouldn't be done unless we actually plan on running a VCPU, and we're
> going to do things like setting up the timer to handle timer interrupts
> in an ISR, which doesn't make sense unless the VCPU is running.
> 
> Add to that, that loading an entire VM's state onto hardware, only to
> read back a single register from hardware and returning it to user
> space, doesn't really fall within optimization vs. non-optimization in
> the critical path, but is just wrong, IMHO.

For GET/SET_ONE_REG it certainly makes sense.  For everything else, I'm
wondering which ioctls (and how many calls to each of them) exactly you
are seeing, and also on which userspace paths.

> That doesn't solve my need as I want to *only* do the arch vcpu_load for
> KVM_RUN, I should have been more clear in the commit message.

That's what you want to do, but it might not be what you need to do.

Paolo

  reply	other threads:[~2017-11-23 17:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-23 16:05 [RFC PATCH] KVM: Only register preempt notifiers and load arch cpu state as needed Christoffer Dall
2017-11-23 16:17 ` Paolo Bonzini
2017-11-23 17:06   ` Christoffer Dall
2017-11-23 17:12     ` Paolo Bonzini [this message]
2017-11-23 17:48       ` Christoffer Dall
2017-11-23 18:16         ` Paolo Bonzini
2017-11-23 18:32           ` Christoffer Dall
2017-11-23 18:43             ` Paolo Bonzini
2017-11-23 18:05     ` Christian Borntraeger
2017-11-23 18:32       ` Christoffer Dall

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=62ae4eb1-fd57-c525-cd73-e3f646d340e1@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox