Your message dated Sun, 6 Jan 2008 19:48:15 +0100
with message-id <[EMAIL PROTECTED]>
and subject line [qemu-devel] Bug#265989: qemu: QEMU acts incorrectly when TSS 
of v86 task is not in user mode page
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: qemu
Version: 0.6.0-1
Severity: normal

When operating in Virtual-8086 mode, when the processor hits an instruction
that should cause a 0x0D General Protection exception, it accesses the TSS of
the v86 task.

On an actual Intel processor, with paging enabled, the TSS of a Virtual-8086
mode task can be located in a page marked for supervisor-only access, and when
the processor attempts to access the TSS it does so without difficulty, even
though a v86 task is a user mode task, since it first switches to supervisor
mode to handle the exception.  The 0x0D General Protection exception proceeds
normally.

Under QEMU, if the TSS of the v86 task is located in a page marked for
supervisor-only access, instead of the expected 0x0D General Protection
exception, we instead receive a 0x0E Page Fault exception, with the error
code 5 (indicating a protection violation from user mode) and the CR2
register pointing to the 103rd byte of the v86 task's TSS.

This causes code that executes perfectly fine on real hardware or under Bochs
to fail when running under QEMU.  Contact me if you require sample code that
demonstrates this behavior.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=C, LC_CTYPE=C

Versions of packages qemu depends on:
ii  libc6                       2.3.2.ds1-16 GNU C Library: Shared libraries an
ii  libsdl1.2debian             1.2.7-7      Simple DirectMedia Layer

-- no debconf information


--- End Message ---
--- Begin Message ---
Version: 0.9.0-1

On Tue, Nov 30, 2004 at 11:30:36AM +0100, Guillem Jover wrote:
> Hi Guy,
> 
> On Mon, Aug 16, 2004 at 12:42:18AM -0500, Guy T. Rice wrote:
> > When operating in Virtual-8086 mode, when the processor hits an instruction
> > that should cause a 0x0D General Protection exception, it accesses the TSS 
> > of
> > the v86 task.
> > 
> > On an actual Intel processor, with paging enabled, the TSS of a Virtual-8086
> > mode task can be located in a page marked for supervisor-only access, and 
> > when
> > the processor attempts to access the TSS it does so without difficulty, even
> > though a v86 task is a user mode task, since it first switches to supervisor
> > mode to handle the exception.  The 0x0D General Protection exception 
> > proceeds
> > normally.
> > 
> > Under QEMU, if the TSS of the v86 task is located in a page marked for
> > supervisor-only access, instead of the expected 0x0D General Protection
> > exception, we instead receive a 0x0E Page Fault exception, with the error
> > code 5 (indicating a protection violation from user mode) and the CR2
> > register pointing to the 103rd byte of the v86 task's TSS.
> > 
> > This causes code that executes perfectly fine on real hardware or under 
> > Bochs
> > to fail when running under QEMU.  Contact me if you require sample code that
> > demonstrates this behavior.
> 
> Can you send a test case for that?
> 

No news from the submitter for more than 3 years. The problem has
probably been fixed meanwhile. Closing the bug, feel free to reopen it
if the problem is still present.


-- 
  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   [EMAIL PROTECTED]         | [EMAIL PROTECTED]
   `-    people.debian.org/~aurel32 | www.aurel32.net


--- End Message ---

Reply via email to