ase for MMIO during vectoring
> https://github.com/kvm-x86/linux/commit/62e41f6b4f36
>
> --
> https://github.com/kvm-x86/linux/tree/next
Hi Sean,
The commits (and the messages specifically) look good to me, thanks a
lot for making the changelogs better! :)
Also, I ran the selftests for the `next` branch on both Intel and AMD
platforms, and all of them seem to pass.
--
Kind regards,
Ivan Orlov
ah, I thought that covering the change in non-cacheable MMIO / shadow
paged #PF handling, but forgot to include it into the commit message :(
Could you please fix the message when applying? The message you
suggested looks good to me.
Thanks!
--
Kind regards,
Ivan Orlov
On 12/18/24 18:44, Sean Christopherson wrote:
On Tue, Dec 17, 2024, Ivan Orlov wrote:
Currently, the unhandleable vectoring (e.g. when guest accesses MMIO
during vectoring) is handled differently on VMX and SVM: on VMX KVM
returns internal error, when SVM goes into infinite loop trying to
that the subsequent patches won't make KVM exit to
userspace when handling an intercepted #PF during vectoring without
checking whether unprotect & retry is possible.
Suggested-by: Sean Christopherson
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- This patch wasn't included in V1.
es that we got a corrent reported GPA in internal.data[3]
Also, add a definition of non-canonical address to processor.h
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Get rid of pronouns, redundant comments and incorrect wording
- Define noncanonical address in processor.h
- Fix indentation and wra
Implement a function for setting the IDT descriptor from the guest
code. Replace the existing lidt occurrences with calls to this function
as `lidt` is used in multiple places.
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- This patch wasn't included in V1.
V2 -> V3:
- No changes
to
oring if it is due to an intercepted
#PF
- Add a new patch for checking whether unprotect & retry is possible
before exiting to userspace due to unhandleable vectoring
- Codestyle fixes
Ivan Orlov (7):
KVM: x86: Add function for vectoring error generation
KVM: x86: Add emulation status f
Detect unhandleable vectoring in check_emulate_instruction to prevent
infinite loop on SVM and eliminate the difference in how intercepted #PF
during vectoring is handled on SVM and VMX.
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Detect the unhandleable vectoring error
can't emulate
an instruction when vectoring an event.
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- This patch wasn't included in V1.
V2 -> V3:
- Make new X86EMUL_ code more generic to allow using it for any type
of unhandleable vectoring
arch/x86/kvm/kvm_emulate.h | 2 ++
arch/x86/
PF as this flag doesn't necessarily
mean MMIO anymore: it can also be set due to the write protection
violation.
Suggested-by: Sean Christopherson
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Detect the unhandleable vectoring error in vmx_check_emulate_instruction
instead of handling it in t
Extract VMX code for unhandleable VM-Exit during vectoring into
vendor-agnostic function so that boiler-plate code can be shared by SVM.
Report an actual GPA for EPT misconfig or invalid GPA for any other exit
code in internal.data[3].
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Return GPA
g).
> and then I believe this? Where this diff can be a separate prep patch
> (though I'm
> pretty sure it's technically pointless without the vectoring angle, because
> shadow
> #PF can't coincide with any of the failure paths for
> kvm_check_emulate_insn()).
>
L
test forces KVM to emulate the write.
>
> No action needed, the test is a-ok as-is. I'm really just curious :-)
:) Just tried enabling `force_emulation_prefix` kvm parameter and replacing the
write with
vcpu_arch_put_guest(*((uint8_t *)NONCANONICAL), 0x1);
And the test simply passes
t anymore), guest shouldn't really
care and it can continue execution.
However, I'm not sure what happens if vectoring is caused by external
interrupt: if we unprotect the page and re-execute the instruction,
will IRQ be delivered nonetheless, or it will be lost as irq is
already in ISR? Do we need to re-inject it in such a case?
--
Kind regards,
Ivan Orlov
(emul_type & ~(EMULTYPE_PF));
}
So it returns true if EMULTYPE_PF is not set or if it's not the only set
bit.
--
Kind regards,
Ivan Orlov
On 12/11/24 18:15, Sean Christopherson wrote:
On Mon, Nov 11, 2024, Ivan Orlov wrote:
Move unhandleable vmexit due to MMIO during vectoring error detection
into check_emulate_instruction. Implement a function which checks if
emul_type indicates MMIO so it can be used for both VMX and SVM.
Fix
On 12/11/24 18:20, Sean Christopherson wrote:
On Mon, Nov 11, 2024, Ivan Orlov wrote:
Currently, the situation when guest accesses MMIO during vectoring is
handled differently on VMX and SVM: on VMX KVM returns internal error,
when SVM goes into infinite loop trying to deliver an event again
Implement a function for setting the IDT descriptor from the guest
code. Replace the existing lidt occurrences with calls to this function
as `lidt` is used in multiple places.
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- This patch wasn't included in V1.
tools/testing/selftests/kvm
es that we got a corrent reported GPA in internal.data[3]
Also, add a definition of non-canonical address to processor.h
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Get rid of pronouns, redundant comments and incorrect wording
- Define noncanonical address in processor.h
- Fix indentation and wra
Handle MMIO during vectoring error in check_emulate_instruction to
prevent infinite loop on SVM and eliminate the difference in how the
situation when the guest accesses MMIO during vectoring is handled on
SVM and VMX.
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Detect the unhandleable vector
Add emulation status for vectoring error due to MMIO. Such a situation
can occur if guest sets the IDT descriptor base to point to MMIO region,
and triggers an exception after that.
Exit to userspace with event delivery error when MMIO happens during
vectoring.
Signed-off-by: Ivan Orlov
---
V1
t can also be set due to the write protection
violation.
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Detect the unhandleable vectoring error in vmx_check_emulate_instruction
instead of handling it in the common MMU code (which is specific for
cached MMIO)
arch/x86/include/asm/kvm_hos
Extract VMX code for unhandleable VM-Exit during vectoring into
vendor-agnostic function so that boiler-plate code can be shared by SVM.
Report an actual GPA for EPT misconfig or invalid GPA for any other exit
code in internal.data[3].
Signed-off-by: Ivan Orlov
---
V1 -> V2:
- Return GPA
UL_ return type and detect the unhandleable
vectoring error in vendor-specific check_emulate_instruction instead of
handling it in the common MMU code (which is specific for cached MMIO)
Ivan Orlov (6):
KVM: x86: Add function for vectoring error generation
KVM: x86: Add emulation status for vector
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
39 matches
Mail list logo
