From: Laszlo Ersek <lersek@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>
Cc: edk2-devel list <edk2-devel@lists.sourceforge.net>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
kvm@vger.kernel.org, gleb@kernel.org, mtosatti@redhat.com,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]
Date: Wed, 15 Jul 2015 11:57:30 +0200 [thread overview]
Message-ID: <55A62E8A.9060708@redhat.com> (raw)
In-Reply-To: <20150714223704.12156.30765@jljusten-ivb>
On 07/15/15 00:37, Jordan Justen wrote:
> 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
>>>> <https://github.com/tianocore/edk2/commit/98f378a7>. 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?
If the page table building in the reset vector is not too costly with
UC, then yes, it should suffice if MtrrLib was put to use first just
before the decompression in SEC.
Thanks
Laszlo
> -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
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
next prev parent reply other threads:[~2015-07-15 9:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 6:42 [PATCH v3 00/10] KVM: MTRR fixes and some cleanups Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 01/10] KVM: MMU: fix decoding cache type from MTRR Xiao Guangrong
2015-05-13 8:09 ` Wanpeng Li
2015-07-12 17:33 ` Alex Williamson
2015-07-12 18:59 ` Xiao Guangrong
2015-07-13 7:32 ` Paolo Bonzini
2015-07-13 14:45 ` Xiao Guangrong
2015-07-13 15:13 ` Paolo Bonzini
2015-07-13 15:15 ` Xiao Guangrong
2015-07-14 21:12 ` MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR] Laszlo Ersek
2015-07-14 21:15 ` [edk2] " Paolo Bonzini
2015-07-14 21:29 ` Laszlo Ersek
2015-07-14 22:37 ` Jordan Justen
2015-07-15 9:57 ` Laszlo Ersek [this message]
2015-07-15 0:14 ` [edk2] " Fan, Jeff
2015-07-15 19:30 ` Xiao Guangrong
2015-07-15 19:41 ` Laszlo Ersek
2015-07-12 19:12 ` [PATCH v3 01/10] KVM: MMU: fix decoding cache type from MTRR Bandan Das
2015-05-13 6:42 ` [PATCH v3 02/10] KVM: MMU: introduce for_each_rmap_spte() Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 03/10] KVM: MMU: introduce PT_MAX_HUGEPAGE_LEVEL Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 04/10] KVM: MMU: introduce for_each_slot_rmap_range Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 05/10] KVM: MMU: introduce slot_handle_level_range() and its helpers Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 06/10] KVM: MMU: use slot_handle_level and its helper to clean up the code Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 07/10] KVM: MMU: introduce kvm_zap_rmapp Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 08/10] KVM: MMU: introduce kvm_zap_gfn_range Xiao Guangrong
2015-05-13 6:42 ` [PATCH v3 09/10] KVM: MMU: fix MTRR update Xiao Guangrong
2015-05-13 8:43 ` Wanpeng Li
2015-05-13 14:10 ` Paolo Bonzini
2015-05-14 0:16 ` Wanpeng Li
2015-05-14 8:43 ` Paolo Bonzini
2015-05-13 6:42 ` [PATCH v3 10/10] KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed Xiao Guangrong
2015-05-13 14:14 ` [PATCH v3 00/10] KVM: MTRR fixes and some cleanups Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A62E8A.9060708@redhat.com \
--to=lersek@redhat.com \
--cc=edk2-devel@lists.sourceforge.net \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=jordan.l.justen@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).