Avi Kivity wrote: > On 11/17/2009 11:16 AM, Jan Kiszka wrote: >> >>> That's because qemu has no need for this. But kvm is more than just >>> serving qemu, we try to be more general. That said, I can't really see >>> anyone wanting to arbitrarily inject an exception. >>> >> Well, the current API comes with millions of ways to shoot yourself into >> the foot. I don't think we can avoid them all. >> > > It would be nice to make the API saner. Do you know of more holes? > >>> The current interface is subtly dangerous, you can't run set(get()) as >>> you would expect. >>> >>> (well you can't with the lapic or the tsc msr either...) >>> >>> >> We may start documenting such dependency in kvm/api.txt. On the other >> hand, if you have a get/set interface vs. an inject channel, I think >> it's obvious that one can overwrite the other. >> > > Problem is, the inject channels are implied (APIC messages in smp > guests). Documentation is good, but if we can avoid it that's better. > > Note the only way to rmw vcpu events during smp is pausing the guest, > because of this race. That's what qemu does on reset and load. The alternative would be a complex get&lock/put&unlock + a queue for async events during the lock + an option to ignore what was queued when doing a true reset. Back to square #1: we would still need the proposed high-level interface to communicate the difference between replay and drop queue. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
