| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fa
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
|
|
|
| |
|
Home