[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 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. 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |