On 02/10/2010 06:25 PM, Marcelo Tosatti wrote:
On Wed, Feb 10, 2010 at 09:02:00AM +0200, Avi Kivity wrote:
On 02/09/2010 10:58 PM, Marcelo Tosatti wrote:
You're right... this should be enough to avoid a stop with uncomplete
PIO (and this is what happens for MMIO already). The signal will not
be dequeued, so KVM will complete_pio and exit before entering with
-EAGAIN. Please review and queue for stable.
Not right enough. This is very fragile, we depend on the kernel
noticing the signal after completing pio but before starting
execution. I don't think we guarantee that.
As long as the signal is blocked, we do (and for older kernels too).
I meant, that was not an intentional part of the design, but rather a
side effect of the implementation. We can pretend it was all part of a
master plan and document it, though.
Maybe we should turn complete_pio/complete_mmio to an ioctl, so that
we can control what happens exactly. Or maybe it's simplest to
document it as a feature and guarantee it. There's some merit in it
- only guest execution is the nonatomic part, so we only interrupt
that.
Right. So would you like a patch to x86.c to comment on this, on top of
complete_pio / mmio completion?
Documentation/kvm/api.txt. Note it's not x86 specific. Alex, can you
check if ppc complies?
qemu upstream needs a bit more work.
Could be as simple as raising a blocked exception that is unmasked
by kvm, then entering the guest.
The vcpu inner loop is not atomic in upstream as it is in qemu-kvm. It
breaks out to process pending events way too easily.
Hmm. We can add an explicit call to KVM_RUN.
Note we need to loop there. My 16-byte mmio patches (which never saw
the light of day) split 16-byte mmios into two 8-byte mmios issued back
to back, and we have to be prepared for that eventuality.
--
error compiling committee.c: too many arguments to function
--
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
