Re: [Xen-devel] Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)

[Steven Haigh]

On Mon, Sep 2, 2019 at 6:34 PM, Paul Durrant <paul.durr...@citrix.com> 
wrote:
 -----Original Message-----
 From: Steven Haigh <net...@crc.id.au>
 Sent: 02 September 2019 09:32
 To: Paul Durrant <paul.durr...@citrix.com>
 Cc: Andrew Cooper <andrew.coop...@citrix.com>; Andreas Kinzler 
<h...@posteo.de>; 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 <net...@crc.id.au>
 >>> Sent: 02 September 2019 09:09
 >>> To: Paul Durrant <paul.durr...@citrix.com>
 >>> Cc: Andreas Kinzler <h...@posteo.de>; Andrew Cooper
 >>> <andrew.coop...@citrix.com>; 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