cs 23453:4f4970d2848d beaks Win 7

cs 23453:4f4970d2848d beaks Win 7

[Christoph Egger]

Hi Ian,

cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
as shown in the device manager and this causes a BSOD on shutdown.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: cs 23453:4f4970d2848d beaks Win 7

[Ian Campbell]

On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote:
> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
> as shown in the device manager and this causes a BSOD on shutdown.

Are you 100% sure it's that cset? It moves a few things around but it
doesn't actually remove anything.

Ian.

Re: cs 23453:4f4970d2848d beaks Win 7

[Christoph Egger]

On 09/01/11 10:50, Ian Campbell wrote:
> On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote:
>> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
>> as shown in the device manager and this causes a BSOD on shutdown.
>
> Are you 100% sure it's that cset?

Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel
and toolchain, just replaced the hvmloader binary and booted a
Win7 guest (both 32bit and 64bit) with one vcpu.

An hvmloader binary built from c/s 23452 works.
BTW: I use the rombios.

 > It moves a few things around but it doesn't actually remove anything.

 From a first glance, bios_info_setup() is called earlier with this c/s.


Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: cs 23453:4f4970d2848d beaks Win 7

[Ian Campbell]

On Thu, 2011-09-01 at 10:08 +0100, Christoph Egger wrote:
> On 09/01/11 10:50, Ian Campbell wrote:
> > On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote:
> >> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
> >> as shown in the device manager and this causes a BSOD on shutdown.
> >
> > Are you 100% sure it's that cset?
> 
> Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel
> and toolchain, just replaced the hvmloader binary and booted a
> Win7 guest (both 32bit and 64bit) with one vcpu.
> 
> An hvmloader binary built from c/s 23452 works.
> BTW: I use the rombios.
> 
>  > It moves a few things around but it doesn't actually remove anything.
> 
>  From a first glance, bios_info_setup() is called earlier with this c/s.

I guess something could be clobbering that datastructure but there isn't
much of interest in it now anyway. This stuff has subsequently been
reorganised even more and moved around etc. I presume it is broken even
for xen-unstable.hg 23809:85b29185c911?

I'll see if I can repro. Can you post your guest cfg file please?

Ian.

Re: Re: cs 23453:4f4970d2848d beaks Win 7

[Christoph Egger]

On 09/01/11 11:32, Ian Campbell wrote:
> On Thu, 2011-09-01 at 10:08 +0100, Christoph Egger wrote:
>> On 09/01/11 10:50, Ian Campbell wrote:
>>> On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote:
>>>> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
>>>> as shown in the device manager and this causes a BSOD on shutdown.
>>>
>>> Are you 100% sure it's that cset?
>>
>> Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel
>> and toolchain, just replaced the hvmloader binary and booted a
>> Win7 guest (both 32bit and 64bit) with one vcpu.
>>
>> An hvmloader binary built from c/s 23452 works.
>> BTW: I use the rombios.
>>
>>   >  It moves a few things around but it doesn't actually remove anything.
>>
>>   From a first glance, bios_info_setup() is called earlier with this c/s.
>
> I guess something could be clobbering that datastructure but there isn't
> much of interest in it now anyway. This stuff has subsequently been
> reorganised even more and moved around etc. I presume it is broken even
> for xen-unstable.hg 23809:85b29185c911?

Yes, it is.

> I'll see if I can repro. Can you post your guest cfg file please?


builder="hvm"
memory=2048
name="win7"
vcpus=1
acpi=1
apic=1
vif = [ 'type=ioemu, model=e1000' ]
disk = [ 'file:/hvm-guest/win7.img,ioemu:hda,w' ]
sdl=0
vnc=1
stdvga=1
usb=1
usbdevice='tablet'


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

RE: Re: cs 23453:4f4970d2848d beaks Win 7

[Hao, Xudong]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

Windows2008 guest has this BSOD issue too.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1778


