On 12/10/2010 03:51 PM, Andre Przywara wrote:
In case of a nested page fault or an intercepted #PF newer SVM
implementations provide a copy of the faulting instruction bytes
in the VMCB.
Use these bytes to feed the instruction emulator and avoid the costly
guest instruction fetch in this case.
+static int svm_prefetch_instruction(struct kvm_vcpu *vcpu)
+{
+ struct vcpu_svm *svm = to_svm(vcpu);
+ uint8_t len;
+ struct fetch_cache *fetch;
+
+ len = svm->vmcb->control.insn_len& 0x0F;
+ if (len == 0)
+ return 1;
+
+ fetch =&svm->vcpu.arch.emulate_ctxt.decode.fetch;
+ fetch->start = kvm_rip_read(&svm->vcpu);
+ fetch->end = fetch->start + len;
+ memcpy(fetch->data, svm->vmcb->control.insn_bytes, len);
+
+ return 0;
+}
This reaching in into the emulator internals from svm code is not very
good. It also assumes ->prefetch_instruction() is called immediately
after an exit; this isn't true in vmx and at least was considered for
svm (emulating multiple instructions during the nsvm vmexit sequence).
Alternatives are:
- add the insn data to emulate_instruction() and friends (my first
suggestion)
- adding x86_decode_insn_init(), which initializes the decode cache, and
x86_decode_insn_prefill_cache(), called only if we have the insn data
Another one: teach kvm_fetch_guest_virt() to check if addr/bytes
intersects with csbase+rip/len; if so, use that instead of doing the
page table dance.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
