Re: [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Jul 27, 2015 at 5:35 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
> On 07/24/2015 06:44 PM, Boris Ostrovsky wrote:
>>
>> On 07/24/2015 12:39 PM, Juergen Gross wrote:
>>>
>>>
>>>
>>> I don't say mangling cpuids can't solve the scheduling problem. It
>>> surely can. But it can't solve the scheduling problem without hiding
>>> information like number of sockets or cores which might be required
>>> for license purposes. If we don't care, fine.
>>>
>>
>> (this is somewhat repeating the email I just sent)
>>
>> Why can's we construct socket/core info with CPUID (and *possibly* ACPI
>> changes) that we present a reasonable (licensing-wise) picture?
>>
>> Can you suggest an example where it will not work and then maybe we can
>> figure something out?
>
>
> Let's assume a software with license based on core count. You have a
> system with a 2 8 core processors and hyperthreads enabled, summing up
> to 32 logical processors. Your license is valid for up to 16 cores, so
> running the software on bare metal on your system is fine.
>
> Now you are running the software inside a virtual machine with 24 vcpus
> in a cpupool with 24 logical cpus limited to 12 cores (6 cores of each
> processor). As we have to hide hyperthreading in order to not to have
> to pin each vcpu to just a single logical processor, the topology
> resulting from this picture will have to present 24 cores. The license
> will not cover this hardware.

But how does doing a PV topology help this situation?  Because we're
telling one thing to the OS (via our PV interface) and another thing
to applications (via direct CPUID access)?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel