On Mon, Feb 13, 2012 at 06:50:08PM +0000, Blue Swirl wrote: > On Mon, Feb 13, 2012 at 10:16, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > > On 2012-02-11 16:25, Blue Swirl wrote: > >> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > >>> This enables acceleration for MMIO-based TPR registers accesses of > >>> 32-bit Windows guest systems. It is mostly useful with KVM enabled, > >>> either on older Intel CPUs (without flexpriority feature, can also be > >>> manually disabled for testing) or any current AMD processor. > >>> > >>> The approach introduced here is derived from the original version of > >>> qemu-kvm. It was refactored, documented, and extended by support for > >>> user space APIC emulation, both with and without KVM acceleration. The > >>> VMState format was kept compatible, so was the ABI to the option ROM > >>> that implements the guest-side para-virtualized driver service. This > >>> enables seamless migration from qemu-kvm to upstream or, one day, > >>> between KVM and TCG mode. > >>> > >>> The basic concept goes like this: > >>> - VAPIC PV interface consisting of I/O port 0x7e and (for KVM in-kernel > >>> irqchip) a vmcall hypercall is registered > >>> - VAPIC option ROM is loaded into guest > >>> - option ROM activates TPR MMIO access reporting via port 0x7e > >>> - TPR accesses are trapped and patched in the guest to call into option > >>> ROM instead, VAPIC support is enabled > >>> - option ROM TPR helpers track state in memory and invoke hypercall to > >>> poll for pending IRQs if required > >>> > >>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > >> > >> I must say that I find the approach horrible, patching guests and ROMs > >> and looking up Windows internals. Taking the same approach to extreme, > >> we could for example patch Xen guest to become a KVM guest. Not that I > >> object merging. > > > > Yes, this is horrible. But there is no real better way in the absence of > > hardware assisted virtualization of the TPR. I think MS is recommending > > this patching approach as well. > > Maybe instead of routing via ROM and the hypercall, the TPR accesses > could be handled directly with guest invisible breakpoints (like GDB > breakpoints, but for QEMU internal use), much like other > instrumentation could be handled. > Hypercall is rarely called. The idea behind patching is to not have exit on each TPR update. Breakpoint will cause exit making the whole exercise pointless. -- Gleb. -- 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
