From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:53190)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Ugqvm-0000l9-Ax
	for qemu-devel@nongnu.org; Mon, 27 May 2013 02:29:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Ugqvh-0002mS-8I
	for qemu-devel@nongnu.org; Mon, 27 May 2013 02:29:18 -0400
Received: from mail-ee0-f41.google.com ([74.125.83.41]:39458)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Ugqvh-0002m9-1f
	for qemu-devel@nongnu.org; Mon, 27 May 2013 02:29:13 -0400
Received: by mail-ee0-f41.google.com with SMTP id d4so3627411eek.14
	for <qemu-devel@nongnu.org>; Sun, 26 May 2013 23:29:12 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <51A2FD2F.1030702@redhat.com>
Date: Mon, 27 May 2013 08:29:03 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1369431456-11887-1-git-send-email-lersek@redhat.com>
	<51A147DB.2020606@twiddle.net> <51A1C8DF.506@redhat.com>
	<51A29E8E.10109@redhat.com>
In-Reply-To: <51A29E8E.10109@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] i386/translate: ignore 0x67 (PREFIX_ADR)
 on TARGET_X86_64 && CODE64()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Laszlo Ersek <lersek@redhat.com>
Cc: qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>

Il 27/05/2013 01:45, Laszlo Ersek ha scritto:
> I believe aflag++ is incorrect if the current default address size for
> 32-bit is 16-bit (ie. (s->code32 & 1) == 0).

... which cannot happen. :)

(Sorry, should have been more verbose).

See cpu_x86_load_seg_cache:

#ifdef TARGET_X86_64
            if ((env->hflags & HF_LMA_MASK) && (flags & DESC_L_MASK)) {
                /* long mode */
                env->hflags |= HF_CS32_MASK | HF_SS32_MASK | HF_CS64_MASK;
                env->hflags &= ~(HF_ADDSEG_MASK);
            } else
#endif
            {
                /* legacy / compatibility case */
                new_hflags = (env->segs[R_CS].flags & DESC_B_MASK)
                    >> (DESC_B_SHIFT - HF_CS32_SHIFT);
                env->hflags = (env->hflags & ~(HF_CS32_MASK | HF_CS64_MASK)) |
                    new_hflags;
            }

This is the only place where HF_CS64_MASK is added to env->hflags.  Then:

    dc->code64 = (flags >> HF_CS64_SHIFT) & 1;

#define CODE64(s) ((s)->code64)

Paolo

 In this case the first XOR
> (seeing the 0x67 prefix) flips it to 1, and the increment would change
> it to 2. aflag==2 corresponds to 64-bit address, but in 64-bit mode with
> the 0x67 prefix we must choose 32-bit.
> 
> (IOW in 32-bit mode the meaning of the 0x67 prefix is not absolute but
> relative.)
> 
> Laszlo
> 
>