[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 |