From: Jim Mattson <jmattson@google.com> To: Alexander Graf <agraf@suse.de> Cc: "kvm list" <kvm@vger.kernel.org>, "Radim Krčmář" <rkrcmar@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, LKML <linux-kernel@vger.kernel.org>, "Gabriel L. Somlo" <gsomlo@gmail.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Jonathan Corbet" <corbet@lwn.net>, "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, "the arch/x86 maintainers" <x86@kernel.org>, "Joerg Roedel" <joro@8bytes.org>, linux-doc@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [PATCH v6] kvm: better MWAIT emulation for guests Date: Wed, 12 Apr 2017 08:20:21 -0700 [thread overview] Message-ID: <CALMp9eRndxWDknB8ncmXB5DeK4KxO8Zcu+=4VVJNo6nqpA70Xw@mail.gmail.com> (raw) In-Reply-To: <204f274d-697d-f9c6-8719-9bf91105f8b9@suse.de> On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf <agraf@suse.de> wrote: > > > On 12.04.17 16:34, Jim Mattson wrote: >> >> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate >> monitor and mwait instructions as nop"), so when we intercept >> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from >> vanilla kvm that motivates the following idea... > > > So you're not running upstream kvm? In that case, you can just not take this > patch either :). This patch should be harmless. :-) > >> Since we're still not going to report MONITOR support in CPUID, the >> only guests of consequence are paravirtual guests. What if a > > > Only if someone actually implemented something for PV guests, yes. > > The real motivation is to allow user space to force set the MONITOR CPUID > flag. That way an admin can - if he really wants to - dedicate pCPUs to the > VM. > > I agree that we don't need the kvm pv flag for that. I'd be happy to drop > that if everyone agrees. > >> paravirtual guest was aware of the fact that sometimes MONITOR/MWAIT >> would work as architected, and sometimes they would raise #UD (or do >> something else that's guest-visible, to indicate that the hypevisor is >> intercepting the instructions). Such a guest could first try a >> MONITOR/MWAIT-based idle loop and then fall back on a HLT-based idle >> loop if the hypervisor rejected its use of MONITOR/MWAIT. > > > How would that work? That guest would have to atomically notify all other > vCPUs that wakeup notifications now go via IPIs instead of cache line > dirtying. > > That's probably as much work to get right as it would be to just emulate > MWAIT inside kvm ;). True. I don't have an easy solution to that problem. > >> We already have the loose concept of "this pCPU has other things to >> do," which is encoded in the variable-sized PLE window. With >> MONITOR/MWAIT, the choice is binary, but a simple implementation could >> tie the two together, by allowing the guest to use MONITOR/MWAIT >> whenever the PLE window exceeds a certain threshold. Or the decision >> could be left to the userspace agent. > > > I agree, and that's basically the idea I mentioned earlier with MWAIT > emulation. We could (for well behaved guests) switch between emulating MWAIT > and running native MWAIT. Yes, that would probably be the preferred solution. > > > > Alex
WARNING: multiple messages have this Message-ID (diff)
From: Jim Mattson <jmattson@google.com> To: Alexander Graf <agraf@suse.de> Cc: "kvm list" <kvm@vger.kernel.org>, "Radim Krčmář" <rkrcmar@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, LKML <linux-kernel@vger.kernel.org>, "Gabriel L. Somlo" <gsomlo@gmail.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Jonathan Corbet" <corbet@lwn.net>, "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, "the arch/x86 maintainers" <x86@kernel.org>, "Joerg Roedel" <joro@8bytes.org>, linux-doc@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH v6] kvm: better MWAIT emulation for guests Date: Wed, 12 Apr 2017 08:20:21 -0700 [thread overview] Message-ID: <CALMp9eRndxWDknB8ncmXB5DeK4KxO8Zcu+=4VVJNo6nqpA70Xw@mail.gmail.com> (raw) In-Reply-To: <204f274d-697d-f9c6-8719-9bf91105f8b9@suse.de> On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf <agraf@suse.de> wrote: > > > On 12.04.17 16:34, Jim Mattson wrote: >> >> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate >> monitor and mwait instructions as nop"), so when we intercept >> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from >> vanilla kvm that motivates the following idea... > > > So you're not running upstream kvm? In that case, you can just not take this > patch either :). This patch should be harmless. :-) > >> Since we're still not going to report MONITOR support in CPUID, the >> only guests of consequence are paravirtual guests. What if a > > > Only if someone actually implemented something for PV guests, yes. > > The real motivation is to allow user space to force set the MONITOR CPUID > flag. That way an admin can - if he really wants to - dedicate pCPUs to the > VM. > > I agree that we don't need the kvm pv flag for that. I'd be happy to drop > that if everyone agrees. > >> paravirtual guest was aware of the fact that sometimes MONITOR/MWAIT >> would work as architected, and sometimes they would raise #UD (or do >> something else that's guest-visible, to indicate that the hypevisor is >> intercepting the instructions). Such a guest could first try a >> MONITOR/MWAIT-based idle loop and then fall back on a HLT-based idle >> loop if the hypervisor rejected its use of MONITOR/MWAIT. > > > How would that work? That guest would have to atomically notify all other > vCPUs that wakeup notifications now go via IPIs instead of cache line > dirtying. > > That's probably as much work to get right as it would be to just emulate > MWAIT inside kvm ;). True. I don't have an easy solution to that problem. > >> We already have the loose concept of "this pCPU has other things to >> do," which is encoded in the variable-sized PLE window. With >> MONITOR/MWAIT, the choice is binary, but a simple implementation could >> tie the two together, by allowing the guest to use MONITOR/MWAIT >> whenever the PLE window exceeds a certain threshold. Or the decision >> could be left to the userspace agent. > > > I agree, and that's basically the idea I mentioned earlier with MWAIT > emulation. We could (for well behaved guests) switch between emulating MWAIT > and running native MWAIT. Yes, that would probably be the preferred solution. > > > > Alex
next prev parent reply other threads:[~2017-04-12 15:20 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-11 11:45 [PATCH v6] kvm: better MWAIT emulation for guests Alexander Graf 2017-04-11 11:45 ` [Qemu-devel] " Alexander Graf 2017-04-11 12:41 ` Gabriel L. Somlo 2017-04-11 12:41 ` [Qemu-devel] " Gabriel L. Somlo 2017-04-11 12:43 ` Gabriel L. Somlo 2017-04-11 12:43 ` [Qemu-devel] " Gabriel L. Somlo 2017-04-11 12:43 ` Alexander Graf 2017-04-11 12:43 ` [Qemu-devel] " Alexander Graf 2017-04-11 17:10 ` Jim Mattson 2017-04-11 17:10 ` [Qemu-devel] " Jim Mattson 2017-04-11 18:23 ` Alexander Graf 2017-04-11 18:23 ` [Qemu-devel] " Alexander Graf 2017-04-12 14:34 ` Jim Mattson 2017-04-12 14:34 ` [Qemu-devel] " Jim Mattson 2017-04-12 14:54 ` Alexander Graf 2017-04-12 14:54 ` [Qemu-devel] " Alexander Graf 2017-04-12 15:20 ` Jim Mattson [this message] 2017-04-12 15:20 ` Jim Mattson 2017-04-12 16:29 ` Michael S. Tsirkin 2017-04-12 16:29 ` [Qemu-devel] " Michael S. Tsirkin 2017-04-21 10:02 ` Paolo Bonzini 2017-04-21 10:02 ` [Qemu-devel] " Paolo Bonzini 2017-04-21 10:05 ` Alexander Graf 2017-04-21 10:05 ` [Qemu-devel] " Alexander Graf 2017-04-21 10:06 ` Paolo Bonzini 2017-04-21 10:06 ` [Qemu-devel] " Paolo Bonzini
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='CALMp9eRndxWDknB8ncmXB5DeK4KxO8Zcu+=4VVJNo6nqpA70Xw@mail.gmail.com' \ --to=jmattson@google.com \ --cc=agraf@suse.de \ --cc=corbet@lwn.net \ --cc=gsomlo@gmail.com \ --cc=hpa@zytor.com \ --cc=joro@8bytes.org \ --cc=kvm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=rkrcmar@redhat.com \ --cc=tglx@linutronix.de \ --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: linkBe 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.