---------- Forwarded message ---------- From: mihai pricopi <[email protected]> Date: Wed, Aug 25, 2010 at 9:22 AM Subject: Re: Get values per thread To: Volos Stavros <[email protected]>
Hi Stavros, So I have Solaris10 running in Simics and at prompt I tried 2 versions: 1) mdb -k and then I try to check the content of the cpu_list with cpu_list/X and is 0 2) adb -k /dev/ksyms /dev/mem and the same when I try cpu_list/X is 0. In kernel there is an array of cpu_t which is cpu_t *cpu[]. I tried to read the content of cpu with cpu/X and is also 0. Would it be because of some OS protection or do I have to set the OS boot in a specific mode ? Thanks, Mihai On Wed, Aug 25, 2010 at 12:22 AM, Volos Stavros <[email protected]> wrote: > Hi, > > It's been a long time since I last used the debugger but I was able to get a > value for the > cpu_list pointer that was not zero. Which command are you using? > > -Stavros > ________________________________________ > From: mihai pricopi [[email protected]] > Sent: Tuesday, August 24, 2010 11:49 AM > To: Volos Stavros > Cc: [email protected] > Subject: Re: Get values per thread > > Hi, > > Yes indeed the pointer in Solaris 10 on 64bit is 8byte long. But I > still don't get why the cpu_list pointer is NULL. I created a new > machine and is still the same. This list is supposed to be initialised > at booting time ... > > Mihai > > On Tue, Aug 24, 2010 at 3:02 PM, mihai pricopi <[email protected]> > wrote: >> Hi, >> >> Under mdb -K I tried to read the content of cpu_list which shall be >> an address. But the value is 0. I wonder if this should be 0 or maybe >> I`m doing something wrong in the debugger. Did you try in the debugger >> to read the value of the pointer and see it ? >> >> Thanks, >> Mihai >> >> On Tue, Aug 24, 2010 at 1:23 AM, Volos Stavros <[email protected]> wrote: >>> Hi Mihai, >>> >>> The pointers in Solaris are 8 bytes so you need to use 8. For cpu_id, t_id >>> etc you only need 4 bytes. >>> >>> Did you assign the new value to KernelVaddr_cpu_list variable ? >>> >>> Currently you have, >>> >>> // boost::tie( paddr, ignored1, ignored2) = >>> cpu->translateTSB_SimicsImpl(VirtualMemoryAddress(cpu_ptr + 0x10), 4 >>> /*NUCLEUS*/ ); >>> // cpu_ptr = >>> VirtualMemoryAddress(cpu->readVAddr(VirtualMemoryAddress(cpu_ptr + 0x48), 4 >>> /*NUCLEUS*/, 8)); //next CPU pointer at offset 0x48 - solaris8 >>> >>> The first line reads the thread id from the cpu struct (current thread >>> field) and the second line reads the pointer in the next cpu (cpu_next >>> field). >>> You need to come up with the values that are valid for Solaris 10. >>> >>> Cheers, >>> -Stavros >>> ________________________________________ >>> From: mihai pricopi [[email protected]] >>> Sent: Friday, August 20, 2010 10:23 AM >>> To: Volos Stavros >>> Cc: [email protected] >>> Subject: Re: Get values per thread >>> >>> Hello, >>> >>> I tried to do as you suggested with the cpu_list pointer but I have >>> troubles understand why : >>> cpuX->readVAddr(VirtualMemoryAddress(addr), 4, 4); >>> >>> is not working. So first I took the cpuvar.h from the Solaris10 operating >>> system. There there is this set of variables: >>> >>> extern struct cpu *cpu[]; /* indexed by CPU number */ >>> extern cpu_t *cpu_list; /* list of CPUs */ >>> extern int ncpus; /* number of CPUs present */ >>> extern int ncpus_online; /* number of CPUs not quiesced */ >>> extern int max_ncpus; /* max present before ncpus is known */ >>> extern int boot_max_ncpus; /* like max_ncpus but for real */ >>> extern processorid_t max_cpuid; /* maximum CPU number */ >>> extern struct cpu *cpu_inmotion; /* offline or partition move target >>> */ >>> >>> While OS running I debugged it using mdb -K and looking for the addresses >>> of the symbols. I took the addresses for the ncpus and cpu_list and cpu[]. >>> If I do this: >>> >>> VirtualMemoryAddress kernel_ncpus(ncpus_add); >>> uint64_t kernelCpus = cpuX->readVAddr(VirtualMemoryAddress(kernel_ncpus), >>> 4, 4); >>> >>> The value is correct in this case. Then I tried to see the structure of the >>> struct cpu which is: >>> >>> /* >>> * Per-CPU data. >>> */ >>> typedef struct cpu { >>> processorid_t cpu_id; /* CPU number */ >>> processorid_t cpu_seqid; /* sequential CPU id (0..ncpus-1) */ >>> volatile cpu_flag_t cpu_flags; /* flags indicating CPU state */ >>> struct cpu *cpu_self; /* pointer to itself */ >>> kthread_t *cpu_thread; /* current thread */ >>> kthread_t *cpu_idle_thread; /* idle thread for this CPU */ >>> kthread_t *cpu_pause_thread; /* pause thread for this CPU */ >>> klwp_id_t cpu_lwp; /* current lwp (if any) */ >>> klwp_id_t cpu_fpowner; /* currently loaded fpu owner */ >>> struct cpupart *cpu_part; /* partition with this CPU */ >>> struct lgrp_ld *cpu_lpl; /* pointer to this cpu's load */ >>> struct chip *cpu_chip; /* cpu's chip data */ >>> int cpu_rechoose; /* cpu's rechoose_interval */ >>> int cpu_cache_offset; /* see kmem.c for details */ >>> >>> .............................................................................................. >>> >>> So theoretically if I red the cpu_id should be the cpuid of the current >>> cpu. I tried this: >>> >>> VirtualMemoryAddress kernel_cpuid(cpu_list_add); >>> VirtualMemoryAddress cpuIdAddr = >>> VirtualMemoryAddress(cpu1->readVAddr(VirtualMemoryAddress(kernel_cpuid), >>> 4,8)); >>> uint64_t mycpuId = cpu1->readVAddr(VirtualMemoryAddress(cpuIdAddr), 4,4); >>> >>> if I execute this in WhiteBox constructor and run it everytime the value is >>> 0 regardless of the processor. >>> >>> May I also ask why the last argument for the VirtualMemoryAddress is 8 when >>> I read a pointer and 4 when I read data ? >>> >>> >>> On Thu, Jul 29, 2010 at 1:00 AM, Volos Stavros >>> <[email protected]<mailto:[email protected]>> wrote: >>> In the WhiteBoxImpl.cpp there is a function get_thread_t(aCPU). This >>> function >>> returns the thread_t pointer of the cpu struct. Actually there is a cpu >>> list in the >>> kernel. There is an offset to find the next cpu in the list. Then inside >>> the cpu struct >>> there is a pointer in a thread_t struct where you can find the thread id. >>> >>> The numbers 0x10, 0x48 are hardcoded for Solaris 8. >>> >>> You can look in Open solaris source code to see what is true for Solaris 10 >>> >>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/cpuvar.h#cpu_t >>> >>> You will also need to find the virtual address of the cpu_list in the >>> kernel. You can use >>> the kernel debugger (kdb). >>> >>> Regards, >>> -Stavros >>> >>> ________________________________ >>> From: mihai pricopi >>> [[email protected]<mailto:[email protected]>] >>> Sent: Wednesday, July 28, 2010 12:44 PM >>> To: Volos Stavros >>> Cc: [email protected]<mailto:[email protected]> >>> >>> Subject: Re: Get values per thread >>> >>> Hello, >>> >>> I`m trying to understand how the white box is working. I see this code >>> where I suppose I have to find the answer: >>> >>> struct WhiteBoxImpl : WhiteBox { >>> API::symtable_interface_t * theSymTable; >>> >>> std::vector< PhysicalMemoryAddress > theThreadTs; >>> std::vector< PhysicalMemoryAddress > theIdleThreadTs; >>> >>> WhiteBoxImpl() { >>> #if FLEXUS_TARGET_IS(v9) >>> API::SIM_load_module("symtable"); >>> API::conf_class_t * symtable_class = API::SIM_get_class("symtable"); >>> API::conf_object_t * symtable_obj = API::SIM_new_object(symtable_class, >>> "flexus_symtable"); >>> theSymTable = reinterpret_cast<API::symtable_interface_t >>> *>(API::SIM_get_class_interface(symtable_class, "symtable")); >>> >>> for (int32_t i = 0; i < API::SIM_number_processors(); ++i) { >>> API::conf_object_t * ctx = >>> API::SIM_get_attribute(Simics::APIFwd::SIM_get_processor(i), >>> "current_context").u.object; >>> API::attr_value_t val; >>> val.kind = API::Sim_Val_Object; >>> val.u.object = symtable_obj; >>> API::SIM_set_attribute(ctx, "symtable", &val); >>> } >>> API::attr_value_t arch = API::SIM_get_attribute( >>> Simics::APIFwd::SIM_get_processor(0), "architecture"); >>> API::SIM_set_attribute( symtable_obj, "arch", &arch); >>> >>> DBG_(Dev, ( << "symtable loaded" ) ); >>> #endif >>> >>> >>> } >>> >>> The problem is that I don't know which thread is being executed because I >>> suspect Solaris10 is doing the thread migration meanwhile and I can't rely >>> on the values until I see per thread. Does the ctx hold the information >>> about the current thread that the timing simulation is executing per core ? >>> >>> Thanks >>> Mihai >>> >>> On Wed, Jul 28, 2010 at 4:22 AM, Volos Stavros >>> <[email protected]<mailto:[email protected]>> wrote: >>> Actually, the component WhiteBox is responsible to give the thread id of >>> the thread >>> that is being executed in a particular CPU. However, this component is >>> hardcoded >>> for Solaris 8. I worked on this component to support Solaris 10, but I >>> didn't have time >>> to check whether it works properly or not. >>> >>> Assuming that you know which thread is being executed, it should be easy to >>> get >>> measured values per software thread. >>> >>> Regards, >>> -Stavros >>> >>> ________________________________ >>> From: mihai pricopi >>> [[email protected]<mailto:[email protected]>] >>> Sent: Tuesday, July 27, 2010 6:07 PM >>> To: Volos Stavros >>> Subject: Re: Get values per thread >>> >>> Per software thread. I discovered that Solaris modifies a register when it >>> does the context switch but I`m not sure where exactly in flexus i can read >>> that register and if flexus already gives me this information ? >>> >>> Thanks >>> >>> On Tue, Jul 27, 2010 at 11:55 PM, Volos Stavros >>> <[email protected]<mailto:[email protected]>> wrote: >>> Hi Mihai, >>> >>> What do you mean by the term "thread"? Do you mean software thread or >>> hardware thread (multithreaded >>> processor) ? >>> >>> Regards, >>> -Stavros >>> >>> ________________________________ >>> From: mihai pricopi >>> [[email protected]<mailto:[email protected]>] >>> Sent: Tuesday, July 27, 2010 12:57 PM >>> To: [email protected]<mailto:[email protected]> >>> Subject: Get values per thread >>> >>> Hi, >>> >>> Is it possible that Flexus can give measured values per thread not per >>> core ? >>> >>> Thanks >>> >>> >>> >>> >> >
