Re: [PATCH RFC V3 5/5] xen: Handle resumed instruction based on previous mem_event reply

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 07/24/2014 06:42 PM, Jan Beulich wrote:
>>>> On 23.07.14 at 14:34, <rcojocaru@bitdefender.com> wrote:
>> +            {
>> +                v->arch.mem_event.emulate_flags = MEM_EVENT_FLAG_EMULATE;
>> +                v->arch.mem_event.gpa = gpa;
>> +                v->arch.mem_event.eip = eip;
>> +            }
>> +        }
>> +    }
>> +
>> +    if ( v->arch.mem_event.gpa != gpa || v->arch.mem_event.eip != eip )
>> +    {
>> +        v->arch.mem_event.emulate_flags = 0;
>> +        v->arch.mem_event.gpa = gpa;
>> +        v->arch.mem_event.eip = eip;
>> +    }
> 
> So the default value for gpa and eip is zero - how do you deal with
> guests having code/data at virtual/physical address zero? It would
> seem to me that you need a "valid" qualification for these fields, but
> since the purpose of this last block isn't really clear to me maybe I'm
> simply missing something and a comment might help.

Some instruction may trigger a page fault, which then sends out a
mem_event, and the reply might have the MEM_EVENT_FLAG_EMULATE flag set.
If it is set, we could simply emulate the next instruction that triggers
a page fault, but unless eip and gpa match, that might be some other
instruction, not the one that originally triggered the mem_event.

What the last block does is it verifies that we're not emulating an
instruction different from the one that triggered the mem_event in the
first place. If this is not the same instruction, then don't emulate it
(but send out a new mem_event for it), and just reset those values.

That the default values are zero has not been a problem for us, but I do
see how that might not be desirable for other clients. A "valid"
qualification might indeed be the solution for this.


Thanks,
Razvan Cojocaru