|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |