Hi, > Can qemu not handle an mmio range where writes are trapped, but reads are > not? That would force the use of the shadow variable, but should otherwise > provide a nice speedup.
No. vmexit is needed anyway btw, but the round-trip to qemu userspace could be short-cutted in theory. It's non-trivial though. Alex had a talk about it at kvm forum (covering ide). First a simple read directly + write via qemu isn't that useful. You need a policy per register. For most reads it would work, but there are exceptions. Registers holding timers for example. frindex is actually an example of that. With async_stepdown active frindex updates are quite jumpy. We might want to update the register on guest reads (and maybe also reset async stepdown in that case). Likewise the other way around: Not all register writes have some effect which qemu must emulate, some are just storage (like ehci frame list address). Locking is an unsolved issue (in-kernel register reads/writes don't grab the qemu lock and thus would race with iothread accessing the register variables). cheers, Gerd
