From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 16 Oct 2019 08:45:28 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iKevu-0000jV-9F for speck@linutronix.de; Wed, 16 Oct 2019 10:45:27 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id F1125AFCF for ; Wed, 16 Oct 2019 08:45:19 +0000 (UTC) Date: Wed, 16 Oct 2019 10:45:18 +0200 From: Joerg Roedel Subject: [MODERATED] Re: ***UNCHECKED*** Re: NX, nested virtualization and arch caps Message-ID: <20191016084518.GE4695@suse.de> References: <20191016081507.GD4695@suse.de> MIME-Version: 1.0 In-Reply-To: <20191016081507.GD4695@suse.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Oct 16, 2019 at 10:15:07AM +0200, speck for Joerg Roedel wrote: > I also think that any nested hypervisor can ignore the ITLB_MULTIHIT > bug, but for a different reason: The host also builds the nested EPT > table as a shadow of the guests EPT table, so it does the mitigation on > behalf of the nested hypervisor. Left out the case where host mitigation is disabled: I agree in this case too with your reasoning, one should only disable the host mitigation when the guests are trusted. And the guests are only trusted when they only run trusted guests themselves. By passing through the issue to the nested hypervisor we could support untrusted nested guests on trusted guests with host mitigation disabled. But this is probably not faster than enabling the mitigation on the host because then KVM will trap/emulate all the guest EPT updates for splitting/promoting hugepages. Regards, Joerg