[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <afad1722-9200-9eef-6116-2a9d4ce2d882@redhat.com>
Date: Thu, 16 Jun 2016 19:21:58 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: David Matlack <dmatlack@...gle.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>, bsd@...hat.com,
Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit
On 16/06/2016 19:03, David Matlack wrote:
> > > If you make the else case the same as svm_handle_external_intr, can we
> > > avoid requiring ack-intr-on-exit?
> >
> > Yes, but the sti/nop/cli would be useless if ack-intr-on-exit is
> > available. It's a bit ugly, so I RFCed the bold thing instead.
>
> Ahh, and handle_external_intr is called on every VM-exit, not just
> VM-exits caused by external interrupts. So we'd be doing the
> sti/nop/cli quite often. I was thinking we never hit the else case
> when the CPU supports ack-intr-on-exit.
Actually it's really just aesthetics, because the sti and cli are pretty
cheap. It's the pushf/popf that kills performance for kvm_guest_exit.
I also thought of just doing a cli/sti around __kvm_guest_exit and
calling it a day.
Ubuntu 14.04 had kernel 3.13, but the latest hardware enablement kernels
are as recent as 4.4. And the most recent released RHEL (7.2) has all
the fixes too.
Debian Jessie has 3.16.7-ckt25, and all three patches for APICv support
have been backported to 3.16.7-ckt11. So they should be there (but I
can only check tomorrow).
Paolo
>> >
>> > Are you thinking of some distros in particular that lack nested
>> > ack-intr-on-exit? All processors have it as far as I know.
> Nope, I just thought it was possible to avoid the requirement.
>
Powered by blists - more mailing lists