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: Thu, 17 Mar 2022 13:11:27 +0000 From: Boris Petkov <bp@...e.de> To: Peter Gonda <pgonda@...gle.com>, Joerg Roedel <jroedel@...e.de> CC: Michael Roth <michael.roth@....com>, Brijesh Singh <brijesh.singh@....com>, the arch/x86 maintainers <x86@...nel.org>, Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, kvm list <kvm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, platform-driver-x86@...r.kernel.org, Andy Lutomirski <luto@...nel.org>, Sergio Lopez <slp@...hat.com>, linux-efi@...r.kernel.org, linux-coco@...ts.linux.dev, Ingo Molnar <mingo@...hat.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, Tony Luck <tony.luck@...el.com>, linux-mm@...ck.org, Jim Mattson <jmattson@...gle.com>, Ard Biesheuvel <ardb@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, Tom Lendacky <thomas.lendacky@....com>, David Rientjes <rientjes@...gle.com>, Dov Murik <dovmurik@...ux.ibm.com>, Tobin Feldman-Fitzthum <tobin@....com>, Sean Christopherson <seanjc@...gle.com>, Vlastimil Babka <vbabka@...e.cz>, Paolo Bonzini <pbonzini@...hat.com>, Andi Kleen <ak@...ux.intel.com>, Borislav Petkov <bp@...en8.de>, brijesh.ksingh@...il.com, Vitaly Kuznetsov <vkuznets@...hat.com>, Marc Orr <marcorr@...gle.com>, "Dr . David Alan Gilbert" <dgilbert@...hat.com>, Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@...ux.intel.com> Subject: Re: [PATCH v12 32/46] x86/compressed/64: Add support for SEV-SNP CPUID table in #VC handlers On March 14, 2022 5:34:42 PM UTC, Peter Gonda <pgonda@...gle.com> wrote: >I was also thinking about adding a vcpu run exit reason for >termination. It would be nice to get a more informative exit reason >than -EINVAL in userspace. Thoughts? Absolutely - it should be unambiguously clear why we're terminating. -- Sent from a small device: formatting sux and brevity is inevitable.
Powered by blists - more mailing lists