[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y2timmto.fsf@vitty.brq.redhat.com>
Date: Tue, 04 Feb 2020 15:47:15 +0100
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Andy Lutomirski <luto@...capital.net>
Cc: David Laight <David.Laight@...lab.com>,
Xiaoyao Li <xiaoyao.li@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"x86\@kernel.org" <x86@...nel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm\@vger.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH 1/2] KVM: x86: Emulate split-lock access as a write
Sean Christopherson <sean.j.christopherson@...el.com> writes:
> Exiting to host userspace with "emulation failed" is the other reasonable
> alternative, but that's basically the same as killing the guest. We're
> arguing that, in the extremely unlikely event that there is a workload out
> there that hits this, it's preferable to *maybe* corrupt guest memory and
> log the anomaly in the kernel log, as opposed to outright killing the guest
> with a generic "emulation failed".
>
FWIW, if I was to cast a vote I'd pick 'kill the guest' one way or
another. "Maybe corrupt guest memory" scares me much more and in many
cases host and guest are different responsibility domains (think
'cloud').
--
Vitaly
Powered by blists - more mailing lists