Re: [PATCH 1/2] kvm-unit-tests: Add a func to run instruction in emulator

[Gleb Natapov <gleb@redhat.com>]

On Sun, Jun 09, 2013 at 11:23:26PM +0800, 李春奇 <Arthur Chunqi Li> wrote:
> On Sun, Jun 9, 2013 at 10:09 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Jun 09, 2013 at 09:22:27PM +0800, 李春奇 <Arthur Chunqi Li> wrote:
> >> On Sun, Jun 9, 2013 at 8:49 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Sun, Jun 09, 2013 at 08:44:32PM +0800, 李春奇 <Arthur Chunqi Li> wrote:
> >> >> On Sun, Jun 9, 2013 at 7:07 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> > On Fri, Jun 07, 2013 at 10:31:38AM +0800, Arthur Chunqi Li wrote:
> >> >> >> Add a function trap_emulator to run an instruction in emulator.
> >> >> >> Set inregs first (%rax, %rsp, %rbp, %rflags have special usage and
> >> >> >> cannot set in inregs), put instruction codec in alt_insn and call
> >> >> >> func with alt_insn_length. Get results in outregs.
> >> >> >>
> >> >> > Why %rax, %rsp, %rbp, %rflags cannot be set in inregs?
> >> >> >
> >> >> > %rax because trapping instruction uses it? Use one that does not use
> >> >> > register at all: MOV r/m32, imm32
> >> >> I don't know why set %rax before call alt_insn_page can cause error. I
> >> >> use "xchg %%rax, 0+%[save]" before "call *%1" and the %rcx is not set
> >> >> correctly.
> >> > We better find this out :)
> >> I found that before calling alt_insn_page, address of "mem" is saved
> >> to %rax, why?
> > Because instruction that we use to trigger vmexit is mov %eax, (%rax) so
> > MMOI address mem is loaded into %rax before jumping into it.
> I think this is why changing %rax will cause error. If we use mov
> %eax, (%rax) to trigger vmexit, and %rax is changed before calling
> alt_insn_page, codes in alt_insn_page will not be executed and return
> directly.
> I changed the codes which trigger vmexit to "mov %eax, (%r8)" and set
> "mem" to %r8 before calling alt_insn_page, it runs OK.
> 
Just use an instruction that does not use registers at all. mov $1, addr
where addr is immediate and encoded from mem parameter.

> Besides, I also don't know if changed %rflags may cause some
> unpredictable actions, so now we just treat it with no error :)
If test sets rflags to a value that causes crashes this is a test bug,
no need to prevent this from happening.

--
			Gleb.