Brendan,
I was also getting the same BSOD error codes. I was very busy with
other stuff recently, so I pretty much didn't get any further than
what I said in my last mail. But I'm more than happy helping out if
you need anything debugging this. Just let me know
-Clemens
On Thu, Sep 27, 2012 at 4:55 PM, Brendan Dolan-Gavitt
<brenda...@gatech.edu> wrote:
> I also debugged this issue today and ended up in the same place --
> after enabling the CPUID_DE bit in cpuid.c, I am able to start the
> Windows 7 x64 installer, but it bluescreens with various messages
> after a minute or so (with various codes like
> DRIVER_IRQL_NOT_LESS_OR_EQUAL, KMODE_EXCEPTION_NOT_HANDLED, etc.).
>
> As far as I can tell, CPUID_DE says whether the CPU supports setting
> I/O breakpoints (break on in, out, ins, outs), and slightly changes
> how accesses to DR4 and DR5 behave. This is further controlled by a
> bit in the CR4 register. TCG does not support this yet; there is a
> comment in target-i386/helper.c:
> void hw_breakpoint_insert(CPUState *env, int index)
> {
> [...]
> case 2:
> /* No support for I/O watchpoints yet */
> break;
> [...]
> }
>
> I doubt this is the root cause of the Win7 x64 bluescreens, though; it
> seems pretty unlikely that the installer would be trying to use I/O
> debugging. I'll try to find the time to verify that no code is trying
> to set CR4.DE, though.
>
> So, I would also support having this bit turned on by default so that
> more people can investigate these crashes. I'll certainly be looking
> into them when I have time.
>
> For what it's worth, Windows 7 32-bit works quite well when running
> under qemu-system-x86_64.
>
> -Brendan
>
> For the sake of completeness, here's what I found in Intel's
> documentation on CPUID_DE, CR4.DE, and I/O breakpoints:
>
> Bit 2, DE. Debugging Extensions. Support for I/O breakpoints,
> including CR4.DE for controlling the feature, and optional trapping of
> accesses to DR4 and DR5.
> [...]
> Debug Registers DR4 and DR5
>
> Debug registers DR4 and DR5 are reserved when debug extensions are
> enabled (when the DE flag in control register CR4 is set) and attempts
> to reference the DR4 and DR5 registers cause invalid-opcode exceptions
> (#UD). When debug extensions are not enabled (when the DE flag is
> clear), these registers are aliased to debug registers DR6 and DR7.
> [...]
>
> Debug Control Register (DR7)
> [...]
> R/W0 through R/W3 (read/write) fields (bits 16, 17, 20, 21, 24, 25,
> 28, and 29) — Specifies the breakpoint condition for the corresponding
> breakpoint. The DE (debug extensions) flag in control register CR4
> determines how the bits in the R/Wn fields are interpreted. When the
> DE flag is set, the processor interprets bits as follows:
>
> 00 -- Break on instruction execution only.
> 01 -- Break on data writes only.
> 10 -- Break on I/O reads or writes.
> 11 -- Break on data reads or writes but not instruction fetches.
>
> When the DE flag is clear, the processor interprets the R/Wn bits the
> same as for the Intel386TM and Intel486TM
> processors, which is as follows:
>
> 00 -- Break on instruction execution only.
> 01 -- Break on data writes only.
> 10 -- Undefined.
> 11 -- Break on data reads or writes but not instruction fetches.
>
> On Mon, Sep 17, 2012 at 2:54 PM, Clemens Kolbitsch
> <kolbit...@lastline.com> wrote:
>> On Mon, Sep 17, 2012 at 11:19 AM, Aurelien Jarno <aurel...@aurel32.net>
>> wrote:
>>> On Mon, Sep 17, 2012 at 10:27:35AM -0700, Clemens Kolbitsch wrote:
>>>> On Mon, Sep 10, 2012 at 10:31 AM, Aurelien Jarno <aurel...@aurel32.net>
>>>> wrote:
>>>> > On Mon, Sep 10, 2012 at 06:23:43PM +0200, Stefan Weil wrote:
>>>> >> Am 10.09.2012 08:19, schrieb Clemens Kolbitsch:
>>>> >> >On Sat, Sep 8, 2012 at 11:22 AM, Clemens Kolbitsch
>>>> >> ><kolbit...@lastline.com> wrote:
>>>> >> >>On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil <s...@weilnetz.de> wrote:
>>>> >> >>>Am 08.09.2012 02:48, schrieb Clemens Kolbitsch:
>>>> >> >>>>Hi guys,
>>>> >> >>>>
>>>> >> >>>>I need to run Win7 64bit in Qemu without KVM support. I found a few
>>>> >> >>>>messages concerning the "unsupported architecture" problem (Windows
>>>> >> >>>>shows a BSOD with "STOP 0x0000005D ..." on boot), for example
>>>> >> >>>>
>>>> >> >>>>http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html
>>>> >> >>>>or
>>>> >> >>>>http://permalink.gmane.org/gmane.comp.emulators.qemu/92457
>>>> >> >>>>
>>>> >> >>>>but I don't think there was ever a solution to the problem - at
>>>> >> >>>>least
>>>> >> >>>>what is proposed does not work (I've tried stable and GIT versions).
>>>> >> >>>>
>>>> >> >>>>Since I have a decent background of modifying the Qemu internals,
>>>> >> >>>>I'm
>>>> >> >>>>more than happy to contribute to solving this issue, but I'm not
>>>> >> >>>>sure
>>>> >> >>>>if anyone is currently working on it (i.e., I don't want to start
>>>> >> >>>>at 0
>>>> >> >>>>in case someone is about to release a patch).
>>>> >> >>>>
>>>> >> >>>>Please let me know if there is already a know solution/workaround or
>>>> >> >>>>whoever might be working on it, please ping me so we can sync.
>>>> >> >>>>
>>>> >> >>>>BTW, in case this is necessary, here are the details of what I
>>>> >> >>>>need/what is not working:
>>>> >> >>>>
>>>> >> >>>>Qemu: current git-trunk,
>>>> >> >>>>
>>>> >> >>>>x86_64-softmmu$ ./qemu-system-x86_64 --version
>>>> >> >>>>QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice
>>>> >> >>>>Bellard
>>>> >> >>>>
>>>> >> >>>>host: 64bit, Ubuntu LTS12.04
>>>> >> >>>>
>>>> >> >>>>guest: 64bit Windows 7, no KVM possible
>>>> >> >>>>
>>>> >> >>>>Thanks!
>>>> >> >>>>-Clemens
>>>> >> >>>
>>>> >> >>>Hi Clemens,
>>>> >> >>>
>>>> >> >>>AFAIK, nobody is working on this issue which exists for a long time
>>>> >> >>>now.
>>>> >> >>>It would be great if you could find a solution to make QEMU without
>>>> >> >>>KVM
>>>> >> >>>work with Windows guests.
>>>> >> >>Hi Stefan,
>>>> >> >>
>>>> >> >>thanks for the info. I'll work on it then - hopefully I can come back
>>>> >> >>with a patch soon!
>>>> >> >>
>>>> >> >>>PS: It's QEMU, not Qemu. I modified the subject in my reply :-)
>>>> >> >>hehe, old habbit :) I'll try to remember - but why is the ML then
>>>> >> >>called "Qemu-devel" ? ;)
>>>> >> >After a first night of debugging, I have come up with a simple patch.
>>>> >> >I'm still testing and it seems it's not the ultimate solution yet
>>>> >> >(there are still bluescreens), but it already gets you much further
>>>> >> >while booting (using either the install CD or an actual image).
>>>> >> >
>>>> >> >This diffs against the current stable-1.1. As you can see, one of the
>>>> >> >feature bits of the CPUID are removed due to TCG not supporting them
>>>> >> >(or the TCG bitmask is just missing them). Since Qemu uses CPUID_DE in
>>>> >>
>>>> >> QEMU :-)
>>>> >>
>>>> >> >other locations, I'm assuming the bitmask is just wrong.
>>>> >> >
>>>> >> >Can someone confirm that TCG supports CPUID_DE ? If not, I'll need to
>>>> >> >work on this, otherwise I'll investigate why Win7 still crashes with a
>>>> >> >BSOD.
>>>> >> >
>>>> >> >Thanks!
>>>> >> >Clemens
>>>> >> >
>>>> >> >
>>>> >> >qemu$ git diff
>>>> >> >diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>>> >> >index 388bc5c..f2af36d 100644
>>>> >> >--- a/target-i386/cpu.c
>>>> >> >+++ b/target-i386/cpu.c
>>>> >> >@@ -259,7 +259,8 @@ typedef struct x86_def_t {
>>>> >> > CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP
>>>> >> > | \
>>>> >> > CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
>>>> >> > CPUID_PAT | \
>>>> >> > CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
>>>> >> >- CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS)
>>>> >> >+ CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | \
>>>> >> >+ CPUID_DE) /* needed by Win7 64bit */
>>>> >> > /* partly implemented:
>>>> >> > CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64)
>>>> >> > CPUID_PSE36 (needed for Solaris) */
>>>> >>
>>>> >> Hi Clemens,
>>>> >>
>>>> >> indeed, it looks like CPUID_DE fixes that BSOD with "STOP 0x0000005D
>>>> >> ...".
>>>> >> In my test scenario Windows now reboots instead of showing the BSOD.
>>>> >>
>>>> >> This commit added the TCG feature bit trimming which broke Windows:
>>>> >>
>>>> >> commit 551a2dec8fa55006a68393b9d6fb63577d2b3f1c
>>>> >> Autor: Andre Przywara <andre.przyw...@amd.com> Do Mär 11 14:39:03
>>>> >> 2010
>>>> >> Eintragender: Aurelien Jarno <aurel...@aurel32.net> Sa Mär 13
>>>> >> 16:50:54 2010
>>>> >>
>>>> >> x86/cpuid: add TCG feature bit trimming
>>>> >>
>>>> >> In KVM we trim the user provided CPUID bits to match the host CPU's
>>>> >> one. Introduce a similar feature to QEMU/TCG. Create a mask of TCG's
>>>> >> capabilities and apply it to the user bits.
>>>> >> This allows to let the CPU models reflect their native archetypes.
>>>> >>
>>>> >> Signed-off-by: Andre Przywara <andre.przyw...@amd.com>
>>>> >> Signed-off-by: Aurelien Jarno <aurel...@aurel32.net>
>>>> >>
>>>> >>
>>>> >> Andre, why don't we set the requested feature bits - no matter what
>>>> >> TCG provides?
>>>> >>
>>>> >
>>>> > Well the CPU flags are supposed to represent what a code can use. If we
>>>> > announce things that we don't support, some code might enable some
>>>> > features or instructions that are just causing an illegal instruction.
>>>> >
>>>> > Now the question is to know if DE is implemented in TCG or not. It
>>>> > *seems* there are some parts implemented, but not fully.
>>>> >
>>>> > --
>>>> > Aurelien Jarno GPG: 1024D/F1BCDB73
>>>> > aurel...@aurel32.net http://www.aurel32.net
>>>>
>>>> Aurelien,
>>>>
>>>> I understand the concern you mention above and agree that TCG should
>>>> announce only what it can do/supports. On the other hand, the current
>>>> TCG implementation seems to emulate Windows7 guests properly and
>>>> supporting this OS seems rather important to me. Maybe, allowing to
>>>> enable "experimental" support of this bit would be an acceptable
>>>> compromise and allow the community to move forward adding full support
>>>> eventually.
>>>
>>> For what I have read in this thread it seems the guest is still unstable
>>> after that. Are we sure this is not due to the missing parts of the DE
>>> implementation?
>>>
>>> Also it would be nice that someone actually looks at what is implemented
>>> and what is missing, so we have a better view on how to proceed.
>>>
>>>> In case you agree, I have included a patch below that enables this TCG
>>>> bit at compile-time (default=OFF) and warns that this is an
>>>> experimental feature. Please let me know what you think.
>>>
>>> We had this kind of hack in the past, but I am not sure it's something
>>> we want to re-add.
>>
>> The status of running Windows7 guests is the following: I manage to
>> run a guest in safe-mode quite reliably - only when booting in "normal
>> mode", there is a BSOD (after a few minutes of running, but it always
>> occurs). This tells me that the core kernel seems to work fine with
>> the emulation the TCG backend offers at this point. However, as you
>> said, it's possible that the missing implementation causes problems in
>> some other parts (e.g., device drivers) [ but it might also be
>> completely unrelated ].
>>
>> Given my little experience with the TCG backend, I doubt I can be of
>> much help at this point/for that part. This is the reason I decided to
>> post a patch that will at least move the implementation forward and
>> deliver what I promised a few days ago (solving the boot failure
>> mystery).
>>
>> -Clemens
>>
