On 25.06.14 02:21, Scott Wood wrote:
On Wed, 2014-06-25 at 01:40 +0200, Alexander Graf wrote:
On 25.06.14 01:15, Scott Wood wrote:
On Wed, 2014-06-25 at 00:41 +0200, Alexander Graf wrote:
On 24.06.14 20:53, Scott Wood wrote:
The timer interrupt works, but I'm not fully convinced that it's a good
idea for things like MC events which we also block during critical
sections on e500v2.
Are you concerned about the guest seeing machine checks that are (more)
asynchronous with the error condition? e500v2 machine checks are always
asynchronous. From the core manual:
Machine check interrupts are typically caused by a hardware or
memory subsystem failure or by an attempt to access an invalid
address. They may be caused indirectly by execution of an
instruction, but may not be recognized or reported until long
after the processor has executed past the instruction that
caused the machine check. As such, machine check interrupts are
not thought of as synchronous or asynchronous nor as precise or
imprecise.
I don't think the lag would be a problem, and certainly it's better than
the current situation.
So what value would you set the timer to? If the value is too small, we
never finish the critical section. If it's too big, we add lots of jitter.
Maybe something like 100us?
Single stepping would be better, though.
Single stepping is hard enough to get right on interaction between QEMU,
KVM and the guest. I didn't really want to make that stuff any more
complicated.
I'm not sure that it would add much complexity. We'd just need to check
whether any source other than the magic page turned wants DCBR0_IC on,
to determine whether to exit to userspace or not.
What if the guest is single stepping itself? How do we determine when to
unset the bit again? When we get out of the critical section? How do we
know what the value was before we set it?
Keep track of each requester of single stepping separately, and only
ever set the real bit by ORing them.
Considering that Paul started working on integrating the in-kernel
emulator with KVM I think we're best off to just wait for that one and
then use it :).
Alex
--
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
