* Paolo Bonzini <[email protected]> wrote:
> > Hmm.
> >
> > If we did this, I think I'd prefer a slightly more general approach. First
> > teach KVM to support a mode in which it's purely an emulator (Paolo: how
> > hard
> > is this? It would also make testing the emulator much easier).
>
> This isn't hard, at least for Intel: make emulation_required() return true
> always (and fix the fallout). However, it's not necessary. The emulator is
> designed to be independent from the rest of KVM. At some point I think Avi
> was
> testing it in userspace (or planning to do so). So you would just move it
> from
> arch/x86/kvm to arch/x86/emulate.
Very nice!
> The obvious downside is that the emulator isn't really designed for speed.
>
> In KVM it's currently 1000-1500 times slower than the real thing. Even if
> you
> modified it to remove the KVM overhead (vm86 is just running ring 3 code; no
> interrupts and no pagetables to walk), it probably would take 300-500 cycles
> to
> execute one instruction.
This needs to be tested, but I wouldn't expect it to be a big issue:
- if anyone cares they can improve its performance
- or worst case they can upgrade their tool to something newer which will use
user-space emulation of 16-bit code anyway ...
- Furthermore I suspect with vm86 we'd trap out of vm86 mode rather often -
and a
single trap can take thousands of cycles. So I suspect the effective
slowdown
depends on the workload.
- In the absolute worst case it will perform like a really old CPU.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
