[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.