From: Jan Kiszka <jan.kiszka@web.de>
To: Gleb Natapov <gleb@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: Add instruction length to VCPU event state
Date: Sat, 13 Feb 2010 18:49:44 +0100 [thread overview]
Message-ID: <4B76E638.5010100@web.de> (raw)
In-Reply-To: <20100213152635.GA2511@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3929 bytes --]
Gleb Natapov wrote:
> On Sat, Feb 13, 2010 at 10:51:40AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> VMX requires a properly set instruction length VM entry field when
>> trying to inject soft exception and interrupts. We have to preserve this
>> state across VM save/restore to avoid breaking the re-injection of such
>> events on Intel. So add it to the new VCPU event state.
>>
> We shouldn't re-inject soft exceptions/interrupts after migration, but
> re-execute instruction instead. Instruction length field doesn't exist
> on SVM and migration shouldn't expose implementation details.
>
Hmm, then I guess this totally untested patch should fly:
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f9a2f66..f87c3a5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -315,8 +315,6 @@ struct kvm_vcpu_arch {
struct kvm_pio_request pio;
void *pio_data;
- u8 event_exit_inst_len;
-
struct kvm_queued_exception {
bool pending;
bool has_error_code;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f82b072..a7111da 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -889,8 +889,7 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
vmx->rmode.irq.vector = nr;
vmx->rmode.irq.rip = kvm_rip_read(vcpu);
if (kvm_exception_is_soft(nr))
- vmx->rmode.irq.rip +=
- vmx->vcpu.arch.event_exit_inst_len;
+ vmx->rmode.irq.rip++;
intr_info |= INTR_TYPE_SOFT_INTR;
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 1);
@@ -899,8 +898,7 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
}
if (kvm_exception_is_soft(nr)) {
- vmcs_write32(VM_ENTRY_INSTRUCTION_LEN,
- vmx->vcpu.arch.event_exit_inst_len);
+ vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 1);
intr_info |= INTR_TYPE_SOFT_EXCEPTION;
} else
intr_info |= INTR_TYPE_HARD_EXCEPTION;
@@ -2639,8 +2637,7 @@ static void vmx_inject_irq(struct kvm_vcpu *vcpu)
vmx->rmode.irq.vector = irq;
vmx->rmode.irq.rip = kvm_rip_read(vcpu);
if (vcpu->arch.interrupt.soft)
- vmx->rmode.irq.rip +=
- vmx->vcpu.arch.event_exit_inst_len;
+ vmx->rmode.irq.rip += 2;
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
irq | INTR_TYPE_SOFT_INTR | INTR_INFO_VALID_MASK);
vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 1);
@@ -2650,8 +2647,7 @@ static void vmx_inject_irq(struct kvm_vcpu *vcpu)
intr = irq | INTR_INFO_VALID_MASK;
if (vcpu->arch.interrupt.soft) {
intr |= INTR_TYPE_SOFT_INTR;
- vmcs_write32(VM_ENTRY_INSTRUCTION_LEN,
- vmx->vcpu.arch.event_exit_inst_len);
+ vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 2);
} else
intr |= INTR_TYPE_EXT_INTR;
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr);
@@ -3688,9 +3684,6 @@ static void vmx_complete_interrupts(struct vcpu_vmx *vmx)
GUEST_INTR_STATE_NMI);
break;
case INTR_TYPE_SOFT_EXCEPTION:
- vmx->vcpu.arch.event_exit_inst_len =
- vmcs_read32(VM_EXIT_INSTRUCTION_LEN);
- /* fall through */
case INTR_TYPE_HARD_EXCEPTION:
if (idt_vectoring_info & VECTORING_INFO_DELIVER_CODE_MASK) {
u32 err = vmcs_read32(IDT_VECTORING_ERROR_CODE);
@@ -3699,9 +3692,6 @@ static void vmx_complete_interrupts(struct vcpu_vmx *vmx)
kvm_queue_exception(&vmx->vcpu, vector);
break;
case INTR_TYPE_SOFT_INTR:
- vmx->vcpu.arch.event_exit_inst_len =
- vmcs_read32(VM_EXIT_INSTRUCTION_LEN);
- /* fall through */
case INTR_TYPE_EXT_INTR:
kvm_queue_interrupt(&vmx->vcpu, vector,
type == INTR_TYPE_SOFT_INTR);
As we actually do not support privileged soft exceptions, we are left
with int3 and into as single-byte instructions triggering soft
exceptions and int N as a two-byte instruction a the reason for soft
interrupts. Am I missing something?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-02-13 17:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-13 9:51 [PATCH] KVM: x86: Add instruction length to VCPU event state Jan Kiszka
2010-02-13 10:21 ` Avi Kivity
2010-02-13 10:55 ` Jan Kiszka
2010-02-13 15:26 ` Gleb Natapov
2010-02-13 17:49 ` Jan Kiszka [this message]
2010-02-13 18:22 ` Gleb Natapov
2010-02-13 18:41 ` Jan Kiszka
2010-02-13 19:06 ` Gleb Natapov
2010-02-13 19:20 ` Jan Kiszka
2010-02-13 19:25 ` Gleb Natapov
2010-02-14 10:19 ` Jan Kiszka
2010-02-14 13:44 ` Paolo Bonzini
2010-02-14 14:38 ` Gleb Natapov
2010-02-14 15:10 ` Avi Kivity
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=4B76E638.5010100@web.de \
--to=jan.kiszka@web.de \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.