linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: rkrcmar@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] kvm: VMX: do not use vm-exit instruction length for fast MMIO
Date: Fri, 18 Aug 2017 13:57:43 +0200	[thread overview]
Message-ID: <901d4c2e-aa94-2002-babc-7f042946a327@redhat.com> (raw)
In-Reply-To: <1502890494-35208-1-git-send-email-pbonzini@redhat.com>

On 16.08.2017 15:34, Paolo Bonzini wrote:
> Microsoft pointed out privately to me that KVM's handling of
> KVM_FAST_MMIO_BUS is invalid.  Using skip_emulation_instruction is invalid
> in EPT misconfiguration vmexit handlers, because neither EPT violations
> nor misconfigurations are listed in the manual among the VM exits that
> set the VM-exit instruction length field.
> 
> While physical processors seem to set the field, this is not architectural
> and is just a side effect of the implementation.  I couldn't convince
> myself of any condition on the exit qualification where VM-exit
> instruction length "has" to be defined; there are no trap-like VM-exits
> that can be repurposed; and fault-like VM-exits such as descriptor-table
> exits provide no decoding information.  So I don't really see any way
> to keep the full speedup.

What about a hack:

1. clear instruction length when entering
2. check if instruction length is set when trying to forward the RIP
2a. if set, use it
2b. if not set, compute it

this at least should give full speedup in existing setups. Not 99%
architecturally correct but might just work.

> 
> What we can do is use EMULTYPE_SKIP; it only saves 200 clock cycles
> because computing the physical RIP and reading the instruction is
> expensive, but at least the eventfd is signaled before entering the
> emulator.  This saves on latency.  While at it, don't check breakpoints
> when skipping the instruction, as presumably any side effect has been
> exposed already.
> 
> Adding a hypercall or MSR write that does a fast MMIO write to a physical
> address would do it, but it adds hypervisor knowledge in virtio, including
> CPUID handling.  So it would be pretty ugly in the guest-side implementation,
> but if somebody wants to do it and the virtio side is acceptable to the
> virtio maintainers, I am okay with it.
> 


-- 

Thanks,

David

  parent reply	other threads:[~2017-08-18 11:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 13:34 [PATCH] kvm: VMX: do not use vm-exit instruction length for fast MMIO Paolo Bonzini
2017-08-16 14:10 ` Michael S. Tsirkin
2017-08-16 16:56   ` Radim Krčmář
2017-08-16 17:04     ` Michael S. Tsirkin
2017-08-17  8:07     ` Yang Zhang
2017-08-17  8:28       ` Wanpeng Li
2017-08-17  8:31         ` Wanpeng Li
2017-08-17  8:48           ` Yang Zhang
2017-08-17  8:51             ` Wanpeng Li
2017-08-18  3:33               ` Yang Zhang
2017-08-18  8:46   ` Jason Wang
2017-08-21 16:03     ` Radim Krčmář
2017-08-18 11:57 ` David Hildenbrand [this message]
2017-08-18 12:35   ` Paolo Bonzini
2017-08-18 12:41     ` David Hildenbrand

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=901d4c2e-aa94-2002-babc-7f042946a327@redhat.com \
    --to=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=stable@vger.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: 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;
as well as URLs for NNTP newsgroup(s).