Thanks,
-Xudong

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christoph Egger
> Sent: Thursday, September 01, 2011 5:08 PM
> To: Ian Campbell
> Cc: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7
> 
> On 09/01/11 10:50, Ian Campbell wrote:
> > On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote:
> >> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
> >> as shown in the device manager and this causes a BSOD on shutdown.
> >
> > Are you 100% sure it's that cset?
> 
> Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel and
> toolchain, just replaced the hvmloader binary and booted a
> Win7 guest (both 32bit and 64bit) with one vcpu.
> 
> An hvmloader binary built from c/s 23452 works.
> BTW: I use the rombios.
> 
>  > It moves a few things around but it doesn't actually remove anything.
> 
>  From a first glance, bios_info_setup() is called earlier with this c/s.
> 
> 
> Christoph
> 
> 
> --
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht
> Muenchen, HRB Nr. 43632
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Re: cs 23453:4f4970d2848d beaks Win 7

[Tobias Geiger]

Hallo List!,

To bring even more confusion to this:


W7 64bit (prof) HVM guest works fine here (i.e. no BSOD like the ones described 
here) with:

xen_changeset          : Thu Aug 25 12:03:14 2011 +0100 23791:227130622561

Standard qemu, no seabios/upstreamqemu.

OTOH - see the screenshot here: 
http://img199.imagevenue.com/img.php?image=84661_win64_strange_cpus_122_233lo.jpg

This "behaviour" is normal here - since Win7_64, in Win7_32 and WinXP_32 this 
was no the case iirc.
Windows7_64 seems to have Problems "to start" the CPU (Code: 10) - but with no 
visible consquences besides this funny looking devicemanager... 
Here's the xen cfg for this guest:

acpi=1
apic=1
boot="c"
builder = 'hvm'
cpus = [ "2", "3", "4", "5", "6", "7" ]
disk = ['tap:qcow2:/home/kaeptnb/.kvm/windows7.qcow2,ioemu:hda,w' ]
gfx_passthru=0
hpet=1
keymap = "de"
memory = '4900'
monitor=1
name = 'win'
on_crash = "preserve"
on_poweroff = "preserve"
on_reboot = "preserve"
on_xend_stop = "shutdown"
pae=1
pci = [ '08:00.0' , '08:00.1'  , '00:1a.7' ]
pci_msitranslate=1
pci_power_mgmt = 1
sdl=0
serial = 'pty'
shadow_memory=32
stdvga=1
uuid = "someuuid :)"
vcpus = 6
vif = ['type=ioemu, bridge=br0, mac=anymac:), model=e1000' ]
viridian=1
vnc=1
vncconsole=0
vncpasswd=""
xen_platform_pci=1



Greetings
Tobias

Am Donnerstag, 1. September 2011, 11:45:03 schrieb Christoph Egger:
> On 09/01/11 11:32, Ian Campbell wrote:
> > On Thu, 2011-09-01 at 10:08 +0100, Christoph Egger wrote:
> >> On 09/01/11 10:50, Ian Campbell wrote:
> >>> On Thu, 2011-09-01 at 09:36 +0100, Christoph Egger wrote:
> >>>> cs 23453:4f4970d2848d breaks Win 7. It fails to initialize the CPUs
> >>>> as shown in the device manager and this causes a BSOD on shutdown.
> >>> 
> >>> Are you 100% sure it's that cset?
> >> 
> >> Yes, I am. I found that c/s by bisecting. I used the latest xen-kernel
> >> and toolchain, just replaced the hvmloader binary and booted a
> >> Win7 guest (both 32bit and 64bit) with one vcpu.
> >> 
> >> An hvmloader binary built from c/s 23452 works.
> >> BTW: I use the rombios.
> >> 
> >>   >  It moves a few things around but it doesn't actually remove
> >>   >  anything.
> >>   
> >>   From a first glance, bios_info_setup() is called earlier with this
> >>   c/s.
> > 
> > I guess something could be clobbering that datastructure but there isn't
> > much of interest in it now anyway. This stuff has subsequently been
> > reorganised even more and moved around etc. I presume it is broken even
> > for xen-unstable.hg 23809:85b29185c911?
> 
> Yes, it is.
> 
> > I'll see if I can repro. Can you post your guest cfg file please?
> 
> builder="hvm"
> memory=2048
> name="win7"
> vcpus=1
> acpi=1
> apic=1
> vif = [ 'type=ioemu, model=e1000' ]
> disk = [ 'file:/hvm-guest/win7.img,ioemu:hda,w' ]
> sdl=0
> vnc=1
> stdvga=1
> usb=1
> usbdevice='tablet'

