From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755290AbbCPRfb (ORCPT <rfc822;w@1wt.eu>);
	Mon, 16 Mar 2015 13:35:31 -0400
Received: from mx1.redhat.com ([209.132.183.28]:58438 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751351AbbCPRf2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Mar 2015 13:35:28 -0400
Date: Mon, 16 Mar 2015 18:34:59 +0100
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
To: Joel Schopp <joel.schopp@amd.com>
Cc: Gleb Natapov <gleb@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
        kvm@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
        Borislav Petkov <bp@alien8.de>, linux-kernel@vger.kernel.org,
        David Kaplan <david.kaplan@amd.com>
Subject: Re: [PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts
Message-ID: <20150316173459.GB14216@potion.brq.redhat.com>
References: <20150312201746.2953.11716.stgit@joelvm2.amd.com>
 <20150312212002.GA1711@potion.brq.redhat.com>
 <550701C5.8050603@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <550701C5.8050603@amd.com>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

2015-03-16 11:16-0500, Joel Schopp:
> On 03/12/2015 04:20 PM, Radim Krčmář wrote:
> > 2015-03-12 15:17-0500, Joel Schopp:
> >> There isn't really a valid reason for kvm to intercept cr* reads
> >> on svm hardware.  The current kvm code just ends up returning
> >> the register
> > There is no need to intercept CR* if the value that the guest should see
> > is equal to what we set there, but that is not always the case:
> > - CR0 might differ from what the guest should see because of lazy fpu
> Based on our previous conversations I understand why we have to trap the
> write to the CR0 ts bit for lazy fpu, but don't understand why that
> should affect a read.

KVM keeps one CR0 with guest's state (svm.vcpu.arch.cr0) and a second
one that is loaded to hardware CR0 on VMRUN (svm.vmcb->save.cr0);
these two might not match.
If we didn't intercept read, it would return hardware CR0, so the guest
could do CLTS (change svm.vcpu.arch.cr0) and read CR0.TS = 1, because of
lazy FPU.

Correct emulation is what we want.

> > CR2 and CR8 already aren't intercepted, so it looks like only CR0 and
> > CR4 could use some optimizations.
> I'll send out a v2 with these less aggressive optimizations.

Thanks.