On Thu, Apr 08, 2021, Tom Lendacky wrote: > > > On 4/8/21 12:37 PM, Sean Christopherson wrote: > > On Thu, Apr 08, 2021, Tom Lendacky wrote: > >> On 4/8/21 12:10 PM, Sean Christopherson wrote: > >>> On Thu, Apr 08, 2021, Tom Lendacky wrote: > >>>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > >>>> index 83e00e524513..7ac67615c070 100644 > >>>> --- a/arch/x86/kvm/svm/sev.c > >>>> +++ b/arch/x86/kvm/svm/sev.c > >>>> @@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector) > >>>> * the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a > >>>> * non-zero value. > >>>> */ > >>>> + if (WARN_ON_ONCE(!svm->ghcb)) > >>> > >>> Isn't this guest triggerable? I.e. send a SIPI without doing the reset hold? > >>> If so, this should not WARN. > >> > >> Yes, it is a guest triggerable event. But a guest shouldn't be doing that, > >> so I thought adding the WARN_ON_ONCE() just to detect it wasn't bad. > >> Definitely wouldn't want a WARN_ON(). > > > > WARNs are intended only for host issues, e.g. a malicious guest shouldn't be > > able to crash the host when running with panic_on_warn. > > > > Ah, yeah, forgot about panic_on_warn. I can go back to the original patch > or do a pr_warn_once(), any pref? No strong preference. If you think the print would be helpful for ongoing development, then it's probably worth adding.
