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

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

Hi Keir,
   I had some discussion with Jun/Asit, and I understand your comments
better now. :)

I think your points are:

1. Access to non privileged user: In a fashion similar to /proc/cpuinfo
or /sys/cpuinfo. I think this is very much doable, I can add a new sys
interface hierarchy for dom0 kernel like
/sys/xen/cpu/cpu0/topology/core_id. Do you see any issue with this
approach?

2. Temporary altering vcpu-pcpu binding: To get information for all cpus
in the guest_land. 
  One issue with this approach is, if the admin has giving fewer than
total cpus to dom0, and it has hard bound the dom0 vpcus to pvcpus, then
this will not work.
  Instead as you mentioned we can make an interface just like microcode
in the hypervisor for this. Sorry I am not up2date on this "We already
started to discuss general ways we could execute arbitrary guest code on
the appropriate physical CPU.", Can you provide more details.

Also exporting the APICID to vcpu will be needed, for guests to figure
out their own cpu's topology.

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: Kamble, Nitin A
>Sent: Wednesday, December 13, 2006 5:21 PM
>To: 'Keir Fraser'; 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
>
>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