Jan Kiszka wrote:
But it seems the best thing to do is not to trap #DB in
update_exception_bitmap()?
Was my first idea as well. I do not understand what is going on there,
but when I simply exclude #DB from the exception bitmap in real mode,
the problem pops up again: #GP on the instruction that should raise the #DB.
Right. The docs say that a #DB (like all exceptions) will trap to the
protected mode handler through the #GP exception.
So, we do need kvm_queue_exception.
/me now wonders if there are not even more exceptions that have to be
forwarded. Right now we catch them all, but I did not find some path
via which actual ones are pushed to the guest.
Looks like update_exception_bitmap() assumes none. From a cursory look,
seems like #DE (divide error), #DB, #BP (Breakpoint), #OF (overflow),
#BR (range check) all need to be passed to the guest.
Hmm, unless KVM did something to fix up some exception, shouldn't all of
them be passed?
Yes, they should. But it can't be done using the exception bitmap.
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
