[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems
On Sat, 2006-04-29 at 09:00 +0100, Keir Fraser wrote: > The APIC and IO-APIC are accessed via mmio. The former is written > fairly frequently with singleton updates (to the TPR and EOI registers) > so we'd want to carry on dealing with those directly in Xen I should > think. Still you'd have to deal with the case that one of the > Xen-emulated devices is accessed while emulating in qemu-dm -- as you > say you'd probably have to pull their state vectors out of Xen when > starting emulating. We'll need that for save/restore anyway though. The state is already partially exposed to qemu-dm through the shared global I/O data page (include/public/hvm/ioreq.h). This is easy to extend so that a context switch doesn't involve copying device state. This is also the place where we should store the vmx_assist_context information that is required by the emulator. The mmio *pic operations could just be handled by x86_emulate. > I don't know if this will make sense for emulated I/O but it does sound > like a very sane alternative to vmxassist for dealing with real mode. The big advantage I see for I/O is that 1) we don't need the instruction decode support anymore so it cleans up the hypervisor, 2) it has the potential to greatly reducing the number of exits that are caused by I/O by emulating subsequent I/O operations before returning to the HVM partition. Especially for the older devices that we are currently emulating this could be a major win, but even for modern devices where you are manipulating ring buffers that reside in I/O space it would be a win. I don't think that moving the I/O decoding from the hypervisor to the device model is going to be a major performance bottleneck. This cost is dwarfed by the upcall into qemu-dm. Leendert _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |