Clyde Griffin
2006-Apr-19 19:31 UTC
[Xen-devel] [PATCH] Fix hvm cpuid to hide hyperthreaded processor when apic is disabled.
2 Issues: Issue 1) There are instances where we DO NOT want an hvm guest to run an MP enabled kernel. In such situations we should have a workaround to guarantee hvm guests will not detect MP. For example, in the absence of ACPI and MPS the installation code in some linux distributions key off the presence of cpuid edx/HTT bit (indicating the presence of Hyper-Threading Technology) to determine if another logical processor is present and if so load an MP enabled kernel instead of a uniprocessor kernel. SMBIOS is also looked at for the same purpose and presents a potential problem as well. While both approaches for selecting an MP kernel are debatable (since using MPS or ACPI have long been the standard for MP detection), these approaches are something we have to live and work around with because making a change in the fully virtualized guest is not an option. To solve the problem we need to hide all secondary processors from the hvm guest. Since the hvm does not surface MPS tables, we only need to deal with ACPI, cpuid HTT, and possibly SMBIOS. (I did not have time right now to look closely at the hvm BIOS to know if SMBIOS is also going to be a problem.) To avoid any confusion within the hvm guest about MP availability, I propose that we use "acpi=0" and "apic=0" as the Xen way of indicating to the guest that it should not make any attempt to run an MP enabled kernel. "acpi=0" will hide the MADT table and "apic=0" will hide the APIC and HTT cpuid feature bits from the guest. I ran this proposed change by Intel (Wilfred) and AMD (Elsie) and unless someone comes up with other reasons why we should not hide HTT when apic=0, they are okay with this change. Issue 2) Also fixed a logic problem the code path where apic=0 was not being handled correctly (vmx path only). Compare with the svm counterpart. Please also add to 3.0.2. Signed- off- by: Clyde Griffin <cgriffin@novell.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel