Re: [Xen-devel] Re: cpuid information to hvm guest
Changing VLAPIC identifiers breaks ‘xm restore’ of old saved images.|
The reason for picking the current mapping is to strictly obey the constraints of the IOAPIC hardware that we emulate, which only supports a 4-bit identifier. Hence it is not strictly correct to number IO-APICs downwards from 0xfe: we would need to number it 0xf or lower.
This coupled with needing to give VCPU0 APIC ID 0 (some OSes get upset otherwise) and not wanting to make a hole in the VCPU vLAPIC ID space for vIOAPICs, led to the vLAPIC_ID == vCPU_ID * 2 relationship.
So, there is a reason why it is as it is, and a reason why it is a pain to change. And there’s no particular reason to change it either, since we can appropriately translate host CPUID parameters quite easily.
On 29/9/08 23:32, "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> wrote:
I think what you are suggesting would work, and I was also thinking about it.
Only thing is we will be adding 2nd effect to nullify 1st effect. IMHO correcting 1st effect will be a better.
Why are you so sensitive to changing vlapic_id? If it has to stay the same, then I can provide you a patch with your approach.
Thanks & Regards,
Linux Open Source Technology Center, Intel Corporation
The Mind is like a parachute; it works much better when it's open.
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Monday, September 29, 2008 2:31 PM
To: Kamble, Nitin A
Subject: Re: [Xen-devel] Re: cpuid information to hvm guest
How about the following changes to our default HVM CPUID?
Guest_CPUID.1:EBX[23:17] = Host_CPUID.1:EBX[22:16]
Guest_CPUID.1:EBX = 0
Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26]
Guest_CPUID.4:EAX = 1
Guest_CPUID.1:EDX = Host_CPUID.1:EDX
Basically pass-through HT/multicore support, but specify max-cores-per-package and max-threads-per-package as twice the host values. This deals with the fact our virtual APIC IDs are 2*VCPUID.
On 29/9/08 21:15, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
I’d be happy, by default, for xend to detect threads-per-socket on the host system and replicate that on guest CPUID. I don’t see how direct pass-through of host CPUID values can work, because for example host LAPIC identifiers may be guest different from guest vLAPIC identifiers. So I won’t apply anything like your original patches, period.
On 29/9/08 18:48, "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> wrote:
Hiding those details by default is a good strategy we’d like to maintain.
[Nitin>] Why do you say it is a good strategy? What are the benefits associated with it?
Furthermore we cannot change CPU-to-LAPIC identifier mapping without breaking saved guest images, which is not acceptable.
[Nitin>] I am not clear on this part, how saved guest images get broken? I think this change is like upgrading BIOS. It should not break guest images.
If our hiding of host information is broken, we’d like a patch to fix it; likewise any other CPUID inconsistency. What specific issues are you seeing?
[Nitin>] This is an issue with OS which have licensing restriction on CPUs. A customer reported to us that they were not seeing all cpus on windows server because Xen is exposing each vcpu as a socket on a multi-core host system.
Xen-devel mailing list
Xen-devel mailing list