qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH 1/1] target-ppc: Support rtas_get_sysparm(PROCESSO


From: Nishanth Aravamudan
Subject: Re: [Qemu-ppc] [PATCH 1/1] target-ppc: Support rtas_get_sysparm(PROCESSOR_MODULE_INFO)
Date: Mon, 2 Nov 2015 17:28:41 -0800
User-agent: Mutt/1.5.21 (2010-09-15)

On 03.11.2015 [11:51:13 +1100], Alexey Kardashevskiy wrote:
> On 11/03/2015 09:43 AM, Sukadev Bhattiprolu wrote:
> >Alexey Kardashevskiy address@hidden wrote:
> >| On 10/31/2015 03:33 AM, Sukadev Bhattiprolu wrote:
> >| >Alexey Kardashevskiy address@hidden wrote:
> >| >
> >| >Thanks for the review. Agree with your other comments and will address
> >| >them.
> >| >
> >| >| >+#include <string.h>
> >| >| >+#include <errno.h>
> >| >| >+
> >| >| >+/*
> >| >| >+ * TODO: <fts.h> doesn't like __USE_FILE_OFFSET64 but hopefully we 
> >don't
> >| >|
> >| >|
> >| >| That's ugly :-/ Google is saying there is
> >| >| http://linux.die.net/man/3/ftw which looks newer => better.
> >| >
> >| >Like I say below...
> >| >
> >| >|
> >| >|
> >| >| >+ *     need to deal with large file offsets in /proc/device-tree. If 
> >we
> >| >| >+ *     must, we should fall back to walking the tree with opendir().
> >| >| >+ *     Another alternative is nftw() but that requires us to use 
> >global
> >| >| >+ *     variables to keep the counts of chips/cores etc so we need to
> >| >| >+ *     serialize access to the globals.
> >| >| >+ */
> >| >
> >| >for each file, nftw() calls the 'fn()' parameter but there is no state
> >| >info saved from one call to next. So if we find a chip and want to 
> >increment
> >| >a counter, we need a global variable and some serialization. I was trying
> >| >to keep it simple, given that device-tree files we care about are not 
> >large.
> >| >But should we add a mutex and increment global counts instead?
> >|
> >| I do not really understand why you need to walk the whole tree while
> >| the nodes you are interested in are just these:
> >|
> >| /proc/device-tree/cpus/PowerPC,address@hidden/ibm,chip-id
> >| /proc/device-tree/cpus/PowerPC,address@hidden/device-type
> >| /proc/device-tree/address@hidden/ibm,chip-id
> >| /proc/device-tree/address@hidden/ibm,hw-module-id
> >|
> >| These are known locations which are unlike to change.
> >
> >Agree. I was trying to use existing interfaces like nftw()/fts_open()
> >to walk the directory tree. If we continue with fts_open(), we could
> >use fts_set(FTS_SKIP) to skip over sub trees that we don't care about.
> >Or should we just use opendir() to walk those two directories trees?
> 
> Whichever you like. You might also wait a bit till somebody else
> comments on this.
> 
> 
> btw this "fts.h" does not exists in my mingw32 environment, have you
> tried this?
> 
> This is how I do this (on fc20/ppc64be):
> ./configure --cc=i686-w64-mingw32-gcc
> --cross-prefix=i686-w64-mingw32- --target-list=ppc64-softmmu
> 
> or (on fc22/x86_64):
> ./configure --cc=x86_64-w64-mingw32-gcc
> --cross-prefix=x86_64-w64-mingw32- --target-list=ppc64-softmmu
> 
> 
> >|
> >| btw why do you double-check for PowerPC,address@hidden/device-type to have
> >| "cpu"? Can it be something different? On what system?
> >
> >I guess I could remove that double check, now that I check the parent
> >dir name prefix ('PowerPC,POWER*)'. The cpus/ directory also has the
> >cache entries and I was trying to skip them.
> >
> >|
> >| And what is "ibm,hw-module-id"? None of my systems has it - Tuleta,
> >| Firestone. Is that NUMA?
> >
> >We have it on our Tuleta host's device tree. It is not (yet?) in the KVM
> >guest's device tree. My understading is that module is an alias for "socket".
> 
> Ah, my bad, found it in /proc/device-tree/address@hidden
> 
> 
> >|
> >| Another thought - all CPUs can be enumerated via
> >| /sys/devices/system/cpu/cpu* and nodes - via
> >| /sys/devices/system/nodes, they all have symlinks to each other and
> >| to the device tree, might be useful for this task, not sure though.
> >
> >I think those entries represent the CPU threads. This RTAS call
> >is looking for cores/chips/sockets.
> 
> Well, you are still matching core to modules, managing maps, etc,
> may be this is already done somewhere in /sys, I just do not know.

What I've found so far is that the sysfs outputs are relying on some of
the in-kernel parsing of the device-tree, and is generally at the core
and thread level (siblings of relevance to the scheduler,
topologically). Modules and sockets and chips are not generally
reflected in sysfs (not that they couldn't be). And, in some ways, the
RTAS interface is really meant to describe the underlying hardware, not
necessarily the host kernel's view of it -- I go back and forth on which
is better to represent to the guests.

-Nish




reply via email to

[Prev in Thread] Current Thread [Next in Thread]