dect
/
linux-2.6
Archived
13
0
Fork 0
This repository has been archived on 2022-02-17. You can view files and clone it, but cannot push or open issues or pull requests.
linux-2.6/arch/tile/include/asm/hardwall.h

62 lines
1.9 KiB
C
Raw Normal View History

arch/tile: Add driver to enable access to the user dynamic network. This network (the "UDN") connects all the cpus on the chip in a wormhole-routed dynamic network. Subrectangles of the chip can be allocated by a "create" ioctl on /dev/hardwall, and then to access the UDN in that rectangle, tasks must perform an "activate" ioctl on that same file object after affinitizing themselves to a single cpu in the region. Sending a wormhole-routed message that tries to leave that subrectangle causes all activated tasks to receive a SIGILL (just as they would if they tried to access the UDN without first activating themselves to a hardwall rectangle). The original submission of this code to LKML had the driver instantiated under /proc/tile/hardwall. Now we just use a character device for this, conventionally /dev/hardwall. Some futures planning for the TILE-Gx chip suggests that we may want to have other types of devices that share the general model of "bind a task to a cpu, then 'activate' a file descriptor on a pseudo-device that gives access to some hardware resource". As such, we are using a device rather than, for example, a syscall, to set up and activate this code. As part of this change, the compat_ptr() declaration was fixed and used to pass the compat_ioctl argument to the normal ioctl. So far we limit compat code to 2GB, so the difference between zero-extend and sign-extend (the latter being correct, eventually) had been overlooked. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-25 21:00:56 +00:00
/*
* Copyright 2010 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.
*
* Provide methods for access control of per-cpu resources like
* UDN, IDN, or IPI.
arch/tile: Add driver to enable access to the user dynamic network. This network (the "UDN") connects all the cpus on the chip in a wormhole-routed dynamic network. Subrectangles of the chip can be allocated by a "create" ioctl on /dev/hardwall, and then to access the UDN in that rectangle, tasks must perform an "activate" ioctl on that same file object after affinitizing themselves to a single cpu in the region. Sending a wormhole-routed message that tries to leave that subrectangle causes all activated tasks to receive a SIGILL (just as they would if they tried to access the UDN without first activating themselves to a hardwall rectangle). The original submission of this code to LKML had the driver instantiated under /proc/tile/hardwall. Now we just use a character device for this, conventionally /dev/hardwall. Some futures planning for the TILE-Gx chip suggests that we may want to have other types of devices that share the general model of "bind a task to a cpu, then 'activate' a file descriptor on a pseudo-device that gives access to some hardware resource". As such, we are using a device rather than, for example, a syscall, to set up and activate this code. As part of this change, the compat_ptr() declaration was fixed and used to pass the compat_ioctl argument to the normal ioctl. So far we limit compat code to 2GB, so the difference between zero-extend and sign-extend (the latter being correct, eventually) had been overlooked. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-25 21:00:56 +00:00
*/
#ifndef _ASM_TILE_HARDWALL_H
#define _ASM_TILE_HARDWALL_H
#include <arch/chip.h>
arch/tile: Add driver to enable access to the user dynamic network. This network (the "UDN") connects all the cpus on the chip in a wormhole-routed dynamic network. Subrectangles of the chip can be allocated by a "create" ioctl on /dev/hardwall, and then to access the UDN in that rectangle, tasks must perform an "activate" ioctl on that same file object after affinitizing themselves to a single cpu in the region. Sending a wormhole-routed message that tries to leave that subrectangle causes all activated tasks to receive a SIGILL (just as they would if they tried to access the UDN without first activating themselves to a hardwall rectangle). The original submission of this code to LKML had the driver instantiated under /proc/tile/hardwall. Now we just use a character device for this, conventionally /dev/hardwall. Some futures planning for the TILE-Gx chip suggests that we may want to have other types of devices that share the general model of "bind a task to a cpu, then 'activate' a file descriptor on a pseudo-device that gives access to some hardware resource". As such, we are using a device rather than, for example, a syscall, to set up and activate this code. As part of this change, the compat_ptr() declaration was fixed and used to pass the compat_ioctl argument to the normal ioctl. So far we limit compat code to 2GB, so the difference between zero-extend and sign-extend (the latter being correct, eventually) had been overlooked. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-25 21:00:56 +00:00
#include <linux/ioctl.h>
#define HARDWALL_IOCTL_BASE 0xa2
/*
* The HARDWALL_CREATE() ioctl is a macro with a "size" argument.
* The resulting ioctl value is passed to the kernel in conjunction
* with a pointer to a standard kernel bitmask of cpus.
* For network resources (UDN or IDN) the bitmask must physically
* represent a rectangular configuration on the chip.
arch/tile: Add driver to enable access to the user dynamic network. This network (the "UDN") connects all the cpus on the chip in a wormhole-routed dynamic network. Subrectangles of the chip can be allocated by a "create" ioctl on /dev/hardwall, and then to access the UDN in that rectangle, tasks must perform an "activate" ioctl on that same file object after affinitizing themselves to a single cpu in the region. Sending a wormhole-routed message that tries to leave that subrectangle causes all activated tasks to receive a SIGILL (just as they would if they tried to access the UDN without first activating themselves to a hardwall rectangle). The original submission of this code to LKML had the driver instantiated under /proc/tile/hardwall. Now we just use a character device for this, conventionally /dev/hardwall. Some futures planning for the TILE-Gx chip suggests that we may want to have other types of devices that share the general model of "bind a task to a cpu, then 'activate' a file descriptor on a pseudo-device that gives access to some hardware resource". As such, we are using a device rather than, for example, a syscall, to set up and activate this code. As part of this change, the compat_ptr() declaration was fixed and used to pass the compat_ioctl argument to the normal ioctl. So far we limit compat code to 2GB, so the difference between zero-extend and sign-extend (the latter being correct, eventually) had been overlooked. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-25 21:00:56 +00:00
* The "size" is the number of bytes of cpu mask data.
*/
#define _HARDWALL_CREATE 1
#define HARDWALL_CREATE(size) \
_IOC(_IOC_READ, HARDWALL_IOCTL_BASE, _HARDWALL_CREATE, (size))
#define _HARDWALL_ACTIVATE 2
#define HARDWALL_ACTIVATE \
_IO(HARDWALL_IOCTL_BASE, _HARDWALL_ACTIVATE)
#define _HARDWALL_DEACTIVATE 3
#define HARDWALL_DEACTIVATE \
_IO(HARDWALL_IOCTL_BASE, _HARDWALL_DEACTIVATE)
arch/tile: more /proc and /sys file support 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 Bergmann 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. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-05-26 16:40:09 +00:00
#define _HARDWALL_GET_ID 4
#define HARDWALL_GET_ID \
_IO(HARDWALL_IOCTL_BASE, _HARDWALL_GET_ID)
#ifdef __KERNEL__
arch/tile: more /proc and /sys file support 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 Bergmann 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. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-05-26 16:40:09 +00:00
/* /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
arch/tile: Add driver to enable access to the user dynamic network. This network (the "UDN") connects all the cpus on the chip in a wormhole-routed dynamic network. Subrectangles of the chip can be allocated by a "create" ioctl on /dev/hardwall, and then to access the UDN in that rectangle, tasks must perform an "activate" ioctl on that same file object after affinitizing themselves to a single cpu in the region. Sending a wormhole-routed message that tries to leave that subrectangle causes all activated tasks to receive a SIGILL (just as they would if they tried to access the UDN without first activating themselves to a hardwall rectangle). The original submission of this code to LKML had the driver instantiated under /proc/tile/hardwall. Now we just use a character device for this, conventionally /dev/hardwall. Some futures planning for the TILE-Gx chip suggests that we may want to have other types of devices that share the general model of "bind a task to a cpu, then 'activate' a file descriptor on a pseudo-device that gives access to some hardware resource". As such, we are using a device rather than, for example, a syscall, to set up and activate this code. As part of this change, the compat_ptr() declaration was fixed and used to pass the compat_ioctl argument to the normal ioctl. So far we limit compat code to 2GB, so the difference between zero-extend and sign-extend (the latter being correct, eventually) had been overlooked. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-25 21:00:56 +00:00
#endif
#endif /* _ASM_TILE_HARDWALL_H */