Yang, Sheng wrote: > Avi Kivity wrote: > >> Yang, Sheng wrote: >> >>> Another comment: I forgot if I answer the question on why eip should >>> > move > >>> backward. I did it because some instruction like "mov" will move eip >>> > to > >>> skip some dst/src operand when executing, so eip should be kept for >>> consistency. >>> >>> >> I think you're talking about >> >> >>> case 0xa0 ... 0xa1: /* mov */ >>> c->dst.ptr = (unsigned long *)&c->regs[VCPU_REGS_RAX]; >>> c->dst.val = c->src.val; >>> /* skip src displacement */ >>> c->eip += c->ad_bytes; >>> break; >>> >> ? >> >> If so, instead of skipping, we can fetch the address here. >> >> It's been annoying me for a long time; it causes a dependency on cr2 >> which we don't have in real mode (and with FlexPriority), and which is >> broken anyway because cr2 points at the wrong address during a page >> fault on the second page of a misaligned cross-page access. >> > > Yeah, like that. But I don't think only "mov" has memory operand, so > fetch > address in some determined place is better than inside every instruction > executing > code. > >
I think mov is the only instruction that uses absolute addresses without modrm encoding. And modrm encoding is implemented correctly for a long time. > Another thing, if we can use physical address as supplement of cr2 in > emulate_instrcutions, > that will be better. Any suggestion? > Sorry, I don't understand the question. I'd like to see cr2 completely removed from x86_emulate.c. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
