I have a machine with 2 physical CPUs (Xeon 5355) with each 2 cores and as such when I do cat /proc/cpuinfo on Dom0 (host) it reports 4 CPUs. One of the DomU (guest) instances runs software for which I have bought a 1CPU license. However it is ok to have 1 CPU with multiple cores. Therefore I want to give the DomU 2 virtual CPUs to speed things up.
That's where CPUID comes in: Xen allows to change CPUID results from the CPU and present these to the DomU. I've been reading the Intel® Processor Identification and the CPUID Instruction docs (http://www.intel.com/Assets/PDF/appnote/241618.pdf) to try to figure out how I can tell Xen to assign 2 cores to this DomU instance, but present it as 1 socket CPU with 2 cores.
Assuming 2 threads per core and 2 cores per CPU, I figured that CPUID should report the following:
- register EDX bit 28 should be set to 1 to enable Multi-Threading
- register EBX bits 16-23 (number of logical processors per physical processor package) should be set to 00000100 (decimal value 4)
- register EAX bits 26-31 (number of cores per physical package) should be set to 000011
However my application still complains that 'The server has 2 CPUs, but this product is licensed for 1'. What am I doing wrong? I have a m1.xlarge instance on Amazon EC2, which exposes a single CPU with 4 cores to the OS and the application eats that perfectly. So it should be possible...
Although I dont know the specifific of XEN implementation details, I can speak to the general requirements of VMM and CPUID. It may be of some use to you.
There are several things you may want to investigate.
1. Hardware configuration: Each Intel Xeon processor 5355 has 4 cores and no Hyperthreading (you assumption of two threads per core does not apply to 5355). If you have two physical processors, there are eight cores at the disposal of Xen's host and guest. So if Dom0 says it has subscribed 4 cores, your guest VM would have 4 other cores to be partitioned. Whether the 4 cores subscribed by Dom0 resides in the same physical package will require verification via APIC ID. The same goes to your guest's allocation of the other 4 cores, whether they reside in the same physical package or not.
2. I suspect the robustness requirement of Hypervisor will allow VCPUs to either time-share or have exclusive control of phyical core. So when you query inside DOM0 or DOMU with /proc/info, you probably want to examine the APIC ID associated with each VCPU and ensure configuration of each guest meets your expectation. If the configuration of each guest differs from your expectation, then correct them as needed. It sounds like the optimal partition for you is to have the 4 cores allocated to DOM0 residing in the same physical package. The relationship of sorting out unique APIC ID to distinguish physical package and where each core resides with respect to package is documented in the white paper. http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/
3. The examples you give appears to have a couple of contradictions: (a) it seems to suggest you had Xen console configured a DomU with one VCPU and when you ask the DomU to report its capability, it replies with 2 VCPU! Doesn't that suggest you found a bug in Xen?
(b) It also suggest when you try to run the 3rd party app on the DomU with one VCPU, the application was able to take control more CPU than the Xen conole allowed allocation (in order to detmined phycial package-based licensing was not in compliance), implying a breach of of virtualization premise?