Re: PV-vNUMA issue: topology is misinterpreted by the guest

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 16/07/15 17:59, Boris Ostrovsky wrote:
> On 07/16/2015 12:39 PM, Andrew Cooper wrote:
>> On 16/07/15 17:29, Jan Beulich wrote:
>>>>>> On 16.07.15 at 17:50, <boris.ostrovsky@oracle.com> wrote:
>>>> Can't we set leaf 1's EBX[32:16] to 1?
>
> (I obviously fat-fingered this --- I meant EBX[23:16])
>
>>> I don't think we should partially overwrite the relevant parts of
>>> CPUID output - either all or nothing (so that things at least
>>> remain consistent).
>
> Possibly more, but specifically for Dario's problem I think this could
> resolve that.
>
>> Also, there are no masking/override MSRs for that feature leaf on any
>> hardware I am aware of, and a PV guest using plain `cpuid` will not
>> observe any attempt of Xen's to control the value.
>
> True, but we already modify other CPUID bits (e.g. we clear
> X86_FEATURE_TOPOEXT) so it won't make things much worse. (And again,
> for this specific problem CPUID is queried by guest kernel which uses
> PV CPUID instruction).

The current state of cpuid handling is fragile to say the least. 
Overriding that leaf might indeed work, if configured from the toolstack
level.  It can't be clobbered in the hypervisor (like some of the
existing cpuid clobbering) as that would break migration.

>
> And in general (both for PV and HVM) --- is there any reason to expose
> CPU topology at all? I can see it being useful if VCPUs are pinned but
> if they are not then it can make performance worse.

For better or for worse, lots of software running in VMs have licensing
restrictions on CPU topology.  XenServer has options to configure the
visible topology inside the VM, to work around the issue that currently
every vcpu looks like a separate socket.

~Andrew