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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2011-Sep-01 09:45 UTC
Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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''_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2011-Sep-01 15:57 UTC
Re: [Xen-devel] Re: cs 23453:4f4970d2848d beaks Win 7
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
+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);_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel