Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
On Mon, Sep 2, 2019 at 6:34 PM, Paul Durrant wrote: -Original Message- From: Steven Haigh Sent: 02 September 2019 09:32 To: Paul Durrant Cc: Andrew Cooper ; Andreas Kinzler ; xen- de...@lists.xenproject.org Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X) On 2019-09-02 18:25, Steven Haigh wrote: > On 2019-09-02 18:20, Paul Durrant wrote: >>> -Original Message- >>> From: Steven Haigh >>> Sent: 02 September 2019 09:09 >>> To: Paul Durrant >>> Cc: Andreas Kinzler ; Andrew Cooper >>> ; xen- >>> de...@lists.xenproject.org >>> Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and >>> 3900X) >>> >>> On 2019-09-02 18:04, Paul Durrant wrote: >>> >> -Original Message- >>> >> Further to the above, I did some experimentation. The following is a >>> >> list of attempted boot configurations and their outcomes: >>> >> >>> >> viridian=1 >>> >> vcpus=4 >>> >> STOPCODE: HAL MEMORY ALLOCATION >>> >> >>> >> viridian=0 >>> >> vcpus=4 >>> >> STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED >>> >> >>> >> viridian=0 >>> >> vcpus=1 >>> >> Boot OK - get to Windows Server 2016 login etc >>> >> >>> > >>> > And to complete the set, how about viridian=1 vcpus=1? >>> >>> Any vcpus value where viridian=1 is used creates a HAL MEMORY >>> ALLOCATION >>> stopcode when trying to boot Windows. >> >> Ok, so I guess that issue hits first and, only if you get beyond that >> do you hit the multiprocessor problem. >> >> The viridian option is not actually a boolean any more (that >> interpretation is just for compat) so it would be a good datapoint to >> know which of the enlightenments causes the change in behaviour. Could >> you try viridian=['base'] to see if that's sufficient to cause the >> problem? (I'm guessing it probably is but it would be good to know). > > > Hi Paul, > > I can confirm that viridian=['base'] crashes with the same HAL MEMORY > ALLOCATION stopcode - even on 1 vcpu. Also, just wondering, we're using 8.2.0 of the Windows PV drivers on this VM. Does this matter? Has there been any changes that would affect this in 8.2.1 or 8.2.2? From what you describe, I think this is happening way before any PV driver code is entered. I guess it would be prudent to make sure by trying it on a fresh VM (but didn't you say before that this happens when booting from the installation media?) The original poster mentioned the problem with the install media. To be honest, I haven't tried that as yet. My case / tests are from a working Windows Server 2016 install imaged on a different machine (that works and boots fine there). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
> -Original Message- > From: Steven Haigh > Sent: 02 September 2019 09:32 > To: Paul Durrant > Cc: Andrew Cooper ; Andreas Kinzler > ; xen- > de...@lists.xenproject.org > Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X) > > On 2019-09-02 18:25, Steven Haigh wrote: > > On 2019-09-02 18:20, Paul Durrant wrote: > >>> -Original Message- > >>> From: Steven Haigh > >>> Sent: 02 September 2019 09:09 > >>> To: Paul Durrant > >>> Cc: Andreas Kinzler ; Andrew Cooper > >>> ; xen- > >>> de...@lists.xenproject.org > >>> Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and > >>> 3900X) > >>> > >>> On 2019-09-02 18:04, Paul Durrant wrote: > >>> >> -Original Message- > >>> >> Further to the above, I did some experimentation. The following is a > >>> >> list of attempted boot configurations and their outcomes: > >>> >> > >>> >> viridian=1 > >>> >> vcpus=4 > >>> >> STOPCODE: HAL MEMORY ALLOCATION > >>> >> > >>> >> viridian=0 > >>> >> vcpus=4 > >>> >> STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED > >>> >> > >>> >> viridian=0 > >>> >> vcpus=1 > >>> >> Boot OK - get to Windows Server 2016 login etc > >>> >> > >>> > > >>> > And to complete the set, how about viridian=1 vcpus=1? > >>> > >>> Any vcpus value where viridian=1 is used creates a HAL MEMORY > >>> ALLOCATION > >>> stopcode when trying to boot Windows. > >> > >> Ok, so I guess that issue hits first and, only if you get beyond that > >> do you hit the multiprocessor problem. > >> > >> The viridian option is not actually a boolean any more (that > >> interpretation is just for compat) so it would be a good datapoint to > >> know which of the enlightenments causes the change in behaviour. Could > >> you try viridian=['base'] to see if that's sufficient to cause the > >> problem? (I'm guessing it probably is but it would be good to know). > > > > > > Hi Paul, > > > > I can confirm that viridian=['base'] crashes with the same HAL MEMORY > > ALLOCATION stopcode - even on 1 vcpu. > > Also, just wondering, we're using 8.2.0 of the Windows PV drivers on > this VM. > > Does this matter? Has there been any changes that would affect this in > 8.2.1 or 8.2.2? > From what you describe, I think this is happening way before any PV driver code is entered. I guess it would be prudent to make sure by trying it on a fresh VM (but didn't you say before that this happens when booting from the installation media?) Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
On 2019-09-02 18:25, Steven Haigh wrote: On 2019-09-02 18:20, Paul Durrant wrote: -Original Message- From: Steven Haigh Sent: 02 September 2019 09:09 To: Paul Durrant Cc: Andreas Kinzler ; Andrew Cooper ; xen- de...@lists.xenproject.org Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X) On 2019-09-02 18:04, Paul Durrant wrote: >> -Original Message- >> Further to the above, I did some experimentation. The following is a >> list of attempted boot configurations and their outcomes: >> >> viridian=1 >> vcpus=4 >> STOPCODE: HAL MEMORY ALLOCATION >> >> viridian=0 >> vcpus=4 >> STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED >> >> viridian=0 >> vcpus=1 >> Boot OK - get to Windows Server 2016 login etc >> > > And to complete the set, how about viridian=1 vcpus=1? Any vcpus value where viridian=1 is used creates a HAL MEMORY ALLOCATION stopcode when trying to boot Windows. Ok, so I guess that issue hits first and, only if you get beyond that do you hit the multiprocessor problem. The viridian option is not actually a boolean any more (that interpretation is just for compat) so it would be a good datapoint to know which of the enlightenments causes the change in behaviour. Could you try viridian=['base'] to see if that's sufficient to cause the problem? (I'm guessing it probably is but it would be good to know). Hi Paul, I can confirm that viridian=['base'] crashes with the same HAL MEMORY ALLOCATION stopcode - even on 1 vcpu. Also, just wondering, we're using 8.2.0 of the Windows PV drivers on this VM. Does this matter? Has there been any changes that would affect this in 8.2.1 or 8.2.2? -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
On 2019-09-02 18:20, Paul Durrant wrote: -Original Message- From: Steven Haigh Sent: 02 September 2019 09:09 To: Paul Durrant Cc: Andreas Kinzler ; Andrew Cooper ; xen- de...@lists.xenproject.org Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X) On 2019-09-02 18:04, Paul Durrant wrote: >> -Original Message- >> Further to the above, I did some experimentation. The following is a >> list of attempted boot configurations and their outcomes: >> >> viridian=1 >> vcpus=4 >> STOPCODE: HAL MEMORY ALLOCATION >> >> viridian=0 >> vcpus=4 >> STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED >> >> viridian=0 >> vcpus=1 >> Boot OK - get to Windows Server 2016 login etc >> > > And to complete the set, how about viridian=1 vcpus=1? Any vcpus value where viridian=1 is used creates a HAL MEMORY ALLOCATION stopcode when trying to boot Windows. Ok, so I guess that issue hits first and, only if you get beyond that do you hit the multiprocessor problem. The viridian option is not actually a boolean any more (that interpretation is just for compat) so it would be a good datapoint to know which of the enlightenments causes the change in behaviour. Could you try viridian=['base'] to see if that's sufficient to cause the problem? (I'm guessing it probably is but it would be good to know). Hi Paul, I can confirm that viridian=['base'] crashes with the same HAL MEMORY ALLOCATION stopcode - even on 1 vcpu. -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
> -Original Message- > From: Steven Haigh > Sent: 02 September 2019 09:09 > To: Paul Durrant > Cc: Andreas Kinzler ; Andrew Cooper > ; xen- > de...@lists.xenproject.org > Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X) > > On 2019-09-02 18:04, Paul Durrant wrote: > >> -Original Message- > >> Further to the above, I did some experimentation. The following is a > >> list of attempted boot configurations and their outcomes: > >> > >> viridian=1 > >> vcpus=4 > >> STOPCODE: HAL MEMORY ALLOCATION > >> > >> viridian=0 > >> vcpus=4 > >> STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED > >> > >> viridian=0 > >> vcpus=1 > >> Boot OK - get to Windows Server 2016 login etc > >> > > > > And to complete the set, how about viridian=1 vcpus=1? > > Any vcpus value where viridian=1 is used creates a HAL MEMORY ALLOCATION > stopcode when trying to boot Windows. Ok, so I guess that issue hits first and, only if you get beyond that do you hit the multiprocessor problem. The viridian option is not actually a boolean any more (that interpretation is just for compat) so it would be a good datapoint to know which of the enlightenments causes the change in behaviour. Could you try viridian=['base'] to see if that's sufficient to cause the problem? (I'm guessing it probably is but it would be good to know). Paul > > -- > Steven Haigh > > ? net...@crc.id.au ? http://www.crc.id.au > ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
On 2019-09-02 18:04, Paul Durrant wrote: -Original Message- Further to the above, I did some experimentation. The following is a list of attempted boot configurations and their outcomes: viridian=1 vcpus=4 STOPCODE: HAL MEMORY ALLOCATION viridian=0 vcpus=4 STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED viridian=0 vcpus=1 Boot OK - get to Windows Server 2016 login etc And to complete the set, how about viridian=1 vcpus=1? Any vcpus value where viridian=1 is used creates a HAL MEMORY ALLOCATION stopcode when trying to boot Windows. -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
> -Original Message- > > Further to the above, I did some experimentation. The following is a > list of attempted boot configurations and their outcomes: > > viridian=1 > vcpus=4 > STOPCODE: HAL MEMORY ALLOCATION > > viridian=0 > vcpus=4 > STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED > > viridian=0 > vcpus=1 > Boot OK - get to Windows Server 2016 login etc > And to complete the set, how about viridian=1 vcpus=1? Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
On 2019-09-02 11:42, Steven Haigh wrote: On 2019-08-21 06:57, Andreas Kinzler wrote: On 20.08.2019 22:38, Andrew Cooper wrote: On 20/08/2019 21:36, Andreas Kinzler wrote: On 20.08.2019 20:12, Andrew Cooper wrote: Xen version 4.10.2. dom0 kernel 4.13.16. The BIOS version is unchanged from 2700X (working) to 3700X (crashing). So you've done a Zen v1 => Zen v2 CPU upgrade and an existing system? With "existing system" you mean the Windows installation? I meant same computer, not same VM. Tried with 2 mainboards: Asrock X370 Pro4 and AsrockRack X470D4U. You need to flash the BIOS for Zen2. X470D4U BIOS 3.1 works with 2700X but not with 3700X. X370 Pro4 with somewhat older BIOS worked for 2700X and does not work with current (6.00) BIOS and 3700X. Yes, but it is not relevant. The same BSODs happen if you boot the HVM with just the iso installation medium and no disks. That's a useful datapoint. I wouldn't expect this to be relevant, given how Window's HAL works. It should make debugging for you quite "simple" because it can be reproduced very easily. Just to add a data point to this - I also see this problem on a Ryzen 9 3900x. xl dmesg shows: (XEN) d2v0 VIRIDIAN CRASH: ac 0 a0a0 f80293254750 aea (XEN) d3v0 VIRIDIAN CRASH: ac 0 a0a0 f80093a40750 aea (XEN) d5v0 VIRIDIAN CRASH: ac 0 a0a0 f8028e422350 aea (XEN) d6v0 VIRIDIAN CRASH: ac 0 a0a0 f80309431750 aea (XEN) d10v0 VIRIDIAN CRASH: ac 0 a0a0 f8012823e750 aea (XEN) d11v0 VIRIDIAN CRASH: ac 0 a0a0 f8032e657350 aea Windows usually has a stopcode of "HAL MEMORY ALLOCATION" when it blue screens. From xl info: hw_caps: 178bf3ff:f6d8320b:2e500800:244037ff:000f:219c91a9:0044:0500 virt_caps : hvm hvm_directio xen_version: 4.11.2 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 Is there any further info that can be provided? Not being able to virtualise Windows is a bit of a PITA... Further to the above, I did some experimentation. The following is a list of attempted boot configurations and their outcomes: viridian=1 vcpus=4 STOPCODE: HAL MEMORY ALLOCATION viridian=0 vcpus=4 STOPCODE: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED viridian=0 vcpus=1 Boot OK - get to Windows Server 2016 login etc As such, it looks like its not a completely fatal problem - but running Windows on a single vcpu is unpleasant ;) -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
On 2019-08-21 06:57, Andreas Kinzler wrote: On 20.08.2019 22:38, Andrew Cooper wrote: On 20/08/2019 21:36, Andreas Kinzler wrote: On 20.08.2019 20:12, Andrew Cooper wrote: Xen version 4.10.2. dom0 kernel 4.13.16. The BIOS version is unchanged from 2700X (working) to 3700X (crashing). So you've done a Zen v1 => Zen v2 CPU upgrade and an existing system? With "existing system" you mean the Windows installation? I meant same computer, not same VM. Tried with 2 mainboards: Asrock X370 Pro4 and AsrockRack X470D4U. You need to flash the BIOS for Zen2. X470D4U BIOS 3.1 works with 2700X but not with 3700X. X370 Pro4 with somewhat older BIOS worked for 2700X and does not work with current (6.00) BIOS and 3700X. Yes, but it is not relevant. The same BSODs happen if you boot the HVM with just the iso installation medium and no disks. That's a useful datapoint. I wouldn't expect this to be relevant, given how Window's HAL works. It should make debugging for you quite "simple" because it can be reproduced very easily. Just to add a data point to this - I also see this problem on a Ryzen 9 3900x. xl dmesg shows: (XEN) d2v0 VIRIDIAN CRASH: ac 0 a0a0 f80293254750 aea (XEN) d3v0 VIRIDIAN CRASH: ac 0 a0a0 f80093a40750 aea (XEN) d5v0 VIRIDIAN CRASH: ac 0 a0a0 f8028e422350 aea (XEN) d6v0 VIRIDIAN CRASH: ac 0 a0a0 f80309431750 aea (XEN) d10v0 VIRIDIAN CRASH: ac 0 a0a0 f8012823e750 aea (XEN) d11v0 VIRIDIAN CRASH: ac 0 a0a0 f8032e657350 aea Windows usually has a stopcode of "HAL MEMORY ALLOCATION" when it blue screens. From xl info: hw_caps: 178bf3ff:f6d8320b:2e500800:244037ff:000f:219c91a9:0044:0500 virt_caps : hvm hvm_directio xen_version: 4.11.2 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 Is there any further info that can be provided? Not being able to virtualise Windows is a bit of a PITA... -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
