Xen devel - Mar 2008 - [PATCH][retry 2][1/2] new platform hypervisor call to get APICIDs

Some AMD machines have APIC IDs that not equal to CPU IDs.  In
the default Xen configuration, ACPI calls on these machines
can get confused.  This shows up most noticeably when running
AMD PowerNow!.  The only solution is for dom0 to get the
hypervisor''s cpuid to apicid table when needed (ie, when dom0
vcpus are pinned).

Add a new platform hypercall to Xen to allow dom0 to query the
hypervisor for the actual cpuid to apicid table.  

The second patch adds the dom0 call to this platform hypercall.

I have tested this on my 4p/16 core machine and it works.  I
would appreciate testing on other boxes.

-Mark Langsdorf
Operating System Research Center
AMD

Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>

diff -r 7530c4dba8a5 xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Mon Mar 03 15:19:39 2008 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Mon Mar 03 14:36:53 2008 -0600
@@ -340,6 +340,24 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     }
     break;
 
+    case XENPF_getapicids:
+    {
+        XEN_GUEST_HANDLE(uint8) apicids;
+        uint32_t i, nr_cpus;
+
+        nr_cpus = op->u.getapicids.nr_cpus;
+        guest_from_compat_handle(apicids, op->u.getapicids.apicids);
+ 
+        for (i = 0; i < nr_cpus; i++) 
+        {
+             ret = -EFAULT;
+             if ( copy_to_guest_offset(apicids, i, &x86_cpu_to_apicid[i],
1) )
+                 goto out;
+        }
+        ret = copy_to_guest(u_xenpf_op, op, 1) ? -EFAULT : 0;
+    }
+    break;
+
     default:
         ret = -ENOSYS;
         break;
diff -r 7530c4dba8a5 xen/include/public/platform.h
--- a/xen/include/public/platform.h	Mon Mar 03 15:19:39 2008 +0000
+++ b/xen/include/public/platform.h	Mon Mar 03 14:36:53 2008 -0600
@@ -198,6 +198,16 @@ struct xenpf_getidletime {
 };
 typedef struct xenpf_getidletime xenpf_getidletime_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
+
+#define XENPF_getapicids	54
+struct xenpf_getapicids {
+    /* IN variables */
+    /* size of apicid table */
+    uint32_t nr_cpus;
+    /* OUT variables */
+    /* Table of cpu to apicids */
+    XEN_GUEST_HANDLE(uint8) apicids;
+};
 
 struct xen_platform_op {
     uint32_t cmd;
@@ -213,6 +223,7 @@ struct xen_platform_op {
         struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
         struct xenpf_change_freq       change_freq;
         struct xenpf_getidletime       getidletime;
+	struct xenpf_getapicids	       getapicids;
         uint8_t                        pad[128];
     } u;
 };


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Two major comments:

Firstly, if dom0_vcpus_pinned then you do *not* need a hypercall to fetch
the APICIDs. You can use CPUID on each VCPU to find the true underlying
APICID for that CPU (as enumerated by Xen). That is, unless you need the
apicid-cpu mapping before the VCPU is brought up. If you do keep the
hypercall then it would be a simpler interface to get one apicid at a time.
And I''d make it a vcpu_op, and error return could imply that vcpus are
not
pinned (i.e., !dom0_vcpus_pinned, so use our existing bogo apicid-cpu
mapping). Actually, I quite like that interface...

Secondly, what about ACPIID-to-APICID mappings: doesn''t
drivers/acpi/processor_core.c rely on that mapping array being set up? But
this patch doesn''t introduce any setup of that array.

 -- Keir

On 3/3/08 21:40, "Mark Langsdorf" <mark.langsdorf@amd.com>
wrote:
> Some AMD machines have APIC IDs that not equal to CPU IDs.  In
> the default Xen configuration, ACPI calls on these machines
> can get confused.  This shows up most noticeably when running
> AMD PowerNow!.  The only solution is for dom0 to get the
> hypervisor''s cpuid to apicid table when needed (ie, when dom0
> vcpus are pinned).
> 
> Add a new platform hypercall to Xen to allow dom0 to query the
> hypervisor for the actual cpuid to apicid table.
> 
> The second patch adds the dom0 call to this platform hypercall.
> 
> I have tested this on my 4p/16 core machine and it works.  I
> would appreciate testing on other boxes.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel