* Re: [PATCH 4/6] dt-bindings: display: simple: Add NewEast Optoelectronics WJFH116008A compatible
From: Laurent Pinchart @ 2020-02-20 13:54 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, Linus Walleij,
dri-devel, Andrzej Hajda, Thierry Reding, Sam Ravnborg,
Stephen Rothwell, Samuel Holland, Heiko Stuebner, Chen-Yu Tsai,
Icenowy Zheng, Stephan Gerhold, Jonas Karlman, Torsten Duwe,
Rob Herring, Maxime Ripard, linux-arm-kernel, Jernej Skrabec,
linux-kernel, Mark Brown, Daniel Vetter
In-Reply-To: <20200220083508.792071-5-anarsoul@gmail.com>
On Thu, Feb 20, 2020 at 12:35:06AM -0800, Vasily Khoruzhick wrote:
> This commit adds compatible for NewEast Optoelectronics WJFH116008A panel
> to panel-simple binding
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 8fe60ee2531c..721de94cc80a 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -43,6 +43,8 @@ properties:
> - satoz,sat050at40h12r2
> # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
> - sharp,ls020b1dd01d
> + # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
> + - neweast,wjfh116008a
Please keep the entries alphabetically sorted. With this fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> backlight: true
> enable-gpios: true
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: display: simple: Add NewEast Optoelectronics WJFH116008A compatible
From: Laurent Pinchart @ 2020-02-20 13:54 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Thierry Reding, Sam Ravnborg, David Airlie, Daniel Vetter,
Rob Herring, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Icenowy Zheng, Torsten Duwe, Heiko Stuebner, Linus Walleij,
Stephan Gerhold, Mark Brown, Stephen Rothwell, Samuel Holland,
dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20200220083508.792071-5-anarsoul@gmail.com>
On Thu, Feb 20, 2020 at 12:35:06AM -0800, Vasily Khoruzhick wrote:
> This commit adds compatible for NewEast Optoelectronics WJFH116008A panel
> to panel-simple binding
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 8fe60ee2531c..721de94cc80a 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -43,6 +43,8 @@ properties:
> - satoz,sat050at40h12r2
> # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
> - sharp,ls020b1dd01d
> + # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
> + - neweast,wjfh116008a
Please keep the entries alphabetically sorted. With this fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> backlight: true
> enable-gpios: true
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: display: simple: Add NewEast Optoelectronics WJFH116008A compatible
From: Laurent Pinchart @ 2020-02-20 13:54 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, dri-devel,
Andrzej Hajda, Thierry Reding, Sam Ravnborg, Stephen Rothwell,
Samuel Holland, Heiko Stuebner, Chen-Yu Tsai, Icenowy Zheng,
Stephan Gerhold, Jonas Karlman, Torsten Duwe, Rob Herring,
Maxime Ripard, linux-arm-kernel, Jernej Skrabec, linux-kernel,
Mark Brown
In-Reply-To: <20200220083508.792071-5-anarsoul@gmail.com>
On Thu, Feb 20, 2020 at 12:35:06AM -0800, Vasily Khoruzhick wrote:
> This commit adds compatible for NewEast Optoelectronics WJFH116008A panel
> to panel-simple binding
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 8fe60ee2531c..721de94cc80a 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -43,6 +43,8 @@ properties:
> - satoz,sat050at40h12r2
> # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
> - sharp,ls020b1dd01d
> + # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
> + - neweast,wjfh116008a
Please keep the entries alphabetically sorted. With this fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> backlight: true
> enable-gpios: true
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [dpdk-dev] [PATCH v3 2/2] net/mlx5: fix lack of match information in meter
From: Suanming Mou @ 2020-02-20 13:53 UTC (permalink / raw)
To: matan, viacheslavo; +Cc: dev, rasland, stable
In-Reply-To: <1582206824-103222-1-git-send-email-suanmingm@mellanox.com>
As meter flows are split into three subflows each, the prefix subflow
with meter action color the packet, the meter subflow filters out the
colored packets, the suffix subflow applies all the remaining actions
to the passed packets.
Currently, all the user defined items are matched in the prefix flow.
Flow id tag match item is the only item added to the meter suffix
subflow. Some of the remaining actions to be applied in the suffix
subflow require more information in the match item, or the suffix
subflow will not be created successfully.
Actions require the L3/L4 type in the match items as below:
RTE_FLOW_ACTION_TYPE_SET_TP_SRC
RTE_FLOW_ACTION_TYPE_SET_TP_DST
RTE_FLOW_ACTION_TYPE_DEC_TTL
RTE_FLOW_ACTION_TYPE_SET_TTL
RTE_FLOW_ACTION_TYPE_RSS
RTE_FLOW_ACTION_TYPE_QUEUE
Inherit the match item flags from meter prefix subflow to make actions
in suffix subflow get sufficient information.
Fixes: 9ea9b049a960 ("net/mlx5: split meter flow")
Cc: stable@dpdk.org
Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
---
drivers/net/mlx5/mlx5_flow.c | 11 ++++++---
drivers/net/mlx5/mlx5_flow_dv.c | 53 ++++++++++++++++++++++++++++++-----------
2 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 9267858..da60ce7 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -3778,6 +3778,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
* Pointer to Ethernet device.
* @param[in] flow
* Parent flow structure pointer.
+ * @param[in] prefix_layers
+ * Prefix flow layer flags.
* @param[in] attr
* Flow rule attributes.
* @param[in] items
@@ -3794,6 +3796,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
static int
flow_create_split_metadata(struct rte_eth_dev *dev,
struct rte_flow *flow,
+ uint64_t prefix_layers,
const struct rte_flow_attr *attr,
const struct rte_flow_item items[],
const struct rte_flow_action actions[],
@@ -3814,7 +3817,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
if (!config->dv_flow_en ||
config->dv_xmeta_en == MLX5_XMETA_MODE_LEGACY ||
!mlx5_flow_ext_mreg_supported(dev))
- return flow_create_split_inner(dev, flow, NULL, 0,
+ return flow_create_split_inner(dev, flow, NULL, prefix_layers,
attr, items, actions, external,
error);
actions_n = flow_parse_qrss_action(actions, &qrss);
@@ -3897,7 +3900,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
goto exit;
}
/* Add the unmodified original or prefix subflow. */
- ret = flow_create_split_inner(dev, flow, &dev_flow, 0, attr,
+ ret = flow_create_split_inner(dev, flow, &dev_flow, prefix_layers, attr,
items, ext_actions ? ext_actions :
actions, external, error);
if (ret < 0)
@@ -4092,7 +4095,9 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
MLX5_FLOW_TABLE_LEVEL_SUFFIX;
}
/* Add the prefix subflow. */
- ret = flow_create_split_metadata(dev, flow, &sfx_attr,
+ ret = flow_create_split_metadata(dev, flow, dev_flow ?
+ flow_get_prefix_layer_flags(dev_flow) :
+ 0, &sfx_attr,
sfx_items ? sfx_items : items,
sfx_actions ? sfx_actions : actions,
external, error);
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 19f5b61..ebd7a93 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -85,16 +85,35 @@
* Pointer to item specification.
* @param[out] attr
* Pointer to flow attributes structure.
+ * @param[in] dev_flow
+ * Pointer to the sub flow.
* @param[in] tunnel_decap
* Whether action is after tunnel decapsulation.
*/
static void
flow_dv_attr_init(const struct rte_flow_item *item, union flow_dv_attr *attr,
- bool tunnel_decap)
+ struct mlx5_flow *dev_flow, bool tunnel_decap)
{
+ /*
+ * If layers is already initialized, it means this dev_flow is the
+ * suffix flow, the layers flags is set by the prefix flow. Need to
+ * use the layer flags from prefix flow as the suffix flow may not
+ * have the user defined items as the flow is split.
+ */
+ if (dev_flow->layers) {
+ if (dev_flow->layers & MLX5_FLOW_LAYER_OUTER_L3_IPV4)
+ attr->ipv4 = 1;
+ else if (dev_flow->layers & MLX5_FLOW_LAYER_OUTER_L3_IPV6)
+ attr->ipv6 = 1;
+ if (dev_flow->layers & MLX5_FLOW_LAYER_OUTER_L4_TCP)
+ attr->tcp = 1;
+ else if (dev_flow->layers & MLX5_FLOW_LAYER_OUTER_L4_UDP)
+ attr->udp = 1;
+ attr->valid = 1;
+ return;
+ }
for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
uint8_t next_protocol = 0xff;
-
switch (item->type) {
case RTE_FLOW_ITEM_TYPE_GRE:
case RTE_FLOW_ITEM_TYPE_NVGRE:
@@ -640,6 +659,8 @@ struct field_modify_info modify_tcp[] = {
* Pointer to rte_flow_item objects list.
* @param[in] attr
* Pointer to flow attributes structure.
+ * @param[in] dev_flow
+ * Pointer to the sub flow.
* @param[in] tunnel_decap
* Whether action is after tunnel decapsulation.
* @param[out] error
@@ -653,8 +674,8 @@ struct field_modify_info modify_tcp[] = {
(struct mlx5_flow_dv_modify_hdr_resource *resource,
const struct rte_flow_action *action,
const struct rte_flow_item *items,
- union flow_dv_attr *attr, bool tunnel_decap,
- struct rte_flow_error *error)
+ union flow_dv_attr *attr, struct mlx5_flow *dev_flow,
+ bool tunnel_decap, struct rte_flow_error *error)
{
const struct rte_flow_action_set_tp *conf =
(const struct rte_flow_action_set_tp *)(action->conf);
@@ -666,7 +687,7 @@ struct field_modify_info modify_tcp[] = {
struct field_modify_info *field;
if (!attr->valid)
- flow_dv_attr_init(items, attr, tunnel_decap);
+ flow_dv_attr_init(items, attr, dev_flow, tunnel_decap);
if (attr->udp) {
memset(&udp, 0, sizeof(udp));
memset(&udp_mask, 0, sizeof(udp_mask));
@@ -716,6 +737,8 @@ struct field_modify_info modify_tcp[] = {
* Pointer to rte_flow_item objects list.
* @param[in] attr
* Pointer to flow attributes structure.
+ * @param[in] dev_flow
+ * Pointer to the sub flow.
* @param[in] tunnel_decap
* Whether action is after tunnel decapsulation.
* @param[out] error
@@ -729,8 +752,8 @@ struct field_modify_info modify_tcp[] = {
(struct mlx5_flow_dv_modify_hdr_resource *resource,
const struct rte_flow_action *action,
const struct rte_flow_item *items,
- union flow_dv_attr *attr, bool tunnel_decap,
- struct rte_flow_error *error)
+ union flow_dv_attr *attr, struct mlx5_flow *dev_flow,
+ bool tunnel_decap, struct rte_flow_error *error)
{
const struct rte_flow_action_set_ttl *conf =
(const struct rte_flow_action_set_ttl *)(action->conf);
@@ -742,7 +765,7 @@ struct field_modify_info modify_tcp[] = {
struct field_modify_info *field;
if (!attr->valid)
- flow_dv_attr_init(items, attr, tunnel_decap);
+ flow_dv_attr_init(items, attr, dev_flow, tunnel_decap);
if (attr->ipv4) {
memset(&ipv4, 0, sizeof(ipv4));
memset(&ipv4_mask, 0, sizeof(ipv4_mask));
@@ -778,6 +801,8 @@ struct field_modify_info modify_tcp[] = {
* Pointer to rte_flow_item objects list.
* @param[in] attr
* Pointer to flow attributes structure.
+ * @param[in] dev_flow
+ * Pointer to the sub flow.
* @param[in] tunnel_decap
* Whether action is after tunnel decapsulation.
* @param[out] error
@@ -790,8 +815,8 @@ struct field_modify_info modify_tcp[] = {
flow_dv_convert_action_modify_dec_ttl
(struct mlx5_flow_dv_modify_hdr_resource *resource,
const struct rte_flow_item *items,
- union flow_dv_attr *attr, bool tunnel_decap,
- struct rte_flow_error *error)
+ union flow_dv_attr *attr, struct mlx5_flow *dev_flow,
+ bool tunnel_decap, struct rte_flow_error *error)
{
struct rte_flow_item item;
struct rte_flow_item_ipv4 ipv4;
@@ -801,7 +826,7 @@ struct field_modify_info modify_tcp[] = {
struct field_modify_info *field;
if (!attr->valid)
- flow_dv_attr_init(items, attr, tunnel_decap);
+ flow_dv_attr_init(items, attr, dev_flow, tunnel_decap);
if (attr->ipv4) {
memset(&ipv4, 0, sizeof(ipv4));
memset(&ipv4_mask, 0, sizeof(ipv4_mask));
@@ -7505,7 +7530,7 @@ struct field_modify_info modify_tcp[] = {
case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
if (flow_dv_convert_action_modify_tp
(mhdr_res, actions, items,
- &flow_attr, !!(action_flags &
+ &flow_attr, dev_flow, !!(action_flags &
MLX5_FLOW_ACTION_DECAP), error))
return -rte_errno;
action_flags |= actions->type ==
@@ -7515,7 +7540,7 @@ struct field_modify_info modify_tcp[] = {
break;
case RTE_FLOW_ACTION_TYPE_DEC_TTL:
if (flow_dv_convert_action_modify_dec_ttl
- (mhdr_res, items, &flow_attr,
+ (mhdr_res, items, &flow_attr, dev_flow,
!!(action_flags &
MLX5_FLOW_ACTION_DECAP), error))
return -rte_errno;
@@ -7524,7 +7549,7 @@ struct field_modify_info modify_tcp[] = {
case RTE_FLOW_ACTION_TYPE_SET_TTL:
if (flow_dv_convert_action_modify_ttl
(mhdr_res, actions, items, &flow_attr,
- !!(action_flags &
+ dev_flow, !!(action_flags &
MLX5_FLOW_ACTION_DECAP), error))
return -rte_errno;
action_flags |= MLX5_FLOW_ACTION_SET_TTL;
--
1.8.3.1
^ permalink raw reply related
* RE: RFC: Split EPT huge pages in advance of dirty logging
From: Zhoujian (jay) @ 2020-02-20 13:52 UTC (permalink / raw)
To: Peter Xu
Cc: Liujinsong (Paul), linfeng (M), kvm@vger.kernel.org,
quintela@redhat.com, wangxin (U), qemu-devel@nongnu.org,
dgilbert@redhat.com, bgardon@google.com, pbonzini@redhat.com,
Huangweidong (C)
In-Reply-To: <20200219171919.GA34517@xz-x1>
> -----Original Message-----
> From: Peter Xu [mailto:peterx@redhat.com]
> Sent: Thursday, February 20, 2020 1:19 AM
> To: Zhoujian (jay) <jianjay.zhou@huawei.com>
> Cc: kvm@vger.kernel.org; qemu-devel@nongnu.org; pbonzini@redhat.com;
> dgilbert@redhat.com; quintela@redhat.com; Liujinsong (Paul)
> <liu.jinsong@huawei.com>; linfeng (M) <linfeng23@huawei.com>; wangxin (U)
> <wangxinxin.wang@huawei.com>; Huangweidong (C)
> <weidong.huang@huawei.com>
> Subject: Re: RFC: Split EPT huge pages in advance of dirty logging
>
> On Wed, Feb 19, 2020 at 01:19:08PM +0000, Zhoujian (jay) wrote:
> > Hi Peter,
> >
> > > -----Original Message-----
> > > From: Peter Xu [mailto:peterx@redhat.com]
> > > Sent: Wednesday, February 19, 2020 1:43 AM
> > > To: Zhoujian (jay) <jianjay.zhou@huawei.com>
> > > Cc: kvm@vger.kernel.org; qemu-devel@nongnu.org;
> pbonzini@redhat.com;
> > > dgilbert@redhat.com; quintela@redhat.com; Liujinsong (Paul)
> > > <liu.jinsong@huawei.com>; linfeng (M) <linfeng23@huawei.com>;
> > > wangxin (U) <wangxinxin.wang@huawei.com>; Huangweidong (C)
> > > <weidong.huang@huawei.com>
> > > Subject: Re: RFC: Split EPT huge pages in advance of dirty logging
> > >
> > > On Tue, Feb 18, 2020 at 01:13:47PM +0000, Zhoujian (jay) wrote:
> > > > Hi all,
> > > >
> > > > We found that the guest will be soft-lockup occasionally when live
> > > > migrating a 60 vCPU, 512GiB huge page and memory sensitive VM. The
> > > > reason is clear, almost all of the vCPUs are waiting for the KVM
> > > > MMU spin-lock to create 4K SPTEs when the huge pages are write
> > > > protected. This
> > > phenomenon is also described in this patch set:
> > > > https://patchwork.kernel.org/cover/11163459/
> > > > which aims to handle page faults in parallel more efficiently.
> > > >
> > > > Our idea is to use the migration thread to touch all of the guest
> > > > memory in the granularity of 4K before enabling dirty logging. To
> > > > be more specific, we split all the PDPE_LEVEL SPTEs into
> > > > DIRECTORY_LEVEL SPTEs as the first step, and then split all the
> > > > DIRECTORY_LEVEL SPTEs into
> > > PAGE_TABLE_LEVEL SPTEs as the following step.
> > >
> > > IIUC, QEMU will prefer to use huge pages for all the anonymous
> > > ramblocks (please refer to ram_block_add):
> > >
> > > qemu_madvise(new_block->host, new_block->max_length,
> > > QEMU_MADV_HUGEPAGE);
> >
> > Yes, you're right
> >
> > >
> > > Another alternative I can think of is to add an extra parameter to
> > > QEMU to explicitly disable huge pages (so that can even be
> > > MADV_NOHUGEPAGE instead of MADV_HUGEPAGE). However that
> should also
> > > drag down the performance for the whole lifecycle of the VM.
> >
> > From the performance point of view, it is better to keep the huge
> > pages when the VM is not in the live migration state.
> >
> > > A 3rd option is to make a QMP
> > > command to dynamically turn huge pages on/off for ramblocks globally.
> >
> > We're searching a dynamic method too.
> > We plan to add two new flags for each memory slot, say
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES and
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES. These flags can be set through
> > KVM_SET_USER_MEMORY_REGION ioctl.
> >
> > The mapping_level which is called by tdp_page_fault in the kernel side
> > will return PT_DIRECTORY_LEVEL if the
> KVM_MEM_FORCE_PT_DIRECTORY_PAGES
> > flag of the memory slot is set, and return PT_PAGE_TABLE_LEVEL if the
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES flag is set.
> >
> > The key steps to split the huge pages in advance of enabling dirty log
> > is as follows:
> > 1. The migration thread in user space uses
> KVM_SET_USER_MEMORY_REGION
> > ioctl to set the KVM_MEM_FORCE_PT_DIRECTORY_PAGES flag for each
> memory
> > slot.
> > 2. The migration thread continues to use the KVM_SPLIT_HUGE_PAGES
> > ioctl (which is newly added) to do the splitting of large pages in the
> > kernel side.
> > 3. A new vCPU is created temporally(do some initialization but will
> > not
> > run) to help to do the work, i.e. as the parameter of the tdp_page_fault.
> > 4. Collect the GPA ranges of all the memory slots with the
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES flag set.
> > 5. Split the 1G huge pages(collected in step 4) into 2M by calling
> > tdp_page_fault, since the mapping_level will return
> > PT_DIRECTORY_LEVEL. Here is the main difference from the usual path
> > which is caused by the Guest side(EPT violation/misconfig etc), we
> > call it directly in the hypervisor side.
> > 6. Do some cleanups, i.e. free the vCPU related resources 7. The
> > KVM_SPLIT_HUGE_PAGES ioctl returned to the user space side.
> > 8. Using KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES instread of
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES to repeat step 1 ~ step 7, in step
> 5
> > the 2M huge pages will be splitted into 4K pages.
> > 9. Clear the KVM_MEM_FORCE_PT_DIRECTORY_PAGES and
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES flags for each memory slot.
> > 10. Then the migration thread calls the log_start ioctl to enable the
> > dirty logging, and the remaining thing is the same.
>
> I'm not sure... I think it would be good if there is a way to have finer granularity
> control on using huge pages for any process, then KVM can directly leverage
> that because KVM page tables should always respect the mm configurations on
> these (so e.g. when huge page split, KVM gets notifications via mmu notifiers).
> Have you thought of such a more general way?
I did have thought of this, if we split the huge pages into 4K of a process, I'm
afraid it will not be workable for the huge pages sharing scenario, e.g. DPDK,
SPDK etc. So, only split the EPT page table and keep the VM process page table
(e.g. qemu) untouched is the goal.
>
> (And I just noticed that MADV_NOHUGEPAGE is only a hint to khugepaged
> and probably won't split any huge page at all after madvise() returns..)
> To tell the truth I'm still confused on how split of huge pages helped in your
> case...
I'm sorry if the meaning is not expressed clearly, and thanks for your patience.
> If I read it right the test reduced some execution time from 9s to a
> few ms after your splittion of huge pages.
Yes
> The thing is I don't see how split of
> huge pages could solve the mmu_lock contention with the huge VM, because
> IMO even if we split the huge pages into smaller ones, those pages should still
> be write-protected and need merely the same number of page faults to resolve
> when accessed/written? And I thought that should only be fixed with
> solutions like what Ben has proposed with the MMU rework. Could you show
> me what I've missed?
Let me try to describe the reason of mmu_lock contention more clearly and the
effort we tried to do...
The huge VM only has EPT >= level 2 sptes, and level 1 sptes don't
exist at the beginning. Write protect all the huge pages will trigger EPT
violation to create level 1 sptes for all the vCPUs which want to write the
content of the memory. Different vCPU write the different areas of
the memory, but they need the same kvm->mmu_lock to create the level 1
sptes, this situation will be worse if the number of vCPU and the memory of
VM is large(in our case 60U512G), meanwhile the VM has
memory-write-intensive work to do. In order to reduce the mmu_lock
contention, we try to: write protect VM memory gradually in small chunks,
such as 1G or 2M. Using a vCPU temporary creately by migration thread to
split 1G to 2M as the first step, and to split 2M to 4K as the second step
(this is a little hacking...and I do not know any side effect will be triggered
indeed).
Comparing to write protect all VM memory in one go, the write
protected range is limited in this way and only the vCPUs write this limited
range will be involved to take the mmu_lock. The contention will be reduced
since the memory range is small and the number of vCPU involved is small
too.
Of course, it will take some extra time to split all the huge pages into 4K
page before the real migration started, about 60s for 512G in my experiment.
During the memory iterative copy phase, PML will do the dirty logging work
(not write protected case for 4K), or IIRC using fast_page_fault to mark page
dirty if PML is not supported, which case the mmu_lock does not needed.
Regards,
Jay Zhou
^ permalink raw reply
* Re: [PATCH] mm/slub: Detach node lock from counting free objects
From: Wen Yang @ 2020-02-20 13:53 UTC (permalink / raw)
To: Roman Gushchin
Cc: Andrew Morton, Christoph Lameter, Pekka Enberg, David Rientjes,
Joonsoo Kim, Xunlei Pang, linux-mm, linux-kernel
In-Reply-To: <20200218205312.GA3156@carbon>
On 2020/2/19 4:53 上午, Roman Gushchin wrote:
> On Sun, Feb 16, 2020 at 12:15:54PM +0800, Wen Yang wrote:
>>
>>
>> On 2020/2/13 6:52 上午, Andrew Morton wrote:
>>> On Sat, 1 Feb 2020 11:15:02 +0800 Wen Yang <wenyang@linux.alibaba.com> wrote:
>>>
>>>> The lock, protecting the node partial list, is taken when couting the free
>>>> objects resident in that list. It introduces locking contention when the
>>>> page(s) is moved between CPU and node partial lists in allocation path
>>>> on another CPU. So reading "/proc/slabinfo" can possibily block the slab
>>>> allocation on another CPU for a while, 200ms in extreme cases. If the
>>>> slab object is to carry network packet, targeting the far-end disk array,
>>>> it causes block IO jitter issue.
>>>>
>>>> This fixes the block IO jitter issue by caching the total inuse objects in
>>>> the node in advance. The value is retrieved without taking the node partial
>>>> list lock on reading "/proc/slabinfo".
>>>>
>>>> ...
>>>>
>>>> @@ -1768,7 +1774,9 @@ static void free_slab(struct kmem_cache *s, struct page *page)
>>>> static void discard_slab(struct kmem_cache *s, struct page *page)
>>>> {
>>>> - dec_slabs_node(s, page_to_nid(page), page->objects);
>>>> + int inuse = page->objects;
>>>> +
>>>> + dec_slabs_node(s, page_to_nid(page), page->objects, inuse);
>>>
>>> Is this right? dec_slabs_node(..., page->objects, page->objects)?
>>>
>>> If no, we could simply pass the page* to inc_slabs_node/dec_slabs_node
>>> and save a function argument.
>>>
>>> If yes then why?
>>>
>>
>> Thanks for your comments.
>> We are happy to improve this patch based on your suggestions.
>>
>>
>> When the user reads /proc/slabinfo, in order to obtain the active_objs
>> information, the kernel traverses all slabs and executes the following code
>> snippet:
>> static unsigned long count_partial(struct kmem_cache_node *n,
>> int (*get_count)(struct page *))
>> {
>> unsigned long flags;
>> unsigned long x = 0;
>> struct page *page;
>>
>> spin_lock_irqsave(&n->list_lock, flags);
>> list_for_each_entry(page, &n->partial, slab_list)
>> x += get_count(page);
>> spin_unlock_irqrestore(&n->list_lock, flags);
>> return x;
>> }
>>
>> It may cause performance issues.
>>
>> Christoph suggested "you could cache the value in the userspace application?
>> Why is this value read continually?", But reading the /proc/slabinfo is
>> initiated by the user program. As a cloud provider, we cannot control user
>> behavior. If a user program inadvertently executes cat /proc/slabinfo, it
>> may affect other user programs.
>>
>> As Christoph said: "The count is not needed for any operations. Just for the
>> slabinfo output. The value has no operational value for the allocator
>> itself. So why use extra logic to track it in potentially performance
>> critical paths?"
>>
>> In this way, could we show the approximate value of active_objs in the
>> /proc/slabinfo?
>>
>> Based on the following information:
>> In the discard_slab() function, page->inuse is equal to page->total_objects;
>> In the allocate_slab() function, page->inuse is also equal to
>> page->total_objects (with one exception: for kmem_cache_node, page-> inuse
>> equals 1);
>> page->inuse will only change continuously when the obj is constantly
>> allocated or released. (This should be the performance critical path
>> emphasized by Christoph)
>>
>> When users query the global slabinfo information, we may use total_objects
>> to approximate active_objs.
>
> Well, from one point of view, it makes no sense, because the ratio between
> these two numbers is very meaningful: it's the slab utilization rate.
>
> On the other side, with enabled per-cpu partial lists active_objs has
> nothing to do with the reality anyway, so I agree with you, calling
> count_partial() is almost useless.
>
> That said, I wonder if the right thing to do is something like the patch below?
>
> Thanks!
>
> Roman
>
> --
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 1d644143f93e..ba0505e75ecc 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2411,14 +2411,16 @@ static inline unsigned long node_nr_objs(struct kmem_cache_node *n)
> static unsigned long count_partial(struct kmem_cache_node *n,
> int (*get_count)(struct page *))
> {
> - unsigned long flags;
> unsigned long x = 0;
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> + unsigned long flags;
> struct page *page;
>
> spin_lock_irqsave(&n->list_lock, flags);
> list_for_each_entry(page, &n->partial, slab_list)
> x += get_count(page);
> spin_unlock_irqrestore(&n->list_lock, flags);
> +#endif
> return x;
> }
> #endif /* CONFIG_SLUB_DEBUG || CONFIG_SYSFS */
>
Hi Roman,
Thanks for your comments.
In the server scenario, SLUB_CPU_PARTIAL is turned on by default, and
can improve the performance of the cloud server, as follows:
default y
depends on SLUB && SMP
bool "SLUB per cpu partial cache"
help
Per cpu partial caches accelerate objects allocation and freeing
that is local to a processor at the price of more indeterminism
in the latency of the free. On overflow these caches will be cleared
which requires the taking of locks that may cause latency spikes.
Typically one would choose no for a realtime system.
Best wishes,
Wen
^ permalink raw reply
* [PATCH] staging: Replace zero-length array with flexible-array member
From: Gustavo A. R. Silva @ 2020-02-20 13:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, Vaibhav Agarwal, Mark Greer, Johan Hovold,
Alex Elder, Michael Tretter, Pengutronix Kernel Team,
Mauro Carvalho Chehab, Larry Finger, Florian Schilhabel,
Adham Abozaeid, Ajay Singh
Cc: devel, linux-kernel, greybus-dev, linux-media, linux-wireless,
Gustavo A. R. Silva
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/staging/gdm724x/gdm_mux.h | 2 +-
drivers/staging/gdm724x/hci_packet.h | 6 ++--
drivers/staging/greybus/audio_apbridgea.h | 2 +-
drivers/staging/ks7010/ks_hostif.h | 4 +--
.../staging/media/allegro-dvt/allegro-core.c | 2 +-
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
drivers/staging/rtl8192e/rtllib.h | 30 +++++++++----------
.../staging/rtl8192u/ieee80211/ieee80211.h | 28 ++++++++---------
drivers/staging/rtl8712/ieee80211.h | 4 +--
drivers/staging/rtl8712/rtl871x_mp_ioctl.h | 4 +--
drivers/staging/wilc1000/cfg80211.c | 10 +++----
drivers/staging/wilc1000/spi.c | 2 +-
drivers/staging/wlan-ng/hfa384x.h | 4 +--
drivers/staging/wlan-ng/p80211types.h | 4 +--
14 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_mux.h b/drivers/staging/gdm724x/gdm_mux.h
index 51c22e3d8aeb..87b8d921fdc8 100644
--- a/drivers/staging/gdm724x/gdm_mux.h
+++ b/drivers/staging/gdm724x/gdm_mux.h
@@ -29,7 +29,7 @@ struct mux_pkt_header {
__le32 seq_num;
__le32 payload_size;
__le16 packet_type;
- unsigned char data[0];
+ unsigned char data[];
};
struct mux_tx {
diff --git a/drivers/staging/gdm724x/hci_packet.h b/drivers/staging/gdm724x/hci_packet.h
index 6dea3694afdd..faecdfbc664f 100644
--- a/drivers/staging/gdm724x/hci_packet.h
+++ b/drivers/staging/gdm724x/hci_packet.h
@@ -28,7 +28,7 @@
struct hci_packet {
__dev16 cmd_evt;
__dev16 len;
- u8 data[0];
+ u8 data[];
} __packed;
struct tlv {
@@ -51,7 +51,7 @@ struct sdu {
__dev32 dft_eps_ID;
__dev32 bearer_ID;
__dev32 nic_type;
- u8 data[0];
+ u8 data[];
} __packed;
struct multi_sdu {
@@ -59,7 +59,7 @@ struct multi_sdu {
__dev16 len;
__dev16 num_packet;
__dev16 reserved;
- u8 data[0];
+ u8 data[];
} __packed;
struct hci_pdn_table_ind {
diff --git a/drivers/staging/greybus/audio_apbridgea.h b/drivers/staging/greybus/audio_apbridgea.h
index 3f1f4dd2c61a..efec0f815efd 100644
--- a/drivers/staging/greybus/audio_apbridgea.h
+++ b/drivers/staging/greybus/audio_apbridgea.h
@@ -65,7 +65,7 @@
struct audio_apbridgea_hdr {
__u8 type;
__le16 i2s_port;
- __u8 data[0];
+ __u8 data[];
} __packed;
struct audio_apbridgea_set_config_request {
diff --git a/drivers/staging/ks7010/ks_hostif.h b/drivers/staging/ks7010/ks_hostif.h
index ca7dc8f5166c..39138191a556 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -70,7 +70,7 @@ struct hostif_data_request {
#define TYPE_DATA 0x0000
#define TYPE_AUTH 0x0001
__le16 reserved;
- u8 data[0];
+ u8 data[];
} __packed;
#define TYPE_PMK1 0x0001
@@ -194,7 +194,7 @@ enum mib_data_type {
struct hostif_mib_value {
__le16 size;
__le16 type;
- u8 body[0];
+ u8 body[];
} __packed;
struct hostif_mib_get_confirm_t {
diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c b/drivers/staging/media/allegro-dvt/allegro-core.c
index 3be41698df4c..0a09b3622e78 100644
--- a/drivers/staging/media/allegro-dvt/allegro-core.c
+++ b/drivers/staging/media/allegro-dvt/allegro-core.c
@@ -434,7 +434,7 @@ struct mcu_msg_push_buffers_internal_buffer {
struct mcu_msg_push_buffers_internal {
struct mcu_msg_header header;
u32 channel_id;
- struct mcu_msg_push_buffers_internal_buffer buffer[0];
+ struct mcu_msg_push_buffers_internal_buffer buffer[];
} __attribute__ ((__packed__));
struct mcu_msg_put_stream_buffer {
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
index 582c9187559d..61471a19d4e6 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -406,7 +406,7 @@ struct octeon_hcd {
*/
struct octeon_temp_buffer {
void *orig_buffer;
- u8 data[0];
+ u8 data[];
};
static inline struct usb_hcd *octeon_to_hcd(struct octeon_hcd *p)
diff --git a/drivers/staging/rtl8192e/rtllib.h b/drivers/staging/rtl8192e/rtllib.h
index 328f410daa03..b84f00b8d18b 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -728,14 +728,14 @@ struct rtllib_pspoll_hdr {
struct rtllib_hdr {
__le16 frame_ctl;
__le16 duration_id;
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_hdr_1addr {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_hdr_2addr {
@@ -743,7 +743,7 @@ struct rtllib_hdr_2addr {
__le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_hdr_3addr {
@@ -753,7 +753,7 @@ struct rtllib_hdr_3addr {
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
__le16 seq_ctl;
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_hdr_4addr {
@@ -764,7 +764,7 @@ struct rtllib_hdr_4addr {
u8 addr3[ETH_ALEN];
__le16 seq_ctl;
u8 addr4[ETH_ALEN];
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_hdr_3addrqos {
@@ -775,7 +775,7 @@ struct rtllib_hdr_3addrqos {
u8 addr3[ETH_ALEN];
__le16 seq_ctl;
__le16 qos_ctl;
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_hdr_4addrqos {
@@ -787,13 +787,13 @@ struct rtllib_hdr_4addrqos {
__le16 seq_ctl;
u8 addr4[ETH_ALEN];
__le16 qos_ctl;
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtllib_info_element {
u8 id;
u8 len;
- u8 data[0];
+ u8 data[];
} __packed;
struct rtllib_authentication {
@@ -802,7 +802,7 @@ struct rtllib_authentication {
__le16 transaction;
__le16 status;
/*challenge*/
- struct rtllib_info_element info_element[0];
+ struct rtllib_info_element info_element[];
} __packed;
struct rtllib_disauth {
@@ -818,7 +818,7 @@ struct rtllib_disassoc {
struct rtllib_probe_request {
struct rtllib_hdr_3addr header;
/* SSID, supported rates */
- struct rtllib_info_element info_element[0];
+ struct rtllib_info_element info_element[];
} __packed;
struct rtllib_probe_response {
@@ -829,7 +829,7 @@ struct rtllib_probe_response {
/* SSID, supported rates, FH params, DS params,
* CF params, IBSS params, TIM (if beacon), RSN
*/
- struct rtllib_info_element info_element[0];
+ struct rtllib_info_element info_element[];
} __packed;
/* Alias beacon for probe_response */
@@ -840,7 +840,7 @@ struct rtllib_assoc_request_frame {
__le16 capability;
__le16 listen_interval;
/* SSID, supported rates, RSN */
- struct rtllib_info_element info_element[0];
+ struct rtllib_info_element info_element[];
} __packed;
struct rtllib_assoc_response_frame {
@@ -848,7 +848,7 @@ struct rtllib_assoc_response_frame {
__le16 capability;
__le16 status;
__le16 aid;
- struct rtllib_info_element info_element[0]; /* supported rates */
+ struct rtllib_info_element info_element[]; /* supported rates */
} __packed;
struct rtllib_txb {
@@ -859,7 +859,7 @@ struct rtllib_txb {
u16 reserved;
__le16 frag_size;
__le16 payload_size;
- struct sk_buff *fragments[0];
+ struct sk_buff *fragments[];
};
#define MAX_SUBFRAME_COUNT 64
@@ -1792,7 +1792,7 @@ struct rtllib_device {
/* This must be the last item so that it points to the data
* allocated beyond this structure by alloc_rtllib
*/
- u8 priv[0];
+ u8 priv[];
};
#define IEEE_A (1<<0)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 9576b647f6b1..39f4ddd86796 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -886,14 +886,14 @@ enum ieee80211_mfie {
struct rtl_80211_hdr {
__le16 frame_ctl;
__le16 duration_id;
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtl_80211_hdr_1addr {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtl_80211_hdr_2addr {
@@ -901,7 +901,7 @@ struct rtl_80211_hdr_2addr {
__le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtl_80211_hdr_3addr {
@@ -911,7 +911,7 @@ struct rtl_80211_hdr_3addr {
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
__le16 seq_ctl;
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtl_80211_hdr_4addr {
@@ -922,7 +922,7 @@ struct rtl_80211_hdr_4addr {
u8 addr3[ETH_ALEN];
__le16 seq_ctl;
u8 addr4[ETH_ALEN];
- u8 payload[0];
+ u8 payload[];
} __packed;
struct rtl_80211_hdr_3addrqos {
@@ -951,7 +951,7 @@ struct rtl_80211_hdr_4addrqos {
struct ieee80211_info_element {
u8 id;
u8 len;
- u8 data[0];
+ u8 data[];
} __packed;
struct ieee80211_authentication {
@@ -960,7 +960,7 @@ struct ieee80211_authentication {
__le16 transaction;
__le16 status;
/*challenge*/
- struct ieee80211_info_element info_element[0];
+ struct ieee80211_info_element info_element[];
} __packed;
struct ieee80211_disassoc {
@@ -971,7 +971,7 @@ struct ieee80211_disassoc {
struct ieee80211_probe_request {
struct rtl_80211_hdr_3addr header;
/* SSID, supported rates */
- struct ieee80211_info_element info_element[0];
+ struct ieee80211_info_element info_element[];
} __packed;
struct ieee80211_probe_response {
@@ -982,7 +982,7 @@ struct ieee80211_probe_response {
/* SSID, supported rates, FH params, DS params,
* CF params, IBSS params, TIM (if beacon), RSN
*/
- struct ieee80211_info_element info_element[0];
+ struct ieee80211_info_element info_element[];
} __packed;
/* Alias beacon for probe_response */
@@ -993,7 +993,7 @@ struct ieee80211_assoc_request_frame {
__le16 capability;
__le16 listen_interval;
/* SSID, supported rates, RSN */
- struct ieee80211_info_element info_element[0];
+ struct ieee80211_info_element info_element[];
} __packed;
struct ieee80211_reassoc_request_frame {
@@ -1002,7 +1002,7 @@ struct ieee80211_reassoc_request_frame {
__le16 listen_interval;
u8 current_ap[ETH_ALEN];
/* SSID, supported rates, RSN */
- struct ieee80211_info_element info_element[0];
+ struct ieee80211_info_element info_element[];
} __packed;
struct ieee80211_assoc_response_frame {
@@ -1010,7 +1010,7 @@ struct ieee80211_assoc_response_frame {
__le16 capability;
__le16 status;
__le16 aid;
- struct ieee80211_info_element info_element[0]; /* supported rates */
+ struct ieee80211_info_element info_element[]; /* supported rates */
} __packed;
struct ieee80211_txb {
@@ -1021,7 +1021,7 @@ struct ieee80211_txb {
u16 reserved;
__le16 frag_size;
__le16 payload_size;
- struct sk_buff *fragments[0];
+ struct sk_buff *fragments[];
};
#define MAX_TX_AGG_COUNT 16
@@ -2007,7 +2007,7 @@ struct ieee80211_device {
/* This must be the last item so that it points to the data
* allocated beyond this structure by alloc_ieee80211
*/
- u8 priv[0];
+ u8 priv[];
};
#define IEEE_A (1<<0)
diff --git a/drivers/staging/rtl8712/ieee80211.h b/drivers/staging/rtl8712/ieee80211.h
index 8098f6905554..dabaa8fd34fb 100644
--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -535,7 +535,7 @@ struct ieee80211_info_element_hdr {
struct ieee80211_info_element {
u8 id;
u8 len;
- u8 data[0];
+ u8 data[];
} __packed;
/*
@@ -597,7 +597,7 @@ struct ieee80211_txb {
u16 reserved;
u16 frag_size;
u16 payload_size;
- struct sk_buff *fragments[0];
+ struct sk_buff *fragments[];
};
/* SWEEP TABLE ENTRIES NUMBER*/
diff --git a/drivers/staging/rtl8712/rtl871x_mp_ioctl.h b/drivers/staging/rtl8712/rtl871x_mp_ioctl.h
index 64e2ae436625..59fa6664d868 100644
--- a/drivers/staging/rtl8712/rtl871x_mp_ioctl.h
+++ b/drivers/staging/rtl8712/rtl871x_mp_ioctl.h
@@ -48,7 +48,7 @@ struct eeprom_rw_param {
struct EFUSE_ACCESS_STRUCT {
u16 start_addr;
u16 cnts;
- u8 data[0];
+ u8 data[];
};
struct burst_rw_reg {
@@ -324,7 +324,7 @@ struct mp_ioctl_handler {
struct mp_ioctl_param {
unsigned int subcode;
unsigned int len;
- unsigned char data[0];
+ unsigned char data[];
};
#define GEN_MP_IOCTL_SUBCODE(code) _MP_IOCTL_ ## code ## _CMD_
diff --git a/drivers/staging/wilc1000/cfg80211.c b/drivers/staging/wilc1000/cfg80211.c
index 995b1f306807..5d8faa01337d 100644
--- a/drivers/staging/wilc1000/cfg80211.c
+++ b/drivers/staging/wilc1000/cfg80211.c
@@ -62,7 +62,7 @@ struct wilc_p2p_pub_act_frame {
u8 oui_type;
u8 oui_subtype;
u8 dialog_token;
- u8 elem[0];
+ u8 elem[];
} __packed;
struct wilc_vendor_specific_ie {
@@ -70,13 +70,13 @@ struct wilc_vendor_specific_ie {
u8 tag_len;
u8 oui[3];
u8 oui_type;
- u8 attr[0];
+ u8 attr[];
} __packed;
struct wilc_attr_entry {
u8 attr_type;
__le16 attr_len;
- u8 val[0];
+ u8 val[];
} __packed;
struct wilc_attr_oper_ch {
@@ -91,13 +91,13 @@ struct wilc_attr_ch_list {
u8 attr_type;
__le16 attr_len;
u8 country_code[IEEE80211_COUNTRY_STRING_LEN];
- u8 elem[0];
+ u8 elem[];
} __packed;
struct wilc_ch_list_elem {
u8 op_class;
u8 no_of_channels;
- u8 ch_list[0];
+ u8 ch_list[];
} __packed;
static void cfg_scan_result(enum scan_event scan_event,
diff --git a/drivers/staging/wilc1000/spi.c b/drivers/staging/wilc1000/spi.c
index 44f7d48851b5..11653ac118cd 100644
--- a/drivers/staging/wilc1000/spi.c
+++ b/drivers/staging/wilc1000/spi.c
@@ -139,7 +139,7 @@ struct wilc_spi_read_rsp_data {
u8 status;
u8 resp_header;
u8 resp_data[4];
- u8 crc[0];
+ u8 crc[];
} __packed;
struct wilc_spi_rsp_data {
diff --git a/drivers/staging/wlan-ng/hfa384x.h b/drivers/staging/wlan-ng/hfa384x.h
index bdd7f414fdbb..88e894dd3568 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -355,7 +355,7 @@
/* Commonly used basic types */
struct hfa384x_bytestr {
__le16 len;
- u8 data[0];
+ u8 data[];
} __packed;
struct hfa384x_bytestr32 {
@@ -421,7 +421,7 @@ struct hfa384x_authenticate_station_data {
/*-- Configuration Record: WPAData (data portion only) --*/
struct hfa384x_wpa_data {
__le16 datalen;
- u8 data[0]; /* max 80 */
+ u8 data[]; /* max 80 */
} __packed;
/*--------------------------------------------------------------------
diff --git a/drivers/staging/wlan-ng/p80211types.h b/drivers/staging/wlan-ng/p80211types.h
index ac254542fde6..3dcdd022da61 100644
--- a/drivers/staging/wlan-ng/p80211types.h
+++ b/drivers/staging/wlan-ng/p80211types.h
@@ -204,7 +204,7 @@ struct p80211pstr {
struct p80211pstrd {
u8 len;
- u8 data[0];
+ u8 data[];
} __packed;
/* Maximum pascal string */
@@ -249,7 +249,7 @@ struct p80211itemd {
u32 did;
u16 status;
u16 len;
- u8 data[0];
+ u8 data[];
} __packed;
/* message data item for int, BOUNDEDINT, ENUMINT */
--
2.25.0
^ permalink raw reply related
* [dpdk-dev] [PATCH v3 1/2] net/mlx5: fix layer flags missing in metadata
From: Suanming Mou @ 2020-02-20 13:53 UTC (permalink / raw)
To: matan, viacheslavo; +Cc: dev, rasland, stable
In-Reply-To: <1582206824-103222-1-git-send-email-suanmingm@mellanox.com>
Metadata suffix subflow inherits the RSS needed hash_fields from the
prefix subflow as the suffix subflow only has the tag match item unable
to generate the full original hash_fields for RSS action.
Unfortunately, hash_fields will only be generated if flow has RSS action.
So it means the prefix flow won't generate the hash_fields as the RSS
action has been split to the suffix flow.
Copy the layer flags from prefix subflow to suffix subflow to help the
suffix subflow to generate the correct hash_fields itself.
Fixes: 71e254bc0294 ("net/mlx5: split Rx flows to provide metadata copy")
Cc: viacheslavo@mellanox.com
Cc: stable@dpdk.org
Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
---
drivers/net/mlx5/mlx5_flow.c | 67 +++++++++++++++++++++++++++++++++++------
drivers/net/mlx5/mlx5_flow_dv.c | 6 +++-
2 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index ce5aded..9267858 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2727,6 +2727,43 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
}
/**
+ * Get layer flags from the prefix flow.
+ *
+ * Some flows may be split to several subflows, the prefix subflow gets the
+ * match items and the suffix sub flow gets the actions.
+ * Some actions need the user defined match item flags to get the detail for
+ * the action.
+ * This function helps the suffix flow to get the item layer flags from prefix
+ * subflow.
+ *
+ * @param[in] dev_flow
+ * Pointer the created preifx subflow.
+ *
+ * @return
+ * The layers get from prefix subflow.
+ */
+static inline uint64_t
+flow_get_prefix_layer_flags(struct mlx5_flow *dev_flow)
+{
+ uint64_t layers = 0;
+
+ /* If no decap actions, use the layers directly. */
+ if (!(dev_flow->actions & MLX5_FLOW_ACTION_DECAP))
+ return dev_flow->layers;
+ /* Convert L3 layers with decap action. */
+ if (dev_flow->layers & MLX5_FLOW_LAYER_INNER_L3_IPV4)
+ layers |= MLX5_FLOW_LAYER_OUTER_L3_IPV4;
+ else if (dev_flow->layers & MLX5_FLOW_LAYER_INNER_L3_IPV6)
+ layers |= MLX5_FLOW_LAYER_OUTER_L3_IPV6;
+ /* Convert L4 layers with decap action. */
+ if (dev_flow->layers & MLX5_FLOW_LAYER_INNER_L4_TCP)
+ layers |= MLX5_FLOW_LAYER_OUTER_L4_TCP;
+ else if (dev_flow->layers & MLX5_FLOW_LAYER_INNER_L4_UDP)
+ layers |= MLX5_FLOW_LAYER_OUTER_L4_UDP;
+ return layers;
+}
+
+/**
* Get QUEUE/RSS action from the action list.
*
* @param[in] actions
@@ -3406,6 +3443,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
* Parent flow structure pointer.
* @param[in, out] sub_flow
* Pointer to return the created subflow, may be NULL.
+ * @param[in] prefix_layers
+ * Prefix subflow layers, may be 0.
* @param[in] attr
* Flow rule attributes.
* @param[in] items
@@ -3423,6 +3462,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
flow_create_split_inner(struct rte_eth_dev *dev,
struct rte_flow *flow,
struct mlx5_flow **sub_flow,
+ uint64_t prefix_layers,
const struct rte_flow_attr *attr,
const struct rte_flow_item items[],
const struct rte_flow_action actions[],
@@ -3437,6 +3477,12 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
dev_flow->external = external;
/* Subflow object was created, we must include one in the list. */
LIST_INSERT_HEAD(&flow->dev_flows, dev_flow, next);
+ /*
+ * If dev_flow is as one of the suffix flow, some actions in suffix
+ * flow may need some user defined item layer flags.
+ */
+ if (prefix_layers)
+ dev_flow->layers = prefix_layers;
if (sub_flow)
*sub_flow = dev_flow;
return flow_drv_translate(dev, dev_flow, attr, items, actions, error);
@@ -3768,8 +3814,9 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
if (!config->dv_flow_en ||
config->dv_xmeta_en == MLX5_XMETA_MODE_LEGACY ||
!mlx5_flow_ext_mreg_supported(dev))
- return flow_create_split_inner(dev, flow, NULL, attr, items,
- actions, external, error);
+ return flow_create_split_inner(dev, flow, NULL, 0,
+ attr, items, actions, external,
+ error);
actions_n = flow_parse_qrss_action(actions, &qrss);
if (qrss) {
/* Exclude hairpin flows from splitting. */
@@ -3850,9 +3897,9 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
goto exit;
}
/* Add the unmodified original or prefix subflow. */
- ret = flow_create_split_inner(dev, flow, &dev_flow, attr, items,
- ext_actions ? ext_actions : actions,
- external, error);
+ ret = flow_create_split_inner(dev, flow, &dev_flow, 0, attr,
+ items, ext_actions ? ext_actions :
+ actions, external, error);
if (ret < 0)
goto exit;
MLX5_ASSERT(dev_flow);
@@ -3886,7 +3933,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
.type = RTE_FLOW_ACTION_TYPE_END,
},
};
- uint64_t hash_fields = dev_flow->hash_fields;
+ uint64_t layers = flow_get_prefix_layer_flags(dev_flow);
/*
* Configure the tag item only if there is no meter subflow.
@@ -3913,14 +3960,13 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
}
dev_flow = NULL;
/* Add suffix subflow to execute Q/RSS. */
- ret = flow_create_split_inner(dev, flow, &dev_flow,
+ ret = flow_create_split_inner(dev, flow, &dev_flow, layers,
&q_attr, mtr_sfx ? items :
q_items, q_actions,
external, error);
if (ret < 0)
goto exit;
MLX5_ASSERT(dev_flow);
- dev_flow->hash_fields = hash_fields;
}
exit:
@@ -4009,8 +4055,9 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
goto exit;
}
/* Add the prefix subflow. */
- ret = flow_create_split_inner(dev, flow, &dev_flow, attr, items,
- pre_actions, external, error);
+ ret = flow_create_split_inner(dev, flow, &dev_flow, 0, attr,
+ items, pre_actions, external,
+ error);
if (ret) {
ret = -rte_errno;
goto exit;
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index b6e50b1..19f5b61 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -7813,7 +7813,11 @@ struct field_modify_info modify_tcp[] = {
MLX5_ASSERT(!flow_dv_check_valid_spec(matcher.mask.buf,
dev_flow->dv.value.buf));
#endif
- dev_flow->layers = item_flags;
+ /*
+ * Layers may be already initialized from prefix flow if this dev_flow
+ * is the suffix flow.
+ */
+ dev_flow->layers |= item_flags;
if (action_flags & MLX5_FLOW_ACTION_RSS)
flow_dv_hashfields_set(dev_flow);
/* Register matcher. */
--
1.8.3.1
^ permalink raw reply related
* [dpdk-dev] [PATCH v3 0/2] net/mlx5: copy the item flags from prefix flow
From: Suanming Mou @ 2020-02-20 13:53 UTC (permalink / raw)
To: matan, viacheslavo; +Cc: dev, rasland
In-Reply-To: <1582122664-54731-1-git-send-email-suanmingm@mellanox.com>
For flow split to several subflows, the match items maybe in the prefix
flow, and the actions are split to the suffix flow.
In this case, for the actions need the user defined match item will not
create correctly.
Copy the item layers flags to the suffix flow from prefix flow to fix
the issue.
This patch series should be applied after:
https://patches.dpdk.org/project/dpdk/list/?series=8613
v2:
Remove the actions flag inherit. Get the layer flags accordingly
based on the actions in prefix flow.
v3:
Fix NULL pointer issue.
Suanming Mou (2):
net/mlx5: fix layer flags missing in metadata
net/mlx5: fix lack of match information in meter
drivers/net/mlx5/mlx5_flow.c | 74 +++++++++++++++++++++++++++++++++++------
drivers/net/mlx5/mlx5_flow_dv.c | 59 +++++++++++++++++++++++---------
2 files changed, 107 insertions(+), 26 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header
From: Daniel Kiper @ 2020-02-20 13:53 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, lersek, leif, pjones, mjg59, agraf, ilias.apalodimas,
xypron.glpk, nivedita, James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
On Thu, Feb 20, 2020 at 12:06:46PM +0100, Ard Biesheuvel wrote:
> After having added new ways to load the initrd and the mixed mode kernel,
> we will need to tell the loader about this, so it can use the new, generic
> method if supported, and fall back to the existing method(s) otherwise.
>
> This is an RFC - if there are better ways to record this in the image
> somehow, please shout.
>
> Cc: lersek@redhat.com
> Cc: leif@nuviainc.com
> Cc: pjones@redhat.com
> Cc: mjg59@google.com
> Cc: agraf@csgraf.de
> Cc: ilias.apalodimas@linaro.org
> Cc: xypron.glpk@gmx.de
> Cc: daniel.kiper@oracle.com
> Cc: nivedita@alum.mit.edu
> Cc: James.Bottomley@hansenpartnership.com
For all the patches Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>...
I hope that we will see a bootloader, GRUB preferred, implementation for
this thing soon...
Daniel
^ permalink raw reply
* Re: [PATCH 2/6] drm/bridge: anx6345: Clean up error handling in probe()
From: Laurent Pinchart @ 2020-02-20 13:52 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, Linus Walleij,
dri-devel, Andrzej Hajda, Thierry Reding, Sam Ravnborg,
Stephen Rothwell, Samuel Holland, Heiko Stuebner, Chen-Yu Tsai,
Icenowy Zheng, Stephan Gerhold, Jonas Karlman, Torsten Duwe,
Rob Herring, Maxime Ripard, linux-arm-kernel, Jernej Skrabec,
linux-kernel, Mark Brown, Daniel Vetter
In-Reply-To: <20200220083508.792071-3-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> we don't need to print scary message in either case.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 0d8d083b0207..0204bbe4f0a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -713,17 +713,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> /* 1.2V digital core power regulator */
> anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
> - if (IS_ERR(anx6345->dvdd12)) {
> - DRM_ERROR("dvdd12-supply not found\n");
> + if (IS_ERR(anx6345->dvdd12))
> return PTR_ERR(anx6345->dvdd12);
> - }
There could be other errors such as -EBUSY or -EPERM. The following
would ensure a message gets printed in those cases, while avoiding
spamming the kernel log in the EPROBE_DEFER case.
if (IS_ERR(anx6345->dvdd12)) {
if (PTR_ERR(anx6345->dvdd12) != -EPROBE_DEFER)
DRM_ERROR("Failed to get dvdd12 supply (%d)\n",
PTR_ERR(anx6345->dvdd12));
return PTR_ERR(anx6345->dvdd12);
}
But maybe it's overkill ? With or without that change (for the second
regulator below too),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> /* 2.5V digital core power regulator */
> anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
> - if (IS_ERR(anx6345->dvdd25)) {
> - DRM_ERROR("dvdd25-supply not found\n");
> + if (IS_ERR(anx6345->dvdd25))
> return PTR_ERR(anx6345->dvdd25);
> - }
>
> /* GPIO for chip reset */
> anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Ask for Help]LBR usage in kernel
From: 陈弋玺 @ 2020-02-20 13:53 UTC (permalink / raw)
To: linux-kernel, linux-x86_64
Hi experts,
We want to try to retreive callchains of some perf events from LBR rather than frame stacks, as the information in frame stacks would be optimized by compiler. After investigating the usage of LBR in kernel, we found that LBR can only operated via Intel PMU, that means for now only callchains of hardware events can be retrieved from LBR. Is that correct?
If yes, I wonder if callchains of other perf events(eg. tracepoint, software events) can be retrieved from LBR? Or only callchains of events on PMU can be retrieved from LBR as there are some hardware restrictions?
Thanks for any help you can offer!
Best Regards,
Yixi Chen
^ permalink raw reply
* Re: [PATCH 2/6] drm/bridge: anx6345: Clean up error handling in probe()
From: Laurent Pinchart @ 2020-02-20 13:52 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, dri-devel,
Andrzej Hajda, Thierry Reding, Sam Ravnborg, Stephen Rothwell,
Samuel Holland, Heiko Stuebner, Chen-Yu Tsai, Icenowy Zheng,
Stephan Gerhold, Jonas Karlman, Torsten Duwe, Rob Herring,
Maxime Ripard, linux-arm-kernel, Jernej Skrabec, linux-kernel,
Mark Brown
In-Reply-To: <20200220083508.792071-3-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> we don't need to print scary message in either case.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 0d8d083b0207..0204bbe4f0a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -713,17 +713,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> /* 1.2V digital core power regulator */
> anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
> - if (IS_ERR(anx6345->dvdd12)) {
> - DRM_ERROR("dvdd12-supply not found\n");
> + if (IS_ERR(anx6345->dvdd12))
> return PTR_ERR(anx6345->dvdd12);
> - }
There could be other errors such as -EBUSY or -EPERM. The following
would ensure a message gets printed in those cases, while avoiding
spamming the kernel log in the EPROBE_DEFER case.
if (IS_ERR(anx6345->dvdd12)) {
if (PTR_ERR(anx6345->dvdd12) != -EPROBE_DEFER)
DRM_ERROR("Failed to get dvdd12 supply (%d)\n",
PTR_ERR(anx6345->dvdd12));
return PTR_ERR(anx6345->dvdd12);
}
But maybe it's overkill ? With or without that change (for the second
regulator below too),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> /* 2.5V digital core power regulator */
> anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
> - if (IS_ERR(anx6345->dvdd25)) {
> - DRM_ERROR("dvdd25-supply not found\n");
> + if (IS_ERR(anx6345->dvdd25))
> return PTR_ERR(anx6345->dvdd25);
> - }
>
> /* GPIO for chip reset */
> anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/6] drm/bridge: anx6345: Clean up error handling in probe()
From: Laurent Pinchart @ 2020-02-20 13:52 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Thierry Reding, Sam Ravnborg, David Airlie, Daniel Vetter,
Rob Herring, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Icenowy Zheng, Torsten Duwe, Heiko Stuebner, Linus Walleij,
Stephan Gerhold, Mark Brown, Stephen Rothwell, Samuel Holland,
dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20200220083508.792071-3-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> we don't need to print scary message in either case.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 0d8d083b0207..0204bbe4f0a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -713,17 +713,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> /* 1.2V digital core power regulator */
> anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
> - if (IS_ERR(anx6345->dvdd12)) {
> - DRM_ERROR("dvdd12-supply not found\n");
> + if (IS_ERR(anx6345->dvdd12))
> return PTR_ERR(anx6345->dvdd12);
> - }
There could be other errors such as -EBUSY or -EPERM. The following
would ensure a message gets printed in those cases, while avoiding
spamming the kernel log in the EPROBE_DEFER case.
if (IS_ERR(anx6345->dvdd12)) {
if (PTR_ERR(anx6345->dvdd12) != -EPROBE_DEFER)
DRM_ERROR("Failed to get dvdd12 supply (%d)\n",
PTR_ERR(anx6345->dvdd12));
return PTR_ERR(anx6345->dvdd12);
}
But maybe it's overkill ? With or without that change (for the second
regulator below too),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> /* 2.5V digital core power regulator */
> anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
> - if (IS_ERR(anx6345->dvdd25)) {
> - DRM_ERROR("dvdd25-supply not found\n");
> + if (IS_ERR(anx6345->dvdd25))
> return PTR_ERR(anx6345->dvdd25);
> - }
>
> /* GPIO for chip reset */
> anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: RFC: Split EPT huge pages in advance of dirty logging
From: Zhoujian (jay) @ 2020-02-20 13:52 UTC (permalink / raw)
To: Peter Xu
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
dgilbert@redhat.com, quintela@redhat.com, Liujinsong (Paul),
linfeng (M), wangxin (U), Huangweidong (C), bgardon@google.com
In-Reply-To: <20200219171919.GA34517@xz-x1>
> -----Original Message-----
> From: Peter Xu [mailto:peterx@redhat.com]
> Sent: Thursday, February 20, 2020 1:19 AM
> To: Zhoujian (jay) <jianjay.zhou@huawei.com>
> Cc: kvm@vger.kernel.org; qemu-devel@nongnu.org; pbonzini@redhat.com;
> dgilbert@redhat.com; quintela@redhat.com; Liujinsong (Paul)
> <liu.jinsong@huawei.com>; linfeng (M) <linfeng23@huawei.com>; wangxin (U)
> <wangxinxin.wang@huawei.com>; Huangweidong (C)
> <weidong.huang@huawei.com>
> Subject: Re: RFC: Split EPT huge pages in advance of dirty logging
>
> On Wed, Feb 19, 2020 at 01:19:08PM +0000, Zhoujian (jay) wrote:
> > Hi Peter,
> >
> > > -----Original Message-----
> > > From: Peter Xu [mailto:peterx@redhat.com]
> > > Sent: Wednesday, February 19, 2020 1:43 AM
> > > To: Zhoujian (jay) <jianjay.zhou@huawei.com>
> > > Cc: kvm@vger.kernel.org; qemu-devel@nongnu.org;
> pbonzini@redhat.com;
> > > dgilbert@redhat.com; quintela@redhat.com; Liujinsong (Paul)
> > > <liu.jinsong@huawei.com>; linfeng (M) <linfeng23@huawei.com>;
> > > wangxin (U) <wangxinxin.wang@huawei.com>; Huangweidong (C)
> > > <weidong.huang@huawei.com>
> > > Subject: Re: RFC: Split EPT huge pages in advance of dirty logging
> > >
> > > On Tue, Feb 18, 2020 at 01:13:47PM +0000, Zhoujian (jay) wrote:
> > > > Hi all,
> > > >
> > > > We found that the guest will be soft-lockup occasionally when live
> > > > migrating a 60 vCPU, 512GiB huge page and memory sensitive VM. The
> > > > reason is clear, almost all of the vCPUs are waiting for the KVM
> > > > MMU spin-lock to create 4K SPTEs when the huge pages are write
> > > > protected. This
> > > phenomenon is also described in this patch set:
> > > > https://patchwork.kernel.org/cover/11163459/
> > > > which aims to handle page faults in parallel more efficiently.
> > > >
> > > > Our idea is to use the migration thread to touch all of the guest
> > > > memory in the granularity of 4K before enabling dirty logging. To
> > > > be more specific, we split all the PDPE_LEVEL SPTEs into
> > > > DIRECTORY_LEVEL SPTEs as the first step, and then split all the
> > > > DIRECTORY_LEVEL SPTEs into
> > > PAGE_TABLE_LEVEL SPTEs as the following step.
> > >
> > > IIUC, QEMU will prefer to use huge pages for all the anonymous
> > > ramblocks (please refer to ram_block_add):
> > >
> > > qemu_madvise(new_block->host, new_block->max_length,
> > > QEMU_MADV_HUGEPAGE);
> >
> > Yes, you're right
> >
> > >
> > > Another alternative I can think of is to add an extra parameter to
> > > QEMU to explicitly disable huge pages (so that can even be
> > > MADV_NOHUGEPAGE instead of MADV_HUGEPAGE). However that
> should also
> > > drag down the performance for the whole lifecycle of the VM.
> >
> > From the performance point of view, it is better to keep the huge
> > pages when the VM is not in the live migration state.
> >
> > > A 3rd option is to make a QMP
> > > command to dynamically turn huge pages on/off for ramblocks globally.
> >
> > We're searching a dynamic method too.
> > We plan to add two new flags for each memory slot, say
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES and
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES. These flags can be set through
> > KVM_SET_USER_MEMORY_REGION ioctl.
> >
> > The mapping_level which is called by tdp_page_fault in the kernel side
> > will return PT_DIRECTORY_LEVEL if the
> KVM_MEM_FORCE_PT_DIRECTORY_PAGES
> > flag of the memory slot is set, and return PT_PAGE_TABLE_LEVEL if the
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES flag is set.
> >
> > The key steps to split the huge pages in advance of enabling dirty log
> > is as follows:
> > 1. The migration thread in user space uses
> KVM_SET_USER_MEMORY_REGION
> > ioctl to set the KVM_MEM_FORCE_PT_DIRECTORY_PAGES flag for each
> memory
> > slot.
> > 2. The migration thread continues to use the KVM_SPLIT_HUGE_PAGES
> > ioctl (which is newly added) to do the splitting of large pages in the
> > kernel side.
> > 3. A new vCPU is created temporally(do some initialization but will
> > not
> > run) to help to do the work, i.e. as the parameter of the tdp_page_fault.
> > 4. Collect the GPA ranges of all the memory slots with the
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES flag set.
> > 5. Split the 1G huge pages(collected in step 4) into 2M by calling
> > tdp_page_fault, since the mapping_level will return
> > PT_DIRECTORY_LEVEL. Here is the main difference from the usual path
> > which is caused by the Guest side(EPT violation/misconfig etc), we
> > call it directly in the hypervisor side.
> > 6. Do some cleanups, i.e. free the vCPU related resources 7. The
> > KVM_SPLIT_HUGE_PAGES ioctl returned to the user space side.
> > 8. Using KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES instread of
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES to repeat step 1 ~ step 7, in step
> 5
> > the 2M huge pages will be splitted into 4K pages.
> > 9. Clear the KVM_MEM_FORCE_PT_DIRECTORY_PAGES and
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES flags for each memory slot.
> > 10. Then the migration thread calls the log_start ioctl to enable the
> > dirty logging, and the remaining thing is the same.
>
> I'm not sure... I think it would be good if there is a way to have finer granularity
> control on using huge pages for any process, then KVM can directly leverage
> that because KVM page tables should always respect the mm configurations on
> these (so e.g. when huge page split, KVM gets notifications via mmu notifiers).
> Have you thought of such a more general way?
I did have thought of this, if we split the huge pages into 4K of a process, I'm
afraid it will not be workable for the huge pages sharing scenario, e.g. DPDK,
SPDK etc. So, only split the EPT page table and keep the VM process page table
(e.g. qemu) untouched is the goal.
>
> (And I just noticed that MADV_NOHUGEPAGE is only a hint to khugepaged
> and probably won't split any huge page at all after madvise() returns..)
> To tell the truth I'm still confused on how split of huge pages helped in your
> case...
I'm sorry if the meaning is not expressed clearly, and thanks for your patience.
> If I read it right the test reduced some execution time from 9s to a
> few ms after your splittion of huge pages.
Yes
> The thing is I don't see how split of
> huge pages could solve the mmu_lock contention with the huge VM, because
> IMO even if we split the huge pages into smaller ones, those pages should still
> be write-protected and need merely the same number of page faults to resolve
> when accessed/written? And I thought that should only be fixed with
> solutions like what Ben has proposed with the MMU rework. Could you show
> me what I've missed?
Let me try to describe the reason of mmu_lock contention more clearly and the
effort we tried to do...
The huge VM only has EPT >= level 2 sptes, and level 1 sptes don't
exist at the beginning. Write protect all the huge pages will trigger EPT
violation to create level 1 sptes for all the vCPUs which want to write the
content of the memory. Different vCPU write the different areas of
the memory, but they need the same kvm->mmu_lock to create the level 1
sptes, this situation will be worse if the number of vCPU and the memory of
VM is large(in our case 60U512G), meanwhile the VM has
memory-write-intensive work to do. In order to reduce the mmu_lock
contention, we try to: write protect VM memory gradually in small chunks,
such as 1G or 2M. Using a vCPU temporary creately by migration thread to
split 1G to 2M as the first step, and to split 2M to 4K as the second step
(this is a little hacking...and I do not know any side effect will be triggered
indeed).
Comparing to write protect all VM memory in one go, the write
protected range is limited in this way and only the vCPUs write this limited
range will be involved to take the mmu_lock. The contention will be reduced
since the memory range is small and the number of vCPU involved is small
too.
Of course, it will take some extra time to split all the huge pages into 4K
page before the real migration started, about 60s for 512G in my experiment.
During the memory iterative copy phase, PML will do the dirty logging work
(not write protected case for 4K), or IIRC using fast_page_fault to mark page
dirty if PML is not supported, which case the mmu_lock does not needed.
Regards,
Jay Zhou
^ permalink raw reply
* Re: Git Test Coverage Report (Feb. 18, 2020)
From: Johannes Schindelin @ 2020-02-20 13:52 UTC (permalink / raw)
To: Taylor Blau; +Cc: Derrick Stolee, Git List
In-Reply-To: <20200219204430.GB5101@syl.local>
Hi Taylor,
On Wed, 19 Feb 2020, Taylor Blau wrote:
> On Tue, Feb 18, 2020 at 07:46:03AM -0500, Derrick Stolee wrote:
>
> > Taylor Blau 5d5916fd builtin/commit-graph.c: support '--split[=<strategy>]'
> > commit-graph.c
> > 5d5916fd 1751) break;
>
> This 'break' line only changed indentation, so I don't think that this
> is new 'uncovered' code in my series, only that it got a little bit
> harder to trigger.
>
> It is interesting that this is uncovered, but I don't think that there's
> a huge sense of urgency to add tests to cover it.
I could imagine that this is actually not the `break` statement, but the
one before that. It seems to be an issue with the way GCC optimizes that
sometimes GDB (and gcov) have problems attributing precisely the line that
is associated with a given assembler instruction. My guess is that the
optimizer often seems to "reflow" the code, e.g. it would jump to the end
of a switch statement only to jump _back_ to the actual switch case.
So I would expect the report to be legit, but pointing to the incorrect
source code line. At least that's what I seem to recall from the last time
a Test Code Coverage report pointed at one of the `break` statements I had
added.
>
> > Taylor Blau a599e2c9 builtin/commit-graph.c: introduce '--input=<source>'
> > builtin/commit-graph.c
> > a599e2c9 75) *to = 0;
> > a599e2c9 76) return 0;
>
> These seem more interesting to cover, but only marginally so.
>
> > a599e2c9 86) *to |= COMMIT_GRAPH_INPUT_APPEND;
>
> This one I think we could ignore, though, since the same behavior is
> triggered by simply '--append' instead of '--input=append'. We decided
> in [1] to
to...? :-D
Thanks,
Dscho
>
> Thanks,
> Taylor
>
> [1]: 846706e9-efe2-448d-67a3-a96638e9bcbc@gmail.com
>
^ permalink raw reply
* Re: [yocto] Debugging gdb built by Yocto
From: Patrick Doyle @ 2020-02-20 13:52 UTC (permalink / raw)
To: Richard Purdie; +Cc: Yocto discussion list
In-Reply-To: <2c0fedf92f8a5cf805cc9908b438dab40ffd72ec.camel@linuxfoundation.org>
On Wed, Feb 19, 2020 at 5:19 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2020-02-18 at 11:26 -0500, Patrick Doyle wrote:
> > Does anybody have any tips or tricks for how I might debug the
> > (cross-canadian) gdb built by Yocto's SDK?
> Do you perhaps want gdb-cross-mipsel ?
>
> cross-canadian is designed to be run as part of the SDK.
Thank you. That is, indeed, what I want. It demonstrates the same
problem, and I can debug it.
Aside... it's quite a mind bending experience to debug gdb with gdb :-)
Just imagine...
$ gdb gdb-cross-mipsel
(gdb) break main
(gdb) run
(gdb)
That last "(gdb)" prompt is from the gdb I'm debugging :-)
Also aside... and totally off topic, except that I'm sure some might
be wondering why I feel the need to debug gdb...
I am trying to understand why I can't get stack traces from cores file
on a mipsel system. At the moment (after strategic additions of
breakpoints, printf statements, and more breakpoints, and lots of
internet combing), I am chasing down a rabbit hole related to the
facts that the MIPS build uses/produces PIE code (Position Independent
Executables, which is somehow different than Position Independent
Code), a new ELF tag (MIPS_RLD_MAP_REL) was added 5 years ago to
binutils, gdb looks for that tag, but the musl dynamic loader is not
aware of it. I don't know if this is the root cause of my problem or
just (another) rabbit hole. If anybody has any suggestions, I'm all
ears.
--wpd
^ permalink raw reply
* Re: [PATCH v3 02/20] hw: Remove unnecessary cast when calling dma_memory_read()
From: Philippe Mathieu-Daudé @ 2020-02-20 13:51 UTC (permalink / raw)
To: Eric Blake, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, Matthew Rosato, Michael S. Tsirkin,
Jason Wang, Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
kvm, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, David Gibson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, Richard Henderson,
Igor Mitsyanko, Cornelia Huck, Michael Walle, qemu-ppc,
Paolo Bonzini
In-Reply-To: <be623afd-0605-0bdf-daae-f38ba5562012@redhat.com>
On 2/20/20 2:43 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/20 2:16 PM, Eric Blake wrote:
>> On 2/20/20 7:05 AM, Philippe Mathieu-Daudé wrote:
>>> Since its introduction in commit d86a77f8abb, dma_memory_read()
>>> always accepted void pointer argument. Remove the unnecessary
>>> casts.
>>>
>>> This commit was produced with the included Coccinelle script
>>> scripts/coccinelle/exec_rw_const.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>> scripts/coccinelle/exec_rw_const.cocci | 15 +++++++++++++++
>>> hw/arm/smmu-common.c | 3 +--
>>> hw/arm/smmuv3.c | 10 ++++------
>>> hw/sd/sdhci.c | 15 +++++----------
>>> 4 files changed, 25 insertions(+), 18 deletions(-)
>>> create mode 100644 scripts/coccinelle/exec_rw_const.cocci
>>>
>>> diff --git a/scripts/coccinelle/exec_rw_const.cocci
>>> b/scripts/coccinelle/exec_rw_const.cocci
>>> new file mode 100644
>>> index 0000000000..a0054f009d
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/exec_rw_const.cocci
>>> @@ -0,0 +1,15 @@
>>> +// Usage:
>>> +// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
>>> --in-place
>>
>> This command line should also use '--macro-file
>> scripts/cocci-macro-file.h' to cover more of the code base (Coccinelle
>> skips portions of the code that uses macros it doesn't recognize).
>>
>>
>>> @@ -726,13 +724,10 @@ static void get_adma_description(SDHCIState *s,
>>> ADMADescr *dscr)
>>> }
>>> break;
>>> case SDHC_CTRL_ADMA2_64:
>>> - dma_memory_read(s->dma_as, entry_addr,
>>> - (uint8_t *)(&dscr->attr), 1);
>>> - dma_memory_read(s->dma_as, entry_addr + 2,
>>> - (uint8_t *)(&dscr->length), 2);
>>> + dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
>>> + dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
>>
>> The () around &dscr->length are now pointless.
>
> Thanks Eric, patch updated. Peter are you OK if I change the cocci
> header using /* */ as:
>
> -- >8 --
> diff --git a/scripts/coccinelle/exec_rw_const.cocci
> b/scripts/coccinelle/exec_rw_const.cocci
> index a0054f009d..7e42682240 100644
> --- a/scripts/coccinelle/exec_rw_const.cocci
> +++ b/scripts/coccinelle/exec_rw_const.cocci
> @@ -1,5 +1,13 @@
> -// Usage:
> -// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
> --in-place
> +/*
> + Usage:
> +
> + spatch \
> + --macro-file scripts/cocci-macro-file.h \
> + --sp-file scripts/coccinelle/exec_rw_const.cocci \
> + --keep-comments \
> + --in-place \
> + --dir .
> +*/
>
> // Remove useless cast
> @@
> @@ -7,9 +15,9 @@ expression E1, E2, E3, E4;
> type T;
> @@
> (
> -- dma_memory_read(E1, E2, (T *)E3, E4)
> +- dma_memory_read(E1, E2, (T *)(E3), E4)
> + dma_memory_read(E1, E2, E3, E4)
> |
> -- dma_memory_write(E1, E2, (T *)E3, E4)
> +- dma_memory_write(E1, E2, (T *)(E3), E4)
> + dma_memory_write(E1, E2, E3, E4)
> )
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index d5abdaad41..de63ffb037 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -724,10 +724,10 @@ static void get_adma_description(SDHCIState *s,
> ADMADescr *dscr)
> }
> break;
> case SDHC_CTRL_ADMA2_64:
> - dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
> - dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
> + dma_memory_read(s->dma_as, entry_addr, &dscr->attr, 1);
> + dma_memory_read(s->dma_as, entry_addr + 2, &dscr->length, 2);
> dscr->length = le16_to_cpu(dscr->length);
> - dma_memory_read(s->dma_as, entry_addr + 4, (&dscr->addr), 8);
> + dma_memory_read(s->dma_as, entry_addr + 4, &dscr->addr, 8);
> dscr->addr = le64_to_cpu(dscr->addr);
> dscr->attr &= (uint8_t) ~0xC0;
> dscr->incr = 12;
> ---
Series updated here:
https://github.com/philmd/qemu/commits/exec_rw_const_v4
Relevant spatch:
https://github.com/philmd/qemu/blob/exec_rw_const_v4/scripts/coccinelle/exec_rw_const.cocci
I will respin later to let people time to review.
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 02/20] hw: Remove unnecessary cast when calling dma_memory_read()
From: Philippe Mathieu-Daudé @ 2020-02-20 13:51 UTC (permalink / raw)
To: Eric Blake, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, Matthew Rosato, Michael S. Tsirkin,
Jason Wang, Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
kvm, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, David Gibson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, Richard Henderson,
Igor Mitsyanko, Cornelia Huck, Michael Walle, qemu-ppc,
Paolo Bonzini
In-Reply-To: <be623afd-0605-0bdf-daae-f38ba5562012@redhat.com>
On 2/20/20 2:43 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/20 2:16 PM, Eric Blake wrote:
>> On 2/20/20 7:05 AM, Philippe Mathieu-Daudé wrote:
>>> Since its introduction in commit d86a77f8abb, dma_memory_read()
>>> always accepted void pointer argument. Remove the unnecessary
>>> casts.
>>>
>>> This commit was produced with the included Coccinelle script
>>> scripts/coccinelle/exec_rw_const.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>> scripts/coccinelle/exec_rw_const.cocci | 15 +++++++++++++++
>>> hw/arm/smmu-common.c | 3 +--
>>> hw/arm/smmuv3.c | 10 ++++------
>>> hw/sd/sdhci.c | 15 +++++----------
>>> 4 files changed, 25 insertions(+), 18 deletions(-)
>>> create mode 100644 scripts/coccinelle/exec_rw_const.cocci
>>>
>>> diff --git a/scripts/coccinelle/exec_rw_const.cocci
>>> b/scripts/coccinelle/exec_rw_const.cocci
>>> new file mode 100644
>>> index 0000000000..a0054f009d
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/exec_rw_const.cocci
>>> @@ -0,0 +1,15 @@
>>> +// Usage:
>>> +// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
>>> --in-place
>>
>> This command line should also use '--macro-file
>> scripts/cocci-macro-file.h' to cover more of the code base (Coccinelle
>> skips portions of the code that uses macros it doesn't recognize).
>>
>>
>>> @@ -726,13 +724,10 @@ static void get_adma_description(SDHCIState *s,
>>> ADMADescr *dscr)
>>> }
>>> break;
>>> case SDHC_CTRL_ADMA2_64:
>>> - dma_memory_read(s->dma_as, entry_addr,
>>> - (uint8_t *)(&dscr->attr), 1);
>>> - dma_memory_read(s->dma_as, entry_addr + 2,
>>> - (uint8_t *)(&dscr->length), 2);
>>> + dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
>>> + dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
>>
>> The () around &dscr->length are now pointless.
>
> Thanks Eric, patch updated. Peter are you OK if I change the cocci
> header using /* */ as:
>
> -- >8 --
> diff --git a/scripts/coccinelle/exec_rw_const.cocci
> b/scripts/coccinelle/exec_rw_const.cocci
> index a0054f009d..7e42682240 100644
> --- a/scripts/coccinelle/exec_rw_const.cocci
> +++ b/scripts/coccinelle/exec_rw_const.cocci
> @@ -1,5 +1,13 @@
> -// Usage:
> -// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
> --in-place
> +/*
> + Usage:
> +
> + spatch \
> + --macro-file scripts/cocci-macro-file.h \
> + --sp-file scripts/coccinelle/exec_rw_const.cocci \
> + --keep-comments \
> + --in-place \
> + --dir .
> +*/
>
> // Remove useless cast
> @@
> @@ -7,9 +15,9 @@ expression E1, E2, E3, E4;
> type T;
> @@
> (
> -- dma_memory_read(E1, E2, (T *)E3, E4)
> +- dma_memory_read(E1, E2, (T *)(E3), E4)
> + dma_memory_read(E1, E2, E3, E4)
> |
> -- dma_memory_write(E1, E2, (T *)E3, E4)
> +- dma_memory_write(E1, E2, (T *)(E3), E4)
> + dma_memory_write(E1, E2, E3, E4)
> )
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index d5abdaad41..de63ffb037 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -724,10 +724,10 @@ static void get_adma_description(SDHCIState *s,
> ADMADescr *dscr)
> }
> break;
> case SDHC_CTRL_ADMA2_64:
> - dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
> - dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
> + dma_memory_read(s->dma_as, entry_addr, &dscr->attr, 1);
> + dma_memory_read(s->dma_as, entry_addr + 2, &dscr->length, 2);
> dscr->length = le16_to_cpu(dscr->length);
> - dma_memory_read(s->dma_as, entry_addr + 4, (&dscr->addr), 8);
> + dma_memory_read(s->dma_as, entry_addr + 4, &dscr->addr, 8);
> dscr->addr = le64_to_cpu(dscr->addr);
> dscr->attr &= (uint8_t) ~0xC0;
> dscr->incr = 12;
> ---
Series updated here:
https://github.com/philmd/qemu/commits/exec_rw_const_v4
Relevant spatch:
https://github.com/philmd/qemu/blob/exec_rw_const_v4/scripts/coccinelle/exec_rw_const.cocci
I will respin later to let people time to review.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v3 02/20] hw: Remove unnecessary cast when calling dma_memory_read()
From: Philippe Mathieu-Daudé @ 2020-02-20 13:51 UTC (permalink / raw)
To: Eric Blake, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, kvm, Michael S. Tsirkin, Jason Wang,
Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
Matthew Rosato, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, Richard Henderson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, David Gibson, Igor Mitsyanko,
Cornelia Huck, Michael Walle, qemu-ppc, Paolo Bonzini
In-Reply-To: <be623afd-0605-0bdf-daae-f38ba5562012@redhat.com>
On 2/20/20 2:43 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/20 2:16 PM, Eric Blake wrote:
>> On 2/20/20 7:05 AM, Philippe Mathieu-Daudé wrote:
>>> Since its introduction in commit d86a77f8abb, dma_memory_read()
>>> always accepted void pointer argument. Remove the unnecessary
>>> casts.
>>>
>>> This commit was produced with the included Coccinelle script
>>> scripts/coccinelle/exec_rw_const.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>> scripts/coccinelle/exec_rw_const.cocci | 15 +++++++++++++++
>>> hw/arm/smmu-common.c | 3 +--
>>> hw/arm/smmuv3.c | 10 ++++------
>>> hw/sd/sdhci.c | 15 +++++----------
>>> 4 files changed, 25 insertions(+), 18 deletions(-)
>>> create mode 100644 scripts/coccinelle/exec_rw_const.cocci
>>>
>>> diff --git a/scripts/coccinelle/exec_rw_const.cocci
>>> b/scripts/coccinelle/exec_rw_const.cocci
>>> new file mode 100644
>>> index 0000000000..a0054f009d
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/exec_rw_const.cocci
>>> @@ -0,0 +1,15 @@
>>> +// Usage:
>>> +// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
>>> --in-place
>>
>> This command line should also use '--macro-file
>> scripts/cocci-macro-file.h' to cover more of the code base (Coccinelle
>> skips portions of the code that uses macros it doesn't recognize).
>>
>>
>>> @@ -726,13 +724,10 @@ static void get_adma_description(SDHCIState *s,
>>> ADMADescr *dscr)
>>> }
>>> break;
>>> case SDHC_CTRL_ADMA2_64:
>>> - dma_memory_read(s->dma_as, entry_addr,
>>> - (uint8_t *)(&dscr->attr), 1);
>>> - dma_memory_read(s->dma_as, entry_addr + 2,
>>> - (uint8_t *)(&dscr->length), 2);
>>> + dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
>>> + dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
>>
>> The () around &dscr->length are now pointless.
>
> Thanks Eric, patch updated. Peter are you OK if I change the cocci
> header using /* */ as:
>
> -- >8 --
> diff --git a/scripts/coccinelle/exec_rw_const.cocci
> b/scripts/coccinelle/exec_rw_const.cocci
> index a0054f009d..7e42682240 100644
> --- a/scripts/coccinelle/exec_rw_const.cocci
> +++ b/scripts/coccinelle/exec_rw_const.cocci
> @@ -1,5 +1,13 @@
> -// Usage:
> -// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
> --in-place
> +/*
> + Usage:
> +
> + spatch \
> + --macro-file scripts/cocci-macro-file.h \
> + --sp-file scripts/coccinelle/exec_rw_const.cocci \
> + --keep-comments \
> + --in-place \
> + --dir .
> +*/
>
> // Remove useless cast
> @@
> @@ -7,9 +15,9 @@ expression E1, E2, E3, E4;
> type T;
> @@
> (
> -- dma_memory_read(E1, E2, (T *)E3, E4)
> +- dma_memory_read(E1, E2, (T *)(E3), E4)
> + dma_memory_read(E1, E2, E3, E4)
> |
> -- dma_memory_write(E1, E2, (T *)E3, E4)
> +- dma_memory_write(E1, E2, (T *)(E3), E4)
> + dma_memory_write(E1, E2, E3, E4)
> )
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index d5abdaad41..de63ffb037 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -724,10 +724,10 @@ static void get_adma_description(SDHCIState *s,
> ADMADescr *dscr)
> }
> break;
> case SDHC_CTRL_ADMA2_64:
> - dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
> - dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
> + dma_memory_read(s->dma_as, entry_addr, &dscr->attr, 1);
> + dma_memory_read(s->dma_as, entry_addr + 2, &dscr->length, 2);
> dscr->length = le16_to_cpu(dscr->length);
> - dma_memory_read(s->dma_as, entry_addr + 4, (&dscr->addr), 8);
> + dma_memory_read(s->dma_as, entry_addr + 4, &dscr->addr, 8);
> dscr->addr = le64_to_cpu(dscr->addr);
> dscr->attr &= (uint8_t) ~0xC0;
> dscr->incr = 12;
> ---
Series updated here:
https://github.com/philmd/qemu/commits/exec_rw_const_v4
Relevant spatch:
https://github.com/philmd/qemu/blob/exec_rw_const_v4/scripts/coccinelle/exec_rw_const.cocci
I will respin later to let people time to review.
^ permalink raw reply
* Re: [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 13:48 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
linux-mm@kvack.org, ocfs2-devel@oss.oracle.com,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
In-Reply-To: <SN4PR0401MB35987D7B76007B93B1C5CE5E9B130@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 09:42:19AM +0000, Johannes Thumshirn wrote:
> On 19/02/2020 22:03, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Use the new readahead operation in btrfs. Add a
> > readahead_for_each_batch() iterator to optimise the loop in the XArray.
>
> OK I must admit I haven't followed this series closely, but what
> happened to said readahead_for_each_batch()?
>
> As far as I can see it's now:
>
> [...]
> > + while ((nr = readahead_page_batch(rac, pagepool))) {
Oops, forgot to update the changelog there. Yes, that's exactly what it
changed to. That discussion was here:
https://lore.kernel.org/linux-fsdevel/20200219144117.GP24185@bombadil.infradead.org/
... and then Christoph pointed out the iterators weren't really adding
much value at that point, so they got deleted. New changelog for
this patch:
btrfs: Convert from readpages to readahead
Implement the new readahead method in btrfs. Add a readahead_page_batch()
to optimise fetching a batch of pages at once.
^ permalink raw reply
* Re: [PATCH v3 6/6] powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst and add 64bit part
From: Christophe Leroy @ 2020-02-20 13:50 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, benh, paulus,
npiggin, keescook, kernel-hardening, oss
Cc: linux-kernel, zhaohongjiang
In-Reply-To: <20200206025825.22934-7-yanaijie@huawei.com>
Le 06/02/2020 à 03:58, Jason Yan a écrit :
> Now we support both 32 and 64 bit KASLR for fsl booke. Add document for
> 64 bit part and rename kaslr-booke32.rst to kaslr-booke.rst.
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> .../{kaslr-booke32.rst => kaslr-booke.rst} | 35 ++++++++++++++++---
> 1 file changed, 31 insertions(+), 4 deletions(-)
> rename Documentation/powerpc/{kaslr-booke32.rst => kaslr-booke.rst} (59%)
Also update Documentation/powerpc/index.rst ?
Christophe
^ permalink raw reply
* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jin, Yao @ 2020-02-20 13:50 UTC (permalink / raw)
To: Jiri Olsa
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <20200220120655.GA586895@krava>
On 2/20/2020 8:06 PM, Jiri Olsa wrote:
> On Thu, Feb 20, 2020 at 08:03:18PM +0800, Jin, Yao wrote:
>>
>>
>> On 2/20/2020 7:56 PM, Jiri Olsa wrote:
>>> On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
>>>> For perf report on stripped binaries it is currently impossible to do
>>>> annotation. The annotation state is all tied to symbols, but there are
>>>> either no symbols, or symbols are not covering all the code.
>>>>
>>>> We should support the annotation functionality even without symbols.
>>>>
>>>> The first patch uses al_addr to print because it's easy to dump
>>>> the instructions from this address in binary for branch mode.
>>>>
>>>> The second patch supports the annotation on stripped binary.
>>>>
>>>> Jin Yao (2):
>>>> perf util: Print al_addr when symbol is not found
>>>> perf annotate: Support interactive annotation of code without symbols
>>>
>>> looks good, but I'm getting crash when annotating unresolved kernel address:
>>>
>>> jirka
>>>
>>>
>>
>> Thanks for reporting the issue.
>>
>> I guess you are trying the "0xffffffff81c00ae7", let me try to reproduce
>> this issue.
>
> yes, I also checked and it did not happen before
>
> jirka
>
I can reproduce it now.
perf record -e cycles:u ls
perf report --stdio
75.29% ls ld-2.27.so [.] do_lookup_x
23.64% ls ld-2.27.so [.] __GI___tunables_init
1.04% ls [unknown] [k] 0xffffffff85c01210
0.03% ls ld-2.27.so [.] _start
Looks it's caused by skid.
Thanks
Jin Yao
^ permalink raw reply
* Re: [PATCH v3 5/6] powerpc/fsl_booke/64: clear the original kernel if randomized
From: Christophe Leroy @ 2020-02-20 13:49 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, benh, paulus,
npiggin, keescook, kernel-hardening, oss
Cc: linux-kernel, zhaohongjiang
In-Reply-To: <20200206025825.22934-6-yanaijie@huawei.com>
Le 06/02/2020 à 03:58, Jason Yan a écrit :
> The original kernel still exists in the memory, clear it now.
No such problem with PPC32 ? Or is that common ?
Christophe
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/mm/nohash/kaslr_booke.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
> index c6f5c1db1394..ed1277059368 100644
> --- a/arch/powerpc/mm/nohash/kaslr_booke.c
> +++ b/arch/powerpc/mm/nohash/kaslr_booke.c
> @@ -378,8 +378,10 @@ notrace void __init kaslr_early_init(void *dt_ptr, phys_addr_t size)
> unsigned int *__kaslr_offset = (unsigned int *)(KERNELBASE + 0x58);
> unsigned int *__run_at_load = (unsigned int *)(KERNELBASE + 0x5c);
>
> - if (*__run_at_load == 1)
> + if (*__run_at_load == 1) {
> + kaslr_late_init();
> return;
> + }
>
> /* Setup flat device-tree pointer */
> initial_boot_params = dt_ptr;
>
^ permalink raw reply
* [PATCH v2 0/1] scsi: ufs: fix waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: Stanley Chu, bvanassche, andy.teng, chun-hung.wu, kuohong.wang,
linux-kernel, cang, linux-mediatek, peter.wang, matthias.bgg,
beanhuo, linux-arm-kernel, asutoshd
Hi,
This patchset adds waiting time for reference clock provided to UFS device in MediaTek UFS implementation.
v1 -> v2:
- Drop patch #1 "scsi: ufs: add required delay after gating reference clock" since it will impact ufs-qcom flow without solid conclusion yet.
Stanley Chu (1):
scsi: ufs: ufs-mediatek: add waiting time for reference clock
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.