Re: Re: cs 23453:4f4970d2848d beaks Win 7

[Ian Campbell]

The issue with 23453:4f4970d2848d is that it uses madt_csum_addr and
madt_lapic0_addr to initialise bios_info before they have themselves
been initialised.

But in xen-unstable.hg tip everything has moved around and the issue now
turns out to be that we clear the acpi_info struct _after_ we've setup
the madt_* fields. Ooops!

Thanks for reporting.

Cheers,
Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1314889401 -3600
# Node ID bb97bd46df6c6d8562759a964ebf6c31b6361a7a
# Parent  85b29185c9119ff9139596251d7bd13586853994
hvmloader: don't clear acpi_info after filling in some fields

In particular the madt_lapic0_addr and madt_csum_addr fields are
filled in while building the tables.

This fixes a bluescreen on shutdown with certain versions of Windows.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r 85b29185c911 -r bb97bd46df6c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Thu Sep 01 09:39:25 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Thu Sep 01 16:03:21 2011 +0100
@@ -277,6 +277,8 @@ void acpi_build_tables(unsigned int phys
     unsigned long        secondary_tables[16];
     int                  nr_secondaries, i;
 
+    memset(acpi_info, 0, sizeof(*acpi_info));
+
     /*
      * Fill in high-memory data structures, starting at @buf.
      */
@@ -375,7 +377,6 @@ void acpi_build_tables(unsigned int phys
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
-    memset(acpi_info, 0, sizeof(*acpi_info));
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
     acpi_info->lpt1_present = lpt_exists(0x378);

Re: Re: cs 23453:4f4970d2848d beaks Win 7

[Ian Campbell]

On Thu, 2011-09-01 at 15:28 +0100, Tobias Geiger wrote:

> OTOH - see the screenshot here: 
> http://img199.imagevenue.com/img.php?image=84661_win64_strange_cpus_122_233lo.jpg
> 
> This "behaviour" is normal here - since Win7_64, in Win7_32 and WinXP_32 this 
> was no the case iirc.

Does the patch I posted for Christoph's issue help?

If not then please can you try and identify what the last working
changeset is for you e.g. by bisecting. You should only need to
rebuild/reinstall the tools/firmware directory on each iteration.

Thanks,

Ian.

Re: Re: cs 23453:4f4970d2848d beaks Win 7

[Christoph Egger]

On 09/01/11 17:05, Ian Campbell wrote:
> The issue with 23453:4f4970d2848d is that it uses madt_csum_addr and
> madt_lapic0_addr to initialise bios_info before they have themselves
> been initialised.
>
> But in xen-unstable.hg tip everything has moved around and the issue now
> turns out to be that we clear the acpi_info struct _after_ we've setup
> the madt_* fields. Ooops!
>
> Thanks for reporting.
>
> Cheers,
> Ian.

I successfully tested your patch with Windows 7 (both 32bit and 64bit).
Windows 7 can initialize its CPUs and no longer crashes on shutdown.
Thanks for fixing. Please apply the fix.

Tested-and-acked-by: Christoph Egger <Christoph.Egger@amd.com>

Christoph


>
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1314889401 -3600
> # Node ID bb97bd46df6c6d8562759a964ebf6c31b6361a7a
> # Parent  85b29185c9119ff9139596251d7bd13586853994
> hvmloader: don't clear acpi_info after filling in some fields
>
> In particular the madt_lapic0_addr and madt_csum_addr fields are
> filled in while building the tables.
>
> This fixes a bluescreen on shutdown with certain versions of Windows.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> Reported-by: Christoph Egger<Christoph.Egger@amd.com>
>
> diff -r 85b29185c911 -r bb97bd46df6c tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Thu Sep 01 09:39:25 2011 +0100
> +++ b/tools/firmware/hvmloader/acpi/build.c	Thu Sep 01 16:03:21 2011 +0100
> @@ -277,6 +277,8 @@ void acpi_build_tables(unsigned int phys
>       unsigned long        secondary_tables[16];
>       int                  nr_secondaries, i;
>
> +    memset(acpi_info, 0, sizeof(*acpi_info));
> +
>       /*
>        * Fill in high-memory data structures, starting at @buf.
>        */
> @@ -375,7 +377,6 @@ void acpi_build_tables(unsigned int phys
>                    offsetof(struct acpi_20_rsdp, extended_checksum),
>                    sizeof(struct acpi_20_rsdp));
>
> -    memset(acpi_info, 0, sizeof(*acpi_info));
>       acpi_info->com1_present = uart_exists(0x3f8);
>       acpi_info->com2_present = uart_exists(0x2f8);
>       acpi_info->lpt1_present = lpt_exists(0x378);




-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: Re: cs 23453:4f4970d2848d beaks Win 7

[Tobias Geiger]

+1

now the Devicemanager looks ok too.

Thanks and Greetings
Tobias

Am Donnerstag, 1. September 2011, 17:57:53 schrieb Christoph Egger:
> On 09/01/11 17:05, Ian Campbell wrote:
> > The issue with 23453:4f4970d2848d is that it uses madt_csum_addr and
> > madt_lapic0_addr to initialise bios_info before they have themselves
> > been initialised.
> > 
> > But in xen-unstable.hg tip everything has moved around and the issue now
> > turns out to be that we clear the acpi_info struct _after_ we've setup
> > the madt_* fields. Ooops!
> > 
> > Thanks for reporting.
> > 
> > Cheers,
> > Ian.
> 
> I successfully tested your patch with Windows 7 (both 32bit and 64bit).
> Windows 7 can initialize its CPUs and no longer crashes on shutdown.
> Thanks for fixing. Please apply the fix.
> 
> Tested-and-acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Christoph
> 
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1314889401 -3600
> > # Node ID bb97bd46df6c6d8562759a964ebf6c31b6361a7a
> > # Parent  85b29185c9119ff9139596251d7bd13586853994
> > hvmloader: don't clear acpi_info after filling in some fields
> > 
> > In particular the madt_lapic0_addr and madt_csum_addr fields are
> > filled in while building the tables.
> > 
> > This fixes a bluescreen on shutdown with certain versions of Windows.
> > 
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > Reported-by: Christoph Egger<Christoph.Egger@amd.com>
> > 
> > diff -r 85b29185c911 -r bb97bd46df6c
> > tools/firmware/hvmloader/acpi/build.c ---
> > a/tools/firmware/hvmloader/acpi/build.c	Thu Sep 01 09:39:25 2011 +0100
> > +++ b/tools/firmware/hvmloader/acpi/build.c	Thu Sep 01 16:03:21 2011
> > +0100 @@ -277,6 +277,8 @@ void acpi_build_tables(unsigned int phys
> > 
> >       unsigned long        secondary_tables[16];
> >       int                  nr_secondaries, i;
> > 
> > +    memset(acpi_info, 0, sizeof(*acpi_info));
> > +
> > 
> >       /*
> >       
> >        * Fill in high-memory data structures, starting at @buf.
> >        */
> > 
> > @@ -375,7 +377,6 @@ void acpi_build_tables(unsigned int phys
> > 
> >                    offsetof(struct acpi_20_rsdp, extended_checksum),
> >                    sizeof(struct acpi_20_rsdp));
> > 
> > -    memset(acpi_info, 0, sizeof(*acpi_info));
> > 
> >       acpi_info->com1_present = uart_exists(0x3f8);
> >       acpi_info->com2_present = uart_exists(0x2f8);
> >       acpi_info->lpt1_present = lpt_exists(0x378);