This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: cpuid information to hvm guest

To: "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: cpuid information to hvm guest
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 30 Sep 2008 07:23:21 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 29 Sep 2008 23:23:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8EA2C2C4116BF44AB370468FBF85A7779A5252E0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckiV8fr9iS1sXiMSTKzJGUXP4rdAAAANpB3AABC4vAABZnQswACo56AAADaLXAAEb8xzw==
Thread-topic: [Xen-devel] Re: cpuid information to hvm guest
User-agent: Microsoft-Entourage/
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.

 -- Keir

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
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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[16] = 0
 Guest_CPUID.4:EAX[31:27] = Host_CPUID.4:EAX[30:26]
 Guest_CPUID.4:EAX[26] = 1
 Guest_CPUID.1:EDX[28] = Host_CPUID.1:EDX[28]

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.

 -- Keir

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.

 -- Keir

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