From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06D51C67790 for ; Wed, 25 Jul 2018 15:19:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C000B20891 for ; Wed, 25 Jul 2018 15:19:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C000B20891 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728627AbeGYQbj (ORCPT ); Wed, 25 Jul 2018 12:31:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56648 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728537AbeGYQbj (ORCPT ); Wed, 25 Jul 2018 12:31:39 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 27AAF859A0; Wed, 25 Jul 2018 15:19:31 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.40.205.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 939582026D68; Wed, 25 Jul 2018 15:19:27 +0000 (UTC) From: Vitaly Kuznetsov To: Paolo Bonzini Cc: kvm@vger.kernel.org, Radim =?utf-8?B?S3LEjW3DocWZ?= , Roman Kagan , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , "Michael Kelley \(EOSG\)" , Mohammed Gamal , Cathy Avery , linux-kernel@vger.kernel.org, Jim Mattson , Liran Alon Subject: Re: [PATCH v2 6/6] KVM: nVMX: optimize prepare_vmcs02{,_full} for Enlightened VMCS case References: <20180621123046.29606-1-vkuznets@redhat.com> <20180621123046.29606-7-vkuznets@redhat.com> <87va93pv6w.fsf@vitty.brq.redhat.com> <46052d1e-9ee1-8cee-3f7c-cf27b1cd0373@redhat.com> <87in53pjgv.fsf@vitty.brq.redhat.com> <87effrphu3.fsf@vitty.brq.redhat.com> <2ed3d00b-bc99-2e2d-3a23-a86de767bfec@redhat.com> <87a7qfpfnr.fsf@vitty.brq.redhat.com> Date: Wed, 25 Jul 2018 17:19:26 +0200 In-Reply-To: (Paolo Bonzini's message of "Wed, 25 Jul 2018 16:39:11 +0200") Message-ID: <87muufz6kh.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 25 Jul 2018 15:19:31 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 25 Jul 2018 15:19:31 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vkuznets@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paolo Bonzini writes: > On 25/07/2018 16:13, Vitaly Kuznetsov wrote: >> Paolo Bonzini writes: >> >>> On 25/07/2018 15:26, Vitaly Kuznetsov wrote: >>> >>>> The other place where we set dirty_vmcs12 is the newly introduced >>>> vmx_set_nested_state() but I think I'm going to add support for eVMCS >>>> there later and just return something like -ENOTSUPP for now. Too many >>>> people work on nested simultaneously :-) >>> >>> Hmm, I think that means you have to put the clean fields in the >>> vmx_nested struct. Then it's really easy in vmx_set_nested_state to >>> clear all the clean bits. Touching memory in vmx_set_nested_state is... >>> *puts on sunglasses* a touchy subject (see comment in kvm/queue's >>> enter_vmx_non_root_mode). >>> >> >> Not only clean fields, in case we can't touch memory in >> vmx_set_nested_state I guess we'll need to cache the whole eVMCS, just >> like we save cached_shadow_vmcs12. Anyway, let's eat the elephant one >> bite at a time :-) > > You're right, but do we actually need to save the vmcs12 if eVMCS is > active? The format would be different, but the size wouldn't. I think we don't: vmcs12 can always be re-constructed from eVMCS and vice versa. The size is not exactly the same as we have some stuff which is missing in eVMCS but we know that eVMCS will always fit into vmcs12 area. -- Vitaly