RE: [Xen-devel] [PATCH] Export Multicore information

["Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>]

Hi Keir,
   I think you have interesting ideas. Let me discuss with Jun & Asit
about these ideas.

Thanks & Regards,
Nitin 
Open Source Technology Center, Intel Corporation.
------------------------------------------------------------------------
-
The mind is like a parachute; it works much better when it's open.

>-----Original Message-----
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: Wednesday, December 13, 2006 1:56 AM
>To: Keir Fraser; Kamble, Nitin A; John Levon
>Cc: Yu, Wilfred; Ian Pratt; Xen devel list; Yang, Fred; Mallick, Asit
K;
>Nakajima, Jun
>Subject: Re: [Xen-devel] [PATCH] Export Multicore information
>
>On 13/12/06 08:44, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
>
>> Hm.... Ok, so we can have cache hierarchies where a single cache is
split
>> among *some* of the threads in a core, or *some* of the cores in a
>package?
>> So you end up needing the physical APIC id to be able to apply the
CPUID
>> information and find out *which* siblings are sharing?
>>
>> I'm still tempted just to provide that APICid info to the guest. Was
my
>> earlier presumption that the cache hierarchy in practice will always
be
>> symmetric correct? Because that could simplify things.
>
>Actually, my main problem with these new info interfaces is that there
is
>no
>reason to make them privileged except that they need to run on the
correct
>physical CPU. Hence we've ended up with interfaces for MTRR access,
>microcode updates, MSR accesses, and this will start to add CPUID
access
>also.
>
>We already started to discuss general ways we could execute arbitrary
guest
>code on the appropriate physical CPU. For this topology and cache info,
why
>not make a user app which sets process-VCPU and VCPU-CPU affinities
>appropriately to run its CPUID payload in the right places?
>Sched_setaffinity() (linux syscall) and xc_vcpu_setaffinity() should be
all
>you need. Additionally the affinity-setting code ought to be
generically
>useful in other scenarios too.
>
> -- Keir

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