From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?5p2O5pil5aWHIDxBcnRodXIgQ2h1bnFpIExpPg==?= Subject: Re: [PATCH] Test case of emulating multibyte NOP Date: Thu, 6 Jun 2013 15:17:29 +0800 Message-ID: References: <1370448172-22960-1-git-send-email-yzt356@gmail.com> <20130605161352.GI4725@redhat.com> <20130606054032.GM4725@redhat.com> <20130606070237.GT4725@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm , Paolo Bonzini To: Gleb Natapov Return-path: Received: from mail-lb0-f178.google.com ([209.85.217.178]:49142 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940Ab3FFHSd convert rfc822-to-8bit (ORCPT ); Thu, 6 Jun 2013 03:18:33 -0400 Received: by mail-lb0-f178.google.com with SMTP id y6so1265514lbh.23 for ; Thu, 06 Jun 2013 00:18:32 -0700 (PDT) In-Reply-To: <20130606070237.GT4725@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 6, 2013 at 3:02 PM, Gleb Natapov wrote: > On Thu, Jun 06, 2013 at 02:49:14PM +0800, =E6=9D=8E=E6=98=A5=E5=A5=87= wrote: >> On Thu, Jun 6, 2013 at 1:40 PM, Gleb Natapov wrote= : >> > On Thu, Jun 06, 2013 at 12:28:16AM +0800, =E6=9D=8E=E6=98=A5=E5=A5= =87 wrote: >> >> On Thu, Jun 6, 2013 at 12:13 AM, Gleb Natapov w= rote: >> >> > This time the email is perfect :) >> >> > >> >> > On Thu, Jun 06, 2013 at 12:02:52AM +0800, Arthur Chunqi Li wrot= e: >> >> >> Add multibyte NOP test case to kvm-unit-tests. This version ad= ds test cases into x86/realmode.c. This can test one of bugs when booti= ng RHEL5.9 64-bit. >> >> >> >> >> >> Signed-off-by: Arthur Chunqi Li >> >> >> --- >> >> >> x86/realmode.c | 24 ++++++++++++++++++++++++ >> >> >> 1 file changed, 24 insertions(+) >> >> >> >> >> >> diff --git a/x86/realmode.c b/x86/realmode.c >> >> >> index 981be08..e103ca6 100644 >> >> >> --- a/x86/realmode.c >> >> >> +++ b/x86/realmode.c >> >> >> @@ -1504,6 +1504,29 @@ static void test_fninit(void) >> >> >> report("fninit", 0, fsw =3D=3D 0 && (fcw & 0x103f) =3D=3D= 0x003f); >> >> >> } >> >> >> >> >> >> +static void test_nopl(void) >> >> >> +{ >> >> >> + MK_INSN(nopl1, ".byte 0x90\n\r"); // 1 byte nop >> >> >> + MK_INSN(nopl2, ".byte 0x66, 0x90\n\r"); // 2 bytes nop >> >> >> + MK_INSN(nopl3, ".byte 0x0f, 0x1f, 0x00\n\r"); // 3 bytes= nop >> >> >> + MK_INSN(nopl4, ".byte 0x0f, 0x1f, 0x40, 0x00\n\r"); // 4= bytes nop >> >> > But all nops below that are not supported in 16 bit mode. You c= an >> >> > disassemble realmode.elf in 16bit node (objdump -z -d -mi8086 >> >> > x86/realmode.elf) and check yourself. Lets not complicate thing= s for now >> >> > and test only those that are easy to test. >> >> Yes. But what if a 7-bytes nop runs in 16bit mode? Just the same = as >> >> https://bugzilla.redhat.com/show_bug.cgi?id=3D967652 >> >> >> > It cannot. In 16 bit mode it is decoded as two instructions: >> > 0f 1f 80 00 00 nopw 0x0(%bx,%si) >> > 00 00 add %al,(%bx,%si) >> > >> OK, I will just test the first four nop instructions. Should I commi= t >> another patch? >> > Yes, all others will have to go into emulator.c. You mean I need also add another test for nopl5~nop9 in emulator.c with the "trick" emulator mode? I will commit a modified one for realmode.c since some other works should be done in emulator.c. > >> Arthur. >> >> >> DR6=3D00000000ffff0ff0 DR7=3D0000000000000400 >> >> EFER=3D0000000000000500 >> >> Code=3D00 00 e9 50 ff ff ff 00 00 00 00 85 d2 74 20 45 31 c0 31 c= 9 <0f> >> >> 1f 80 00 00 00 00 0f b6 04 31 41 83 c0 01 88 04 39 48 83 c1 01 41= 39 >> >> d0 75 ec 48 89 f8 >> >> >> >> The error code is "0f 1f 80 00 00 00 00", which is a 7-bytes nop.= Will >> >> the emulator runs well in that case when booting RHEL5.9 64-bit? >> >> >> >> Arthur >> >> >> >> >> >> > >> >> >> + MK_INSN(nopl5, ".byte 0x0f, 0x1f, 0x44, 0x00, 0x00\n\r")= ; // 5 bytes nop >> >> >> + MK_INSN(nopl6, ".byte 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00= \n\r"); // 6 bytes nop >> >> >> + MK_INSN(nopl7, ".byte 0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00= , 0x00\n\r"); // 7 bytes nop >> >> >> + MK_INSN(nopl8, ".byte 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00= , 0x00, 0x00\n\r"); // 8 bytes nop >> >> >> + MK_INSN(nopl9, ".byte 0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00= , 0x00, 0x00, 0x00\n\r"); // 9 bytes nop >> >> >> + exec_in_big_real_mode(&insn_nopl1); >> >> >> + exec_in_big_real_mode(&insn_nopl2); >> >> >> + exec_in_big_real_mode(&insn_nopl3); >> >> >> + exec_in_big_real_mode(&insn_nopl4); >> >> >> + exec_in_big_real_mode(&insn_nopl5); >> >> >> + exec_in_big_real_mode(&insn_nopl6); >> >> >> + exec_in_big_real_mode(&insn_nopl7); >> >> >> + exec_in_big_real_mode(&insn_nopl8); >> >> >> + exec_in_big_real_mode(&insn_nopl9); >> >> >> + report("nopl", 0, 1); >> >> >> +} >> >> >> + >> >> >> void realmode_start(void) >> >> >> { >> >> >> test_null(); >> >> >> @@ -1548,6 +1571,7 @@ void realmode_start(void) >> >> >> test_xlat(); >> >> >> test_salc(); >> >> >> test_fninit(); >> >> >> + test_nopl(); >> >> >> >> >> >> exit(0); >> >> >> } >> >> >> -- >> >> >> 1.7.9.5 >> >> > >> >> > -- >> >> > Gleb. >> > >> > -- >> > Gleb. > > -- > Gleb. -- Arthur Chunqi Li Department of Computer Science School of EECS Peking University Beijing, China