From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cs7J6-0004aE-5J for qemu-devel@nongnu.org; Fri, 21 Jan 2005 17:31:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cs7Iv-0004Uc-8h for qemu-devel@nongnu.org; Fri, 21 Jan 2005 17:31:00 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cs7Iu-0004Q4-E5 for qemu-devel@nongnu.org; Fri, 21 Jan 2005 17:30:56 -0500 Received: from [195.250.128.75] (helo=smtp2.vol.cz) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cs6wK-000565-CT for qemu-devel@nongnu.org; Fri, 21 Jan 2005 17:07:36 -0500 Received: from [10.0.0.2] (prg-v-6-220.static.adsl.vol.cz [62.177.70.220]) by smtp2.vol.cz (8.12.9p2/8.12.9) with ESMTP id j0LM7X8T090941 for ; Fri, 21 Jan 2005 23:07:34 +0100 (CET) (envelope-from xnavara@volny.cz) Message-ID: <41F17D2C.2090300@volny.cz> Date: Fri, 21 Jan 2005 23:07:40 +0100 From: Filip Navara MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] minor x86-64 corrections References: <41F1670C.2060805@volny.cz> <41F177D2.6040809@bellard.org> In-Reply-To: <41F177D2.6040809@bellard.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Fabrice Bellard wrote: > Filip Navara wrote: > >> Changelog: >> >> 2005-01-21 Filip Navara >> >> * Add support for CR8 register. >> * Don't throw exception when assigning zero to SS register >> in 64-bit mode. >> >> BTW, the callgate support for x86-64 in long mode is broken. See=20 >> "AMD64 Architecture Programmer=92s Manual Volume 3: General-Purpose an= d=20 >> System Instructions", page 90. Anybody cares to fix it? > > > No time yet. It would be interesting to find the problem for the Linux=20 > user code too. Ok, I'll try to fix it myself. BTW the same issue is present also in the=20 protected mode JMP code. >> +++ target-i386/helper.c 21 Jan 2005 20:13:30 -0000 >> @@ -1454,8 +1454,13 @@ >> selector &=3D 0xffff; >> if ((selector & 0xfffc) =3D=3D 0) { >> /* null selector case */ >> - if (seg_reg =3D=3D R_SS) >> + if (seg_reg =3D=3D R_SS) { >> +#ifdef TARGET_X86_64 >> + if (env->hflags & HF_CS64_MASK) >> + return; >> +#endif >> raise_exception_err(EXCP0D_GPF, 0); >> + } >> cpu_x86_load_seg_cache(env, seg_reg, selector, 0, 0, 0); > > --- target-i386/helper.c 16 Jan 2005 23:35:43 -0000 1.40 > > Maybe the SS segment cache should be set to zero ? I'm not sure really, but I guess you're right. MOV documentation: ... "It is possible to move a null segment selector value (0000=960003h)=20 into the DS, ES, FS, or GS register. This action does not cause a general protection fault,=20 but a subsequent reference to such a segment does cause a #GP exception. For more=20 information about segment selectors, see =93Segment Selectors and Registers=94 on page 84."= ... GPF is exception is thrown if ... "The SS register was loaded with a=20 null segment selector in non-64-bit mode or while CPL =3D 3." ... >> +void OPPROTO op_movtl_T0_cr7(void) >> +{ >> + T0 =3D (cpu_get_apic_tpr(env) & 0xf) >> 4; >> +} > > Why do you call it cr7 ?=20 Actually that's a typo. Filip Navara navaraf@reactos.com