* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <4DD5334D.4060800@tilera.com> @ 2011-05-19 15:22 ` Arnd Bergmann [not found] ` <201105191722.17685.arnd@arndb.de> 1 sibling, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-19 15:22 UTC (permalink / raw) To: Chris Metcalf, virtualization; +Cc: linux-kernel (adding virtualization mailing list) On Thursday 19 May 2011, Chris Metcalf wrote: > On 5/19/2011 9:41 AM, Arnd Bergmann wrote: > >> /proc/tile/hvconfig > >> Detailed configuration description of the hypervisor config > > I'm concerned about moving this one out of /proc, since it's just (copious) > free text. An "hvconfig" (hypervisor config) file describes hypervisor > driver "dedicated tiles" that run things like network packet or PCIe > ingress/egress processing, etc. In addition it lists hypervisor driver > options, boot flags for the kernel, etc, all kinds of things -- and you > can't really guarantee that it will fit on a 4KB page, though in practice > it usually does. The hypervisor reads this file from the boot stream when > it boots, and then makes it available to Linux not for Linux's use, or even > for programmatic userspace use, but just for end users to be able to review > and verify that the configuration they think they booted is really what > they got, for customer remote debugging, etc. The "remote debugging" > aspect makes truncation to page size a particularly worrisome idea. Since it's not the kernel that is imposing the format here, you could make it a binary sysfs attribute, which works in the same way as a proc file and does not have the size limitations. > >> /proc/tile/board > >> Information on part numbers, serial numbers, etc., of the > >> hardware that the kernel is executing on > >> > >> /proc/tile/switch > >> The type of control path for the onboard network switch, if any. > > These two report information about the hardware, not the hypervisor. For > example: > > # cat /proc/tile/board > board_part: 402-00002-05 > board_serial: NBS-5002-00012 > chip_serial: P62338.01.110 > chip_revision: A0 > board_revision: 2.2 > board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE > # cat /proc/tile/switch > control: mdio gbe/0 I think it's ok to have it below /sys/hypervisor, because the information is provided through a hypervisor ABI, even though it describes something else. This is more like /sys/firmware, but the boundaries between that and /sys/hypervisor are not clearly defined when running virtualized anyway. > The chip_serial and chip_revision can certainly hang off > /sys/devices/system/cpu along with chip_height and chip_width (I've made > this change now) but I don't know where the remaining "board" level > description could go. Note that (as you can see in the source) certain > boards will also include four lines of output with the "mezzanine board" > part number, serial number, revision, and description; this particular > example doesn't have a mezzanine board. The "switch" info is broken out > into a separate file just to make it easier to script some /etc/rc code > that launches a configurator for the Marvell switch on some of our boards, > but is conceptually part of the board info. > > >> /proc/tile/hardwall > >> Information on the set of currently active hardwalls (note that > >> the implementation is already present in arch/tile/kernel/hardwall.c; > >> this change just enables it) > > This one is not a hypervisor-related file. It just lists information about > the set of Linux hardwalls currently active. Again, it's not primarily > intended for programmatic use, but as a diagnostic tool. same here, I'd still put it into the hypervisor structure. Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <201105191722.17685.arnd@arndb.de>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105191722.17685.arnd@arndb.de> @ 2011-05-20 14:26 ` Chris Metcalf [not found] ` <4DD67A31.90802@tilera.com> 2011-05-24 15:38 ` [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute Arnd Bergmann 2 siblings, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-20 14:26 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linux-kernel, virtualization On 5/19/2011 11:22 AM, Arnd Bergmann wrote: > On Thursday 19 May 2011, Chris Metcalf wrote: >>>> /proc/tile/board >>>> Information on part numbers, serial numbers, etc., of the >>>> hardware that the kernel is executing on >>>> >>>> /proc/tile/switch >>>> The type of control path for the onboard network switch, if any. >> These two report information about the hardware, not the hypervisor. For >> example: >> >> # cat /proc/tile/board >> board_part: 402-00002-05 >> board_serial: NBS-5002-00012 >> chip_serial: P62338.01.110 >> chip_revision: A0 >> board_revision: 2.2 >> board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE >> # cat /proc/tile/switch >> control: mdio gbe/0 > I think it's ok to have it below /sys/hypervisor, because the information > is provided through a hypervisor ABI, even though it describes something > else. This is more like /sys/firmware, but the boundaries between that > and /sys/hypervisor are not clearly defined when running virtualized anyway. I'll create a /sys/hypervisor/board/ and report the attributes there. >>>> /proc/tile/hardwall >>>> Information on the set of currently active hardwalls (note that >>>> the implementation is already present in arch/tile/kernel/hardwall.c; >>>> this change just enables it) >> This one is not a hypervisor-related file. It just lists information about >> the set of Linux hardwalls currently active. Again, it's not primarily >> intended for programmatic use, but as a diagnostic tool. > same here, I'd still put it into the hypervisor structure. Since /proc/tile/hardwall has no connection to the hypervisor whatsoever, I'm reluctant to put it under /sys/hypervisor. Perhaps in this case it would be reasonable to just have the hardwall subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? Or I could make the /dev/hardwall char device dump out the ASCII text that we currently get from /proc/hardwall if you read from it, which is a little weird but not inconceivable. For example it currently shows things like this: # cat /proc/tile/hardwall 2x2 1,1 pids: 484@2,1 479@1,1 2x2 0,3 pids: In this example "2x2 1,1" is a 2x2 grid of cpus starting at grid (x,y) position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). -- Chris Metcalf, Tilera Corp. http://www.tilera.com ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <4DD67A31.90802@tilera.com>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <4DD67A31.90802@tilera.com> @ 2011-05-20 14:37 ` Arnd Bergmann [not found] ` <201105201637.20925.arnd@arndb.de> 1 sibling, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-20 14:37 UTC (permalink / raw) To: Chris Metcalf; +Cc: linux-kernel, virtualization On Friday 20 May 2011 16:26:57 Chris Metcalf wrote: > >>>> /proc/tile/hardwall > >>>> Information on the set of currently active hardwalls (note that > >>>> the implementation is already present in arch/tile/kernel/hardwall.c; > >>>> this change just enables it) > >> This one is not a hypervisor-related file. It just lists information about > >> the set of Linux hardwalls currently active. Again, it's not primarily > >> intended for programmatic use, but as a diagnostic tool. > > same here, I'd still put it into the hypervisor structure. > > Since /proc/tile/hardwall has no connection to the hypervisor whatsoever, > I'm reluctant to put it under /sys/hypervisor. Ah, I see. I didn't notice that it was in the other file. You are absolutely right, this does not belong into /sys/hypervisor and fits well into procfs, we just need to find the right place. > Perhaps in this case it would be reasonable to just have the hardwall > subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? > Or I could make the /dev/hardwall char device dump out the ASCII text that > we currently get from /proc/hardwall if you read from it, which is a little > weird but not inconceivable. For example it currently shows things like this: > > # cat /proc/tile/hardwall > 2x2 1,1 pids: 484@2,1 479@1,1 > 2x2 0,3 pids: > > In this example "2x2 1,1" is a 2x2 grid of cpus starting at grid (x,y) > position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <201105201637.20925.arnd@arndb.de>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105201637.20925.arnd@arndb.de> @ 2011-05-20 15:00 ` Chris Metcalf [not found] ` <4DD6821F.6060707@tilera.com> 1 sibling, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-20 15:00 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linux-kernel, virtualization On 5/20/2011 10:37 AM, Arnd Bergmann wrote: > On Friday 20 May 2011 16:26:57 Chris Metcalf wrote: >>>>>> /proc/tile/hardwall >>>>>> Information on the set of currently active hardwalls (note that >>>>>> the implementation is already present in arch/tile/kernel/hardwall.c; >>>>>> this change just enables it) > Ah, I see. I didn't notice that it was in the other file. You are > absolutely right, this does not belong into /sys/hypervisor and > fits well into procfs, we just need to find the right place. >> Perhaps in this case it would be reasonable to just have the hardwall >> subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? >> Or I could make the /dev/hardwall char device dump out the ASCII text that >> we currently get from /proc/hardwall if you read from it, which is a little >> weird but not inconceivable. For example it currently shows things like this: >> >> # cat /proc/tile/hardwall >> 2x2 1,1 pids: 484@2,1 479@1,1 >> 2x2 0,3 pids: >> >> In this example "2x2 1,1" is a 2x2 grid of cpus starting at grid (x,y) >> position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 It's not unreasonable to do what you're suggesting, i.e. "what's this task's hardwall?", but it's not something that we've come up with any kind of use case for in the past, so I'm not currently planning to implement this. If we did, I agree, your solution looks like the right one. The proposed /proc/tile/hardwall really is intended as system-wide information. Each hardwall (one line in the output file example above) corresponds to a "struct file" that may be shared by multiple processes (or threads). Processes may pass the "struct file" to other processes via fork (and maybe exec), or by passing it over Unix sockets. Then those processes can choose a cpu within a hardwall rectangle, affinitize to that cpu only, "activate" the hardwall fd with an ioctl(), and then get access from the OS so they can work together within a hardwall to exchange data across the Tilera "user dynamic network" (a wormhole routed grid network that moves data at 32 bits/cycle with almost no latency). Processes can create a new hardwall as long as it doesn't overlap geometrically with any other existing hardwall on the system. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <4DD6821F.6060707@tilera.com>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <4DD6821F.6060707@tilera.com> @ 2011-05-20 15:13 ` Arnd Bergmann [not found] ` <201105201713.25364.arnd@arndb.de> 1 sibling, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-20 15:13 UTC (permalink / raw) To: Chris Metcalf; +Cc: linux-kernel, virtualization On Friday 20 May 2011 17:00:47 Chris Metcalf wrote: > > Any chance you can still restructure the information? I would recommend > > making it a first-class procfs member, since the data is really per-task. > > > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > > to make it show up for each pid, and then just have the per-task information > > in there to do the lookup the other way round: > > > > # cat /proc/484/hardwall > > 2x2 1,1 @2,1 > > > > # cat /proc/479/hardwall > > 2x2 1,1 @1,1 > > It's not unreasonable to do what you're suggesting, i.e. "what's this > task's hardwall?", but it's not something that we've come up with any kind > of use case for in the past, so I'm not currently planning to implement > this. If we did, I agree, your solution looks like the right one. It's fairly easy to aggregate in user space though, we do similar things for 'lsof' and 'top', which walk all of procfs in order to show the complete picture. This is obviously more overhead than walking the lists in the kernel, but still not an expensive operation, and it keeps the data format much simpler. Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <201105201713.25364.arnd@arndb.de>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105201713.25364.arnd@arndb.de> @ 2011-05-20 19:59 ` Arnd Bergmann [not found] ` <201105202159.50780.arnd@arndb.de> 1 sibling, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-20 19:59 UTC (permalink / raw) To: virtualization; +Cc: linux-kernel, Chris Metcalf On Friday 20 May 2011 17:13:25 Arnd Bergmann wrote: > On Friday 20 May 2011 17:00:47 Chris Metcalf wrote: > > > Any chance you can still restructure the information? I would recommend > > > making it a first-class procfs member, since the data is really per-task. > > > > > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > > > to make it show up for each pid, and then just have the per-task information > > > in there to do the lookup the other way round: > > > > > > # cat /proc/484/hardwall > > > 2x2 1,1 @2,1 > > > > > > # cat /proc/479/hardwall > > > 2x2 1,1 @1,1 > > > > It's not unreasonable to do what you're suggesting, i.e. "what's this > > task's hardwall?", but it's not something that we've come up with any kind > > of use case for in the past, so I'm not currently planning to implement > > this. If we did, I agree, your solution looks like the right one. > > It's fairly easy to aggregate in user space though, we do similar > things for 'lsof' and 'top', which walk all of procfs in order > to show the complete picture. This is obviously more overhead than > walking the lists in the kernel, but still not an expensive > operation, and it keeps the data format much simpler. Another problem with the existing interface is that it doesn't currently support PID name spaces. That could of course be retrofitted, but having the data split by pid directory would make it work implicitly. Another approach would be to have a /proc/hardwall/ directory with one entry per hardwall instance, and symlinks from /proc/<pid>/hardwall to the respective file. Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <201105202159.50780.arnd@arndb.de>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105202159.50780.arnd@arndb.de> @ 2011-05-25 19:09 ` Chris Metcalf 2011-05-25 19:17 ` Chris Metcalf ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-25 19:09 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linux-kernel, virtualization [-- Attachment #1.1: Type: text/plain, Size: 2858 bytes --] On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 > Another problem with the existing interface is that it doesn't currently > support PID name spaces. That could of course be retrofitted, but having > the data split by pid directory would make it work implicitly. > > Another approach would be to have a /proc/hardwall/ directory with > one entry per hardwall instance, and symlinks from /proc/<pid>/hardwall > to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the "hardwall" entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall can be found by reading the "hardwall" files, and we can learn where they are bound in the hardwall by reading the "stat" file as is normal for learning process affinity. > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > under /sys/hypervisor with the name of your hypervisor, to avoid naming > conflicts, e.g. > > /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just "tile" is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com [-- Attachment #1.2: Type: text/html, Size: 3718 bytes --] [-- Attachment #2: Type: text/plain, Size: 184 bytes --] _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105202159.50780.arnd@arndb.de> 2011-05-25 19:09 ` Chris Metcalf @ 2011-05-25 19:17 ` Chris Metcalf 2011-05-25 19:18 ` Chris Metcalf [not found] ` <4DDD55ED.2080607@tilera.com> 3 siblings, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-25 19:17 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linux-kernel, virtualization [-- Attachment #1.1: Type: text/plain, Size: 2936 bytes --] (Resending after marking LKML in my Thunderbird address book for "no HTML".) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 > Another problem with the existing interface is that it doesn't currently > support PID name spaces. That could of course be retrofitted, but having > the data split by pid directory would make it work implicitly. > > Another approach would be to have a /proc/hardwall/ directory with > one entry per hardwall instance, and symlinks from /proc/<pid>/hardwall > to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the "hardwall" entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall can be found by reading the "hardwall" files, and we can learn where they are bound in the hardwall by reading the "stat" file as is normal for learning process affinity. > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > under /sys/hypervisor with the name of your hypervisor, to avoid naming > conflicts, e.g. > > /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just "tile" is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com [-- Attachment #1.2: Type: text/html, Size: 3815 bytes --] [-- Attachment #2: Type: text/plain, Size: 184 bytes --] _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105202159.50780.arnd@arndb.de> 2011-05-25 19:09 ` Chris Metcalf 2011-05-25 19:17 ` Chris Metcalf @ 2011-05-25 19:18 ` Chris Metcalf [not found] ` <4DDD55ED.2080607@tilera.com> 3 siblings, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-25 19:18 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linux-kernel, virtualization (Resending with no HTML for LKML.) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 > Another problem with the existing interface is that it doesn't currently > support PID name spaces. That could of course be retrofitted, but having > the data split by pid directory would make it work implicitly. > > Another approach would be to have a /proc/hardwall/ directory with > one entry per hardwall instance, and symlinks from /proc/<pid>/hardwall > to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the "hardwall" entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall can be found by reading the "hardwall" files, and we can learn where they are bound in the hardwall by reading the "stat" file as is normal for learning process affinity. > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > under /sys/hypervisor with the name of your hypervisor, to avoid naming > conflicts, e.g. > > /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just "tile" is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <4DDD55ED.2080607@tilera.com>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <4DDD55ED.2080607@tilera.com> @ 2011-05-25 20:20 ` Arnd Bergmann [not found] ` <201105252220.23948.arnd@arndb.de> 1 sibling, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-25 20:20 UTC (permalink / raw) To: virtualization; +Cc: linux-kernel, Chris Metcalf On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: > (Resending with no HTML for LKML.) > > On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > > Any chance you can still restructure the information? I would recommend > > making it a first-class procfs member, since the data is really per-task. > > > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > > to make it show up for each pid, and then just have the per-task information > > in there to do the lookup the other way round: > > > > # cat /proc/484/hardwall > > 2x2 1,1 @2,1 > > > > # cat /proc/479/hardwall > > 2x2 1,1 @1,1 > > Another problem with the existing interface is that it doesn't currently > > support PID name spaces. That could of course be retrofitted, but having > > the data split by pid directory would make it work implicitly. > > > > Another approach would be to have a /proc/hardwall/ directory with > > one entry per hardwall instance, and symlinks from /proc/<pid>/hardwall > > to the respective file. > > I went ahead and implemented this, and will send out a v2 patch shortly. I > added the "hardwall" entry to both the tgid_base (since everything is > reflected there) but also to the tid_base_stuff[], since it can be > different (in principle) for different threads. Ok, sounds good. > I played around with using a symlink, but the bottom line seems to be that > if I make it a symlink (via a SYM() macro in the table) it always has to > exist -- so what does it point to when there's no hardwall activated? I > tried making it point to /dev/null, but that just seemed silly. In the end > I made /proc/PID/hardwall a file, either empty, or else containing the > hardwall id. ok. I suppose you could make a non-hardwall file that you can link to, but an empty file also sounds ok. > The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the > hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid > allocator seemed too tied to task_structs. We only need at most NR_CPUS > hardwall ids, so it's pretty simple to just use a cpumask to hold the set > of allocated hardwall IDs. ok. > The contents of the hardwall ID file are then just a cpulist of the cpus > covered by the hardwall, rather than introducing a new convention (as > quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall > can be found by reading the "hardwall" files, and we can learn where they > are bound in the hardwall by reading the "stat" file as is normal for > learning process affinity. Be careful with listing PID values in the hardwall files, as the PIDs may not be unique or visible if you combine this with PID name spaces. I guess the right solution would be to only list the tasks that are present in the name space of the thread reading the file. > > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > > under /sys/hypervisor with the name of your hypervisor, to avoid naming > > conflicts, e.g. > > > > /sys/hypervisor/tilera-hv/board/board_serial > > I don't see an easy way to put a directory in /sys/hypervisor. It seems > complex to create a kobject and a suitable class, etc., just for a > subdirectory. Or is there something simple I'm missing? I'll keep looking. > > I also suspect just "tile" is an adequate subdirectory name here in the > context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. I just checked for other users. The only one I could find was drivers/xen/sys-hypervisor.c, and it also doesn't use a subdirectory to identify that hypervisor. It's probably more consistent if you also don't do it then. You can create a directory with multiple files using sysfs_create_group() as the xen code does, but not nested directories. Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <201105252220.23948.arnd@arndb.de>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105252220.23948.arnd@arndb.de> @ 2011-05-25 20:31 ` Chris Metcalf [not found] ` <4DDD6729.7070201@tilera.com> [not found] ` <201105261648.p4QGmNKf001636@farm-0023.internal.tilera.com> 2 siblings, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-25 20:31 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linux-kernel, virtualization On 5/25/2011 4:20 PM, Arnd Bergmann wrote: > On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: >> The contents of the hardwall ID file are then just a cpulist of the cpus >> covered by the hardwall, rather than introducing a new convention (as >> quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall >> can be found by reading the "hardwall" files, and we can learn where they >> are bound in the hardwall by reading the "stat" file as is normal for >> learning process affinity. > Be careful with listing PID values in the hardwall files, as the PIDs > may not be unique or visible if you combine this with PID name spaces. > I guess the right solution would be to only list the tasks that are > present in the name space of the thread reading the file. Sorry not to be clearer -- I am no longer listing any PID values in the hardwall files, for that exact reason. You have to look at /proc/*/hardwall (or /proc/*/tasks/*/hardwall) to find the files that are in a particular hardwall. This pattern is not one that's normally directly useful, though, so I'm happy leaving it to userspace if it's desired. >>> When you do a /sys/hypervisor/ interface, put everything into a subdirectory >>> under /sys/hypervisor with the name of your hypervisor, to avoid naming >>> conflicts, e.g. >>> >>> /sys/hypervisor/tilera-hv/board/board_serial > I just checked for other users. The only one I could find was > drivers/xen/sys-hypervisor.c, and it also doesn't use a subdirectory to > identify that hypervisor. It's probably more consistent if you also don't > do it then. > > You can create a directory with multiple files using sysfs_create_group() > as the xen code does, but not nested directories. I'll look into sysfs_create_group(), and then send a revised patch with all the /proc and /sys changes. Thanks! -- Chris Metcalf, Tilera Corp. http://www.tilera.com ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <4DDD6729.7070201@tilera.com>]
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <4DDD6729.7070201@tilera.com> @ 2011-05-25 20:34 ` Arnd Bergmann 0 siblings, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-25 20:34 UTC (permalink / raw) To: Chris Metcalf; +Cc: linux-kernel, virtualization On Wednesday 25 May 2011 22:31:37 Chris Metcalf wrote: > On 5/25/2011 4:20 PM, Arnd Bergmann wrote: > > On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: > >> The contents of the hardwall ID file are then just a cpulist of the cpus > >> covered by the hardwall, rather than introducing a new convention (as > >> quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall > >> can be found by reading the "hardwall" files, and we can learn where they > >> are bound in the hardwall by reading the "stat" file as is normal for > >> learning process affinity. > > Be careful with listing PID values in the hardwall files, as the PIDs > > may not be unique or visible if you combine this with PID name spaces. > > I guess the right solution would be to only list the tasks that are > > present in the name space of the thread reading the file. > > Sorry not to be clearer -- I am no longer listing any PID values in the > hardwall files, for that exact reason. You have to look at > /proc/*/hardwall (or /proc/*/tasks/*/hardwall) to find the files that are > in a particular hardwall. This pattern is not one that's normally directly > useful, though, so I'm happy leaving it to userspace if it's desired. Ok, thanks for the clarification. Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <201105261648.p4QGmNKf001636@farm-0023.internal.tilera.com>]
* Re: [PATCH v2] arch/tile: more /proc and /sys file support [not found] ` <201105261648.p4QGmNKf001636@farm-0023.internal.tilera.com> @ 2011-05-27 14:23 ` Arnd Bergmann 0 siblings, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-27 14:23 UTC (permalink / raw) To: Chris Metcalf; +Cc: Andrew Morton, linux-kernel, Al Viro, virtualization On Thursday 26 May 2011, Chris Metcalf wrote: > This change introduces a few of the less controversial /proc and > /proc/sys interfaces for tile, along with sysfs attributes for > various things that were originally proposed as /proc/tile files. > It also adjusts the "hardwall" proc API. Looks good to me now, except > Finally, after some feedback from Arnd Berghamm for the previous typo ^^^^ Reviewed-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute [not found] ` <201105191722.17685.arnd@arndb.de> 2011-05-20 14:26 ` Chris Metcalf [not found] ` <4DD67A31.90802@tilera.com> @ 2011-05-24 15:38 ` Arnd Bergmann 2 siblings, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2011-05-24 15:38 UTC (permalink / raw) To: virtualization; +Cc: linux-kernel, Chris Metcalf On Thursday 19 May 2011, Arnd Bergmann wrote: > > > > # cat /proc/tile/board > > board_part: 402-00002-05 > > board_serial: NBS-5002-00012 > > chip_serial: P62338.01.110 > > chip_revision: A0 > > board_revision: 2.2 > > board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE > > # cat /proc/tile/switch > > control: mdio gbe/0 > > I think it's ok to have it below /sys/hypervisor, because the information > is provided through a hypervisor ABI, even though it describes something > else. This is more like /sys/firmware, but the boundaries between that > and /sys/hypervisor are not clearly defined when running virtualized anyway. A minor point that I meant to bring up but had not gotten to: When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial Arnd ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2] arch/tile: more /proc and /sys file support [not found] <201105181807.p4II7C5g015224@farm-0002.internal.tilera.com> [not found] ` <201105191541.11939.arnd@arndb.de> @ 2011-05-26 16:40 ` Chris Metcalf 1 sibling, 0 replies; 15+ messages in thread From: Chris Metcalf @ 2011-05-26 16:40 UTC (permalink / raw) To: Arnd Bergmann, linux-kernel, virtualization, Andrew Morton This change introduces a few of the less controversial /proc and /proc/sys interfaces for tile, along with sysfs attributes for various things that were originally proposed as /proc/tile files. It also adjusts the "hardwall" proc API. Arnd Bergmann reviewed the initial arch/tile submission, which included a complete set of all the /proc/tile and /proc/sys/tile knobs that we had added in a somewhat ad hoc way during initial development, and provided feedback on where most of them should go. One knob turned out to be similar enough to the existing /proc/sys/debug/exception-trace that it was re-implemented to use that model instead. Another knob was /proc/tile/grid, which reported the "grid" dimensions of a tile chip (e.g. 8x8 processors = 64-core chip). Arnd suggested looking at sysfs for that, so this change moves that information to a pair of sysfs attributes (chip_width and chip_height) in the /sys/devices/system/cpu directory. We also put the "chip_serial" and "chip_revision" information from our old /proc/tile/board file as attributes in /sys/devices/system/cpu. Other information collected via hypervisor APIs is now placed in /sys/hypervisor. We create a /sys/hypervisor/type file (holding the constant string "tilera") to be parallel with the Xen use of /sys/hypervisor/type holding "xen". We create three top-level files, "version" (the hypervisor's own version), "config_version" (the version of the configuration file), and "hvconfig" (the contents of the configuration file). The remaining information from our old /proc/tile/board and /proc/tile/switch files becomes an attribute group appearing under /sys/hypervisor/board/. Finally, after some feedback from Arnd Berghamm for the previous version of this patch, the /proc/tile/hardwall file is split up into two conceptual parts. First, a directory /proc/tile/hardwall/ which contains one file per active hardwall, each file named after the hardwall's ID and holding a cpulist that says which cpus are enclosed by the hardwall. Second, a /proc/PID file "hardwall" that is either empty (for non-hardwall-using processes) or contains the hardwall ID. Finally, this change pushes the /proc/sys/tile/unaligned_fixup/ directory, with knobs controlling the kernel code for handling the fixup of unaligned exceptions. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> --- arch/tile/Kconfig | 1 + arch/tile/include/asm/hardwall.h | 15 +++- arch/tile/kernel/Makefile | 2 +- arch/tile/kernel/hardwall.c | 90 ++++++++++++++----- arch/tile/kernel/proc.c | 73 +++++++++++++++ arch/tile/kernel/sysfs.c | 185 ++++++++++++++++++++++++++++++++++++++ fs/proc/base.c | 9 ++ 7 files changed, 347 insertions(+), 28 deletions(-) create mode 100644 arch/tile/kernel/sysfs.c diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig index 635e1bf..3f7d63c 100644 --- a/arch/tile/Kconfig +++ b/arch/tile/Kconfig @@ -12,6 +12,7 @@ config TILE select GENERIC_IRQ_PROBE select GENERIC_PENDING_IRQ if SMP select GENERIC_IRQ_SHOW + select SYS_HYPERVISOR # FIXME: investigate whether we need/want these options. # select HAVE_IOREMAP_PROT diff --git a/arch/tile/include/asm/hardwall.h b/arch/tile/include/asm/hardwall.h index 0bed3ec..2ac4228 100644 --- a/arch/tile/include/asm/hardwall.h +++ b/arch/tile/include/asm/hardwall.h @@ -40,6 +40,10 @@ #define HARDWALL_DEACTIVATE \ _IO(HARDWALL_IOCTL_BASE, _HARDWALL_DEACTIVATE) +#define _HARDWALL_GET_ID 4 +#define HARDWALL_GET_ID \ + _IO(HARDWALL_IOCTL_BASE, _HARDWALL_GET_ID) + #ifndef __KERNEL__ /* This is the canonical name expected by userspace. */ @@ -47,9 +51,14 @@ #else -/* Hook for /proc/tile/hardwall. */ -struct seq_file; -int proc_tile_hardwall_show(struct seq_file *sf, void *v); +/* /proc hooks for hardwall. */ +struct proc_dir_entry; +#ifdef CONFIG_HARDWALL +void proc_tile_hardwall_init(struct proc_dir_entry *root); +int proc_pid_hardwall(struct task_struct *task, char *buffer); +#else +static inline void proc_tile_hardwall_init(struct proc_dir_entry *root) {} +#endif #endif diff --git a/arch/tile/kernel/Makefile b/arch/tile/kernel/Makefile index b4c8e8e..b4dbc05 100644 --- a/arch/tile/kernel/Makefile +++ b/arch/tile/kernel/Makefile @@ -5,7 +5,7 @@ extra-y := vmlinux.lds head_$(BITS).o obj-y := backtrace.o entry.o init_task.o irq.o messaging.o \ pci-dma.o proc.o process.o ptrace.o reboot.o \ - setup.o signal.o single_step.o stack.o sys.o time.o traps.o \ + setup.o signal.o single_step.o stack.o sys.o sysfs.o time.o traps.o \ intvec_$(BITS).o regs_$(BITS).o tile-desc_$(BITS).o obj-$(CONFIG_HARDWALL) += hardwall.o diff --git a/arch/tile/kernel/hardwall.c b/arch/tile/kernel/hardwall.c index 3bddef7..8c41891 100644 --- a/arch/tile/kernel/hardwall.c +++ b/arch/tile/kernel/hardwall.c @@ -40,16 +40,25 @@ struct hardwall_info { struct list_head list; /* "rectangles" list */ struct list_head task_head; /* head of tasks in this hardwall */ + struct cpumask cpumask; /* cpus in the rectangle */ int ulhc_x; /* upper left hand corner x coord */ int ulhc_y; /* upper left hand corner y coord */ int width; /* rectangle width */ int height; /* rectangle height */ + int id; /* integer id for this hardwall */ int teardown_in_progress; /* are we tearing this one down? */ }; /* Currently allocated hardwall rectangles */ static LIST_HEAD(rectangles); +/* /proc/tile/hardwall */ +static struct proc_dir_entry *hardwall_proc_dir; + +/* Functions to manage files in /proc/tile/hardwall. */ +static void hardwall_add_proc(struct hardwall_info *rect); +static void hardwall_remove_proc(struct hardwall_info *rect); + /* * Guard changes to the hardwall data structures. * This could be finer grained (e.g. one lock for the list of hardwall @@ -105,6 +114,8 @@ static int setup_rectangle(struct hardwall_info *r, struct cpumask *mask) r->ulhc_y = cpu_y(ulhc); r->width = cpu_x(lrhc) - r->ulhc_x + 1; r->height = cpu_y(lrhc) - r->ulhc_y + 1; + cpumask_copy(&r->cpumask, mask); + r->id = ulhc; /* The ulhc cpu id can be the hardwall id. */ /* Width and height must be positive */ if (r->width <= 0 || r->height <= 0) @@ -388,6 +399,9 @@ static struct hardwall_info *hardwall_create( /* Set up appropriate hardwalling on all affected cpus. */ hardwall_setup(rect); + /* Create a /proc/tile/hardwall entry. */ + hardwall_add_proc(rect); + return rect; } @@ -645,6 +659,9 @@ static void hardwall_destroy(struct hardwall_info *rect) /* Restart switch and disable firewall. */ on_each_cpu_mask(&mask, restart_udn_switch, NULL, 1); + /* Remove the /proc/tile/hardwall entry. */ + hardwall_remove_proc(rect); + /* Now free the rectangle from the list. */ spin_lock_irqsave(&hardwall_lock, flags); BUG_ON(!list_empty(&rect->task_head)); @@ -654,35 +671,57 @@ static void hardwall_destroy(struct hardwall_info *rect) } -/* - * Dump hardwall state via /proc; initialized in arch/tile/sys/proc.c. - */ -int proc_tile_hardwall_show(struct seq_file *sf, void *v) +static int hardwall_proc_show(struct seq_file *sf, void *v) { - struct hardwall_info *r; + struct hardwall_info *rect = sf->private; + char buf[256]; - if (udn_disabled) { - seq_printf(sf, "%dx%d 0,0 pids:\n", smp_width, smp_height); - return 0; - } - - spin_lock_irq(&hardwall_lock); - list_for_each_entry(r, &rectangles, list) { - struct task_struct *p; - seq_printf(sf, "%dx%d %d,%d pids:", - r->width, r->height, r->ulhc_x, r->ulhc_y); - list_for_each_entry(p, &r->task_head, thread.hardwall_list) { - unsigned int cpu = cpumask_first(&p->cpus_allowed); - unsigned int x = cpu % smp_width; - unsigned int y = cpu / smp_width; - seq_printf(sf, " %d@%d,%d", p->pid, x, y); - } - seq_printf(sf, "\n"); - } - spin_unlock_irq(&hardwall_lock); + int rc = cpulist_scnprintf(buf, sizeof(buf), &rect->cpumask); + buf[rc++] = '\n'; + seq_write(sf, buf, rc); return 0; } +static int hardwall_proc_open(struct inode *inode, + struct file *file) +{ + return single_open(file, hardwall_proc_show, PDE(inode)->data); +} + +static const struct file_operations hardwall_proc_fops = { + .open = hardwall_proc_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static void hardwall_add_proc(struct hardwall_info *rect) +{ + char buf[64]; + snprintf(buf, sizeof(buf), "%d", rect->id); + proc_create_data(buf, 0444, hardwall_proc_dir, + &hardwall_proc_fops, rect); +} + +static void hardwall_remove_proc(struct hardwall_info *rect) +{ + char buf[64]; + snprintf(buf, sizeof(buf), "%d", rect->id); + remove_proc_entry(buf, hardwall_proc_dir); +} + +int proc_pid_hardwall(struct task_struct *task, char *buffer) +{ + struct hardwall_info *rect = task->thread.hardwall; + return rect ? sprintf(buffer, "%d\n", rect->id) : 0; +} + +void proc_tile_hardwall_init(struct proc_dir_entry *root) +{ + if (!udn_disabled) + hardwall_proc_dir = proc_mkdir("hardwall", root); +} + /* * Character device support via ioctl/close. @@ -716,6 +755,9 @@ static long hardwall_ioctl(struct file *file, unsigned int a, unsigned long b) return -EINVAL; return hardwall_deactivate(current); + case _HARDWALL_GET_ID: + return rect ? rect->id : -EINVAL; + default: return -EINVAL; } diff --git a/arch/tile/kernel/proc.c b/arch/tile/kernel/proc.c index 2e02c41..62d8208 100644 --- a/arch/tile/kernel/proc.c +++ b/arch/tile/kernel/proc.c @@ -27,6 +27,7 @@ #include <asm/processor.h> #include <asm/sections.h> #include <asm/homecache.h> +#include <asm/hardwall.h> #include <arch/chip.h> @@ -88,3 +89,75 @@ const struct seq_operations cpuinfo_op = { .stop = c_stop, .show = show_cpuinfo, }; + +/* + * Support /proc/tile directory + */ + +static int __init proc_tile_init(void) +{ + struct proc_dir_entry *root = proc_mkdir("tile", NULL); + if (root == NULL) + return 0; + + proc_tile_hardwall_init(root); + + return 0; +} + +arch_initcall(proc_tile_init); + +/* + * Support /proc/sys/tile directory + */ + +#ifndef __tilegx__ /* FIXME: GX: no support for unaligned access yet */ +static ctl_table unaligned_subtable[] = { + { + .procname = "enabled", + .data = &unaligned_fixup, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec + }, + { + .procname = "printk", + .data = &unaligned_printk, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec + }, + { + .procname = "count", + .data = &unaligned_fixup_count, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec + }, + {} +}; + +static ctl_table unaligned_table[] = { + { + .procname = "unaligned_fixup", + .mode = 0555, + .child = unaligned_subtable + }, + {} +}; +#endif + +static struct ctl_path tile_path[] = { + { .procname = "tile" }, + { } +}; + +static int __init proc_sys_tile_init(void) +{ +#ifndef __tilegx__ /* FIXME: GX: no support for unaligned access yet */ + register_sysctl_paths(tile_path, unaligned_table); +#endif + return 0; +} + +arch_initcall(proc_sys_tile_init); diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c new file mode 100644 index 0000000..b671a86 --- /dev/null +++ b/arch/tile/kernel/sysfs.c @@ -0,0 +1,185 @@ +/* + * Copyright 2011 Tilera Corporation. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or + * NON INFRINGEMENT. See the GNU General Public License for + * more details. + * + * /sys entry support. + */ + +#include <linux/sysdev.h> +#include <linux/cpu.h> +#include <linux/slab.h> +#include <linux/smp.h> +#include <hv/hypervisor.h> + +/* Return a string queried from the hypervisor, truncated to page size. */ +static ssize_t get_hv_confstr(char *page, int query) +{ + ssize_t n = hv_confstr(query, (unsigned long)page, PAGE_SIZE - 1); + n = n < 0 ? 0 : min(n, (ssize_t)PAGE_SIZE - 1) - 1; + if (n) + page[n++] = '\n'; + page[n] = '\0'; + return n; +} + +static ssize_t chip_width_show(struct sysdev_class *dev, + struct sysdev_class_attribute *attr, + char *page) +{ + return sprintf(page, "%u\n", smp_width); +} +static SYSDEV_CLASS_ATTR(chip_width, 0444, chip_width_show, NULL); + +static ssize_t chip_height_show(struct sysdev_class *dev, + struct sysdev_class_attribute *attr, + char *page) +{ + return sprintf(page, "%u\n", smp_height); +} +static SYSDEV_CLASS_ATTR(chip_height, 0444, chip_height_show, NULL); + +static ssize_t chip_serial_show(struct sysdev_class *dev, + struct sysdev_class_attribute *attr, + char *page) +{ + return get_hv_confstr(page, HV_CONFSTR_CHIP_SERIAL_NUM); +} +static SYSDEV_CLASS_ATTR(chip_serial, 0444, chip_serial_show, NULL); + +static ssize_t chip_revision_show(struct sysdev_class *dev, + struct sysdev_class_attribute *attr, + char *page) +{ + return get_hv_confstr(page, HV_CONFSTR_CHIP_REV); +} +static SYSDEV_CLASS_ATTR(chip_revision, 0444, chip_revision_show, NULL); + + +static ssize_t type_show(struct sysdev_class *dev, + struct sysdev_class_attribute *attr, + char *page) +{ + return sprintf(page, "tilera\n"); +} +static SYSDEV_CLASS_ATTR(type, 0444, type_show, NULL); + +#define HV_CONF_ATTR(name, conf) \ + static ssize_t name ## _show(struct sysdev_class *dev, \ + struct sysdev_class_attribute *attr, \ + char *page) \ + { \ + return get_hv_confstr(page, conf); \ + } \ + static SYSDEV_CLASS_ATTR(name, 0444, name ## _show, NULL); + +HV_CONF_ATTR(version, HV_CONFSTR_HV_SW_VER) +HV_CONF_ATTR(config_version, HV_CONFSTR_HV_CONFIG_VER) + +HV_CONF_ATTR(board_part, HV_CONFSTR_BOARD_PART_NUM) +HV_CONF_ATTR(board_serial, HV_CONFSTR_BOARD_SERIAL_NUM) +HV_CONF_ATTR(board_revision, HV_CONFSTR_BOARD_REV) +HV_CONF_ATTR(board_description, HV_CONFSTR_BOARD_DESC) +HV_CONF_ATTR(mezz_part, HV_CONFSTR_MEZZ_PART_NUM) +HV_CONF_ATTR(mezz_serial, HV_CONFSTR_MEZZ_SERIAL_NUM) +HV_CONF_ATTR(mezz_revision, HV_CONFSTR_MEZZ_REV) +HV_CONF_ATTR(mezz_description, HV_CONFSTR_MEZZ_DESC) +HV_CONF_ATTR(switch_control, HV_CONFSTR_SWITCH_CONTROL) + +static struct attribute *board_attrs[] = { + &attr_board_part.attr, + &attr_board_serial.attr, + &attr_board_revision.attr, + &attr_board_description.attr, + &attr_mezz_part.attr, + &attr_mezz_serial.attr, + &attr_mezz_revision.attr, + &attr_mezz_description.attr, + &attr_switch_control.attr, + NULL +}; + +static struct attribute_group board_attr_group = { + .name = "board", + .attrs = board_attrs, +}; + + +static struct bin_attribute hvconfig_bin; + +static ssize_t +hvconfig_bin_read(struct file *filp, struct kobject *kobj, + struct bin_attribute *bin_attr, + char *buf, loff_t off, size_t count) +{ + static size_t size; + + /* Lazily learn the true size (minus the trailing NUL). */ + if (size == 0) + size = hv_confstr(HV_CONFSTR_HV_CONFIG, 0, 0) - 1; + + /* Check and adjust input parameters. */ + if (off > size) + return -EINVAL; + if (count > size - off) + count = size - off; + + if (count) { + /* Get a copy of the hvc and copy out the relevant portion. */ + char *hvc; + + size = off + count; + hvc = kmalloc(size, GFP_KERNEL); + if (hvc == NULL) + return -ENOMEM; + hv_confstr(HV_CONFSTR_HV_CONFIG, (unsigned long)hvc, size); + memcpy(buf, hvc + off, count); + kfree(hvc); + } + + return count; +} + +static int __init create_sysfs_entries(void) +{ + struct sysdev_class *cls = &cpu_sysdev_class; + int err = 0; + +#define create_cpu_attr(name) \ + if (!err) \ + err = sysfs_create_file(&cls->kset.kobj, &attr_##name.attr); + create_cpu_attr(chip_width); + create_cpu_attr(chip_height); + create_cpu_attr(chip_serial); + create_cpu_attr(chip_revision); + +#define create_hv_attr(name) \ + if (!err) \ + err = sysfs_create_file(hypervisor_kobj, &attr_##name.attr); + create_hv_attr(type); + create_hv_attr(version); + create_hv_attr(config_version); + + if (!err) + err = sysfs_create_group(hypervisor_kobj, &board_attr_group); + + if (!err) { + sysfs_bin_attr_init(&hvconfig_bin); + hvconfig_bin.attr.name = "hvconfig"; + hvconfig_bin.attr.mode = S_IRUGO; + hvconfig_bin.read = hvconfig_bin_read; + hvconfig_bin.size = PAGE_SIZE; + err = sysfs_create_bin_file(hypervisor_kobj, &hvconfig_bin); + } + + return err; +} +subsys_initcall(create_sysfs_entries); diff --git a/fs/proc/base.c b/fs/proc/base.c index dfa5327..3ad615f 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -83,6 +83,9 @@ #include <linux/pid_namespace.h> #include <linux/fs_struct.h> #include <linux/slab.h> +#ifdef CONFIG_HARDWALL +#include <asm/hardwall.h> +#endif #include "internal.h" /* NOTE: @@ -2894,6 +2897,9 @@ static const struct pid_entry tgid_base_stuff[] = { #ifdef CONFIG_TASK_IO_ACCOUNTING INF("io", S_IRUGO, proc_tgid_io_accounting), #endif +#ifdef CONFIG_HARDWALL + INF("hardwall", S_IRUGO, proc_pid_hardwall), +#endif }; static int proc_tgid_base_readdir(struct file * filp, @@ -3232,6 +3238,9 @@ static const struct pid_entry tid_base_stuff[] = { #ifdef CONFIG_TASK_IO_ACCOUNTING INF("io", S_IRUGO, proc_tid_io_accounting), #endif +#ifdef CONFIG_HARDWALL + INF("hardwall", S_IRUGO, proc_pid_hardwall), +#endif }; static int proc_tid_base_readdir(struct file * filp, -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-05-27 14:23 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <201105181807.p4II7C5g015224@farm-0002.internal.tilera.com>
[not found] ` <201105191541.11939.arnd@arndb.de>
[not found] ` <4DD5334D.4060800@tilera.com>
2011-05-19 15:22 ` [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute Arnd Bergmann
[not found] ` <201105191722.17685.arnd@arndb.de>
2011-05-20 14:26 ` Chris Metcalf
[not found] ` <4DD67A31.90802@tilera.com>
2011-05-20 14:37 ` Arnd Bergmann
[not found] ` <201105201637.20925.arnd@arndb.de>
2011-05-20 15:00 ` Chris Metcalf
[not found] ` <4DD6821F.6060707@tilera.com>
2011-05-20 15:13 ` Arnd Bergmann
[not found] ` <201105201713.25364.arnd@arndb.de>
2011-05-20 19:59 ` Arnd Bergmann
[not found] ` <201105202159.50780.arnd@arndb.de>
2011-05-25 19:09 ` Chris Metcalf
2011-05-25 19:17 ` Chris Metcalf
2011-05-25 19:18 ` Chris Metcalf
[not found] ` <4DDD55ED.2080607@tilera.com>
2011-05-25 20:20 ` Arnd Bergmann
[not found] ` <201105252220.23948.arnd@arndb.de>
2011-05-25 20:31 ` Chris Metcalf
[not found] ` <4DDD6729.7070201@tilera.com>
2011-05-25 20:34 ` Arnd Bergmann
[not found] ` <201105261648.p4QGmNKf001636@farm-0023.internal.tilera.com>
2011-05-27 14:23 ` [PATCH v2] arch/tile: more /proc and /sys file support Arnd Bergmann
2011-05-24 15:38 ` [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute Arnd Bergmann
2011-05-26 16:40 ` [PATCH v2] arch/tile: more /proc and /sys file support Chris Metcalf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox