From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966028AbbCPQSW (ORCPT ); Mon, 16 Mar 2015 12:18:22 -0400 Received: from mail-bl2on0106.outbound.protection.outlook.com ([65.55.169.106]:42558 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964975AbbCPQQS convert rfc822-to-8bit (ORCPT ); Mon, 16 Mar 2015 12:16:18 -0400 X-WSS-ID: 0NLBBUY-08-70Q-02 X-M-MSG: Message-ID: <550701C5.8050603@amd.com> Date: Mon, 16 Mar 2015 11:16:05 -0500 From: Joel Schopp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= CC: Gleb Natapov , Paolo Bonzini , , Joerg Roedel , Borislav Petkov , , David Kaplan Subject: Re: [PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts References: <20150312201746.2953.11716.stgit@joelvm2.amd.com> <20150312212002.GA1711@potion.brq.redhat.com> In-Reply-To: <20150312212002.GA1711@potion.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.180.168.240] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=Joel.Schopp@amd.com; 8bytes.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;EFV:NLI;BMV:1;SFV:NSPM;SFS:(10019020)(6009001)(428002)(377454003)(199003)(51704005)(189002)(24454002)(479174004)(377424004)(87266999)(33656002)(87936001)(59896002)(92566002)(2950100001)(77156002)(50466002)(47776003)(62966003)(101416001)(86362001)(23676002)(65806001)(76176999)(50986999)(65956001)(65816999)(54356999)(83506001)(77096005)(99136001)(5820100001)(64126003)(110136001)(105586002)(106466001)(46102003)(36756003);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0201MB1053;H:atltwp02.amd.com;FPR:;SPF:None;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB1053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);SRVR:DM2PR0201MB1053;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB1053; X-Forefront-PRVS: 05177D47DC X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2015 16:16:14.9026 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.222];Helo=[atltwp02.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB1053 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. I'll take another look at the code to see what I'm missing. You are probably correct in which case I'll modify the patch to only turn off the read intercepts when lazy fpu isn't active. > - CR3 isn't intercepted with nested paging and it should differ > otherwise > - CR4 contains PAE bit when run without nested paging > > 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.