lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Mar 2017 17:32:53 +0200 From: Borislav Petkov <bp@...e.de> To: Paolo Bonzini <pbonzini@...hat.com> Cc: Brijesh Singh <brijesh.singh@....com>, simon.guinot@...uanux.org, linux-efi@...r.kernel.org, kvm@...r.kernel.org, rkrcmar@...hat.com, matt@...eblueprint.co.uk, linux-pci@...r.kernel.org, linus.walleij@...aro.org, gary.hook@....com, linux-mm@...ck.org, paul.gortmaker@...driver.com, hpa@...or.com, cl@...ux.com, dan.j.williams@...el.com, aarcange@...hat.com, sfr@...b.auug.org.au, andriy.shevchenko@...ux.intel.com, herbert@...dor.apana.org.au, bhe@...hat.com, xemul@...allels.com, joro@...tes.org, x86@...nel.org, peterz@...radead.org, piotr.luc@...el.com, mingo@...hat.com, msalter@...hat.com, ross.zwisler@...ux.intel.com, dyoung@...hat.com, thomas.lendacky@....com, jroedel@...e.de, keescook@...omium.org, arnd@...db.de, toshi.kani@....com, mathieu.desnoyers@...icios.com, luto@...nel.org, devel@...uxdriverproject.org, bhelgaas@...gle.com, tglx@...utronix.de, mchehab@...nel.org, iamjoonsoo.kim@....com, labbott@...oraproject.org, tony.luck@...el.com, alexandre.bounine@....com, kuleshovmail@...il.com, linux-kernel@...r.kernel.org, mcgrof@...nel.org, mst@...hat.com, linux-crypto@...r.kernel.org, tj@...nel.org, akpm@...ux-foundation.org, davem@...emloft.net Subject: Re: [RFC PATCH v2 16/32] x86: kvm: Provide support to create Guest and HV shared per-CPU variables On Wed, Mar 29, 2017 at 05:21:13PM +0200, Paolo Bonzini wrote: > The GHCB would have to be allocated much earlier, possibly even by > firmware depending on how things will be designed. How about a statically allocated page like we do with the early pagetable pages in head_64.S? > I think it's premature to consider SEV-ES requirements. My only concern is not to have to redo a lot when SEV-ES gets enabled. So it would be prudent to design with SEV-ES in the back of our minds. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Powered by blists - more mailing lists