From: Christoffer Dall <cdall@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Christoffer Dall" <christoffer.dall@linaro.org>,
kvm@vger.kernel.org, "Andrew Jones" <drjones@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Marc Zyngier" <marc.zyngier@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
"James Hogan" <jhogan@kernel.org>,
linux-mips@linux-mips.org, "Alexander Graf" <agraf@suse.com>,
kvm-ppc@vger.kernel.org,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Cornelia Huck" <cohuck@redhat.com>,
linux-s390@vger.kernel.org
Subject: Re: [RFC PATCH] KVM: Only register preempt notifiers and load arch cpu state as needed
Date: Thu, 23 Nov 2017 17:48:04 +0000 [thread overview]
Message-ID: <20171123174804.GB28855@cbox> (raw)
In-Reply-To: <62ae4eb1-fd57-c525-cd73-e3f646d340e1@redhat.com>
On Thu, Nov 23, 2017 at 06:12:41PM +0100, Paolo Bonzini wrote:
> 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.
>
Outside of migration, not many. It's not about optimizing certain
ioctl's, but rather that I think it's wrong and potentially vulnerable
to do significant work on the system which is strictly unnecessary.
> > 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.
>
Well, why would we want to do a lot of work when there's absolutely no
need to?
I see that this patch is invasive, and that's why I originally proposed
the other approach of recording the ioctl number.
While it may be possible to call kvm_arch_vcpu_load() for a number of
non-KVM_RUN ioctls, it makes the KVM/ARM code more difficult to reason
about, especially after my optimization series, because a lot of things
can now happen, where we have to consider if we're really in the process
of running a vcpu or not.
Thanks,
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: Christoffer Dall <cdall@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Christoffer Dall" <christoffer.dall@linaro.org>,
kvm@vger.kernel.org, "Andrew Jones" <drjones@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Marc Zyngier" <marc.zyngier@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
"James Hogan" <jhogan@kernel.org>,
linux-mips@linux-mips.org, "Alexander Graf" <agraf@suse.com>,
kvm-ppc@vger.kernel.org,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Cornelia Huck" <cohuck@redhat.com>,
linux-s390@vger.kernel.org
Subject: Re: [RFC PATCH] KVM: Only register preempt notifiers and load arch cpu state as needed
Date: Thu, 23 Nov 2017 18:48:04 +0100 [thread overview]
Message-ID: <20171123174804.GB28855@cbox> (raw)
In-Reply-To: <62ae4eb1-fd57-c525-cd73-e3f646d340e1@redhat.com>
On Thu, Nov 23, 2017 at 06:12:41PM +0100, Paolo Bonzini wrote:
> 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.
>
Outside of migration, not many. It's not about optimizing certain
ioctl's, but rather that I think it's wrong and potentially vulnerable
to do significant work on the system which is strictly unnecessary.
> > 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.
>
Well, why would we want to do a lot of work when there's absolutely no
need to?
I see that this patch is invasive, and that's why I originally proposed
the other approach of recording the ioctl number.
While it may be possible to call kvm_arch_vcpu_load() for a number of
non-KVM_RUN ioctls, it makes the KVM/ARM code more difficult to reason
about, especially after my optimization series, because a lot of things
can now happen, where we have to consider if we're really in the process
of running a vcpu or not.
Thanks,
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: cdall@linaro.org (Christoffer Dall)
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:48:04 +0100 [thread overview]
Message-ID: <20171123174804.GB28855@cbox> (raw)
In-Reply-To: <62ae4eb1-fd57-c525-cd73-e3f646d340e1@redhat.com>
On Thu, Nov 23, 2017 at 06:12:41PM +0100, Paolo Bonzini wrote:
> 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.
>
Outside of migration, not many. It's not about optimizing certain
ioctl's, but rather that I think it's wrong and potentially vulnerable
to do significant work on the system which is strictly unnecessary.
> > 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.
>
Well, why would we want to do a lot of work when there's absolutely no
need to?
I see that this patch is invasive, and that's why I originally proposed
the other approach of recording the ioctl number.
While it may be possible to call kvm_arch_vcpu_load() for a number of
non-KVM_RUN ioctls, it makes the KVM/ARM code more difficult to reason
about, especially after my optimization series, because a lot of things
can now happen, where we have to consider if we're really in the process
of running a vcpu or not.
Thanks,
-Christoffer
next prev parent reply other threads:[~2017-11-23 17:48 UTC|newest]
Thread overview: 33+ 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:05 ` Christoffer Dall
2017-11-23 16:05 ` Christoffer Dall
2017-11-23 16:17 ` Paolo Bonzini
2017-11-23 16:17 ` Paolo Bonzini
2017-11-23 16:17 ` Paolo Bonzini
2017-11-23 16:17 ` Paolo Bonzini
2017-11-23 17:06 ` Christoffer Dall
2017-11-23 17:06 ` Christoffer Dall
2017-11-23 17:06 ` Christoffer Dall
2017-11-23 17:12 ` Paolo Bonzini
2017-11-23 17:12 ` Paolo Bonzini
2017-11-23 17:12 ` Paolo Bonzini
2017-11-23 17:12 ` Paolo Bonzini
2017-11-23 17:48 ` Christoffer Dall [this message]
2017-11-23 17:48 ` Christoffer Dall
2017-11-23 17:48 ` Christoffer Dall
2017-11-23 18:16 ` Paolo Bonzini
2017-11-23 18:16 ` Paolo Bonzini
2017-11-23 18:16 ` Paolo Bonzini
2017-11-23 18:32 ` Christoffer Dall
2017-11-23 18:32 ` Christoffer Dall
2017-11-23 18:32 ` Christoffer Dall
2017-11-23 18:43 ` Paolo Bonzini
2017-11-23 18:43 ` Paolo Bonzini
2017-11-23 18:43 ` Paolo Bonzini
2017-11-23 18:05 ` Christian Borntraeger
2017-11-23 18:05 ` Christian Borntraeger
2017-11-23 18:05 ` Christian Borntraeger
2017-11-23 18:32 ` Christoffer Dall
2017-11-23 18:32 ` Christoffer Dall
2017-11-23 18:32 ` Christoffer Dall
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=20171123174804.GB28855@cbox \
--to=cdall@linaro.org \
--cc=agraf@suse.com \
--cc=borntraeger@de.ibm.com \
--cc=christoffer.dall@linaro.org \
--cc=cohuck@redhat.com \
--cc=drjones@redhat.com \
--cc=jhogan@kernel.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-s390@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--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 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.