* [PATCH v3 0/2] arm64: Support systems without FP/ASIMD
From: Catalin Marinas @ 2016-11-14 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9b41cca-9a9c-ab92-d3e5-ee1870bb70d4@arm.com>
On Fri, Nov 11, 2016 at 01:41:37PM +0000, Marc Zyngier wrote:
> On 08/11/16 13:56, Suzuki K Poulose wrote:
> > This series adds supports to the kernel and KVM hyp to handle
> > systems without FP/ASIMD properly. At the moment the kernel
> > doesn't check if the FP unit is available before accessing
> > the registers (e.g during context switch). Also for KVM,
> > we trap the FP/ASIMD accesses and handle it by injecting an
> > undefined instruction into the VM on systems without FP.
> >
> > Tested on a FVP_Base-AEM-v8A model by disabling VFP on at
> > least one CPU ( -C clusterX.cpuY.vfp-present=0 ).
> >
> > Changes since V2:
> > - Dropped cleanup patch for arm64/crypto/aes-ce-ccm-glue.c
> > - Removed static_key check from cpus_have_cap. All users with
> > constant caps should use the new API to make use of static_keys.
> > - Removed a dedicated static_key used in irqchip-gic-v3.c for
> > Cavium errata with the new API.
> >
> > Applies on v4.9-rc4 + [1] (which is pushed for rc5)
> >
> > [1] http://marc.info/?l=linux-arm-kernel&m=147819889813214&w=2
> >
> >
> > Suzuki K Poulose (2):
> > arm64: Add hypervisor safe helper for checking constant capabilities
> > arm64: Support systems without FP/ASIMD
> >
> > arch/arm64/include/asm/cpucaps.h | 3 ++-
> > arch/arm64/include/asm/cpufeature.h | 24 +++++++++++++++++-------
> > arch/arm64/include/asm/neon.h | 3 ++-
> > arch/arm64/kernel/cpufeature.c | 17 ++++++++++++++++-
> > arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++
> > arch/arm64/kernel/process.c | 2 +-
> > arch/arm64/kvm/handle_exit.c | 11 +++++++++++
> > arch/arm64/kvm/hyp/hyp-entry.S | 9 ++++++++-
> > arch/arm64/kvm/hyp/switch.c | 5 ++++-
> > drivers/irqchip/irq-gic-v3.c | 13 +------------
> > 10 files changed, 76 insertions(+), 25 deletions(-)
>
> For the series:
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
> How do we plan on merging this? Catalin, are you willing to take it all?
Happy to take it all through the arm64 tree. Thanks for the review.
--
Catalin
^ permalink raw reply
* Re: Can we drop ubuntu 14.04 (trusty) for kraken and lumninous?
From: Tomasz Kuzemko @ 2016-11-14 11:08 UTC (permalink / raw)
To: Sage Weil, ceph-maintainers-Qp0mS5GaXlQ
Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA, ceph-users-Qp0mS5GaXlQ
In-Reply-To: <alpine.DEB.2.11.1611111837410.29579-ie3vfNGmdjePKud3HExfWg@public.gmane.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1091 bytes --]
I vote for 1. until Ubuntu 14.04 is supported.
On 11.11.2016 19:43, Sage Weil wrote:
> Currently the distros we use for upstream testing are
>
> centos 7.x
> ubuntu 16.04 (xenial)
> ubuntu 14.04 (trusty)
>
> We also do some basic testing for Debian 8 and Fedora (some old version).
>
> Jewel was the first release that had native systemd and full xenial
> support, so it's helpful to have both 14.04 and 16.04 supported to provide
> an upgrade path. But I think we can safely drop 14.04 now for kraken and
> luminous. Our options are
>
> 1) keep testing on xenial and trusty, and keep building packages for both
>
> 2) stop testing trusty, but still build packages
>
> 3) stop testing or building for trusty
>
> Preferences?
> sage
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Tomasz Kuzemko
tomasz.kuzemko-Rm6v+N6rxxBWk0Htik3J/w@public.gmane.org
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 178 bytes --]
_______________________________________________
ceph-users mailing list
ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: One Thousand Gnomes @ 2016-11-14 11:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Gabriele Paoloni, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, benh@kernel.crashing.org,
minyard@acm.org, catalin.marinas@arm.com, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, olof@lixom.net, robh+dt@kernel.org,
zourongrong@gmail.com, linux-serial@vger.kernel.org,
linux-pci@vger.kernel.org, bhelgaas@google.com,
liviu.dudau@arm.com, kantyzc@163.com, zhichang.yuan02@gmail.com
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
On Wed, 09 Nov 2016 22:34:38 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> > > On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > > > + /*
> > > > + * The first PCIBIOS_MIN_IO is reserved specifically for
> > > indirectIO.
> > > > + * It will separate indirectIO range from pci host bridge to
> > > > + * avoid the possible PIO conflict.
> > > > + * Set the indirectIO range directly here.
> > > > + */
> > > > + lpcdev->io_ops.start = 0;
> > > > + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > > > + lpcdev->io_ops.devpara = lpcdev;
> > > > + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > > > + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > > > + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > > > + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >
> > > I have to look at patch 2 in more detail again, after missing a few
> > > review
> > > rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> > > range here, and would hope that we can just go through the same
> > > assignment of logical port ranges that we have for PCI buses,
> > > decoupling
> > > the bus addresses from the linux-internal ones.
> >
> > The point here is that we want to avoid any conflict/overlap between
> > the LPC I/O space and the PCI I/O space. With the assignment above
> > we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Pedantically ISA starts at 0x100. The LPC may start at 0x00 as it also
covers motherboard devices (0x00-0xFF). It is also possible that the
'LPC' space is only partially routed to the PCI bridges because some if
it magially disappears on CPU die (at least on x86) and has done since
the era of socket 7 (eg the Cyrix 6x86 doesn't route 0x22/0x23 out of the
CPU).
Assuming LPC starts at 0 ought to be ok given the PCI root bridge
shouldn't see the transactions.
The LPC or it's equivalent may also not be routed via the PCI bridges at
all, so you could have an LPC mapping that is unused or partially used
with another bus actually getting some classes of LPC traffic - on x86 at
least.
Alan
^ permalink raw reply
* RE: [PATCH 4/5] megaraid_sas: scsi-mq support
From: Kashyap Desai @ 2016-11-14 11:07 UTC (permalink / raw)
To: Hannes Reinecke, Martin K. Petersen
Cc: Christoph Hellwig, James Bottomley, Sumit Saxena, linux-scsi,
Hannes Reinecke
In-Reply-To: <1478857492-4581-5-git-send-email-hare@suse.de>
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Hannes Reinecke
> Sent: Friday, November 11, 2016 3:15 PM
> To: Martin K. Petersen
> Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
> scsi@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
> Subject: [PATCH 4/5] megaraid_sas: scsi-mq support
>
> This patch enables full scsi multiqueue support. But as I have been
seeing
> performance regressions I've also added a module parameter 'use_blk_mq',
> allowing multiqueue to be switched off if required.
Hannes - As discussed for hpsa driver related thread for similar support,
I don't think this code changes are helping MR as well.
>
> Signed-off-by: Hannes Reinecke <hare@suse.com>
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 22 +++++++++++++++++
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 38
+++++++++++++++++++++----
> ----
> 2 files changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index d580406..1af47e6 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -48,6 +48,7 @@
> #include <linux/blkdev.h>
> #include <linux/mutex.h>
> #include <linux/poll.h>
> +#include <linux/blk-mq-pci.h>
>
> #include <scsi/scsi.h>
> #include <scsi/scsi_cmnd.h>
> @@ -104,6 +105,9 @@
> module_param(scmd_timeout, int, S_IRUGO);
> MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default
> 90s. See megasas_reset_timer.");
>
> +bool use_blk_mq = true;
> +module_param_named(use_blk_mq, use_blk_mq, bool, 0);
> +
> MODULE_LICENSE("GPL");
> MODULE_VERSION(MEGASAS_VERSION);
> MODULE_AUTHOR("megaraidlinux.pdl@avagotech.com");
> @@ -1882,6 +1886,17 @@ static void megasas_slave_destroy(struct
> scsi_device *sdev)
> sdev->hostdata = NULL;
> }
>
> +static int megasas_map_queues(struct Scsi_Host *shost) {
> + struct megasas_instance *instance = (struct megasas_instance *)
> + shost->hostdata;
> +
> + if (!instance->ctrl_context)
> + return 0;
> +
> + return blk_mq_pci_map_queues(&shost->tag_set, instance->pdev, 0);
}
> +
> /*
> * megasas_complete_outstanding_ioctls - Complete outstanding ioctls
after a
> * kill adapter
> @@ -2986,6 +3001,7 @@ struct device_attribute *megaraid_host_attrs[] = {
> .slave_configure = megasas_slave_configure,
> .slave_alloc = megasas_slave_alloc,
> .slave_destroy = megasas_slave_destroy,
> + .map_queues = megasas_map_queues,
> .queuecommand = megasas_queue_command,
> .eh_target_reset_handler = megasas_reset_target,
> .eh_abort_handler = megasas_task_abort, @@ -5610,6 +5626,12 @@
> static int megasas_io_attach(struct megasas_instance *instance)
> host->max_id = MEGASAS_MAX_DEV_PER_CHANNEL;
> host->max_lun = MEGASAS_MAX_LUN;
> host->max_cmd_len = 16;
> + host->nr_hw_queues = instance->msix_vectors ?
> + instance->msix_vectors : 1;
> + if (use_blk_mq) {
> + host->can_queue = instance->max_scsi_cmds / host-
> >nr_hw_queues;
> + host->use_blk_mq = 1;
> + }
>
> /*
> * Notify the mid-layer about the new controller diff --git
> a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index eb3cb0f..aba53c0 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -1703,6 +1703,7 @@ static int megasas_create_sg_sense_fusion(struct
> megasas_instance *instance)
> struct IO_REQUEST_INFO io_info;
> struct fusion_context *fusion;
> struct MR_DRV_RAID_MAP_ALL *local_map_ptr;
> + u16 msix_index;
> u8 *raidLUN;
>
> device_id = MEGASAS_DEV_INDEX(scp);
> @@ -1792,11 +1793,13 @@ static int megasas_create_sg_sense_fusion(struct
> megasas_instance *instance)
> fp_possible = io_info.fpOkForIo;
> }
>
> - /* Use raw_smp_processor_id() for now until cmd->request->cpu is
CPU
> - id by default, not CPU group id, otherwise all MSI-X queues
won't
> - be utilized */
> - cmd->request_desc->SCSIIO.MSIxIndex = instance->msix_vectors ?
> - raw_smp_processor_id() % instance->msix_vectors : 0;
> + if (shost_use_blk_mq(instance->host)) {
> + u32 blk_tag = blk_mq_unique_tag(scp->request);
> + msix_index = blk_mq_unique_tag_to_hwq(blk_tag);
> + } else
> + msix_index = instance->msix_vectors ?
> + raw_smp_processor_id() % instance->msix_vectors :
0;
> + cmd->request_desc->SCSIIO.MSIxIndex = msix_index;
>
> if (fp_possible) {
> megasas_set_pd_lba(io_request, scp->cmd_len, &io_info,
scp,
> @@ -1971,6 +1974,7 @@ static void megasas_build_ld_nonrw_fusion(struct
> megasas_instance *instance,
> struct RAID_CONTEXT *pRAID_Context;
> struct MR_PD_CFG_SEQ_NUM_SYNC *pd_sync;
> struct fusion_context *fusion = instance->ctrl_context;
> + u16 msix_index;
> pd_sync = (void *)fusion->pd_seq_sync[(instance->pd_seq_map_id -
1)
> & 1];
>
> device_id = MEGASAS_DEV_INDEX(scmd);
> @@ -2013,11 +2017,14 @@ static void megasas_build_ld_nonrw_fusion(struct
> megasas_instance *instance,
> io_request->DevHandle = cpu_to_le16(0xFFFF);
> }
>
> + if (shost_use_blk_mq(instance->host)) {
> + u32 blk_tag = blk_mq_unique_tag(scmd->request);
> + msix_index = blk_mq_unique_tag_to_hwq(blk_tag);
> + } else
> + msix_index = instance->msix_vectors ?
> + (raw_smp_processor_id() % instance->msix_vectors)
:
> 0;
> + cmd->request_desc->SCSIIO.MSIxIndex = msix_index;
> cmd->request_desc->SCSIIO.DevHandle = io_request->DevHandle;
> - cmd->request_desc->SCSIIO.MSIxIndex =
> - instance->msix_vectors ?
> - (raw_smp_processor_id() % instance->msix_vectors) : 0;
> -
>
> if (!fp_possible) {
> /* system pd firmware path */
> @@ -2188,7 +2195,18 @@ static void megasas_build_ld_nonrw_fusion(struct
> megasas_instance *instance,
> return SCSI_MLQUEUE_DEVICE_BUSY;
> }
>
> - cmd = megasas_get_cmd_fusion(instance, scmd->request->tag);
> + if (shost_use_blk_mq(instance->host)) {
> + int msix_vectors, hwq_size;
> + u32 blk_tag = blk_mq_unique_tag(scmd->request);
> + u16 hwq = blk_mq_unique_tag_to_hwq(blk_tag);
> + u16 tag = blk_mq_unique_tag_to_tag(blk_tag);
> +
> + msix_vectors = instance->msix_vectors ?
> + instance->msix_vectors : 1;
> + hwq_size = instance->max_scsi_cmds / msix_vectors;
> + cmd = megasas_get_cmd_fusion(instance, (hwq * hwq_size) +
> tag);
> + } else
> + cmd = megasas_get_cmd_fusion(instance, scmd->request-
> >tag);
>
> index = cmd->index;
>
> --
> 1.8.5.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
> a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/2] arm64: Support systems without FP/ASIMD
From: Catalin Marinas @ 2016-11-14 11:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: ard.biesheuvel, will.deacon, linux-kernel, kvmarm,
linux-arm-kernel
In-Reply-To: <d9b41cca-9a9c-ab92-d3e5-ee1870bb70d4@arm.com>
On Fri, Nov 11, 2016 at 01:41:37PM +0000, Marc Zyngier wrote:
> On 08/11/16 13:56, Suzuki K Poulose wrote:
> > This series adds supports to the kernel and KVM hyp to handle
> > systems without FP/ASIMD properly. At the moment the kernel
> > doesn't check if the FP unit is available before accessing
> > the registers (e.g during context switch). Also for KVM,
> > we trap the FP/ASIMD accesses and handle it by injecting an
> > undefined instruction into the VM on systems without FP.
> >
> > Tested on a FVP_Base-AEM-v8A model by disabling VFP on at
> > least one CPU ( -C clusterX.cpuY.vfp-present=0 ).
> >
> > Changes since V2:
> > - Dropped cleanup patch for arm64/crypto/aes-ce-ccm-glue.c
> > - Removed static_key check from cpus_have_cap. All users with
> > constant caps should use the new API to make use of static_keys.
> > - Removed a dedicated static_key used in irqchip-gic-v3.c for
> > Cavium errata with the new API.
> >
> > Applies on v4.9-rc4 + [1] (which is pushed for rc5)
> >
> > [1] http://marc.info/?l=linux-arm-kernel&m=147819889813214&w=2
> >
> >
> > Suzuki K Poulose (2):
> > arm64: Add hypervisor safe helper for checking constant capabilities
> > arm64: Support systems without FP/ASIMD
> >
> > arch/arm64/include/asm/cpucaps.h | 3 ++-
> > arch/arm64/include/asm/cpufeature.h | 24 +++++++++++++++++-------
> > arch/arm64/include/asm/neon.h | 3 ++-
> > arch/arm64/kernel/cpufeature.c | 17 ++++++++++++++++-
> > arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++
> > arch/arm64/kernel/process.c | 2 +-
> > arch/arm64/kvm/handle_exit.c | 11 +++++++++++
> > arch/arm64/kvm/hyp/hyp-entry.S | 9 ++++++++-
> > arch/arm64/kvm/hyp/switch.c | 5 ++++-
> > drivers/irqchip/irq-gic-v3.c | 13 +------------
> > 10 files changed, 76 insertions(+), 25 deletions(-)
>
> For the series:
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
> How do we plan on merging this? Catalin, are you willing to take it all?
Happy to take it all through the arm64 tree. Thanks for the review.
--
Catalin
^ permalink raw reply
* Configuration of cq->cqe is lower than entries by 1
From: Amrani, Ram @ 2016-11-14 11:07 UTC (permalink / raw)
To: Leon Romanovsky,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi Leon, All,
While inspecting MLX code as well as other vendors' I see that the actual number of cq->cqe is configured to be less by 1 than 'entries'. Why is that?
e.g.
struct ib_cq *mlx4_ib_create_cq(struct ib_device *ibdev,
const struct ib_cq_init_attr *attr,
struct ib_ucontext *context,
struct ib_udata *udata)
{
...
cq->ibcq.cqe = entries - 1;
...
}
static int mlx4_alloc_resize_buf(struct mlx4_ib_dev *dev, struct mlx4_ib_cq *cq,
int entries)
{
...
cq->resize_buf->cqe = entries - 1; // this is later copied to cq->ibcq.cqe
...
}
Thanks,
Ram
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: One Thousand Gnomes @ 2016-11-14 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
On Wed, 09 Nov 2016 22:34:38 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> > > On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > > > + /*
> > > > + * The first PCIBIOS_MIN_IO is reserved specifically for
> > > indirectIO.
> > > > + * It will separate indirectIO range from pci host bridge to
> > > > + * avoid the possible PIO conflict.
> > > > + * Set the indirectIO range directly here.
> > > > + */
> > > > + lpcdev->io_ops.start = 0;
> > > > + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > > > + lpcdev->io_ops.devpara = lpcdev;
> > > > + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > > > + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > > > + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > > > + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >
> > > I have to look at patch 2 in more detail again, after missing a few
> > > review
> > > rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> > > range here, and would hope that we can just go through the same
> > > assignment of logical port ranges that we have for PCI buses,
> > > decoupling
> > > the bus addresses from the linux-internal ones.
> >
> > The point here is that we want to avoid any conflict/overlap between
> > the LPC I/O space and the PCI I/O space. With the assignment above
> > we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Pedantically ISA starts at 0x100. The LPC may start at 0x00 as it also
covers motherboard devices (0x00-0xFF). It is also possible that the
'LPC' space is only partially routed to the PCI bridges because some if
it magially disappears on CPU die (at least on x86) and has done since
the era of socket 7 (eg the Cyrix 6x86 doesn't route 0x22/0x23 out of the
CPU).
Assuming LPC starts at 0 ought to be ok given the PCI root bridge
shouldn't see the transactions.
The LPC or it's equivalent may also not be routed via the PCI bridges at
all, so you could have an LPC mapping that is unused or partially used
with another bus actually getting some classes of LPC traffic - on x86 at
least.
Alan
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: One Thousand Gnomes @ 2016-11-14 11:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gabriele Paoloni, Yuanzhichang,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org, John Garry,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xuwei (O),
Linuxarm, olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
On Wed, 09 Nov 2016 22:34:38 +0100
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> > > On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > > > + /*
> > > > + * The first PCIBIOS_MIN_IO is reserved specifically for
> > > indirectIO.
> > > > + * It will separate indirectIO range from pci host bridge to
> > > > + * avoid the possible PIO conflict.
> > > > + * Set the indirectIO range directly here.
> > > > + */
> > > > + lpcdev->io_ops.start = 0;
> > > > + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > > > + lpcdev->io_ops.devpara = lpcdev;
> > > > + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > > > + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > > > + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > > > + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >
> > > I have to look at patch 2 in more detail again, after missing a few
> > > review
> > > rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> > > range here, and would hope that we can just go through the same
> > > assignment of logical port ranges that we have for PCI buses,
> > > decoupling
> > > the bus addresses from the linux-internal ones.
> >
> > The point here is that we want to avoid any conflict/overlap between
> > the LPC I/O space and the PCI I/O space. With the assignment above
> > we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Pedantically ISA starts at 0x100. The LPC may start at 0x00 as it also
covers motherboard devices (0x00-0xFF). It is also possible that the
'LPC' space is only partially routed to the PCI bridges because some if
it magially disappears on CPU die (at least on x86) and has done since
the era of socket 7 (eg the Cyrix 6x86 doesn't route 0x22/0x23 out of the
CPU).
Assuming LPC starts at 0 ought to be ok given the PCI root bridge
shouldn't see the transactions.
The LPC or it's equivalent may also not be routed via the PCI bridges at
all, so you could have an LPC mapping that is unused or partially used
with another bus actually getting some classes of LPC traffic - on x86 at
least.
Alan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] vfs: fix statfs64() does not handle errors
From: Li Wang @ 2016-11-14 10:59 UTC (permalink / raw)
To: Andreas Dilger; +Cc: viro, linux-fsdevel, linux-kernel
In-Reply-To: <6D8E6AD1-CE9D-4578-A508-8FCD4C97C6BE@dilger.ca>
On Mon, Nov 07, 2016 at 11:03:11AM -0700, Andreas Dilger wrote:
> On Nov 7, 2016, at 3:21 AM, Li Wang <liwang@redhat.com> wrote:
> >
> > statfs64() does NOT return -1 and setting errno to EOVERFLOW when some
> > variables(like: f_bsize) overflowed in the returned struct.
> >
> > reproducer:
> > step1. mount hugetlbfs with two different pagesize on ppc64 arch.
> >
> > $ hugeadm --pool-pages-max 16M:0
> > $ hugeadm --create-mount
> > $ mount | grep -i hugetlbfs
> > none on /var/lib/hugetlbfs/pagesize-16MB type hugetlbfs (rw,relatime,seclabel,pagesize=16777216)
> > none on /var/lib/hugetlbfs/pagesize-16GB type hugetlbfs (rw,relatime,seclabel,pagesize=17179869184)
> >
> > step2. compile & run this C program.
> >
> > $ cat statfs64_test.c
> >
> > #define _LARGEFILE64_SOURCE
> > #include <stdio.h>
> > #include <sys/statfs.h>
> >
> > int main()
> > {
> > struct statfs64 sb;
> > int err;
> >
> > err = statfs64("/var/lib/hugetlbfs/pagesize-16GB", &sb);
> > if (err)
> > return -1;
> >
> > printf("sizeof f_bsize = %d, f_bsize=%ld\n", sizeof(sb.f_bsize), sb.f_bsize);
> >
> > return 0;
> > }
> >
> > $ gcc -m32 statfs64_test.c
> > $ ./a.out
> > sizeof f_bsize = 4, f_bsize=0
> >
> > Signed-off-by: Li Wang <liwang@redhat.com>
> > ---
> >
> > Notes:
> > This is my first patch to kernel fs part, I'm not sure if
> > this one useful, but just want someone have a look.
> >
> > thanks~
> >
> > fs/statfs.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/fs/statfs.c b/fs/statfs.c
> > index 083dc0a..849dde95 100644
> > --- a/fs/statfs.c
> > +++ b/fs/statfs.c
> > @@ -151,6 +151,23 @@ static int do_statfs64(struct kstatfs *st, struct statfs64 __user *p)
> > if (sizeof(buf) == sizeof(*st))
> > memcpy(&buf, st, sizeof(*st));
> > else {
> > + if (sizeof buf.f_bsize == 4) {
>
> Linux CodingStyle says this should be used like sizeof(buf.f_bsize).
agree.
>
> > + if ((st->f_blocks | st->f_bfree | st->f_bavail |
> > + st->f_bsize | st->f_frsize) &
> > + 0xffffffff00000000ULL)
> > + return -EOVERFLOW;
>
> I'm not sure I agree with this check. Sure, if sizeof(buf.f_bsize) == 4
> then the large st->f_bsize will overflow this field, and that is valid.
After thinking over, I feel that my fix in this patch is not right.
The reproducer.c running on ppc64 arch was build in 32bit, but it does
not call SYS_statfs64 in kernel. It calls compat_sys_statfs64 indeed.
# cat reproducer.c
#define _LARGEFILE64_SOURCE
#include <stdio.h>
#include <sys/statfs.h>
#include <sys/syscall.h>
int main()
{
struct statfs64 sb;
int err;
err = syscall(SYS_statfs64, "/var/lib/hugetlbfs/pagesize-16GB", sizeof(sb), &sb);
if (err)
return -1;
printf("sizeof f_bsize = %d, f_bsize=%ld\n", sizeof(sb.f_bsize), sb.f_bsize);
return 0;
}
# gcc reproducer.c -m32
# stap -e 'probe kernel.function("compat_sys_statfs64") {printf ("%s",
$$parms);}' -vvv &
# ./a.out
sizeof f_bsize = 4, f_bsize=0
# pathname=0x100006c4 sz=0x58 buf=0xff8a20b0
Guess the fix should be like:
diff --git a/fs/compat.c b/fs/compat.c
index bd064a2..3d923fd 100644
--- a/fs/compat.c
+++ b/fs/compat.c
@@ -253,7 +253,7 @@ static int put_compat_statfs(struct compat_statfs __user *ubuf, struct kstatfs *
static int put_compat_statfs64(struct compat_statfs64 __user *ubuf,
struct kstatfs *kbuf)
{
- if (sizeof ubuf->f_blocks == 4) {
+ if (sizeof ubuf->f_bsize == 4) {
if ((kbuf->f_blocks | kbuf->f_bfree | kbuf->f_bavail |
kbuf->f_bsize | kbuf->f_frsize) & 0xffffffff00000000ULL)
return -EOVERFLOW;
I will test it and send a new patch.
Regards,
Li Wang
>
> However, that doesn't mean that large values for f_blocks, f_bfree, f_bavail
> should return an error. I assume you are concerned that the product of the
> large f_bsize and one of those values would overflow a 64-bit bytes value,
> but that is for userspace to worry about, since the values in the individual
> fields themselves are OK.
>
> We're already over 100PiB Lustre filesystems (2^57 bytes) today, and I
> don't want statfs() failing prematurely because userspace feels the need
> to multiply out the blocks and blocksize into bytes, instead of shifting
> the values to KB (which would allow filesystems up to 2^74-1024 bytes to
> be handled correctly in userspace).
>
> > + /*
> > + * f_files and f_ffree may be -1; it's okay to stuff
> > + * that into 32 bits
> > + */
> > + if (st->f_files != -1 &&
> > + (st->f_files & 0xffffffff00000000ULL))
> > + return -EOVERFLOW;
>
> > + if (st->f_ffree != -1 &&
> > + (st->f_ffree & 0xffffffff00000000ULL))
> > + return -EOVERFLOW;
>
> Why does sizeof(f_bsize) have anything to do with the number of free files?
> These two checks are just plain wrong, since f_files and f_ffree are 64-bit
> fields in struct statfs64.
right.
>
> Cheers, Andreas
>
> > + }
> > +
> > buf.f_type = st->f_type;
> > buf.f_bsize = st->f_bsize;
> > buf.f_blocks = st->f_blocks;
> > --
> > 1.8.3.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Cheers, Andreas
>
>
>
>
>
^ permalink raw reply related
* [PATCH v2] f2fs: don't wait writeback for datas during checkpoint
From: Chao Yu @ 2016-11-14 11:04 UTC (permalink / raw)
To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu
Normally, while committing checkpoint, we will wait on all pages to be
writebacked no matter the page is data or metadata, so in scenario where
there are lots of data IO being submitted with metadata, we may suffer
long latency for waiting writeback during checkpoint.
Indeed, we only care about persistence for pages with metadata, but not
pages with data, as file system consistent are only related to metadate,
so in order to avoid encountering long latency in above scenario, let's
recognize and reference metadata in submitted IOs, wait writeback only
for metadatas.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
fs/f2fs/checkpoint.c | 2 +-
fs/f2fs/data.c | 36 ++++++++++++++++++++++++++++++++----
fs/f2fs/debug.c | 7 ++++---
fs/f2fs/f2fs.h | 8 +++++---
4 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 7bece59..bdf8a50 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1003,7 +1003,7 @@ static void wait_on_all_pages_writeback(struct f2fs_sb_info *sbi)
for (;;) {
prepare_to_wait(&sbi->cp_wait, &wait, TASK_UNINTERRUPTIBLE);
- if (!atomic_read(&sbi->nr_wb_bios))
+ if (!get_pages(sbi, F2FS_WB_META))
break;
io_schedule_timeout(5*HZ);
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 66d2aee..f52cec3 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -29,6 +29,26 @@
#include "trace.h"
#include <trace/events/f2fs.h>
+static bool f2fs_is_meta_data(struct page *page)
+{
+ struct address_space *mapping = page->mapping;
+ struct f2fs_sb_info *sbi;
+ struct inode *inode;
+
+ /* it is bounce page of encrypted regular inode */
+ if (!mapping)
+ return false;
+
+ inode = mapping->host;
+ sbi = F2FS_I_SB(inode);
+
+ if ((inode->i_ino == F2FS_META_INO(sbi) &&
+ page->index < MAIN_BLKADDR(sbi)) ||
+ inode->i_ino == F2FS_NODE_INO(sbi) ||
+ S_ISDIR(inode->i_mode))
+ return true;
+ return false;
+}
static void f2fs_read_end_io(struct bio *bio)
{
struct bio_vec *bvec;
@@ -73,6 +93,7 @@ static void f2fs_write_end_io(struct bio *bio)
bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
+ bool is_meta = f2fs_is_meta_data(page);
fscrypt_pullback_bio_page(&page, true);
@@ -80,9 +101,10 @@ static void f2fs_write_end_io(struct bio *bio)
mapping_set_error(page->mapping, -EIO);
f2fs_stop_checkpoint(sbi, true);
}
+ dec_page_count(sbi, is_meta ? F2FS_WB_META : F2FS_WB_DATA);
end_page_writeback(page);
}
- if (atomic_dec_and_test(&sbi->nr_wb_bios) &&
+ if (!get_pages(sbi, F2FS_WB_META) &&
wq_has_sleeper(&sbi->cp_wait))
wake_up(&sbi->cp_wait);
@@ -111,7 +133,6 @@ static inline void __submit_bio(struct f2fs_sb_info *sbi,
struct bio *bio, enum page_type type)
{
if (!is_read_io(bio_op(bio))) {
- atomic_inc(&sbi->nr_wb_bios);
if (f2fs_sb_mounted_blkzoned(sbi->sb) &&
current->plug && (type == DATA || type == NODE))
blk_finish_plug(current->plug);
@@ -272,6 +293,15 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
verify_block_addr(sbi, fio->old_blkaddr);
verify_block_addr(sbi, fio->new_blkaddr);
+ bio_page = fio->encrypted_page ? fio->encrypted_page : fio->page;
+
+ if (!is_read) {
+ bool is_meta;
+
+ is_meta = f2fs_is_meta_data(bio_page);
+ inc_page_count(sbi, is_meta ? F2FS_WB_META : F2FS_WB_DATA);
+ }
+
down_write(&io->io_rwsem);
if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
@@ -284,8 +314,6 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
io->fio = *fio;
}
- bio_page = fio->encrypted_page ? fio->encrypted_page : fio->page;
-
if (bio_add_page(io->bio, bio_page, PAGE_SIZE, 0) <
PAGE_SIZE) {
__submit_merged_bio(io);
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 2fdf233..f2d87de 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -50,7 +50,8 @@ static void update_general_status(struct f2fs_sb_info *sbi)
si->ndirty_files = sbi->ndirty_inode[FILE_INODE];
si->ndirty_all = sbi->ndirty_inode[DIRTY_META];
si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
- si->wb_bios = atomic_read(&sbi->nr_wb_bios);
+ si->nr_wb_meta = get_pages(sbi, F2FS_WB_META);
+ si->nr_wb_data = get_pages(sbi, F2FS_WB_DATA);
si->total_count = (int)sbi->user_block_count / sbi->blocks_per_seg;
si->rsvd_segs = reserved_segments(sbi);
si->overp_segs = overprovision_segments(sbi);
@@ -313,8 +314,8 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, " - Inner Struct Count: tree: %d(%d), node: %d\n",
si->ext_tree, si->zombie_tree, si->ext_node);
seq_puts(s, "\nBalancing F2FS Async:\n");
- seq_printf(s, " - inmem: %4d, wb_bios: %4d\n",
- si->inmem_pages, si->wb_bios);
+ seq_printf(s, " - inmem: %4d, wb_meta: %4d, wb_data: %4d\n",
+ si->inmem_pages, si->nr_wb_meta, si->nr_wb_data);
seq_printf(s, " - nodes: %4d in %4d\n",
si->ndirty_node, si->node_pages);
seq_printf(s, " - dents: %4d in dirs:%4d (%4d)\n",
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 23a937f..4df301c 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -682,6 +682,8 @@ enum count_type {
F2FS_DIRTY_META,
F2FS_INMEM_PAGES,
F2FS_DIRTY_IMETA,
+ F2FS_WB_META,
+ F2FS_WB_DATA,
NR_COUNT_TYPE,
};
@@ -849,7 +851,6 @@ struct f2fs_sb_info {
block_t discard_blks; /* discard command candidats */
block_t last_valid_block_count; /* for recovery */
u32 s_next_generation; /* for NFS support */
- atomic_t nr_wb_bios; /* # of writeback bios */
/* # of pages, see count_type */
atomic_t nr_pages[NR_COUNT_TYPE];
@@ -1263,7 +1264,8 @@ static inline void inc_page_count(struct f2fs_sb_info *sbi, int count_type)
{
atomic_inc(&sbi->nr_pages[count_type]);
- if (count_type == F2FS_DIRTY_DATA || count_type == F2FS_INMEM_PAGES)
+ if (count_type == F2FS_DIRTY_DATA || count_type == F2FS_INMEM_PAGES ||
+ count_type == F2FS_WB_META || count_type == F2FS_WB_DATA)
return;
set_sbi_flag(sbi, SBI_IS_DIRTY);
@@ -2219,7 +2221,7 @@ struct f2fs_stat_info {
unsigned int ndirty_dirs, ndirty_files, ndirty_all;
int nats, dirty_nats, sits, dirty_sits, free_nids, alloc_nids;
int total_count, utilization;
- int bg_gc, wb_bios;
+ int bg_gc, nr_wb_meta, nr_wb_data;
int inline_xattr, inline_inode, inline_dir, orphans;
unsigned int valid_count, valid_node_count, valid_inode_count, discard_blks;
unsigned int bimodal, avg_vblocks;
--
2.8.2.311.gee88674
^ permalink raw reply related
* RE: [PATCH] hpsa: scsi-mq support
From: Kashyap Desai @ 2016-11-14 11:05 UTC (permalink / raw)
To: Christoph Hellwig, Hannes Reinecke
Cc: Christoph Hellwig, Hannes Reinecke, Martin K. Petersen,
James Bottomley, Don Brace, linux-scsi, Jens Axboe
In-Reply-To: <20161113115841.GA4818@lst.de>
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Sunday, November 13, 2016 5:29 PM
> To: Hannes Reinecke
> Cc: Christoph Hellwig; Hannes Reinecke; Christoph Hellwig; Martin K.
Petersen;
> James Bottomley; Don Brace; linux-scsi@vger.kernel.org; Jens Axboe
> Subject: Re: [PATCH] hpsa: scsi-mq support
>
> On Sun, Nov 13, 2016 at 10:44:47AM +0100, Hannes Reinecke wrote:
> > One day to mark with bright red in the calendar.
> >
> > Christoph Hellwig is telling me _NOT_ to use scsi-mq.
>
> That's not what I'm doing.
>
> > This patch was done so see what would needed to be done to convert a
> > legacy driver.
> > As I was under the impression that scsi-mq is the way forward, seeing
> > that it should be enabled per default.
> > But I must have been mistaken. Apparently.
>
> What I am doing is to tell you you should not expose multiple queues
unless the
> hardware actually has multiple submissions queues. The blk-mq and
scsi-mq
> code works just fine with a single submission queue, and the hpsa driver
in
> particular works really well with scsi-mq and a single submission queue.
E.g. the
> RAID HBA on slide 19 of this presentations is an hpsa one:
I have similar results for MegaRaid where seen MR driver gives significant
improvement for Single Submission Queue and multiple Completion Queue.
Having said that scsi-mq is enabled but with single Queue is more than
enough to maximize improvement of SCSI-MQ.
Major advantage was seen while IO load is cross the boundary of Physical
CPU socket.
>From this discussion I understood that - Similar logical changes proposed
for megaraid_sas and we are not really going to gain with fake multiple
submission exposed to SML.
Kashyap
>
> http://events.linuxfoundation.org/sites/events/files/slides/scsi.pdf
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
> a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Buildroot] [PATCH v2] htop: enable unicode if possible
From: Jérôme Pouiller @ 2016-11-14 11:04 UTC (permalink / raw)
To: buildroot
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/htop/htop.mk | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
v2:
- explicitily enable unicode
diff --git a/package/htop/htop.mk b/package/htop/htop.mk
index 7409a78..af0f66b 100644
--- a/package/htop/htop.mk
+++ b/package/htop/htop.mk
@@ -7,10 +7,15 @@
HTOP_VERSION = 2.0.2
HTOP_SITE = http://hisham.hm/htop/releases/$(HTOP_VERSION)
HTOP_DEPENDENCIES = ncurses
-HTOP_CONF_OPTS = --disable-unicode
# Prevent htop build system from searching the host paths
HTOP_CONF_ENV = HTOP_NCURSES_CONFIG_SCRIPT=$(STAGING_DIR)/usr/bin/ncurses5-config
HTOP_LICENSE = GPLv2
HTOP_LICENSE_FILES = COPYING
+ifeq ($(BR2_PACKAGE_NCURSES_WCHAR),)
+HTOP_CONF_OPTS = --disable-unicode
+else
+HTOP_CONF_OPTS = --enable-unicode
+endif
+
$(eval $(autotools-package))
--
2.9.3
^ permalink raw reply related
* [PATCH v2] f2fs: don't wait writeback for datas during checkpoint
From: Chao Yu @ 2016-11-14 11:04 UTC (permalink / raw)
To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu
Normally, while committing checkpoint, we will wait on all pages to be
writebacked no matter the page is data or metadata, so in scenario where
there are lots of data IO being submitted with metadata, we may suffer
long latency for waiting writeback during checkpoint.
Indeed, we only care about persistence for pages with metadata, but not
pages with data, as file system consistent are only related to metadate,
so in order to avoid encountering long latency in above scenario, let's
recognize and reference metadata in submitted IOs, wait writeback only
for metadatas.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
fs/f2fs/checkpoint.c | 2 +-
fs/f2fs/data.c | 36 ++++++++++++++++++++++++++++++++----
fs/f2fs/debug.c | 7 ++++---
fs/f2fs/f2fs.h | 8 +++++---
4 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 7bece59..bdf8a50 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1003,7 +1003,7 @@ static void wait_on_all_pages_writeback(struct f2fs_sb_info *sbi)
for (;;) {
prepare_to_wait(&sbi->cp_wait, &wait, TASK_UNINTERRUPTIBLE);
- if (!atomic_read(&sbi->nr_wb_bios))
+ if (!get_pages(sbi, F2FS_WB_META))
break;
io_schedule_timeout(5*HZ);
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 66d2aee..f52cec3 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -29,6 +29,26 @@
#include "trace.h"
#include <trace/events/f2fs.h>
+static bool f2fs_is_meta_data(struct page *page)
+{
+ struct address_space *mapping = page->mapping;
+ struct f2fs_sb_info *sbi;
+ struct inode *inode;
+
+ /* it is bounce page of encrypted regular inode */
+ if (!mapping)
+ return false;
+
+ inode = mapping->host;
+ sbi = F2FS_I_SB(inode);
+
+ if ((inode->i_ino == F2FS_META_INO(sbi) &&
+ page->index < MAIN_BLKADDR(sbi)) ||
+ inode->i_ino == F2FS_NODE_INO(sbi) ||
+ S_ISDIR(inode->i_mode))
+ return true;
+ return false;
+}
static void f2fs_read_end_io(struct bio *bio)
{
struct bio_vec *bvec;
@@ -73,6 +93,7 @@ static void f2fs_write_end_io(struct bio *bio)
bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
+ bool is_meta = f2fs_is_meta_data(page);
fscrypt_pullback_bio_page(&page, true);
@@ -80,9 +101,10 @@ static void f2fs_write_end_io(struct bio *bio)
mapping_set_error(page->mapping, -EIO);
f2fs_stop_checkpoint(sbi, true);
}
+ dec_page_count(sbi, is_meta ? F2FS_WB_META : F2FS_WB_DATA);
end_page_writeback(page);
}
- if (atomic_dec_and_test(&sbi->nr_wb_bios) &&
+ if (!get_pages(sbi, F2FS_WB_META) &&
wq_has_sleeper(&sbi->cp_wait))
wake_up(&sbi->cp_wait);
@@ -111,7 +133,6 @@ static inline void __submit_bio(struct f2fs_sb_info *sbi,
struct bio *bio, enum page_type type)
{
if (!is_read_io(bio_op(bio))) {
- atomic_inc(&sbi->nr_wb_bios);
if (f2fs_sb_mounted_blkzoned(sbi->sb) &&
current->plug && (type == DATA || type == NODE))
blk_finish_plug(current->plug);
@@ -272,6 +293,15 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
verify_block_addr(sbi, fio->old_blkaddr);
verify_block_addr(sbi, fio->new_blkaddr);
+ bio_page = fio->encrypted_page ? fio->encrypted_page : fio->page;
+
+ if (!is_read) {
+ bool is_meta;
+
+ is_meta = f2fs_is_meta_data(bio_page);
+ inc_page_count(sbi, is_meta ? F2FS_WB_META : F2FS_WB_DATA);
+ }
+
down_write(&io->io_rwsem);
if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
@@ -284,8 +314,6 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
io->fio = *fio;
}
- bio_page = fio->encrypted_page ? fio->encrypted_page : fio->page;
-
if (bio_add_page(io->bio, bio_page, PAGE_SIZE, 0) <
PAGE_SIZE) {
__submit_merged_bio(io);
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 2fdf233..f2d87de 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -50,7 +50,8 @@ static void update_general_status(struct f2fs_sb_info *sbi)
si->ndirty_files = sbi->ndirty_inode[FILE_INODE];
si->ndirty_all = sbi->ndirty_inode[DIRTY_META];
si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
- si->wb_bios = atomic_read(&sbi->nr_wb_bios);
+ si->nr_wb_meta = get_pages(sbi, F2FS_WB_META);
+ si->nr_wb_data = get_pages(sbi, F2FS_WB_DATA);
si->total_count = (int)sbi->user_block_count / sbi->blocks_per_seg;
si->rsvd_segs = reserved_segments(sbi);
si->overp_segs = overprovision_segments(sbi);
@@ -313,8 +314,8 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, " - Inner Struct Count: tree: %d(%d), node: %d\n",
si->ext_tree, si->zombie_tree, si->ext_node);
seq_puts(s, "\nBalancing F2FS Async:\n");
- seq_printf(s, " - inmem: %4d, wb_bios: %4d\n",
- si->inmem_pages, si->wb_bios);
+ seq_printf(s, " - inmem: %4d, wb_meta: %4d, wb_data: %4d\n",
+ si->inmem_pages, si->nr_wb_meta, si->nr_wb_data);
seq_printf(s, " - nodes: %4d in %4d\n",
si->ndirty_node, si->node_pages);
seq_printf(s, " - dents: %4d in dirs:%4d (%4d)\n",
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 23a937f..4df301c 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -682,6 +682,8 @@ enum count_type {
F2FS_DIRTY_META,
F2FS_INMEM_PAGES,
F2FS_DIRTY_IMETA,
+ F2FS_WB_META,
+ F2FS_WB_DATA,
NR_COUNT_TYPE,
};
@@ -849,7 +851,6 @@ struct f2fs_sb_info {
block_t discard_blks; /* discard command candidats */
block_t last_valid_block_count; /* for recovery */
u32 s_next_generation; /* for NFS support */
- atomic_t nr_wb_bios; /* # of writeback bios */
/* # of pages, see count_type */
atomic_t nr_pages[NR_COUNT_TYPE];
@@ -1263,7 +1264,8 @@ static inline void inc_page_count(struct f2fs_sb_info *sbi, int count_type)
{
atomic_inc(&sbi->nr_pages[count_type]);
- if (count_type == F2FS_DIRTY_DATA || count_type == F2FS_INMEM_PAGES)
+ if (count_type == F2FS_DIRTY_DATA || count_type == F2FS_INMEM_PAGES ||
+ count_type == F2FS_WB_META || count_type == F2FS_WB_DATA)
return;
set_sbi_flag(sbi, SBI_IS_DIRTY);
@@ -2219,7 +2221,7 @@ struct f2fs_stat_info {
unsigned int ndirty_dirs, ndirty_files, ndirty_all;
int nats, dirty_nats, sits, dirty_sits, free_nids, alloc_nids;
int total_count, utilization;
- int bg_gc, wb_bios;
+ int bg_gc, nr_wb_meta, nr_wb_data;
int inline_xattr, inline_inode, inline_dir, orphans;
unsigned int valid_count, valid_node_count, valid_inode_count, discard_blks;
unsigned int bimodal, avg_vblocks;
--
2.8.2.311.gee88674
^ permalink raw reply related
* Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods
From: Hans de Goede @ 2016-11-14 11:04 UTC (permalink / raw)
To: Frank Rowand, Rob Herring, Pantelis Antoniou
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <582968FA.4020800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On 14-11-16 08:34, Frank Rowand wrote:
> Hi Hans, Pantelis,
>
> On 11/12/16 18:15, Frank Rowand wrote:
>> On 11/04/16 07:42, Hans de Goede wrote:
>>> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>
>>> Changesets are very powerful, but the lack of a helper API
>>> makes using them cumbersome. Introduce a simple copy based
>>> API that makes things considerably easier.
>>>
>>> To wit, adding a property using the raw API.
>>>
>>> struct property *prop;
>>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>> prop->name = kstrdup("compatible");
>>> prop->value = kstrdup("foo,bar");
>>> prop->length = strlen(prop->value) + 1;
>>> of_changeset_add_property(ocs, np, prop);
>>>
>>> while using the helper API
>>>
>>> of_changeset_add_property_string(ocs, np, "compatible",
>>> "foo,bar");
>>>
>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> Changes in v2 (hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>>> -Address review comments from:
>>> https://www.spinics.net/lists/kernel/msg2252845.html
>>
>> That points to the May 9 version 1 patches from Pantelis (as expected),
>> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4
>> seems to have disappeared?
>>
>> Pantelis then sent a version 2 set of the patches on May 16.
>>
>> Your version is a modification of the May 9 patches (as would be expected
>> of a version 2). It is confusing to have two different version 2 patch
>> sets. I don't have any brilliant ideas on how this patch set could have
>> been named differently to avoid that confusion.
>>
>> The point of this little side-track is simply to note the existence of two
>> different version 2 series so I won't be confused when I revisit this
>> thread in the future.
>>
>>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling
>>> -Remove (by manual inlining) these 2 static helpers:
>>> __of_changeset_add_update_property_u32
>>> __of_changeset_add_update_property_bool
>>> -Remove the following exported helper method:
>>> of_changeset_node_move_to
>>
>> Not all comments were addressed.
>>
>> There are some other changes made that are not noted in the changelog.
>>
>> I am still reading through the patches. I will reply again either with
>> a reviewed-by or specific comments when I finish.
>
> Replying here for the entire patchset (there was no patch 0 to reply to).
>
> After reading through the patches, my reply is meta instead of specific
> comments about the code.
>
> There are very few users of change sets in tree. I do not see the need to
> add these helpers until such users are likely to appear.
>
> I would expect change sets to be _mostly_ used internally by the device tree
> overlay framework, not directly by drivers. If change sets are an attractive
> technology for drivers, I want to approach that usage very carefully to avoid
> inappropriate use, which could be very difficult to reign in after the fact.
>
> Even if helpers should be added, this seems to be an overly complex approach.
> If the need for these helpers becomes apparent I can provide review comments
> with the specifics about how it appears to be overly complex.
>
> Can you please provide some more insights into the needs driving the desire
> to have change set helpers and the expected use cases of them? Please put
> your architect's hat on when replying to this question.
My use case for this is discussed in this thread:
https://www.spinics.net/lists/arm-kernel/msg536111.html
With the dt-bindings for the hardware-manager I want to add here:
https://www.spinics.net/lists/arm-kernel/msg536109.html
Note that there is a lot of discussion in this thread whether or
not this belongs in the kernel. I strongly believe though that
some functionality like this will be needed in the kernel for
ARM+dt devices going forward, just like there is plenty of x86
code which adjusts itself to specific hardware, because whether
we like it or not hardware (revisions) will always have quirks.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net/phy: add trace events for mdio accesses
From: Uwe Kleine-König @ 2016-11-14 11:03 UTC (permalink / raw)
To: Florian Fainelli, Steven Rostedt, Ingo Molnar; +Cc: netdev
Make it possible to generate trace events for mdio read and write accesses.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/net/phy/mdio_bus.c | 15 +++++++++++++++
include/trace/events/mdio.h | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
create mode 100644 include/trace/events/mdio.h
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 09deef4bed09..0f3f207419f6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -38,6 +38,9 @@
#include <asm/irq.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/mdio.h>
+
int mdiobus_register_device(struct mdio_device *mdiodev)
{
if (mdiodev->bus->mdio_map[mdiodev->addr])
@@ -461,6 +464,9 @@ int mdiobus_read_nested(struct mii_bus *bus, int addr, u32 regnum)
retval = bus->read(bus, addr, regnum);
mutex_unlock(&bus->mdio_lock);
+ if (retval >= 0)
+ trace_mdio_access(bus, 1, addr, regnum, retval);
+
return retval;
}
EXPORT_SYMBOL(mdiobus_read_nested);
@@ -485,6 +491,9 @@ int mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
retval = bus->read(bus, addr, regnum);
mutex_unlock(&bus->mdio_lock);
+ if (retval >= 0)
+ trace_mdio_access(bus, 1, addr, regnum, retval);
+
return retval;
}
EXPORT_SYMBOL(mdiobus_read);
@@ -513,6 +522,9 @@ int mdiobus_write_nested(struct mii_bus *bus, int addr, u32 regnum, u16 val)
err = bus->write(bus, addr, regnum, val);
mutex_unlock(&bus->mdio_lock);
+ if (!err)
+ trace_mdio_access(bus, 0, addr, regnum, val);
+
return err;
}
EXPORT_SYMBOL(mdiobus_write_nested);
@@ -538,6 +550,9 @@ int mdiobus_write(struct mii_bus *bus, int addr, u32 regnum, u16 val)
err = bus->write(bus, addr, regnum, val);
mutex_unlock(&bus->mdio_lock);
+ if (!err)
+ trace_mdio_access(bus, 0, addr, regnum, val);
+
return err;
}
EXPORT_SYMBOL(mdiobus_write);
diff --git a/include/trace/events/mdio.h b/include/trace/events/mdio.h
new file mode 100644
index 000000000000..dcb2d456a346
--- /dev/null
+++ b/include/trace/events/mdio.h
@@ -0,0 +1,40 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM mdio
+
+#if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_MDIO_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(mdio_access,
+
+ TP_PROTO(struct mii_bus *bus, int read,
+ unsigned addr, unsigned regnum, u16 val),
+
+ TP_ARGS(bus, read, addr, regnum, val),
+
+ TP_STRUCT__entry(
+ __array(char, busid, MII_BUS_ID_SIZE)
+ __field(int, read)
+ __field(unsigned, addr)
+ __field(unsigned, regnum)
+ __field(u16, val)
+ ),
+
+ TP_fast_assign(
+ strncpy(__entry->busid, bus->id, MII_BUS_ID_SIZE);
+ __entry->read = read;
+ __entry->addr = addr;
+ __entry->regnum = regnum;
+ __entry->val = val;
+ ),
+
+ TP_printk("%s %-5s phy:0x%02x reg:0x%02x val:0x%04hx",
+ __entry->busid, __entry->read ? "read" : "write",
+ __entry->addr, __entry->regnum, __entry->val)
+);
+
+#endif /* if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ) */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v4] i2c: designware: Implement support for SMBus block read and write
From: Andy Shevchenko @ 2016-11-14 11:03 UTC (permalink / raw)
To: Alexander Stein, linux-kernel
Cc: tnhuynh, Jarkko Nikula, Mika Westerberg, Wolfram Sang, linux-i2c,
Loc Ho, Thang Nguyen, Phong Vo, patches
In-Reply-To: <4917823.j8OxAtZYNT@ws-stein>
On Mon, 2016-11-14 at 11:59 +0100, Alexander Stein wrote:
> On Thursday 10 November 2016 09:56:33, tnhuynh@apm.com wrote:
> > --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> > @@ -75,6 +75,7 @@ struct dw_pci_controller {
> > I2C_FUNC_SMBUS_BYTE |
> > \
> > I2C_FUNC_SMBUS_BYTE_DATA |
> > \
> > I2C_FUNC_SMBUS_WORD_DATA |
> > \
> > + I2C_FUNC_SMBUS_BLOCK_DATA |
> > \
> > I2C_FUNC_SMBUS_I2C_BLOCK)
> >
> > /* Merrifield HCNT/LCNT/SDA hold time */
> > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> > b/drivers/i2c/busses/i2c-designware-platdrv.c index 0b42a12..886fb62
> > 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -220,6 +220,7 @@ static int dw_i2c_plat_probe(struct
> > platform_device
> > *pdev) I2C_FUNC_SMBUS_BYTE |
> > I2C_FUNC_SMBUS_BYTE_DATA |
> > I2C_FUNC_SMBUS_WORD_DATA |
> > + I2C_FUNC_SMBUS_BLOCK_DATA |
> > I2C_FUNC_SMBUS_I2C_BLOCK;
> >
> > dev->master_cfg = DW_IC_CON_MASTER |
> > DW_IC_CON_SLAVE_DISABLE |
>
> Shouldn't those functionality bits moved to a common place, like i2c-
> designware-core.h?
It would. But it's a separate story. So, if you are willing to do this,
go ahead and send a patch.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Jerome Brunet @ 2016-11-14 11:02 UTC (permalink / raw)
To: Giuseppe CAVALLARO, Martin Blumenstingl
Cc: André Roth, Alexandre Torgue, Johnson Leung, linux-amlogic,
netdev, afaerber
In-Reply-To: <68696e92-d056-5f29-9e71-72066f0c7673@st.com>
On Mon, 2016-11-14 at 08:47 +0100, Giuseppe CAVALLARO wrote:
> Hello Martin
>
> On 11/7/2016 6:37 PM, Martin Blumenstingl wrote:
> >
> > Hi Peppe,
> >
> > On Mon, Nov 7, 2016 at 11:59 AM, Giuseppe CAVALLARO
> > <peppe.cavallaro@st.com> wrote:
> > >
> > > In the meantime, I will read again the thread just to see if
> > > there is something I am missing.
> > if you are re-reading this thread: please note that there are two
> > devices in discussion here!
>
> many thx for the sum :-)
>
> >
> > Both are using the Amlogic S905 (GXBB) SoC and both are
> > experiencing
> > the same issue (Gbit TX issues, RX with Gbit speeds and RX/TX with
> > 100Mbit speed are NOT affected):
> > - Odroid-C2 (used by Jerome and André Roth)
> > - Tronsmart Vega S95 Meta (my device)
> >
> > The (Gbit TX) problem seems to be gone on the Odroid-C2 with
> > Jerome's
> > patch which disables EEE in drivers/net/phy/realtek.c (at least in
> > his
> > tests, I don't have that device so I can't verify).
> > The same problem still appears on my Tronsmart Vega S95 Meta even
> > with
> > the patched PHY driver.
>
> just an doubt, maybe useful, in the past, on GiGa setup I saw similar
> problems and it was due to retiming so maybe 2ns could be necessary
> (or better granularity via PAD logic if available).
>
> Regards
> Peppe
Peppe, Martin,
With Andre's feedback, I think we can confirm that disabling EEE solve
the problem for the OdroidC2 design.
We do have the same results as Martin on MXQ-Pro based designs. For
these particular boards, disabling EEE does not seems to enough to get
a stable Tx path in 1000Base-T.
I will submit the patch for the Odroidc2 later today.
For the Vega, you should probably check the Tx delay as Peppe suggests.
To do these tests, It would probably be better to disable EEE as well.
Do you want me to include this change for the vega in the patch ?
Cheers
Jerome
>
> >
> > Unfortunately I don't have a second device to rule out that my
> > Tronsmart Vega S95 Meta could be broken (not unlikely, I get DDR
> > errors from time to time in u-boot). Maybe Andreas Faerber can test
> > ethernet with and without Jerome's patch on one of his Tronsmart
> > devices.
> >
> >
> > Regards,
> > Martin
> >
>
^ permalink raw reply
* stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Jerome Brunet @ 2016-11-14 11:02 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <68696e92-d056-5f29-9e71-72066f0c7673@st.com>
On Mon, 2016-11-14 at 08:47 +0100, Giuseppe CAVALLARO wrote:
> Hello Martin
>
> On 11/7/2016 6:37 PM, Martin Blumenstingl wrote:
> >
> > Hi Peppe,
> >
> > On Mon, Nov 7, 2016 at 11:59 AM, Giuseppe CAVALLARO
> > <peppe.cavallaro@st.com> wrote:
> > >
> > > In the meantime, I will read again the thread just to see if
> > > there is something I am missing.
> > if you are re-reading this thread: please note that there are two
> > devices in discussion here!
>
> many thx for the sum :-)
>
> >
> > Both are using the Amlogic S905 (GXBB) SoC and both are
> > experiencing
> > the same issue (Gbit TX issues, RX with Gbit speeds and RX/TX with
> > 100Mbit speed are NOT affected):
> > - Odroid-C2 (used by Jerome and Andr? Roth)
> > - Tronsmart Vega S95 Meta (my device)
> >
> > The (Gbit TX) problem seems to be gone on the Odroid-C2 with
> > Jerome's
> > patch which disables EEE in drivers/net/phy/realtek.c (at least in
> > his
> > tests, I don't have that device so I can't verify).
> > The same problem still appears on my Tronsmart Vega S95 Meta even
> > with
> > the patched PHY driver.
>
> just an doubt, maybe useful, in the past, on GiGa setup I saw similar
> problems and it was due to retiming so maybe 2ns could be necessary
> (or better granularity via PAD logic if available).
>
> Regards
> Peppe
Peppe, Martin,
With Andre's feedback, I think we can confirm that disabling EEE solve
the problem for the OdroidC2 design.
We do have the same results as Martin on MXQ-Pro based designs. For
these particular boards, disabling EEE does not seems to enough to get
a stable Tx path in 1000Base-T.
I will submit the patch for the Odroidc2 later today.
For the Vega, you should probably check the Tx delay as Peppe suggests.
To do these tests, It would probably be better to disable EEE as well.
Do you want me to include this change for the vega in the patch ?
Cheers
Jerome?
>
> >
> > Unfortunately I don't have a second device to rule out that my
> > Tronsmart Vega S95 Meta could be broken (not unlikely, I get DDR
> > errors from time to time in u-boot). Maybe Andreas Faerber can test
> > ethernet with and without Jerome's patch on one of his Tronsmart
> > devices.
> >
> >
> > Regards,
> > Martin
> >
>
^ permalink raw reply
* [PATCH for-4.8 2/2] x86/traps: Don't call hvm_hypervisor_cpuid_leaf() for PV guests
From: Andrew Cooper @ 2016-11-14 11:01 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
In-Reply-To: <1479121286-6390-1-git-send-email-andrew.cooper3@citrix.com>
Luckily, hvm_hypervisor_cpuid_leaf() and vmx_hypervisor_cpuid_leaf() are safe
to execute in the context of a PV guest, but HVM-specific feature flags
shouldn't be visible to PV guests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/traps.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 14abb62..d56d76e 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -928,6 +928,11 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t sub_idx,
break;
case 4:
+ if ( !has_hvm_container_domain(currd) )
+ {
+ *eax = *ebx = *ecx = *edx = 0;
+ break;
+ }
hvm_hypervisor_cpuid_leaf(sub_idx, eax, ebx, ecx, edx);
break;
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH for-4.8 1/2] x86/vmx: Correct the long mode check in vmx_cpuid_intercept()
From: Andrew Cooper @ 2016-11-14 11:01 UTC (permalink / raw)
To: Xen-devel; +Cc: Andrew Cooper, Kevin Tian, Wei Liu, Jun Nakajima, Jan Beulich
%cs.L may be set in a legacy mode segment, or clear in a compatibility mode
segment; it is not the correct way to check for long mode being active.
Both of these situations result in incorrect visibility of the SYSCALL feature
in CPUID, and by extension, incorrect behaviour in hvm_efer_valid().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Jun Nakajima <jun.nakajima@intel.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
xen/arch/x86/hvm/vmx/vmx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9a8f694..a18db28 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2407,7 +2407,6 @@ static void vmx_cpuid_intercept(
unsigned int *ecx, unsigned int *edx)
{
unsigned int input = *eax;
- struct segment_register cs;
struct vcpu *v = current;
hvm_cpuid(input, eax, ebx, ecx, edx);
@@ -2416,8 +2415,7 @@ static void vmx_cpuid_intercept(
{
case 0x80000001:
/* SYSCALL is visible iff running in long mode. */
- vmx_get_segment_register(v, x86_seg_cs, &cs);
- if ( cs.attr.fields.l )
+ if ( hvm_long_mode_enabled(v) )
*edx |= cpufeat_mask(X86_FEATURE_SYSCALL);
else
*edx &= ~(cpufeat_mask(X86_FEATURE_SYSCALL));
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v4 1/3] clk: qcom: Fix .set_rate to handle alpha PLLs w/wo dynamic update
From: Rajendra Nayak @ 2016-11-14 11:00 UTC (permalink / raw)
To: sboyd, mturquette
Cc: linux-clk, linux-arm-msm, linux-kernel, tdas, Rajendra Nayak
In-Reply-To: <1479121240-20922-1-git-send-email-rnayak@codeaurora.org>
From: Taniya Das <tdas@codeaurora.org>
Alpha PLLs which do not support dynamic update feature
need to be explicitly disabled before a rate change.
The ones which do support dynamic update do so within a
single vco range, so add a min/max freq check for such
PLLs so they fall in the vco range.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
---
drivers/clk/qcom/clk-alpha-pll.c | 71 +++++++++++++++++++++++++++++++++-------
drivers/clk/qcom/clk-alpha-pll.h | 5 +++
2 files changed, 65 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 47a1da3..ecb9e7f 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -376,19 +376,46 @@ static unsigned long alpha_pll_calc_rate(u64 prate, u32 l, u32 a)
return alpha_pll_calc_rate(prate, l, a);
}
-static int clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long prate)
+static int alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long prate,
+ int (*enable)(struct clk_hw *hw),
+ void (*disable)(struct clk_hw *hw))
{
+ bool enabled;
struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
const struct pll_vco *vco;
u32 l, off = pll->offset;
u64 a;
rate = alpha_pll_round_rate(rate, prate, &l, &a);
- vco = alpha_pll_find_vco(pll, rate);
- if (!vco) {
- pr_err("alpha pll not in a valid vco range\n");
- return -EINVAL;
+ enabled = clk_hw_is_enabled(hw);
+
+ if (pll->flags & SUPPORTS_DYNAMIC_UPDATE) {
+ /*
+ * PLLs which support dynamic updates support one single
+ * vco range, between min_rate and max_rate supported
+ */
+ if (rate < pll->min_rate || rate > pll->max_rate) {
+ pr_err("alpha pll rate outside supported min/max range\n");
+ return -EINVAL;
+ }
+ } else {
+ /*
+ * All alpha PLLs which do not support dynamic update,
+ * should be disabled before a vco update.
+ */
+ if (enabled)
+ disable(hw);
+
+ vco = alpha_pll_find_vco(pll, rate);
+ if (!vco) {
+ pr_err("alpha pll not in a valid vco range\n");
+ return -EINVAL;
+ }
+
+ regmap_update_bits(pll->clkr.regmap, off + PLL_USER_CTL,
+ PLL_VCO_MASK << PLL_VCO_SHIFT,
+ vco->val << PLL_VCO_SHIFT);
}
regmap_write(pll->clkr.regmap, off + PLL_L_VAL, l);
@@ -401,16 +428,29 @@ static int clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
regmap_write(pll->clkr.regmap, off + PLL_ALPHA_VAL_U, a >> 32);
}
- regmap_update_bits(pll->clkr.regmap, off + PLL_USER_CTL,
- PLL_VCO_MASK << PLL_VCO_SHIFT,
- vco->val << PLL_VCO_SHIFT);
-
regmap_update_bits(pll->clkr.regmap, off + PLL_USER_CTL, PLL_ALPHA_EN,
PLL_ALPHA_EN);
+ if (!(pll->flags & SUPPORTS_DYNAMIC_UPDATE) && enabled)
+ enable(hw);
+
return 0;
}
+static int clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long prate)
+{
+ return alpha_pll_set_rate(hw, rate, prate, clk_alpha_pll_enable,
+ clk_alpha_pll_disable);
+}
+
+static int clk_alpha_pll_hwfsm_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long prate)
+{
+ return alpha_pll_set_rate(hw, rate, prate, clk_alpha_pll_hwfsm_enable,
+ clk_alpha_pll_hwfsm_disable);
+}
+
static long clk_alpha_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
@@ -420,6 +460,15 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long min_freq, max_freq;
rate = alpha_pll_round_rate(rate, *prate, &l, &a);
+
+ if (pll->flags & SUPPORTS_DYNAMIC_UPDATE) {
+ if (rate < pll->min_rate)
+ rate = pll->min_rate;
+ else if (rate > pll->max_rate)
+ rate = pll->max_rate;
+ return rate;
+ }
+
if (alpha_pll_find_vco(pll, rate))
return rate;
@@ -445,7 +494,7 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw, unsigned long rate,
.is_enabled = clk_alpha_pll_hwfsm_is_enabled,
.recalc_rate = clk_alpha_pll_recalc_rate,
.round_rate = clk_alpha_pll_round_rate,
- .set_rate = clk_alpha_pll_set_rate,
+ .set_rate = clk_alpha_pll_hwfsm_set_rate,
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_hwfsm_ops);
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index d6e1ee2..7aaa11c 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -27,6 +27,8 @@ struct pll_vco {
* struct clk_alpha_pll - phase locked loop (PLL)
* @offset: base address of registers
* @vco_table: array of VCO settings
+ * @min_rate: Minimim rate for PLLs with single VCO range
+ * @max_rate: Maximun rate for PLLs with single VCO range
* @clkr: regmap clock handle
*/
struct clk_alpha_pll {
@@ -37,8 +39,11 @@ struct clk_alpha_pll {
#define SUPPORTS_OFFLINE_REQ BIT(0)
#define SUPPORTS_16BIT_ALPHA BIT(1)
#define SUPPORTS_FSM_MODE BIT(2)
+#define SUPPORTS_DYNAMIC_UPDATE BIT(3)
u8 flags;
+ unsigned long min_rate;
+ unsigned long max_rate;
struct clk_regmap clkr;
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v4 0/3] clk: qcom: PLL updates..take2
From: Rajendra Nayak @ 2016-11-14 11:00 UTC (permalink / raw)
To: sboyd, mturquette
Cc: linux-clk, linux-arm-msm, linux-kernel, tdas, Rajendra Nayak
This is a v4 of the patches left over from v3.
Reworked and rebased on top of clk-next.
Changes in v4:
* got rid of the use of init structures from the .set_rate ops
Rajendra Nayak (1):
clk: qcom: mmcc-8996: Add capability flags for some alpha PLLs
Taniya Das (2):
clk: qcom: Fix .set_rate to handle alpha PLLs w/wo dynamic update
clk: qcom: support dynamic update using latched interface
drivers/clk/qcom/clk-alpha-pll.c | 106 +++++++++++++++++++++++++++++++++++----
drivers/clk/qcom/clk-alpha-pll.h | 10 ++++
drivers/clk/qcom/mmcc-msm8996.c | 4 ++
3 files changed, 109 insertions(+), 11 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v4 3/3] clk: qcom: mmcc-8996: Add capability flags for some alpha PLLs
From: Rajendra Nayak @ 2016-11-14 11:00 UTC (permalink / raw)
To: sboyd, mturquette
Cc: linux-clk, linux-arm-msm, linux-kernel, tdas, Rajendra Nayak
In-Reply-To: <1479121240-20922-1-git-send-email-rnayak@codeaurora.org>
Flag alpha PLLs which support fsmmode, dynamic update and the ones
with latched input interface.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
drivers/clk/qcom/mmcc-msm8996.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
index f77206f..c6122e1 100644
--- a/drivers/clk/qcom/mmcc-msm8996.c
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -269,6 +269,7 @@ enum {
.offset = 0x0,
.vco_table = mmpll_p_vco,
.num_vco = ARRAY_SIZE(mmpll_p_vco),
+ .flags = SUPPORTS_FSM_MODE,
.clkr = {
.enable_reg = 0x100,
.enable_mask = BIT(0),
@@ -297,6 +298,7 @@ enum {
.offset = 0x30,
.vco_table = mmpll_p_vco,
.num_vco = ARRAY_SIZE(mmpll_p_vco),
+ .flags = SUPPORTS_FSM_MODE,
.clkr = {
.enable_reg = 0x100,
.enable_mask = BIT(1),
@@ -445,6 +447,8 @@ enum {
.offset = 0x4200,
.vco_table = mmpll_t_vco,
.num_vco = ARRAY_SIZE(mmpll_t_vco),
+ .flags = SUPPORTS_DYNAMIC_UPDATE | SUPPORTS_LATCHED_INPUT,
+ .latch_ack_bit = 29,
.clkr.hw.init = &(struct clk_init_data){
.name = "mmpll9_early",
.parent_names = (const char *[]){ "xo" },
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v4 2/3] clk: qcom: support dynamic update using latched interface
From: Rajendra Nayak @ 2016-11-14 11:00 UTC (permalink / raw)
To: sboyd, mturquette
Cc: linux-clk, linux-arm-msm, linux-kernel, tdas, Rajendra Nayak
In-Reply-To: <1479121240-20922-1-git-send-email-rnayak@codeaurora.org>
From: Taniya Das <tdas@codeaurora.org>
Alpha PLLs can support 2 kinds of input signals, normal and latched. The
normal input is directly passed to the core, while the latched input
requires a latch and acknowledge sequence to be performed for the
changed input to propagate.
Alpha PLLs can support dynamic update with both kind of input signals.
The ones which support this using a latched interface however need to
follow the latch/wait-for-ack sequence to be performed when the rate changes.
Mark these with a new flag 'SUPPORTS_LATCHED_INPUT' to handle this as
part of clk_alpha_pll_set_rate()
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
---
drivers/clk/qcom/clk-alpha-pll.c | 37 ++++++++++++++++++++++++++++++++++++-
drivers/clk/qcom/clk-alpha-pll.h | 5 +++++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index ecb9e7f..15703b4 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -32,6 +32,7 @@
# define PLL_VOTE_FSM_ENA BIT(20)
# define PLL_FSM_ENA BIT(20)
# define PLL_VOTE_FSM_RESET BIT(21)
+# define PLL_UPDATE BIT(22)
# define PLL_OFFLINE_ACK BIT(28)
# define PLL_ACTIVE_FLAG BIT(30)
# define PLL_LOCK_DET BIT(31)
@@ -48,6 +49,7 @@
# define PLL_VCO_MASK 0x3
#define PLL_USER_CTL_U 0x14
+# define PLL_LATCH_INTERFACE BIT(11)
#define PLL_CONFIG_CTL 0x18
#define PLL_CONFIG_CTL_U 0x20
@@ -109,6 +111,10 @@ static int wait_for_pll(struct clk_alpha_pll *pll, u32 mask, bool inverse,
#define wait_for_pll_offline(pll) \
wait_for_pll(pll, PLL_OFFLINE_ACK, 0, "offline")
+#define wait_for_pll_latch_ack(pll) \
+ wait_for_pll(pll, BIT(pll->latch_ack_bit), pll->latch_ack_inverse, \
+ "latch ack")
+
void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
const struct alpha_pll_config *config)
{
@@ -140,6 +146,10 @@ void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
if (pll->flags & SUPPORTS_FSM_MODE)
qcom_pll_set_fsm_mode(regmap, off + PLL_MODE, 6, 0);
+
+ if (pll->flags & SUPPORTS_LATCHED_INPUT)
+ regmap_update_bits(regmap, off + PLL_USER_CTL_U,
+ PLL_LATCH_INTERFACE, 0);
}
static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
@@ -376,6 +386,27 @@ static unsigned long alpha_pll_calc_rate(u64 prate, u32 l, u32 a)
return alpha_pll_calc_rate(prate, l, a);
}
+static int clk_alpha_pll_update_latch(struct clk_alpha_pll *pll)
+{
+ /* Latch the input to the PLL */
+ regmap_update_bits(pll->clkr.regmap, pll->offset + PLL_MODE,
+ PLL_UPDATE, PLL_UPDATE);
+
+ /* Wait for 2 reference cycle before checking ACK bit */
+ udelay(1);
+
+ wait_for_pll_latch_ack(pll);
+
+ /* Return latch input to 0 */
+ regmap_update_bits(pll->clkr.regmap, pll->offset + PLL_MODE,
+ PLL_UPDATE, 0);
+
+ /* Wait for PLL output to stabilize */
+ udelay(100);
+
+ return 0;
+}
+
static int alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long prate,
int (*enable)(struct clk_hw *hw),
@@ -431,8 +462,12 @@ static int alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
regmap_update_bits(pll->clkr.regmap, off + PLL_USER_CTL, PLL_ALPHA_EN,
PLL_ALPHA_EN);
- if (!(pll->flags & SUPPORTS_DYNAMIC_UPDATE) && enabled)
+ if (pll->flags & SUPPORTS_DYNAMIC_UPDATE) {
+ if (pll->flags & SUPPORTS_LATCHED_INPUT)
+ clk_alpha_pll_update_latch(pll);
+ } else if (enabled) {
enable(hw);
+ }
return 0;
}
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index 7aaa11c..c580d20 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -27,6 +27,8 @@ struct pll_vco {
* struct clk_alpha_pll - phase locked loop (PLL)
* @offset: base address of registers
* @vco_table: array of VCO settings
+ * @latch_ack_bit: Bit to check for latch acknowledge
+ * @latch_ack_inverse: Bit set to 0 signifies an ack
* @min_rate: Minimim rate for PLLs with single VCO range
* @max_rate: Maximun rate for PLLs with single VCO range
* @clkr: regmap clock handle
@@ -40,7 +42,10 @@ struct clk_alpha_pll {
#define SUPPORTS_16BIT_ALPHA BIT(1)
#define SUPPORTS_FSM_MODE BIT(2)
#define SUPPORTS_DYNAMIC_UPDATE BIT(3)
+#define SUPPORTS_LATCHED_INPUT BIT(4)
u8 flags;
+ u8 latch_ack_bit;
+ bool latch_ack_inverse;
unsigned long min_rate;
unsigned long max_rate;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention
From: One Thousand Gnomes @ 2016-11-14 10:59 UTC (permalink / raw)
To: Ricardo Neri
Cc: Andy Lutomirski, Peter Zijlstra, Ingo Molnar, Thomas Gleixner,
H. Peter Anvin, linux-kernel@vger.kernel.org, X86 ML,
linux-doc@vger.kernel.org, Andy Lutomirski, Andrew Morton,
Borislav Petkov, Brian Gerst, Chen Yucong, Chris Metcalf,
Dave Hansen, Fenghua Yu, Huang Rui, Jiri Slaby, Jonathan Corbet,
Michael S . Tsirkin, Paul Gortmaker, Ravi V . Shankar,
Vlastimil Babka, Shuah Khan, linux-msdos
In-Reply-To: <1478760361.2551.21.camel@ranerica-desktop>
> I took a closer look at the dosemu code. It appears that it does not
That doesn't tell you want DOS itself will try and do...
> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> does use SGDT (in protected mode) to emulate certain functionality such
> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> However, this code seems to be disabled [1]. dosemu includes an i386
> emulator that in some cases uses the actual instructions of the host
> system. In such cases, UMIP might be needed to be disabled.
Is anyone actually still using DOSemu these days or are people all
using DOSbox ?
Alan
^ 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.