kvm_prepare_ev_delivery_failure_exit(vcpu, gpa, is_mmio);
+ kvm_prepare_ev_delivery_failure_exit(vcpu, gpa, false);
return 0;
}
All in all, I think this is the basic gist? Definitely feel free to propose a
better name than X86EMUL_UNHANDLEABLE_VECTORING.
On 10/16/24 22:05, Sean Christopherson wrote:
On Tue, Oct 15, 2024, Ivan Orlov wrote:
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index c67e448c6ebd..afd785e7f3a3 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6550,19 +6550,10 @@ static int
Hi Sean,
On Fri, Oct 11, 2024 at 04:20:46PM -0700, Sean Christopherson wrote:
> "KVM: VMX:" for the scope. See "Shortlog" in
> Documentation/process/maintainer-kvm-x86.rst
>
Ah, will update in the next version, thanks!
> On Fri, Sep 27, 202
OR)
and suberror code (KVM_INTERNAL_ERROR_DELIVERY_EV)
4) Verifies that we got a corrent "faulty" GPA in internal.data[3]
Signed-off-by: Ivan Orlov
---
.../selftests/kvm/set_memory_region_test.c| 46 +++
1 file changed, 46 insertions(+)
diff --git a/tools/t
M/VMX specific vmexit
handler to signal that we are in the middle of the event delivery.
This way we won't introduce much overhead for VMX platform either, as
the situation when the guest accesses MMIO during event delivery is
quite rare and shouldn't happen frequently.
Signed-off
ned-off-by: Ivan Orlov
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/vmx/vmx.c | 15 +++
arch/x86/kvm/x86.c | 22 ++
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/i
eliminates this difference by returning a KVM internal
error with suberror = KVM_INTERNAL_ERROR_DELIVERY_EV when guest is
performing MMIO during event delivery, for both VMX and SVM.
Also, it introduces a selftest test case which covers the MMIO during
event delivery error handling.
Ivan Orlov (3
try and keep the guest alive.
Yeah, I just thought that "internal error" is not the best exit code for
the situations when guest fetches from MMIO (since it is a perfectly legal
operation from the architectural point of view). But I agree that it
would be a breaking change without functional benefit ( especially if we
provide a flag about what happened :) ).
P.S. I tested the latest kvm/next, and if we set the IDT descriptor base to
an MMIO address it still falls into the infinite loop on SVM. I'm going
to send the fix in the next couple of days.
Kind regards,
Ivan Orlov
, and I believe how we do this
is debatable. I maintain we should either set a flag in emulation_failure.flags
to indicate that the error happened due to fetch from mmio (to give more
information to VMM), or we shouldn't return an error at all... Maybe it
should be KVM_EXIT_MMIO with some flag set? What do you think?
Thank you!
Kind regards,
Ivan Orlov
Update the set_memory_region test, test case test_zero_memory_regions to
use an updated exit code if the VM starts with no RAM. Now we are
issuing a triple fault in such a case, not an internal error.
Signed-off-by: Ivan Orlov
---
tools/testing/selftests/kvm/set_memory_region_test.c | 3 ++-
1
internal error
Additionaly, this patch series includes a KVM selftest which covers
different cases of MMIO misuse.
Also, update the set_memory_region_test to expect the triple fault when
starting VM with no RAM.
Ivan Orlov (4):
KVM: vmx, svm, mmu: Fix MMIO during event delivery handling
KVM
VM/VMX specific vmexit handler to signal
that we are in the middle of the event delivery.
Signed-off-by: Ivan Orlov
---
arch/x86/include/asm/kvm_host.h | 6 ++
arch/x86/kvm/mmu/mmu.c | 13 -
arch/x86/kvm/svm/svm.c | 4
arch/x86/kvm/vmx/vmx.
about the issue we faced
2) the issue is triggered by the guest itself, so it is not the KVM
"internal" error.
Inject the #UD into the guest instead and resume it's execution without
giving an error to VMM, as it would be if we can't find a valid
instruction at MMIO addre
ow.
These test cases depend on previous patches in this patch series.
Signed-off-by: Ivan Orlov
---
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/x86_64/faulty_mmio.c| 199 ++
2 files changed, 200 insertions(+)
create mode 100644 tools/testing
oticeable to the maintainers.
Thank you again for doing this.
--
Kind regards,
Ivan Orlov
15 matches
Mail list logo