Gerd Hoffmann wrote:
That said, I'd like to be able to emulate the Xen HVM hypercalls. But in
any case, they hypercall implementation has to be in the kernel,
No. With Xenner the xen hypercall emulation code lives in guest
address space.
In this case the guest ring-0 code should trap the #GP, and install the
hypercall page (which uses sysenter/syscall?). No kvm or qemu changes
needed.
Especially if we need to support
tricky bits like continuations.
Is there any reason to? I *think* xen does it for better scheduling
latency. But with xen emulation sitting in guest address space we can
schedule the guest at will anyway.
It also improves latency within the guest itself. At least I think that
what was the Hyper-V spec is saying. You can interrupt the execution of
a long hypercall, inject and interrupt, and resume. Sort of like a
rep/movs instruction, which the cpu can and will interrupt.
Same MSR, multiple writes (page number in the low bits).
Nasty. The hypervisor has to remember all of the pages, so it can update
them for live migration.
Xenner doesn't need update-on-migration, so there is no need at all to
remember this. At the end of the day it is just memcpy(guest, data,
PAGESIZE) triggered by wrmsr.
For Xenner, no (and you don't need to intercept the msr at all), but for
pv-on-hvm, you do need to update the code.
--
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
