On 08/01/2021 08:32, Paul Durrant wrote: >> -----Original Message----- >> From: Igor Druzhinin <igor.druzhi...@citrix.com> >> Sent: 08 January 2021 00:47 >> To: xen-devel@lists.xenproject.org >> Cc: p...@xen.org; w...@xen.org; i...@xenproject.org; >> anthony.per...@citrix.com; >> andrew.coop...@citrix.com; george.dun...@citrix.com; jbeul...@suse.com; >> jul...@xen.org; >> sstabell...@kernel.org; roger....@citrix.com; Igor Druzhinin >> <igor.druzhi...@citrix.com> >> Subject: [PATCH 1/2] viridian: remove implicit limit of 64 VPs per partition >> >> TLFS 7.8.1 stipulates that "a virtual processor index must be less than >> the maximum number of virtual processors per partition" that "can be obtained >> through CPUID leaf 0x40000005". Furthermore, "Requirements for Implementing >> the Microsoft Hypervisor Interface" defines that starting from Windows Server >> 2012, which allowed more than 64 CPUs to be brought up, this leaf can now >> contain a value -1 basically assuming the hypervisor has no restriction while >> 0 (that we currently expose) means the default restriction is still present. >> >> Along with previous changes exposing ExProcessorMasks this allows a recent >> Windows VM with Viridian extension enabled to have more than 64 vCPUs without >> going into immediate BSOD. >> > > This is very odd as I was happily testing with a 128 vCPU VM once > ExProcessorMasks was implemented... no need for the extra leaf. > The documentation for 0x40000005 states " Describes the scale limits > supported in the current hypervisor implementation. If any > value is zero, the hypervisor does not expose the corresponding information". > It does not say (in section 7.8.1 or elsewhere AFAICT) > what implications that has for VP_INDEX.
The text says that VP_INDEX "must" be below that limit - that is clear enough for me. I admit I have not tested with ExProssorMasks exposed but I disabled TLB flush and IPI extensions before that - Windows is mysterious in it's handling of this logic. Let me align all of the changes and perform some clean cut testing. > In " Requirements for Implementing the Microsoft Hypervisor Interface" I > don't see anything saying what the semantics of not > implementing leaf 0x40000005 are, only that if implementing it then -1 must > be used to break the 64 VP limit. Yes, that's exactly the info this change is based on. > It also says that > reporting -1 in 0x40000005 means that 40000004.EAX bits 1 and 2 *must* be > clear, which is clearly not true if ExProcessorMasks is > enabled. That document is dated June 13th 2012 so I think it should be taken > with a pinch of salt. True - I assumed that for them to work ExProcessorMasks is necessary then. Igor
