Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller
On 05/03/2016 19:20, Parav Pandit wrote: >> > 3 is fine but resource [un]charging is not hot path? > charge/uncharge is hot path from cgroup perspective. Most of the resources the RDMA cgroup handles are only allocated at the beginning of the application. The RDMA subsystem allows direct user-space access to the devices, so most of the hot path operations don't go through the kernel at all. It is true though that for some applications MR registration and de-registration is in the hot path. Haggai -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/10] watchdog: Add support for keepalives triggered by infrastructure
Hi Guenter, > The watchdog infrastructure is currently purely passive, meaning > it only passes information from user space to drivers and vice versa. > > Since watchdog hardware tends to have its own quirks, this can result > in quite complex watchdog drivers. A number of scanarios are especially > common. > > - A watchdog is always active and can not be disabled, or can not be disabled > once enabled. To support such hardware, watchdog drivers have to implement > their own timers and use those timers to trigger watchdog keepalives while > the watchdog device is not or not yet opened. > - A variant of this is the desire to enable a watchdog as soon as its driver > has been instantiated, to protect the system while it is still booting up, > but the watchdog daemon is not yet running. > - Some watchdogs have a very short maximum timeout, in the range of just a few > seconds. Such low timeouts are difficult if not impossible to support from > user space. Drivers supporting such watchdog hardware need to implement > a timer function to augment heartbeats from user space. > > This patch set solves the above problems while keeping changes to the > watchdog core minimal. > > - A new status flag, WDOG_HW_RUNNING, informs the watchdog subsystem that > a watchdog is running, and that the watchdog subsystem needs to generate > heartbeat requests while the associated watchdog device is closed. > - A new parameter in the watchdog data structure, max_hw_heartbeat_ms, informs > the watchdog subsystem about a maximum hardware heartbeat. The watchdog > subsystem uses this information together with the configured timeout > and the maximum permitted timeout to determine if it needs to generate > additional heartbeat requests. > > As part of this patchset, the semantics of the 'timeout' variable and of > the WDOG_ACTIVE flag are changed slightly. > > Per the current watchdog kernel API, the 'timeout' variable is supposed > to reflect the actual hardware watchdog timeout. WDOG_ACTIVE is supposed > to reflect if the hardware watchdog is running or not. > > Unfortunately, this does not always reflect reality. In drivers which solve > the above mentioned problems internally, 'timeout' is the watchdog timeout > as seen from user space, and WDOG_ACTIVE reflects that user space is expected > to send keepalive requests to the watchdog driver. > > After this patch set is applied, this so far inofficial interpretation > is the 'official' semantics for the timeout variable and the WDOG_ACTIVE > flag. In other words, both values no longer reflect the hardware watchdog > status, but its status as seen from user space. > > Patch #1 makes the set_timeout function optional. > > Patch #2 adds timer functionality to the watchdog core. It solves the problem > of short maximum hardware heartbeats by augmenting heartbeats triggered from > user space with internally triggered heartbeats. > > Patch #3 adds functionality to generate heartbeats while the watchdog device > is closed. It handles situation where where the watchdog is running after > the driver has been instantiated, but the device is not yet opened, > and post-close situations necessary if a watchdog can not be stopped. > > Patch #4 makes the stop function optional. > > Patch #5 adds code to ensure that the minimum time between heartbeats meets > constraints provided by the watchdog driver. > > Patch #6 to #10 are example conversions of some watchdog drivers. > Out of those, patches #6 (dw_wdt) and #7 (imx2) have been tested. > Patches #8 to #10 will require testing and are marked as RFT. > > The patch series is also available in branch watchdog-timer of > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git. > The series is curently based on top of v4.5-rc5. > > The patch series was inspired by an earlier patch set from Timo Kokonnen. > > v8: > - max_hw_timeout_ms -> max_hw_heartbeat_ms > - Rebased to v4.5-rc5 > - The patch to make the set_timeout function optional is now the first > patch of the series. > - Separate code making the stop function optional into a separate patch. > - Dropped all Acked-by: and Tested-by: tags. Even though there are no > functional changes, I concluded that the changes are too substantial > to warrant maintaining previously provided tags. > Note: while the patch series was rearranged, correctness was ensured > by implementing the max_hw_timeout_ms -> max_hw_heartbeat_ms changes > separately on top of the original series and comparing the results. > v7: > - Rebased to v4.5-rc1. > - Moved new variables to local data structure > - Fixed typos in documentation (hw_max_timeout_ms -> max_hw_timeout_ms). > - Enforce that max_hw_timeout_ms must be set if the stop function is > not implemented by a driver. > - Set max_hw_timeout_ms in converted drivers. > v6: > - Added patch #9, converting the dw_wdt driver. > - Set last_keepalive more accurately when starting the watchdog. > - Rebased
[PATCH v4] tty: serial: meson: Implement earlycon support
Split off the bulk of the existing meson_serial_console_write()
implementation into meson_serial_port_write() for implementing
meson_serial_early_console_write().
Use "meson" as the earlycon driver name, courtesy of Nicolas.
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Carlo Caione
Signed-off-by: Andreas Färber
---
v3 -> v4:
* Select SERIAL_EARLYCON (Arnd)
v2 -> v3:
* Rename from "meson_serial" to just "meson" (Nicolas)
v1 -> v2:
* Implement meson_serial_early_console_write() instead of reusing
meson_serial_console_write() (Peter)
Documentation/kernel-parameters.txt | 6 ++
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/meson_uart.c | 42 ++---
3 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index e0a21e4556a6..a7c1377fd80f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1039,6 +1039,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
the driver will use only 32-bit accessors to read/write
the device registers.
+ meson,
+ Start an early, polled-mode console on a meson serial
+ port at the specified address. The serial port must
+ already be setup and configured. Options are not yet
+ supported.
+
msm_serial,
Start an early, polled-mode console on an msm serial
port at the specified address. The serial port
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index bdbe1c533c6a..ad7538e8a4e8 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -213,6 +213,7 @@ config SERIAL_MESON_CONSOLE
bool "Support for console on meson"
depends on SERIAL_MESON=y
select SERIAL_CORE_CONSOLE
+ select SERIAL_EARLYCON
help
Say Y here if you wish to use a Amlogic MesonX UART as the
system console (the system console is the device which
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index 024445aa0521..6aea0f4a9165 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -481,18 +481,13 @@ static void meson_console_putchar(struct uart_port *port,
int ch)
writel(ch, port->membase + AML_UART_WFIFO);
}
-static void meson_serial_console_write(struct console *co, const char *s,
- u_int count)
+static void meson_serial_port_write(struct uart_port *port, const char *s,
+ u_int count)
{
- struct uart_port *port;
unsigned long flags;
int locked;
u32 val, tmp;
- port = meson_ports[co->index];
- if (!port)
- return;
-
local_irq_save(flags);
if (port->sysrq) {
locked = 0;
@@ -516,6 +511,18 @@ static void meson_serial_console_write(struct console *co,
const char *s,
local_irq_restore(flags);
}
+static void meson_serial_console_write(struct console *co, const char *s,
+ u_int count)
+{
+ struct uart_port *port;
+
+ port = meson_ports[co->index];
+ if (!port)
+ return;
+
+ meson_serial_port_write(port, s, count);
+}
+
static int meson_serial_console_setup(struct console *co, char *options)
{
struct uart_port *port;
@@ -554,6 +561,27 @@ static int __init meson_serial_console_init(void)
}
console_initcall(meson_serial_console_init);
+static void meson_serial_early_console_write(struct console *co,
+const char *s,
+u_int count)
+{
+ struct earlycon_device *dev = co->data;
+
+ meson_serial_port_write(&dev->port, s, count);
+}
+
+static int __init
+meson_serial_early_console_setup(struct earlycon_device *device, const char
*opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->con->write = meson_serial_early_console_write;
+ return 0;
+}
+OF_EARLYCON_DECLARE(meson, "amlogic,meson-uart",
+ meson_serial_early_console_setup);
+
#define MESON_SERIAL_CONSOLE (&meson_serial_console)
#else
#define MESON_SERIAL_CONSOLE NULL
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver
On 03/03/2016 04:38 PM, Ramesh Shanmugasundaram wrote:
> Changes since v1:
> * Removed testmodes & debugfs code (suggested by Oliver H)
> * Fixed tx path race issue by introducing lock (suggested by Marc K)
> * Removed __maybe_unused attribute of rcar_canfd_of_table
>
> obj-$(CONFIG_CAN_M_CAN) += m_can/
> obj-$(CONFIG_CAN_RCAR) += rcar_can.o
> +obj-$(CONFIG_CANFD_RCAR) += rcar_canfd.o
Just for the sake of an ordered directory structure:
Would it make sense to create a rcar directory where rcar_can.c and
rcar_canfd.c are placed?
Additionally (besides of one accident with the obsolete PCH_CAN) all CAN
drivers start with CONFIG_CAN_...
Following that scheme the config option should be named
CONFIG_CAN_RCAR_CANFD
as we had in CONFIG_CAN_IFI_CANFD.
> obj-$(CONFIG_CAN_SJA1000)+= sja1000/
> obj-$(CONFIG_CAN_SUN4I) += sun4i_can.o
> obj-$(CONFIG_CAN_TI_HECC)+= ti_hecc.o
> diff --git a/drivers/net/can/rcar_canfd.c b/drivers/net/can/rcar_canfd.c
(..)
> +/* Channel priv data */
> +struct rcar_canfd_channel {
> + struct can_priv can;/* Must be the first member */
> + struct net_device *ndev;
> + struct rcar_canfd_global *gpriv;/* Controller reference */
> + void __iomem *base; /* Register base address */
> +#ifdef CONFIG_DEBUG_FS
> + struct dentry *dev_root;
> +#endif /* CONFIG_DEBUG_FS */
Some missed stuff from debugfs removal?
> + struct napi_struct napi;
> + u8 tx_len[RCANFD_FIFO_DEPTH]; /* For net stats */
> + u32 tx_head;/* Incremented on xmit */
> + u32 tx_tail;/* Incremented on xmit done */
> + u32 channel;/* Channel number */
> + spinlock_t tx_lock; /* To protect tx path */
> +};
(..)
> +static int rcar_canfd_start(struct net_device *ndev)
> +{
> + struct rcar_canfd_channel *priv = netdev_priv(ndev);
> + int err = -EOPNOTSUPP;
> + u32 sts, ch = priv->channel;
> + u32 ridx = ch + RCANFD_RFFIFO_IDX;
> +
> + /* Ensure channel starts in FD mode */
> + if (!(priv->can.ctrlmode & CAN_CTRLMODE_FD)) {
> + netdev_err(ndev, "enable can fd mode for channel %d\n", ch);
> + goto fail_mode;
> + }
What's the reason behind this check?
A CAN FD capable CAN controller can be either configured to run as CAN 2.0
(Classic CAN) or as CAN FD controller.
So why are to throwing an error here and produce an initialization failure?
Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel docs: muddying the waters a bit
On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
>
> I converted one of the big tables to CSV. At least now it recognized
> it as a table. Yet, the table was very badly formated:
>
> https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
>
> This is how this table should look like:
> https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
>
> Also, as this table has merged cells at the legend. I've no idea how
> to tell sphinx to do that on csv format.
>
> The RST files are on this git tree:
> https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/
Yeah, seems it can't do merged cells in csv. Attached patch converts it
back to grid table format and fixes the table definition.
The html output looks usable, but clearly it is no fun to
work with tables in Sphinx.
Sphinx' latex writer can't handle nested tables, though.
Python's docutils rst2latex can, but that doesn't help here.
rst2pdf also supports it. But I have doubts such a large
table would render OK in pdf without using landscape orientation.
I have not tried because I used python3-sphinx but rst2pdf
is only availble for Python2 in Debian so it does not integrate
with Sphinx.
Johannes
>From 61674b398e778bd5ff644ffd493d5ff1cfaca0ef Mon Sep 17 00:00:00 2001
From: Johannes Stezenbach
Date: Sun, 6 Mar 2016 23:55:19 +0100
Subject: [PATCH] some progress for html output
---
_static/borderless.css | 3 --
_static/v4l2tables.css | 9 +
_templates/layout.html | 9 +
packed-rgb.rst | 88 +-
pixfmt-yuyv.rst| 2 +-
v4l-table-within-table.rst | 72 +++--
6 files changed, 105 insertions(+), 78 deletions(-)
delete mode 100644 _static/borderless.css
create mode 100644 _static/v4l2tables.css
diff --git a/_static/borderless.css b/_static/borderless.css
deleted file mode 100644
index bfd4b01..000
--- a/_static/borderless.css
+++ /dev/null
@@ -1,3 +0,0 @@
-table#table-borderless {
-border: 1px solid black;
-}
diff --git a/_static/v4l2tables.css b/_static/v4l2tables.css
new file mode 100644
index 000..c045e45
--- /dev/null
+++ b/_static/v4l2tables.css
@@ -0,0 +1,9 @@
+table.noborder {
+border: 1px solid black;
+background: white;
+white-space: nowrap;
+}
+
+table.noborder td, table.noborder th {
+padding: 0px;
+}
diff --git a/_templates/layout.html b/_templates/layout.html
index b6bf12b..637332d 100644
--- a/_templates/layout.html
+++ b/_templates/layout.html
@@ -1,9 +1,2 @@
{% extends "!layout.html" %}
-{% block tables %}
-
-table#table-borderless {
-border: 1px solid black;
-}
-
-{{ super() }}
-{% endblock %}
+{% set css_files = css_files + ["_static/v4l2tables.css"] %}
diff --git a/packed-rgb.rst b/packed-rgb.rst
index 352b91c..b4fcf3e 100644
--- a/packed-rgb.rst
+++ b/packed-rgb.rst
@@ -9,25 +9,46 @@ graphics frame buffers. They occupy 8, 16, 24 or 32 bits per pixel.
These are all packed-pixel formats, meaning all the data for a pixel lie
next to each other in memory.
-.. csv-table:: Table: Packed RGB Image Formats
- :header: Identifier,Code, ,Byte 0 in memory,Byte 1,Byte 2,Byte 3
+.. table:: Packed RGB Image Formats
+ :class: noborder
- ``V4L2_PIX_FMT_RGB332``,'RGB1',,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`1`,b\ :sub:`0`
- ``V4L2_PIX_FMT_ARGB444``,'AR12',,g\ :sub:`3`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,a\ :sub:`3`,a\ :sub:`2`,a\ :sub:`1`,a\ :sub:`0`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`
- ``V4L2_PIX_FMT_XRGB444``,'XR12',,g\ :sub:`3`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,-,-,-,-,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`
- ``V4L2_PIX_FMT_ARGB555``,'AR15',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,a,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`
- ``V4L2_PIX_FMT_XRGB555``,'XR15',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,-,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`
- ``V4L2_PIX_FMT_RGB565``,'RGBP',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`5`,g\ :sub:`4`,g\ :sub:`3`
- ``V4L2_PIX_FMT_ARGB555X``,'AR15' | (1<<31),,a,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`,,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`
- ``V4L2_PIX_FMT_XRGB555X``,'XR15' | (1<<31),,-,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`,,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`
- ``V4L2_PIX_FMT_RGB565X``,'RGBR',,r\ :sub:`4`,r\
[PATCH] modsign: Fix documentation on module signing enforcement parameter.
>From 033be2a07878841081a30408aecce3a6b6c8f677 Mon Sep 17 00:00:00 2001 From: James Johnston Date: Sun, 6 Mar 2016 19:54:38 -0500 Subject: [PATCH] modsign: Fix documentation on module signing enforcement parameter. Modify the documentation to match the actual parameter as implemented in kernel/module.c:273. Signed-off-by: James Johnston --- Documentation/module-signing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt index a78bf1f..696d5ca 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -254,7 +254,7 @@ signature checking is all done within the kernel. NON-VALID SIGNATURES AND UNSIGNED MODULES = -If CONFIG_MODULE_SIG_FORCE is enabled or enforcemodulesig=1 is supplied on +If CONFIG_MODULE_SIG_FORCE is enabled or module.sig_enforce=1 is supplied on the kernel command line, the kernel will only load validly signed modules for which it has a public key. Otherwise, it will also load modules that are unsigned. Any module for which the kernel has a key, but which proves to have -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: Howto: Fixed subtitles style
Fixed subtitles style, aligned them with their header. Signed-off-by: Philippe Loctaux --- Documentation/HOWTO | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/HOWTO b/Documentation/HOWTO index d5a699d..109ec84 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -68,7 +68,7 @@ For common questions and answers about the GPL, please see: Documentation - +- The Linux kernel source tree has a large range of documents that are invaluable for learning how to interact with the kernel community. When @@ -263,7 +263,7 @@ mailing list about kernel releases: preconceived timeline." 4.x.y -stable kernel tree +- Kernels with 3-part versions are -stable kernels. They contain relatively small and critical fixes for security problems or significant regressions discovered in a given 4.x kernel. @@ -286,7 +286,7 @@ documents what kinds of changes are acceptable for the -stable tree, and how the release process works. 4.x -git patches --- + These are daily snapshots of Linus' kernel tree which are managed in a git repository (hence the name.) These patches are usually released daily and represent the current state of Linus' tree. They are more @@ -318,7 +318,7 @@ accepted, or rejected. Most of these patchwork sites are listed at http://patchwork.kernel.org/. 4.x -next kernel tree for integration tests -- +--- Before updates from subsystem trees are merged into the mainline 4.x tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are -- 2.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/10] watchdog: Add support for keepalives triggered by infrastructure
Hi Wim, any chance to get this series into the next release ? Thanks, Guenter On 02/28/2016 01:12 PM, Guenter Roeck wrote: The watchdog infrastructure is currently purely passive, meaning it only passes information from user space to drivers and vice versa. Since watchdog hardware tends to have its own quirks, this can result in quite complex watchdog drivers. A number of scanarios are especially common. - A watchdog is always active and can not be disabled, or can not be disabled once enabled. To support such hardware, watchdog drivers have to implement their own timers and use those timers to trigger watchdog keepalives while the watchdog device is not or not yet opened. - A variant of this is the desire to enable a watchdog as soon as its driver has been instantiated, to protect the system while it is still booting up, but the watchdog daemon is not yet running. - Some watchdogs have a very short maximum timeout, in the range of just a few seconds. Such low timeouts are difficult if not impossible to support from user space. Drivers supporting such watchdog hardware need to implement a timer function to augment heartbeats from user space. This patch set solves the above problems while keeping changes to the watchdog core minimal. - A new status flag, WDOG_HW_RUNNING, informs the watchdog subsystem that a watchdog is running, and that the watchdog subsystem needs to generate heartbeat requests while the associated watchdog device is closed. - A new parameter in the watchdog data structure, max_hw_heartbeat_ms, informs the watchdog subsystem about a maximum hardware heartbeat. The watchdog subsystem uses this information together with the configured timeout and the maximum permitted timeout to determine if it needs to generate additional heartbeat requests. As part of this patchset, the semantics of the 'timeout' variable and of the WDOG_ACTIVE flag are changed slightly. Per the current watchdog kernel API, the 'timeout' variable is supposed to reflect the actual hardware watchdog timeout. WDOG_ACTIVE is supposed to reflect if the hardware watchdog is running or not. Unfortunately, this does not always reflect reality. In drivers which solve the above mentioned problems internally, 'timeout' is the watchdog timeout as seen from user space, and WDOG_ACTIVE reflects that user space is expected to send keepalive requests to the watchdog driver. After this patch set is applied, this so far inofficial interpretation is the 'official' semantics for the timeout variable and the WDOG_ACTIVE flag. In other words, both values no longer reflect the hardware watchdog status, but its status as seen from user space. Patch #1 makes the set_timeout function optional. Patch #2 adds timer functionality to the watchdog core. It solves the problem of short maximum hardware heartbeats by augmenting heartbeats triggered from user space with internally triggered heartbeats. Patch #3 adds functionality to generate heartbeats while the watchdog device is closed. It handles situation where where the watchdog is running after the driver has been instantiated, but the device is not yet opened, and post-close situations necessary if a watchdog can not be stopped. Patch #4 makes the stop function optional. Patch #5 adds code to ensure that the minimum time between heartbeats meets constraints provided by the watchdog driver. Patch #6 to #10 are example conversions of some watchdog drivers. Out of those, patches #6 (dw_wdt) and #7 (imx2) have been tested. Patches #8 to #10 will require testing and are marked as RFT. The patch series is also available in branch watchdog-timer of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git. The series is curently based on top of v4.5-rc5. The patch series was inspired by an earlier patch set from Timo Kokonnen. v8: - max_hw_timeout_ms -> max_hw_heartbeat_ms - Rebased to v4.5-rc5 - The patch to make the set_timeout function optional is now the first patch of the series. - Separate code making the stop function optional into a separate patch. - Dropped all Acked-by: and Tested-by: tags. Even though there are no functional changes, I concluded that the changes are too substantial to warrant maintaining previously provided tags. Note: while the patch series was rearranged, correctness was ensured by implementing the max_hw_timeout_ms -> max_hw_heartbeat_ms changes separately on top of the original series and comparing the results. v7: - Rebased to v4.5-rc1. - Moved new variables to local data structure - Fixed typos in documentation (hw_max_timeout_ms -> max_hw_timeout_ms). - Enforce that max_hw_timeout_ms must be set if the stop function is not implemented by a driver. - Set max_hw_timeout_ms in converted drivers. v6: - Added patch #9, converting the dw_wdt driver. - Set last_keepalive more accurately when starting the watchdog. - Rebased to v4.4-rc2. - Renamed WDOG_RUNNING to WDOG_HW_RUNNING and
Re: Kernel docs: muddying the waters a bit
On Thu, 03 Mar 2016 16:03:14 +0200 Jani Nikula wrote: > This stalled a bit, but the waters are still muddy... So I've been messing with this a bit; wanted to do a proper patch posting but I'm fried and mostly out of time for the moment. The results I'm getting now can be seen at: http://static.lwn.net/kerneldoc/ I've pulled in a few templates (including gpu.tmpl), converted them, and built them into some reasonable-looking HTML, modulo a fair number of glitches. There's lots of details to deal with, but the broad shape of it is there. If you look, you'll see that things like cross-file cross-references, a feature we've never had before, work nicely. I can also get good EPUB and PDF output - except that rst2pdf is currently crashing on me, which is a little discouraging. Man page output will take more work. What I have so far can be pulled from: git://git.lwn.net/linux.git doc/sphinx It's still based on using docproc because that was easiest (for me). The kernel-doc part is Jani's asciidoc stuff, hacked up and made uglier. I'm not sure that any of it is worth more than a demonstration of what can be done; I'm not particularly proud of (or tied to) any of it. But it's a start. I've not looked at the table situation at all; soon. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
I know that in Germany a good amount of land-line telephone line are still using ISDN. Some telco company try to move people to IP only, but this is currently still a process. Especially company line are using ISDN still, and there are some Linux programs that act on then, e.g. Asterisk and derived PBX software has ISDN support which is actively used. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 2/7] PCI: Use IORESOURCE_WINDOW to identify bridge resources
Now we use the IORESOURCE_STARTALIGN to identify bridge
resources in __assign_resources_sorted(). But there would
be some problems because some PCI devices' resources may
also use IORESOURCE_STARTALIGN, e.g. using "noresize"
option of resource_alignment kernel parameter.
So this patch replaces IORESOURCE_STARTALIGN with
IORESOURCE_WINDOW.
Signed-off-by: Yongji Xie
---
drivers/pci/setup-bus.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..4ff10ca 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -411,11 +411,11 @@ static void __assign_resources_sorted(struct list_head
*head,
/*
* There are two kinds of additional resources in the list:
-* 1. bridge resource -- IORESOURCE_STARTALIGN
-* 2. SR-IOV resource -- IORESOURCE_SIZEALIGN
+* 1. bridge resource -- IORESOURCE_WINDOW
+* 2. SR-IOV resource
* Here just fix the additional alignment for bridge
*/
- if (!(dev_res->res->flags & IORESOURCE_STARTALIGN))
+ if (!(dev_res->res->flags & IORESOURCE_WINDOW))
continue;
add_align = get_res_add_align(realloc_head, dev_res->res);
@@ -956,7 +956,7 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
b_res->start = min_align;
b_res->end = b_res->start + size0 - 1;
- b_res->flags |= IORESOURCE_STARTALIGN;
+ b_res->flags |= IORESOURCE_STARTALIGN | IORESOURCE_WINDOW;
if (size1 > size0 && realloc_head) {
add_to_list(realloc_head, bus->self, b_res, size1-size0,
min_align);
@@ -1104,7 +1104,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
}
b_res->start = min_align;
b_res->end = size0 + min_align - 1;
- b_res->flags |= IORESOURCE_STARTALIGN;
+ b_res->flags |= IORESOURCE_STARTALIGN | IORESOURCE_WINDOW;
if (size1 > size0 && realloc_head) {
add_to_list(realloc_head, bus->self, b_res, size1-size0,
add_align);
dev_printk(KERN_DEBUG, &bus->self->dev, "bridge window %pR to
%pR add_size %llx add_align %llx\n",
@@ -1140,7 +1140,8 @@ static void pci_bus_size_cardbus(struct pci_bus *bus,
*/
b_res[0].start = pci_cardbus_io_size;
b_res[0].end = b_res[0].start + pci_cardbus_io_size - 1;
- b_res[0].flags |= IORESOURCE_IO | IORESOURCE_STARTALIGN;
+ b_res[0].flags |= IORESOURCE_IO | IORESOURCE_STARTALIGN |
+ IORESOURCE_WINDOW;
if (realloc_head) {
b_res[0].end -= pci_cardbus_io_size;
add_to_list(realloc_head, bridge, b_res, pci_cardbus_io_size,
@@ -1152,7 +1153,8 @@ handle_b_res_1:
goto handle_b_res_2;
b_res[1].start = pci_cardbus_io_size;
b_res[1].end = b_res[1].start + pci_cardbus_io_size - 1;
- b_res[1].flags |= IORESOURCE_IO | IORESOURCE_STARTALIGN;
+ b_res[1].flags |= IORESOURCE_IO | IORESOURCE_STARTALIGN |
+ IORESOURCE_WINDOW;
if (realloc_head) {
b_res[1].end -= pci_cardbus_io_size;
add_to_list(realloc_head, bridge, b_res+1, pci_cardbus_io_size,
@@ -1190,7 +1192,7 @@ handle_b_res_2:
b_res[2].start = pci_cardbus_mem_size;
b_res[2].end = b_res[2].start + pci_cardbus_mem_size - 1;
b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH |
- IORESOURCE_STARTALIGN;
+ IORESOURCE_STARTALIGN | IORESOURCE_WINDOW;
if (realloc_head) {
b_res[2].end -= pci_cardbus_mem_size;
add_to_list(realloc_head, bridge, b_res+2,
@@ -1206,7 +1208,8 @@ handle_b_res_3:
goto handle_done;
b_res[3].start = pci_cardbus_mem_size;
b_res[3].end = b_res[3].start + b_res_3_size - 1;
- b_res[3].flags |= IORESOURCE_MEM | IORESOURCE_STARTALIGN;
+ b_res[3].flags |= IORESOURCE_MEM | IORESOURCE_STARTALIGN |
+ IORESOURCE_WINDOW;
if (realloc_head) {
b_res[3].end -= b_res_3_size;
add_to_list(realloc_head, bridge, b_res+3, b_res_3_size,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 0/7] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table
Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because sub-page BARs' mmio page may be shared with other BARs and MSI-X table should not be accessed directly from the guest for security reasons. But these will easily cause some performance issues for mmio accesses in guest when vfio passthrough sub-page BARs or BARs containing MSI-X table on PPC64 platform. This is because PAGE_SIZE is 64KB by default on PPC64 platform and the big page may easily hit the sub-page MMIO BARs' unmmapping and cause the unmmaping of the mmio page which MSI-X table locate in, which lead to mmio emulation in host. For sub-page MMIO BARs' unmmapping, this patchset modifies resource_alignment kernel parameter to enforce the alignment of all MMIO BARs to be at least PAGE_SZIE so that sub-page BAR's mmio page will not be shared with other BARs. Then we can mmap sub-page MMIO BARs in vfio-pci driver with the modified resource_alignment. For MSI-X table's unmmapping, we think MSI-X table is safe to access directly from userspace if PCI host bridge support filtering of MSIs which can ensure that a given pci device can only shoot the MSIs assigned for it. So we allow to mmap MSI-X table if IOMMU_CAP_INTR_REMAP was set. And we add IOMMU_CAP_INTR_REMAP for IODA host bridge on PPC64 platform. With this patchset applied, we can get almost 100% improvement on performance for mmio accesses when we passthrough sub-page BARs to guest in our test. The two vfio related patches(patch 5 and patch 6) are based on the proposed patchset[1]. Changelog v4: - Rebase on v4.5-rc6 with patchset[1] applied. - Remove resource_page_aligned kernel parameter - Fix some problems with resource_alignment kernel parameter - Modify resource_alignment kernel parameter to support multiple devices. - Remove host bridge attribute: msi_filtered - Use IOMMU_CAP_INTR_REMAP to check if MSI-X table can be mmapped - Add IOMMU_CAP_INTR_REMAP for IODA host bridge on PPC64 platform Changelog v3: - Rebase on new linux kernel mainline with the patchset[1] applied. - Add a function to check whether PCI BARs'mmio page is shared with other BARs. - Add a host bridge attribute to indicate PCI host bridge support filtering of MSIs. - Use the new host bridge attribute to check if MSI-X table can be mmapped instead of CONFIG_EEH. - Remove Kconfig option VFIO_PCI_MMAP_MSIX Changelog v2: - Rebase on v4.4-rc6 with the patchset[1] applied. - Use kernel parameter to enforce all MMIO BARs to be page aligned on PCI core code instead of doing it on PPC64 arch code. - Remove flags: VFIO_DEVICE_FLAGS_PCI_PAGE_ALIGNED VFIO_DEVICE_FLAGS_PCI_MSIX_MMAP - Add a Kconfig option to support for mmapping MSI-X table. [1] http://www.spinics.net/lists/kvm/msg127812.html Yongji Xie (7): PCI: Add a new option for resource_alignment to reassign alignment PCI: Use IORESOURCE_WINDOW to identify bridge resources PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set PCI: Modify resource_alignment to support multiple devices vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive vfio-pci: Allow to mmap MSI-X table if IOMMU_CAP_INTR_REMAP was set powerpc/powernv/pci-ioda: Add IOMMU_CAP_INTR_REMAP for IODA host bridge Documentation/kernel-parameters.txt |9 ++- arch/powerpc/platforms/powernv/pci-ioda.c | 17 drivers/pci/pci.c | 126 - drivers/pci/probe.c |3 +- drivers/pci/setup-bus.c | 21 ++--- drivers/vfio/pci/vfio_pci.c | 15 +++- drivers/vfio/pci/vfio_pci_rdwr.c |4 +- include/linux/pci.h |4 + 8 files changed, 162 insertions(+), 37 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 6/7] vfio-pci: Allow to mmap MSI-X table if IOMMU_CAP_INTR_REMAP was set
Current vfio-pci implementation disallows to mmap MSI-X
table in case that user get to touch this directly.
But we should allow to mmap these MSI-X tables if IOMMU
supports interrupt remapping which can ensure that a
given pci device can only shoot the MSIs assigned for it.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |8 +---
drivers/vfio/pci/vfio_pci_rdwr.c |4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 49d7a69..d6f4788 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -592,13 +592,14 @@ static long vfio_pci_ioctl(void *device_data,
IORESOURCE_MEM && !pci_resources_share_page(pdev,
info.index)) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
- if (info.index == vdev->msix_bar) {
+ if (!iommu_capable(pdev->dev.bus,
+ IOMMU_CAP_INTR_REMAP) &&
+ info.index == vdev->msix_bar) {
ret = msix_sparse_mmap_cap(vdev, &caps);
if (ret)
return ret;
}
}
-
break;
case VFIO_PCI_ROM_REGION_INDEX:
{
@@ -1029,7 +1030,8 @@ static int vfio_pci_mmap(void *device_data, struct
vm_area_struct *vma)
if (phys_len < PAGE_SIZE || req_start + req_len > phys_len)
return -EINVAL;
- if (index == vdev->msix_bar) {
+ if (!iommu_capable(pdev->dev.bus, IOMMU_CAP_INTR_REMAP) &&
+ index == vdev->msix_bar) {
/*
* Disallow mmaps overlapping the MSI-X table; users don't
* get to touch this directly. We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9..1c46c29 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "vfio_pci_private.h"
@@ -164,7 +165,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char
__user *buf,
} else
io = vdev->barmap[bar];
- if (bar == vdev->msix_bar) {
+ if (!iommu_capable(pdev->dev.bus, IOMMU_CAP_INTR_REMAP) &&
+ bar == vdev->msix_bar) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 7/7] powerpc/powernv/pci-ioda: Add IOMMU_CAP_INTR_REMAP for IODA host bridge
This patch adds IOMMU_CAP_INTR_REMAP for IODA host bridge so that
we can mmap MSI-X table in vfio driver.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f90dc04..f01b9ab 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1955,6 +1955,20 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
.free = pnv_ioda2_table_free,
};
+static bool pnv_ioda_iommu_capable(enum iommu_cap cap)
+{
+ switch (cap) {
+ case IOMMU_CAP_INTR_REMAP:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static struct iommu_ops pnv_ioda_iommu_ops = {
+ .capable = pnv_ioda_iommu_capable,
+};
+
static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe, unsigned int base,
unsigned int segs)
@@ -3078,6 +3092,9 @@ static void pnv_pci_ioda_fixup(void)
/* Link NPU IODA tables to their PCI devices. */
pnv_npu_ioda_fixup();
+
+ /* Add IOMMU_CAP_INTR_REMAP */
+ bus_set_iommu(&pci_bus_type, &pnv_ioda_iommu_ops);
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set
The resource_alignment will releases memory resources allocated by firmware so that kernel can reassign new resources later on. But this will cause the problem that no resources can be allocated by kernel if PCI_PROBE_ONLY was set, e.g. on pSeries platform because PCI_PROBE_ONLY force kernel to use firmware setup and not to reassign any resources. To solve this problem, this patch ignores resource_alignment if PCI_PROBE_ONLY was set. Signed-off-by: Yongji Xie --- Documentation/kernel-parameters.txt |2 ++ drivers/pci/probe.c |3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d8b29ab..8028631 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2922,6 +2922,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. windows need to be expanded. noresize: Don't change the resources' sizes when reassigning alignment. + Note that this option will not work if + PCI_PROBE_ONLY is set. ecrc= Enable/disable PCIe ECRC (transaction layer end-to-end CRC checking). bios: Use BIOS/firmware settings. This is the diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 6d7ab9b..bc31cad 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1719,7 +1719,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus) pci_fixup_device(pci_fixup_header, dev); /* moved out from quirk header fixup code */ - pci_reassigndev_resource_alignment(dev); + if (!pci_has_flag(PCI_PROBE_ONLY)) + pci_reassigndev_resource_alignment(dev); /* Clear the state_saved flag. */ dev->state_saved = false; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 1/7] PCI: Add a new option for resource_alignment to reassign alignment
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers.
So this patch adds a new option "noresize" for the parameter
to solve this problem.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 -
drivers/pci/pci.c | 36 +--
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9a53c92..d8b29ab 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2912,13 +2912,16 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
window. The default value is 64 megabytes.
resource_alignment=
Format:
- [@][:]:.[; ...]
+ [@][:]:.
+ [:noresize][; ...]
Specifies alignment and device to reassign
aligned memory resources.
If is not specified,
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+ noresize: Don't change the resources' sizes when
+ reassigning alignment.
ecrc= Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 602eb42..760cce5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4598,7 +4598,8 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
* RETURNS: Resource alignment if it is specified.
* Zero if it is not specified.
*/
-static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
+static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
+ bool *resize)
{
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
@@ -4626,6 +4627,11 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev)
}
}
p += count;
+ if (!strncmp(p, ":noresize", 9)) {
+ *resize = false;
+ p += 9;
+ } else
+ *resize = true;
if (seg == pci_domain_nr(dev->bus) &&
bus == dev->bus->number &&
slot == PCI_SLOT(dev->devfn) &&
@@ -4658,11 +4664,12 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
{
int i;
struct resource *r;
+ bool resize;
resource_size_t align, size;
u16 command;
/* check if specified PCI is target device to reassign */
- align = pci_specified_resource_alignment(dev);
+ align = pci_specified_resource_alignment(dev, &resize);
if (!align)
return;
@@ -4684,15 +4691,24 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
if (!(r->flags & IORESOURCE_MEM))
continue;
size = resource_size(r);
- if (size < align) {
- size = align;
- dev_info(&dev->dev,
- "Rounding up size of resource #%d to %#llx.\n",
- i, (unsigned long long)size);
+ if (resize) {
+ if (size < align) {
+ size = align;
+ dev_info(&dev->dev,
+ "Rounding up size of resource #%d to
%#llx.\n",
+ i, (unsigned long long)size);
+ }
+ r->flags |= IORESOURCE_UNSET;
+ r->end = size - 1;
+ r->start = 0;
+ } else {
+ if (size > align)
+ align = size;
+ r->flags &= ~IORESOURCE_SIZEALIGN;
+ r->flags |= IORESOURCE_STARTALIGN | IORESOURCE_UNSET;
+ r->start = align;
+ r->end = r->start + size - 1;
}
- r->flags |= IORESOURCE_UNSET;
- r->end = size - 1;
- r->start = 0;
}
/* Need to disable bridge's resource window,
* to enable the kernel to reassign new resource
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message
[RFC PATCH v4 4/7] PCI: Modify resource_alignment to support multiple devices
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not handle the
mmio accesses to the BARs which leads to mmio emulations
in host.
This is because vfio will not allow to passthrough one
BAR's mmio page which may be shared with other BARs.
To solve this performance issue, this patch modifies
resource_alignment to support syntax where multiple
devices get the same alignment. So we can use something
like "pci=resource_alignment=*:*:*.*:noresize" to
enforce the alignment of all MMIO BARs to be at least
PAGE_SIZE so that one BAR's mmio page would not be
shared with other BARs.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |2 +
drivers/pci/pci.c | 90 ++-
include/linux/pci.h |4 ++
3 files changed, 85 insertions(+), 11 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 8028631..74b38ab 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2918,6 +2918,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
aligned memory resources.
If is not specified,
PAGE_SIZE is used as alignment.
+ , , and can be set to
+ "*" which means match all values.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
noresize: Don't change the resources' sizes when
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 760cce5..44ab59f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -102,6 +102,8 @@ unsigned int pcibios_max_latency = 255;
/* If set, the PCIe ARI capability will not be used. */
static bool pcie_ari_disabled;
+bool pci_resources_page_aligned;
+
/**
* pci_bus_max_busnr - returns maximum PCI bus number of given bus' children
* @bus: pointer to PCI bus structure to search
@@ -4604,6 +4606,7 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
int seg, bus, slot, func, align_order, count;
resource_size_t align = 0;
char *p;
+ bool invalid = false;
spin_lock(&resource_alignment_lock);
p = resource_alignment_param;
@@ -4615,16 +4618,49 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
} else {
align_order = -1;
}
- if (sscanf(p, "%x:%x:%x.%x%n",
- &seg, &bus, &slot, &func, &count) != 4) {
+ if (p[0] == '*' && p[1] == ':') {
+ seg = -1;
+ count = 1;
+ } else if (sscanf(p, "%x%n", &seg, &count) != 1 ||
+ p[count] != ':') {
+ invalid = true;
+ break;
+ }
+ p += count + 1;
+ if (*p == '*') {
+ bus = -1;
+ count = 1;
+ } else if (sscanf(p, "%x%n", &bus, &count) != 1) {
+ invalid = true;
+ break;
+ }
+ p += count;
+ if (*p == '.') {
+ slot = bus;
+ bus = seg;
seg = 0;
- if (sscanf(p, "%x:%x.%x%n",
- &bus, &slot, &func, &count) != 3) {
- /* Invalid format */
- printk(KERN_ERR "PCI: Can't parse
resource_alignment parameter: %s\n",
- p);
+ p++;
+ } else if (*p == ':') {
+ p++;
+ if (p[0] == '*' && p[1] == '.') {
+ slot = -1;
+ count = 1;
+ } else if (sscanf(p, "%x%n", &slot, &count) != 1 ||
+ p[count] != '.') {
+ invalid = true;
break;
}
+ p += count + 1;
+ } else {
+ invalid = true;
+ break;
+ }
+ if (*p == '*') {
+ func = -1;
+ count = 1;
+ } else if (sscanf(p, "%x%n", &func, &count) != 1) {
+ invalid = true;
+ break;
}
p += count;
if (!strncmp(p, ":noresize", 9)) {
@@ -4632,23 +4668,34 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
p += 9;
[RFC PATCH v4 5/7] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs.
But we should allow to mmap these sub-page MMIO BARs if PCI
resource allocator can make sure these BARs' mmio page will
not be shared with other BARs.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1ce1d36..49d7a69 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -589,7 +589,8 @@ static long vfio_pci_ioctl(void *device_data,
VFIO_REGION_INFO_FLAG_WRITE;
if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) &&
pci_resource_flags(pdev, info.index) &
- IORESOURCE_MEM && info.size >= PAGE_SIZE) {
+ IORESOURCE_MEM && !pci_resources_share_page(pdev,
+ info.index)) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
if (info.index == vdev->msix_bar) {
ret = msix_sparse_mmap_cap(vdev, &caps);
@@ -1016,6 +1017,10 @@ static int vfio_pci_mmap(void *device_data, struct
vm_area_struct *vma)
return -EINVAL;
phys_len = pci_resource_len(pdev, index);
+
+ if (!pci_resources_share_page(pdev, index))
+ phys_len = PAGE_ALIGN(phys_len);
+
req_len = vma->vm_end - vma->vm_start;
pgoff = vma->vm_pgoff &
((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
