On 13/02/17 16:20, Jan Beulich wrote:
On 13.02.17 at 14:58, wrote:
>> On 13/02/17 11:40, Jan Beulich wrote:
>> On 10.02.17 at 17:38, wrote:
On 01/02/17 11:12, Jan Beulich wrote:
> Before adding more use of stubs cloned from decoded guest insns, guard
> ourselves against mist
>>> On 13.02.17 at 14:58, wrote:
> On 13/02/17 11:40, Jan Beulich wrote:
> On 10.02.17 at 17:38, wrote:
>>> On 01/02/17 11:12, Jan Beulich wrote:
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
>>
On 13/02/17 11:40, Jan Beulich wrote:
On 10.02.17 at 17:38, wrote:
>> On 01/02/17 11:12, Jan Beulich wrote:
>>> Before adding more use of stubs cloned from decoded guest insns, guard
>>> ourselves against mistakes there: Should an exception (with the
>>> noteworthy exception of #PF) occur ins
>>> On 10.02.17 at 17:38, wrote:
> On 01/02/17 11:12, Jan Beulich wrote:
>> Before adding more use of stubs cloned from decoded guest insns, guard
>> ourselves against mistakes there: Should an exception (with the
>> noteworthy exception of #PF) occur inside the stub, forward it to the
>> guest.
>
On 01/02/17 11:12, Jan Beulich wrote:
> Before adding more use of stubs cloned from decoded guest insns, guard
> ourselves against mistakes there: Should an exception (with the
> noteworthy exception of #PF) occur inside the stub, forward it to the
> guest.
Why exclude #PF ? Nothing in a stub shou
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
noteworthy exception of #PF) occur inside the stub, forward it to the
guest.
Since the exception fixup table entry can't encode the address of the
faulting insn it
