| Message ID | CAN+VXVNYLC9=iX_TNcx_ePWsw8UZj7JRTHLqvzFSRyyes6=U_A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Sep 17, 2012 at 10:27:35AM -0700, Clemens Kolbitsch wrote: > On Mon, Sep 10, 2012 at 10:31 AM, Aurelien Jarno <aurelien@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 > >> ><kolbitsch@lastline.com> wrote: > >> >>On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil <sw@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.przywara@amd.com> Do Mär 11 14:39:03 > >> 2010 > >> Eintragender: Aurelien Jarno <aurelien@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.przywara@amd.com> > >> Signed-off-by: Aurelien Jarno <aurelien@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 > > aurelien@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. Aurelien
On Mon, Sep 17, 2012 at 11:19 AM, Aurelien Jarno <aurelien@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 <aurelien@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 >> >> ><kolbitsch@lastline.com> wrote: >> >> >>On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil <sw@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.przywara@amd.com> Do Mär 11 14:39:03 >> >> 2010 >> >> Eintragender: Aurelien Jarno <aurelien@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.przywara@amd.com> >> >> Signed-off-by: Aurelien Jarno <aurelien@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 >> > aurelien@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
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
<kolbitsch@lastline.com> wrote:
> On Mon, Sep 17, 2012 at 11:19 AM, Aurelien Jarno <aurelien@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 <aurelien@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
>>> >> ><kolbitsch@lastline.com> wrote:
>>> >> >>On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil <sw@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.przywara@amd.com> Do Mär 11 14:39:03
>>> >> 2010
>>> >> Eintragender: Aurelien Jarno <aurelien@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.przywara@amd.com>
>>> >> Signed-off-by: Aurelien Jarno <aurelien@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
>>> > aurelien@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
>
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 <brendandg@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 > <kolbitsch@lastline.com> wrote: >> On Mon, Sep 17, 2012 at 11:19 AM, Aurelien Jarno <aurelien@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 <aurelien@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 >>>> >> ><kolbitsch@lastline.com> wrote: >>>> >> >>On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil <sw@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.przywara@amd.com> Do Mär 11 14:39:03 >>>> >> 2010 >>>> >> Eintragender: Aurelien Jarno <aurelien@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.przywara@amd.com> >>>> >> Signed-off-by: Aurelien Jarno <aurelien@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 >>>> > aurelien@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 >>
diff --git a/configure b/configure index 7e23309..8d66034 100755 --- a/configure +++ b/configure @@ -220,6 +220,7 @@ want_tools="yes" libiscsi="" coroutine="" seccomp="" +experimental_windows7_guest="no" # parse CC options first for opt do @@ -876,6 +877,10 @@ for opt do ;; --disable-seccomp) seccomp="no" ;; + --enable-experimental-windows7-support) experimental_windows7_guest="yes" + ;; + --disable-experimental-windows7-support) experimental_windows7_guest="no" + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac @@ -1164,6 +1169,12 @@ echo " --disable-guest-agent disable building of the QEMU Guest Agent" echo " --enable-guest-agent enable building of the QEMU Guest Agent" echo " --disable-seccomp disable seccomp support" echo " --enable-seccomp enables seccomp support" +echo " --enable-experimental-windows7-support" +echo " enable support for emulating Windows7" +echo " guests (experimental!)" +echo " --disable-experimental-windows7-support" +echo " disable support for emulating Windows7" +echo " guests" echo " --with-coroutine=BACKEND coroutine backend. Supported options:" echo " gthread, ucontext, sigaltstack, windows" echo "" @@ -3203,6 +3214,7 @@ echo "OpenGL support $opengl" echo "libiscsi support $libiscsi" echo "build guest agent $guest_agent" echo "seccomp support $seccomp" +echo "Windows7 support $experimental_windows7_guest" echo "coroutine backend $coroutine_backend" if test "$sdl_too_old" = "yes"; then @@ -3506,6 +3518,10 @@ if test "$seccomp" = "yes"; then echo "CONFIG_SECCOMP=y" >> $config_host_mak fi +if test "$experimental_windows7_guest" = "yes"; then + echo "CONFIG_WINDOWS7_GUEST_SUPPORT=y" >> $config_host_mak +fi + # XXX: suppress that if [ "$bsd" = "yes" ] ; then echo "CONFIG_BSD=y" >> $config_host_mak diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 423e009..f5c9f0e 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -261,11 +261,21 @@ typedef struct x86_def_t { CPUID_PAE | CPUID_SEP | CPUID_APIC) #define EXT2_FEATURE_MASK 0x0183F3FF +#if defined(CONFIG_WINDOWS7_GUEST_SUPPORT) + /* this feature is implemented only partly, but required to + * emulate Windows7 operating system guests. Most of the + * functionality is there, so we consider it 'experimental' */ +#define TCG_FEATURE_CPUID_DE CPUID_DE +#else +#define TCG_FEATURE_CPUID_DE 0 +#endif + #define TCG_FEATURES (CPUID_FP87 | CPUID_PSE | CPUID_TSC | CPUID_MSR | \ 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 | \ + TCG_FEATURE_CPUID_DE) /* partly implemented: CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64) CPUID_PSE36 (needed for Solaris) */