From: Blue Swirl <blauwirbel@gmail.com>
To: Bug 796202 <796202@bugs.launchpad.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 796202] [NEW] Doing a 64 bit load from a 32 bit local APIC register is allowed
Date: Mon, 13 Jun 2011 23:32:49 +0300 [thread overview]
Message-ID: <BANLkTimMhP98xYOn_E7rgKwUUDd+eNPOzQ@mail.gmail.com> (raw)
In-Reply-To: <20110612130357.689.11468.malonedeb@chaenomeles.canonical.com>
On Sun, Jun 12, 2011 at 4:03 PM, Robert Uhl <796202@bugs.launchpad.net> wrote:
> Public bug reported:
>
> Doing
>
> u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20;
>
> and later in an interrupt handler
>
> movq (lapic_idregister), %rcx
> movq (%rcx), %rcx
>
> in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots).
> On real hardware only
>
> movl (%rcx), %ecx
>
> works (also in qemu).
Thank you for the report. Currently QEMU devices only provide access
methods up to 32 bits, a 64 bit access is emulated with two 32 bit
accesses. So it is not possible to handle a 32 bit access differently
from a 64 bit one for now.
So far this hasn't been considered to be a problem for x86, though it
is clearly not correct for Sparc and Alpha. This report shows that it
is necessary to add 64 bit access methods (or otherwise handle 64 bit
accesses more realistically) since x86 is also affected.
Adding the 64 bit method would be a major refactoring though and there
are other designs possible.
next prev parent reply other threads:[~2011-06-13 20:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-12 13:03 [Qemu-devel] [Bug 796202] [NEW] Doing a 64 bit load from a 32 bit local APIC register is allowed Robert Uhl
2011-06-13 20:32 ` Blue Swirl [this message]
2017-05-19 19:44 ` [Qemu-devel] [Bug 796202] " Thomas Huth
2017-07-19 4:17 ` Launchpad Bug Tracker
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=BANLkTimMhP98xYOn_E7rgKwUUDd+eNPOzQ@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=796202@bugs.launchpad.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).