All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filip Navara <xnavara@volny.cz>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] minor x86-64 corrections
Date: Fri, 21 Jan 2005 23:07:40 +0100	[thread overview]
Message-ID: <41F17D2C.2090300@volny.cz> (raw)
In-Reply-To: <41F177D2.6040809@bellard.org>

Fabrice Bellard wrote:

> Filip Navara wrote:
>
>> Changelog:
>>
>> 2005-01-21 Filip Navara <navaraf@reactos.com>
>>
>> * 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 
>> "AMD64 Architecture Programmer’s Manual Volume 3: General-Purpose and 
>> System Instructions", page 90. Anybody cares to fix it?
>
>
> No time yet. It would be interesting to find the problem for the Linux 
> user code too.

Ok, I'll try to fix it myself. BTW the same issue is present also in the 
protected mode JMP code.

>> +++ target-i386/helper.c    21 Jan 2005 20:13:30 -0000
>> @@ -1454,8 +1454,13 @@
>>      selector &= 0xffff;
>>      if ((selector & 0xfffc) == 0) {
>>          /* null selector case */
>> -        if (seg_reg == R_SS)
>> +        if (seg_reg == 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–0003h) 
into the DS, ES, FS,
or GS register. This action does not cause a general protection fault, 
but a subsequent
reference to such a segment does cause a #GP exception. For more 
information about
segment selectors, see “Segment Selectors and Registers” on page 84." ...

GPF is exception is thrown if ... "The SS register was loaded with a 
null segment selector in non-64-bit mode or while CPL = 3." ...

>> +void OPPROTO op_movtl_T0_cr7(void)
>> +{
>> +    T0 = (cpu_get_apic_tpr(env) & 0xf) >> 4;
>> +}
>
> Why do you call it cr7 ? 

Actually that's a typo.

Filip Navara
navaraf@reactos.com

  reply	other threads:[~2005-01-21 22:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 20:33 [Qemu-devel] [PATCH] minor x86-64 corrections Filip Navara
2005-01-21 21:44 ` Fabrice Bellard
2005-01-21 22:07   ` Filip Navara [this message]
2005-01-21 22:27     ` Filip Navara
  -- strict thread matches above, loose matches on Subject: below --
2005-01-23 10:35 Filip Navara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41F17D2C.2090300@volny.cz \
    --to=xnavara@volny.cz \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.