Re: [Qemu-devel] [PATCH 09/26] ehci: Use uframe precision for interrupt threshold checking

[Gerd Hoffmann <kraxel@redhat.com>]

  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