Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752843AbbGNWhJ (ORCPT ); Tue, 14 Jul 2015 18:37:09 -0400 Received: from mga01.intel.com ([192.55.52.88]:62969 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbbGNWhH convert rfc822-to-8bit (ORCPT ); Tue, 14 Jul 2015 18:37:07 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,475,1432623600"; d="scan'208";a="747305228" Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Laszlo Ersek , "Paolo Bonzini" Message-ID: <20150714223704.12156.30765@jljusten-ivb> From: Jordan Justen In-Reply-To: <55A57F27.6090705@redhat.com> Cc: "Xiao Guangrong" , "Alex Williamson" , gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, "edk2-devel list" References: <1431499348-25188-1-git-send-email-guangrong.xiao@linux.intel.com> <1436722432.1391.347.camel@redhat.com> <55A2B8F7.1050805@linux.intel.com> <55A36976.6090807@redhat.com> <55A3CEF2.2030200@linux.intel.com> <55A3D57C.4050100@redhat.com> <55A3D616.8010209@linux.intel.com> <55A57B54.2040305@redhat.com> <922266674.41385307.1436908536320.JavaMail.zimbra@redhat.com> <55A57F27.6090705@redhat.com> Subject: Re: MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR] User-Agent: alot/0.3.6 Date: Tue, 14 Jul 2015 15:37:04 -0700 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1964 Lines: 48 On 2015-07-14 14:29:11, Laszlo Ersek wrote: > On 07/14/15 23:15, Paolo Bonzini wrote: > >> The long delay that Alex reported (for the case when all guest memory > >> was set to UC up-front) is due to the fact that the SEC phase of OVMF > >> decompresses an approximately 1712 KB sized, LZMA-compressed blob, to > >> approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI > >> drivers -- and this decompression is extremely memory-intensive. > >> > >> (When Jordan implemented that reset vector first, we saw similar > >> performance degradation on AMD hosts (albeit not due to MTRR but due to > >> page attributes). See > >> . I'm only mentioning > >> it here because it makes me appreciate the current problem report.) > >> > >> Anyway, the reset vector's page table building is implemented in > >> "OvmfPkg/ResetVector/Ia32/PageTables64.asm". The decompression in SEC > >> can be found in "OvmfPkg/Sec/SecMain.c", function DecompressMemFvs(). > > > > Perhaps the OVMF reset vector should initialize the MTRRs for the BSP? > > That's an idea, yes, if someone feels sufficiently drawn to writing > assembly. Maybe we can use MtrrLib in the SEC C code? -Jordan > Complications: > - the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc > build > - it needs to be determined what memory to cover. > > > I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs > > and set the default type to writeback. > > Seems safe to me, off the top of my head (and testing could confirm / > disprove quickly). > > > In any case we're going to have to quirk it, because of the broken > > guests in the wild. > > Thanks. > Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/