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?
--
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
