[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 24.07.14 at 18:29, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 07/24/2014 06:42 PM, Jan Beulich wrote:
>>>>> On 23.07.14 at 14:34, <rcojocaru@xxxxxxxxxxxxxxx> 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.

Without a code comment I can see why you clear .emulate_flags, but
I don't see the point of updating .gpa and .eip.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.