linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bandan Das <bsd@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Maxim Levitsky <mlevitsk@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wei Huang <wei.huang2@amd.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, seanjc@google.com, joro@8bytes.org,
	bp@alien8.de, tglx@linutronix.de, mingo@redhat.com,
	x86@kernel.org, jmattson@google.com, wanpengli@tencent.com,
	dgilbert@redhat.com
Subject: Re: [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions
Date: Tue, 12 Jan 2021 10:46:25 -0500	[thread overview]
Message-ID: <jpgturmgnu6.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <C121813D-BD61-4C78-9169-8F8FCC1356D7@amacapital.net> (Andy Lutomirski's message of "Tue, 12 Jan 2021 07:22:41 -0800")

Andy Lutomirski <luto@amacapital.net> writes:
...
>>>>> #endif diff --git a/arch/x86/kvm/mmu/mmu.c
>>>>> b/arch/x86/kvm/mmu/mmu.c index 6d16481aa29d..c5c4aaf01a1a 100644
>>>>> --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@
>>>>> -50,6 +50,7 @@ #include <asm/io.h> #include <asm/vmx.h> #include
>>>>> <asm/kvm_page_track.h> +#include <asm/e820/api.h> #include
>>>>> "trace.h"
>>>>> 
>>>>> extern bool itlb_multihit_kvm_mitigation; @@ -5675,6 +5676,12 @@
>>>>> void kvm_mmu_slot_set_dirty(struct kvm *kvm, }
>>>>> EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty);
>>>>> 
>>>>> +bool kvm_is_host_reserved_region(u64 gpa) +{ + return
>>>>> e820__mbapped_raw_any(gpa-1, gpa+1, E820_TYPE_RESERVED); +}
>>>>  While _e820__mapped_any()'s doc says '..  checks if any part of
>>>> the range <start,end> is mapped ..' it seems to me that the real
>>>> check is [start, end) so we should use 'gpa' instead of 'gpa-1',
>>>> no?
>>>  Why do you need to check GPA at all?
>>> 
>> To reduce the scope of the workaround.
>> 
>> The errata only happens when you use one of SVM instructions in the
>> guest with EAX that happens to be inside one of the host reserved
>> memory regions (for example SMM).
>
> This code reduces the scope of the workaround at the cost of
> increasing the complexity of the workaround and adding a nonsensical
> coupling between KVM and host details and adding an export that really
> doesn’t deserve to be exported.
>
> Is there an actual concrete benefit to this check?

Besides reducing the scope, my intention for the check was that we should
know if such exceptions occur for any other undiscovered reasons with other
memory types rather than hiding them under this workaround.

Bandan




  reply	other threads:[~2021-01-12 15:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12  6:37 [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions Wei Huang
2021-01-12  6:37 ` [PATCH 2/2] KVM: SVM: Add support for VMCB address check change Wei Huang
2021-01-12 19:18   ` Sean Christopherson
2021-01-14 11:39     ` Maxim Levitsky
2021-01-14 12:04   ` Maxim Levitsky
2021-01-12 11:09 ` [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions Maxim Levitsky
2021-01-12 21:05   ` Wei Huang
2021-01-12 12:15 ` Vitaly Kuznetsov
2021-01-12 15:11   ` Andy Lutomirski
2021-01-12 15:17     ` Maxim Levitsky
2021-01-12 15:22       ` Andy Lutomirski
2021-01-12 15:46         ` Bandan Das [this message]
2021-01-12 15:51           ` Andy Lutomirski
2021-01-12 17:56             ` Sean Christopherson
2021-01-13  4:55               ` Wei Huang
2021-01-12 21:50   ` Wei Huang
2021-01-12 14:01 ` Paolo Bonzini
2021-01-12 17:42   ` Sean Christopherson
2021-01-13 12:35     ` Paolo Bonzini
2021-01-15  7:00   ` Wei Huang
2021-01-17 18:20     ` Paolo Bonzini
2021-01-12 17:36 ` Sean Christopherson
2021-01-12 17:59   ` Sean Christopherson
2021-01-12 18:58     ` Andy Lutomirski
2021-01-13  5:15       ` Wei Huang
2021-01-14 11:42         ` Maxim Levitsky
2021-01-13  5:03     ` Wei Huang
2021-01-13 12:40     ` Paolo Bonzini
2021-01-12 19:40 ` Sean Christopherson
2021-01-12 20:00   ` Bandan Das
2021-01-14 11:47     ` Maxim Levitsky
2021-01-14 17:19       ` Sean Christopherson
2021-01-14 11:55 ` Maxim Levitsky

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=jpgturmgnu6.fsf@linux.bootlegged.copy \
    --to=bsd@redhat.com \
    --cc=bp@alien8.de \
    --cc=dgilbert@redhat.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=wei.huang2@amd.com \
    --cc=x86@kernel.org \
    /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).