* [PATCH 0/7] sunxi: Add DT representation for the MBUS controller
From: Maxime Ripard @ 2018-05-31 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180409092229.ljcnsqgv7wh2s4op@flea>
On Mon, Apr 09, 2018 at 11:22:29AM +0200, Maxime Ripard wrote:
> Hi Rob,
>
> On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote:
> > On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > property called dma-parent that allows to express the DMA relationship
> > > between a master and its bus, even if they are not direct parents in the DT.
> >
> > Reading thru v6 of the camera driver, it seems like having
> > intermediate buses would solve the problem in your case?
>
> I guess it would yes, but I guess it wouldn't model the hardware
> properly since this seems to be really a bus only meant to do DMA, and
> you're not accessing the registers of the device through that bus.
>
> And as far as I know, the DT implies that the topology is the one of
> the "control" side of the devices.
>
> We'll also need eventually to have retrieve the MBUS endpoints ID to
> be able to support perf and PM QoS properly.
>
> > As Arnd mentioned in that thread, something new needs to address all
> > the deficiencies with dma-ranges and describing DMA bus topologies.
> > This doesn't address the needs of describing bus interconnects.
> > There's been some efforts by the QCom folks with an interconnect
> > binding. They've mostly punted (for now at least) to not describing
> > the whole interconnect in DT and keeping the details in a driver.
>
> Is it that patch serie? https://lkml.org/lkml/2018/3/9/856
>
> > On the flip side, this does mirror the established pattern used by
> > interrupts, so maybe it's okay on it's own. I'll wait for others to
> > comment.
>
> We'll see how it turns out then :)
Ping?
How should we move forward on this?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180531/dc5709d9/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/6] arm64: KVM: Handle Set/Way CMOs as NOPs if FWB is present
From: Marc Zyngier @ 2018-05-31 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531115127.2ymmtlwemz6g5qzj@lakrids.cambridge.arm.com>
On 31/05/18 12:51, Mark Rutland wrote:
> On Wed, May 30, 2018 at 01:47:02PM +0100, Marc Zyngier wrote:
>> Set/Way handling is one of the ugliest corners of KVM. We shouldn't
>> have to handle that, but better safe than sorry.
>>
>> Thankfully, FWB fixes this for us by not requiering any maintenance
>> whatsoever, which means we don't have to emulate S/W CMOs, and don't
>> have to track VM ops either.
>>
>> We still have to trap S/W though, if only to prevent the guest from
>> doing something bad.
>
> S/W ops *also* do I-cache maintenance, so we'd still need to emulate
> that. Though it looks like we're missing that today...
This doesn't look right: CSSELR_EL1 does indeed have an InD bit, but
that's only for the purpose of reading CSSIDR_EL1. DC CSW and co
directly take a level *without* the InD bit, and seem to be limited to
"data and unified cache".
Am I missing something?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/7] iommu/dma: fix trival coding style mistake
From: Robin Murphy @ 2018-05-31 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-2-git-send-email-thunder.leizhen@huawei.com>
On 31/05/18 08:42, Zhen Lei wrote:
> The static function iova_reserve_iommu_regions is only called by function
> iommu_dma_init_domain, and the 'if (!dev)' check in iommu_dma_init_domain
> affect it only, so we can safely move the check into it. I think it looks
> more natural.
As before, I disagree - the logic of iommu_dma_init_domain() is "we
expect to have a valid device, but stop here if we don't", and moving
the check just needlessly obfuscates that. It is not a coincidence that
the arguments of both functions are in effective order of importance.
> In addition, the local variable 'ret' is only assigned in the branch of
> 'if (region->type == IOMMU_RESV_MSI)', so the 'if (ret)' should also only
> take effect in the branch, add a brace to enclose it.
'ret' is clearly also assigned at its declaration, to cover the (very
likely) case where we don't enter the loop at all. Thus testing it in
the loop is harmless, and cluttering that up with extra tabs and braces
is just noise.
Robin.
> No functional changes.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/dma-iommu.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index ddcbbdb..4e885f7 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -231,6 +231,9 @@ static int iova_reserve_iommu_regions(struct device *dev,
> LIST_HEAD(resv_regions);
> int ret = 0;
>
> + if (!dev)
> + return 0;
> +
> if (dev_is_pci(dev))
> iova_reserve_pci_windows(to_pci_dev(dev), iovad);
>
> @@ -246,11 +249,12 @@ static int iova_reserve_iommu_regions(struct device *dev,
> hi = iova_pfn(iovad, region->start + region->length - 1);
> reserve_iova(iovad, lo, hi);
>
> - if (region->type == IOMMU_RESV_MSI)
> + if (region->type == IOMMU_RESV_MSI) {
> ret = cookie_init_hw_msi_region(cookie, region->start,
> region->start + region->length);
> - if (ret)
> - break;
> + if (ret)
> + break;
> + }
> }
> iommu_put_resv_regions(dev, &resv_regions);
>
> @@ -308,8 +312,6 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> }
>
> init_iova_domain(iovad, 1UL << order, base_pfn);
> - if (!dev)
> - return 0;
>
> return iova_reserve_iommu_regions(dev, domain);
> }
>
^ permalink raw reply
* [PATCH 3/7] iommu: prepare for the non-strict mode support
From: Robin Murphy @ 2018-05-31 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-4-git-send-email-thunder.leizhen@huawei.com>
On 31/05/18 08:42, Zhen Lei wrote:
> In common, a IOMMU unmap operation follow the below steps:
> 1. remove the mapping in page table of the specified iova range
> 2. execute tlbi command to invalid the mapping which is cached in TLB
> 3. wait for the above tlbi operation to be finished
> 4. free the IOVA resource
> 5. free the physical memory resource
>
> This maybe a problem when unmap is very frequently, the combination of tlbi
> and wait operation will consume a lot of time. A feasible method is put off
> tlbi and iova-free operation, when accumulating to a certain number or
> reaching a specified time, execute only one tlbi_all command to clean up
> TLB, then free the backup IOVAs. Mark as non-strict mode.
>
> But it must be noted that, although the mapping has already been removed in
> the page table, it maybe still exist in TLB. And the freed physical memory
> may also be reused for others. So a attacker can persistent access to memory
> based on the just freed IOVA, to obtain sensible data or corrupt memory. So
> the VFIO should always choose the strict mode.
>
> This patch just add a new parameter for the unmap operation, to help the
> upper functions capable choose which mode to be applied.
This seems like it might be better handled by a flag in
io_pgtable_cfg->quirks. This interface change on its own looks rather
invasive, and teh fact that it ends up only being used to pass through a
constant property of the domain (which is already known by the point
io_pgtable_alloc() is called) implies that it is indeed the wrong level
of abstraction.
> No functional changes.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 +-
> drivers/iommu/arm-smmu.c | 2 +-
> drivers/iommu/io-pgtable-arm-v7s.c | 6 +++---
> drivers/iommu/io-pgtable-arm.c | 6 +++---
> drivers/iommu/io-pgtable.h | 2 +-
> drivers/iommu/ipmmu-vmsa.c | 2 +-
> drivers/iommu/msm_iommu.c | 2 +-
> drivers/iommu/mtk_iommu.c | 2 +-
> drivers/iommu/qcom_iommu.c | 2 +-
> include/linux/iommu.h | 2 ++
Plus things specific to io-pgtable shouldn't really be spilling into the
core API header either.
Robin.
> 10 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 4402187..59b3387 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1767,7 +1767,7 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
> if (!ops)
> return 0;
>
> - return ops->unmap(ops, iova, size);
> + return ops->unmap(ops, iova, size, IOMMU_STRICT);
> }
>
> static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 69e7c60..253e807 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1249,7 +1249,7 @@ static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
> if (!ops)
> return 0;
>
> - return ops->unmap(ops, iova, size);
> + return ops->unmap(ops, iova, size, IOMMU_STRICT);
> }
>
> static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index 10e4a3d..799eced 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -658,7 +658,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
> }
>
> static size_t arm_v7s_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> - size_t size)
> + size_t size, int strict)
> {
> struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
>
> @@ -883,7 +883,7 @@ static int __init arm_v7s_do_selftests(void)
> size = 1UL << __ffs(cfg.pgsize_bitmap);
> while (i < loopnr) {
> iova_start = i * SZ_16M;
> - if (ops->unmap(ops, iova_start + size, size) != size)
> + if (ops->unmap(ops, iova_start + size, size, IOMMU_STRICT) != size)
> return __FAIL(ops);
>
> /* Remap of partial unmap */
> @@ -902,7 +902,7 @@ static int __init arm_v7s_do_selftests(void)
> while (i != BITS_PER_LONG) {
> size = 1UL << i;
>
> - if (ops->unmap(ops, iova, size) != size)
> + if (ops->unmap(ops, iova, size, IOMMU_STRICT) != size)
> return __FAIL(ops);
>
> if (ops->iova_to_phys(ops, iova + 42))
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 39c2a05..e0f52db 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -624,7 +624,7 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
> }
>
> static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> - size_t size)
> + size_t size, int strict)
> {
> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> arm_lpae_iopte *ptep = data->pgd;
> @@ -1108,7 +1108,7 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
>
> /* Partial unmap */
> size = 1UL << __ffs(cfg->pgsize_bitmap);
> - if (ops->unmap(ops, SZ_1G + size, size) != size)
> + if (ops->unmap(ops, SZ_1G + size, size, IOMMU_STRICT) != size)
> return __FAIL(ops, i);
>
> /* Remap of partial unmap */
> @@ -1124,7 +1124,7 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
> while (j != BITS_PER_LONG) {
> size = 1UL << j;
>
> - if (ops->unmap(ops, iova, size) != size)
> + if (ops->unmap(ops, iova, size, IOMMU_STRICT) != size)
> return __FAIL(ops, i);
>
> if (ops->iova_to_phys(ops, iova + 42))
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index 2df7909..2908806 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -120,7 +120,7 @@ struct io_pgtable_ops {
> int (*map)(struct io_pgtable_ops *ops, unsigned long iova,
> phys_addr_t paddr, size_t size, int prot);
> size_t (*unmap)(struct io_pgtable_ops *ops, unsigned long iova,
> - size_t size);
> + size_t size, int strict);
> phys_addr_t (*iova_to_phys)(struct io_pgtable_ops *ops,
> unsigned long iova);
> };
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 40ae6e8..e6d9e11 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -716,7 +716,7 @@ static size_t ipmmu_unmap(struct iommu_domain *io_domain, unsigned long iova,
> {
> struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
>
> - return domain->iop->unmap(domain->iop, iova, size);
> + return domain->iop->unmap(domain->iop, iova, size, IOMMU_STRICT);
> }
>
> static void ipmmu_iotlb_sync(struct iommu_domain *io_domain)
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 0d33504..180fa3d 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -532,7 +532,7 @@ static size_t msm_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
> unsigned long flags;
>
> spin_lock_irqsave(&priv->pgtlock, flags);
> - len = priv->iop->unmap(priv->iop, iova, len);
> + len = priv->iop->unmap(priv->iop, iova, len, IOMMU_STRICT);
> spin_unlock_irqrestore(&priv->pgtlock, flags);
>
> return len;
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index f2832a1..54661ed 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -386,7 +386,7 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
> size_t unmapsz;
>
> spin_lock_irqsave(&dom->pgtlock, flags);
> - unmapsz = dom->iop->unmap(dom->iop, iova, size);
> + unmapsz = dom->iop->unmap(dom->iop, iova, size, IOMMU_STRICT);
> spin_unlock_irqrestore(&dom->pgtlock, flags);
>
> return unmapsz;
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> index 65b9c99..90abde1 100644
> --- a/drivers/iommu/qcom_iommu.c
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -444,7 +444,7 @@ static size_t qcom_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
> */
> pm_runtime_get_sync(qcom_domain->iommu->dev);
> spin_lock_irqsave(&qcom_domain->pgtbl_lock, flags);
> - ret = ops->unmap(ops, iova, size);
> + ret = ops->unmap(ops, iova, size, IOMMU_STRICT);
> spin_unlock_irqrestore(&qcom_domain->pgtbl_lock, flags);
> pm_runtime_put_sync(qcom_domain->iommu->dev);
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 19938ee..39b3150 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -86,6 +86,8 @@ struct iommu_domain_geometry {
> #define IOMMU_DOMAIN_DMA (__IOMMU_DOMAIN_PAGING | \
> __IOMMU_DOMAIN_DMA_API)
>
> +#define IOMMU_STRICT 1
> +
> struct iommu_domain {
> unsigned type;
> const struct iommu_ops *ops;
>
^ permalink raw reply
* [PATCH 4/7] iommu/amd: make sure TLB to be flushed before IOVA freed
From: Robin Murphy @ 2018-05-31 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-5-git-send-email-thunder.leizhen@huawei.com>
On 31/05/18 08:42, Zhen Lei wrote:
> Although the mapping has already been removed in the page table, it maybe
> still exist in TLB. Suppose the freed IOVAs is reused by others before the
> flush operation completed, the new user can not correctly access to its
> meomory.
This change seems reasonable in isolation, but why is it right in the
middle of a series which has nothing to do with x86?
Robin.
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/amd_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 8fb8c73..93aa389 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -2402,9 +2402,9 @@ static void __unmap_single(struct dma_ops_domain *dma_dom,
> }
>
> if (amd_iommu_unmap_flush) {
> - dma_ops_free_iova(dma_dom, dma_addr, pages);
> domain_flush_tlb(&dma_dom->domain);
> domain_flush_complete(&dma_dom->domain);
> + dma_ops_free_iova(dma_dom, dma_addr, pages);
> } else {
> pages = __roundup_pow_of_two(pages);
> queue_iova(&dma_dom->iovad, dma_addr >> PAGE_SHIFT, pages, 0);
>
^ permalink raw reply
* [PATCH 5/7] iommu/dma: add support for non-strict mode
From: Robin Murphy @ 2018-05-31 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-6-git-send-email-thunder.leizhen@huawei.com>
On 31/05/18 08:42, Zhen Lei wrote:
> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
> capable call domain->ops->flush_iotlb_all to flush TLB.
> 2. Define a new iommu capable: IOMMU_CAP_NON_STRICT, which used to indicate
> that the iommu domain support non-strict mode.
> 3. During the iommu domain initialization phase, call capable() to check
> whether it support non-strcit mode. If so, call init_iova_flush_queue
> to register iovad->flush_cb callback.
> 4. All unmap(contains iova-free) APIs will finally invoke __iommu_dma_unmap
> -->iommu_dma_free_iova. Use iovad->flush_cb to check whether its related
> iommu support non-strict mode or not, and call IOMMU_DOMAIN_IS_STRICT to
> make sure the IOMMU_DOMAIN_UNMANAGED domain always follow strict mode.
Once again, this is a whole load of complexity for a property which
could just be statically encoded at allocation, e.g. in the cookie type.
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/dma-iommu.c | 29 ++++++++++++++++++++++++++---
> include/linux/iommu.h | 3 +++
> 2 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 4e885f7..2e116d9 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -55,6 +55,7 @@ struct iommu_dma_cookie {
> };
> struct list_head msi_page_list;
> spinlock_t msi_lock;
> + struct iommu_domain *domain;
> };
>
> static inline size_t cookie_msi_granule(struct iommu_dma_cookie *cookie)
> @@ -64,7 +65,8 @@ static inline size_t cookie_msi_granule(struct iommu_dma_cookie *cookie)
> return PAGE_SIZE;
> }
>
> -static struct iommu_dma_cookie *cookie_alloc(enum iommu_dma_cookie_type type)
> +static struct iommu_dma_cookie *cookie_alloc(struct iommu_domain *domain,
> + enum iommu_dma_cookie_type type)
> {
> struct iommu_dma_cookie *cookie;
>
> @@ -73,6 +75,7 @@ static struct iommu_dma_cookie *cookie_alloc(enum iommu_dma_cookie_type type)
> spin_lock_init(&cookie->msi_lock);
> INIT_LIST_HEAD(&cookie->msi_page_list);
> cookie->type = type;
> + cookie->domain = domain;
> }
> return cookie;
> }
> @@ -94,7 +97,7 @@ int iommu_get_dma_cookie(struct iommu_domain *domain)
> if (domain->iova_cookie)
> return -EEXIST;
>
> - domain->iova_cookie = cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
> + domain->iova_cookie = cookie_alloc(domain, IOMMU_DMA_IOVA_COOKIE);
> if (!domain->iova_cookie)
> return -ENOMEM;
>
> @@ -124,7 +127,7 @@ int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> if (domain->iova_cookie)
> return -EEXIST;
>
> - cookie = cookie_alloc(IOMMU_DMA_MSI_COOKIE);
> + cookie = cookie_alloc(domain, IOMMU_DMA_MSI_COOKIE);
> if (!cookie)
> return -ENOMEM;
>
> @@ -261,6 +264,17 @@ static int iova_reserve_iommu_regions(struct device *dev,
> return ret;
> }
>
> +static void iova_flush_iotlb_all(struct iova_domain *iovad)
iommu_dma_flush...
> +{
> + struct iommu_dma_cookie *cookie;
> + struct iommu_domain *domain;
> +
> + cookie = container_of(iovad, struct iommu_dma_cookie, iovad);
> + domain = cookie->domain;
> +
> + domain->ops->flush_iotlb_all(domain);
> +}
> +
> /**
> * iommu_dma_init_domain - Initialise a DMA mapping domain
> * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> @@ -276,6 +290,7 @@ static int iova_reserve_iommu_regions(struct device *dev,
> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> u64 size, struct device *dev)
> {
> + const struct iommu_ops *ops = domain->ops;
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
> @@ -313,6 +328,11 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>
> init_iova_domain(iovad, 1UL << order, base_pfn);
>
> + if (ops->capable && ops->capable(IOMMU_CAP_NON_STRICT)) {
> + BUG_ON(!ops->flush_iotlb_all);
> + init_iova_flush_queue(iovad, iova_flush_iotlb_all, NULL);
> + }
> +
> return iova_reserve_iommu_regions(dev, domain);
> }
> EXPORT_SYMBOL(iommu_dma_init_domain);
> @@ -392,6 +412,9 @@ static void iommu_dma_free_iova(struct iommu_dma_cookie *cookie,
> /* The MSI case is only ever cleaning up its most recent allocation */
> if (cookie->type == IOMMU_DMA_MSI_COOKIE)
> cookie->msi_iova -= size;
> + else if (!IOMMU_DOMAIN_IS_STRICT(cookie->domain) && iovad->flush_cb)
> + queue_iova(iovad, iova_pfn(iovad, iova),
> + size >> iova_shift(iovad), 0);
> else
> free_iova_fast(iovad, iova_pfn(iovad, iova),
> size >> iova_shift(iovad));
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 39b3150..01ff569 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -87,6 +87,8 @@ struct iommu_domain_geometry {
> __IOMMU_DOMAIN_DMA_API)
>
> #define IOMMU_STRICT 1
> +#define IOMMU_DOMAIN_IS_STRICT(domain) \
> + (domain->type == IOMMU_DOMAIN_UNMANAGED)
>
> struct iommu_domain {
> unsigned type;
> @@ -103,6 +105,7 @@ enum iommu_cap {
> transactions */
> IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt isolation */
> IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */
> + IOMMU_CAP_NON_STRICT, /* IOMMU supports non-strict mode */
This isn't a property of the IOMMU, it depends purely on the driver
implementation. I think it also doesn't matter anyway - if a caller asks
for lazy unmapping on their domain but the IOMMU driver just does strict
unmaps anyway because that's all it supports, there's no actual harm done.
Robin.
> };
>
> /*
>
^ permalink raw reply
* [PATCH v1 0/2] support to set VSESR_EL2 by user space
From: Dongjiu Geng @ 2018-05-31 13:08 UTC (permalink / raw)
To: linux-arm-kernel
This series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
Dongjiu Geng (2):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
Documentation/virtual/kvm/api.txt | 42 +++++++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/kvm/guest.c | 12 +++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 ++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++
arch/arm64/kvm/guest.c | 36 +++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 +++++-
arch/arm64/kvm/reset.c | 4 ++++
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 21 ++++++++++++++++++
11 files changed, 150 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v1 1/2] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-05-31 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527772139-19665-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 758bf40..fdac969 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4603,3 +4603,14 @@ Architectures: s390
This capability indicates that kvm will implement the interfaces to handle
reset, migration and nested KVM for branch prediction blocking. The stfle
facility 82 should not be provided to the guest without this capability.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e..e88f976 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -948,6 +948,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_BPB 152
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 155
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ permalink raw reply related
* [PATCH v1 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-05-31 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527772139-19665-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
--
this series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
change since V12:
1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 & HCR_VSE) in kvm_arm_vcpu_get_events()
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++++-
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 21 +++++++++++++++++++++
10 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fdac969..8896737 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -835,11 +835,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -910,6 +929,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index c7c28c8..39f9901 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index a18f33e..c685f0e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 1dab3a9..18f61ff 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
return (unsigned long *)&vcpu->arch.hcr_el2;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 469de8a..357304a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -363,6 +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
void __kvm_set_tpidr_el2(u64 tpidr_el2);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 04b3256..df4faee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 56a0260..71d3841 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
+ (!!vcpu_get_vsesr(vcpu));
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index d8e7165..9e0ca56 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
*vcpu_hcr(vcpu) |= HCR_VSE;
}
@@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
pend_guest_serror(vcpu, ESR_ELx_ISV);
}
+
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome)
+{
+ pend_guest_serror(vcpu, syndrome);
+}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a4c1b76..8b43968 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1107,6 +1107,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_arm_vcpu_has_attr(vcpu, &attr);
break;
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ memset(&events, 0, sizeof(events));
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp,
+ sizeof(struct kvm_vcpu_events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
r = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] media: helene: fix tuning frequency of satellite
From: Abylay Ospan @ 2018-05-31 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004201d3f8bb$629d38c0$27d7aa40$@socionext.com>
ok, got it !
2018-05-31 4:43 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> Hello Abylay,
>
> I got a mistake in this patch.
>
> DTV_FREQUENCY for satellite delivery systems, the frequency is in 'kHz' not 'Hz',
> so original code is correct. Sorry for confusing...
>
>
> Regards,
> --
> Katsuhiro Suzuki
>
>
>> -----Original Message-----
>> From: Abylay Ospan <aospan@netup.ru>
>> Sent: Wednesday, May 16, 2018 7:58 PM
>> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
>> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
>> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
>> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
>> linux-kernel at vger.kernel.org
>> Subject: Re: [PATCH] media: helene: fix tuning frequency of satellite
>>
>> True.
>> I'm curious but how did it worked before ...
>> Which hardware (dvb adapter) are you using ?
>>
>> 2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
>> > This patch fixes tuning frequency of satellite to kHz. That as same
>> > as terrestrial one.
>> >
>> > Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
>> > ---
>> > drivers/media/dvb-frontends/helene.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/media/dvb-frontends/helene.c
>> b/drivers/media/dvb-frontends/helene.c
>> > index 04033f0c278b..0a4f312c4368 100644
>> > --- a/drivers/media/dvb-frontends/helene.c
>> > +++ b/drivers/media/dvb-frontends/helene.c
>> > @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
>> > enum helene_tv_system_t tv_system;
>> > struct dtv_frontend_properties *p = &fe->dtv_property_cache;
>> > struct helene_priv *priv = fe->tuner_priv;
>> > - int frequencykHz = p->frequency;
>> > + int frequencykHz = p->frequency / 1000;
>> > uint32_t frequency4kHz = 0;
>> > u32 symbol_rate = p->symbol_rate/1000;
>> >
>> > --
>> > 2.17.0
>> >
>>
>>
>>
>> --
>> Abylay Ospan,
>> NetUP Inc.
>> http://www.netup.tv
>
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Tero Kristo @ 2018-05-31 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e7e3ade1-76b7-f216-ece5-bd64a55cede6@ti.com>
On 31/05/18 13:14, Faiz Abbas wrote:
> Hi,
>
> On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
>> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>>> Add clkctrl data for the m_can clocks and register it within the
> ...
>>>
>>> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
>>> index 5e1061b15aed..d7549c57cac3 100644
>>> --- a/include/dt-bindings/clock/dra7.h
>>> +++ b/include/dt-bindings/clock/dra7.h
>>> @@ -168,5 +168,6 @@
>>> #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
>>> #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
>>> #define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
>>> +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
>>
>> ADC and mcan are the same thing?
>>
>
> The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
Is there any reason for this or is that just a documentation bug?
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH 0/3] Initial Spectre variant 1 patches
From: Russell King - ARM Linux @ 2018-05-31 13:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series adds initial support for the Spectre variant 1 workarounds
to the kernel. This does _not_ cover the user accessors, which are
still in development.
The series adds support for the array_index_mask_nospec() macro, used
by generic kernel code to mask out of bounds pointers, and also adds
the syscall table hardening.
arch/arm/include/asm/assembler.h | 8 ++++++++
arch/arm/include/asm/barrier.h | 31 +++++++++++++++++++++++++++++++
arch/arm/kernel/entry-common.S | 14 +++-----------
arch/arm/kernel/entry-header.S | 25 +++++++++++++++++++++++++
4 files changed, 67 insertions(+), 11 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/3] ARM: spectre-v1: add speculation barrier (csdb) macros
From: Russell King @ 2018-05-31 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
Add assembly and C macros for the new CSDB instruction.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/assembler.h | 8 ++++++++
arch/arm/include/asm/barrier.h | 13 +++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index bc8d4bbd82e2..ef1386b1af9b 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -447,6 +447,14 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
.size \name , . - \name
.endm
+ .macro csdb
+#ifdef CONFIG_THUMB2_KERNEL
+ .inst.w 0xf3af8014
+#else
+ .inst 0xe320f014
+#endif
+ .endm
+
.macro check_uaccess, addr:req, size:req, limit:req, tmp:req, bad:req
#ifndef CONFIG_CPU_USE_DOMAINS
adds \tmp, \addr, #\size - 1
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 40f5c410fd8c..3d9c1d4b7e75 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -17,6 +17,12 @@
#define isb(option) __asm__ __volatile__ ("isb " #option : : : "memory")
#define dsb(option) __asm__ __volatile__ ("dsb " #option : : : "memory")
#define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
+#ifdef CONFIG_THUMB2_KERNEL
+#define CSDB ".inst.w 0xf3af8014"
+#else
+#define CSDB ".inst 0xe320f014"
+#endif
+#define csdb() __asm__ __volatile__(CSDB : : : "memory")
#elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
#define isb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
: : "r" (0) : "memory")
@@ -37,6 +43,13 @@
#define dmb(x) __asm__ __volatile__ ("" : : : "memory")
#endif
+#ifndef CSDB
+#define CSDB
+#endif
+#ifndef csdb
+#define csdb()
+#endif
+
#ifdef CONFIG_ARM_HEAVY_MB
extern void (*soc_mb)(void);
extern void arm_heavy_mb(void);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: spectre-v1: add array_index_mask_nospec() implementation
From: Russell King @ 2018-05-31 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
Add an implementation of the array_index_mask_nospec() function for
mitigating Spectre variant 1 throughout the kernel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/barrier.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 3d9c1d4b7e75..a89adcf53b99 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -76,6 +76,24 @@ extern void arm_heavy_mb(void);
#define __smp_rmb() __smp_mb()
#define __smp_wmb() dmb(ishst)
+#ifdef CONFIG_CPU_SPECTRE
+static inline unsigned long array_index_mask_nospec(unsigned long idx,
+ unsigned long sz)
+{
+ unsigned long mask;
+
+ asm( "cmp %1, %2\n"
+ " sbc %0, %1, %1\n"
+ CSDB
+ : "=r" (mask)
+ : "r" (idx), "Ir" (sz)
+ : "cc");
+
+ return mask;
+}
+#define array_index_mask_nospec array_index_mask_nospec
+#endif
+
#include <asm-generic/barrier.h>
#endif /* !__ASSEMBLY__ */
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: spectre-v1: fix syscall entry
From: Russell King @ 2018-05-31 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
Prevent speculation at the syscall table decoding by clamping the index
used to zero on invalid system call numbers, and using the csdb
speculative barrier.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/kernel/entry-common.S | 14 +++-----------
| 25 +++++++++++++++++++++++++
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3c4f88701f22..78b9f20dd6a3 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -242,9 +242,7 @@ ENTRY(vector_swi)
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
bne __sys_trace
- cmp scno, #NR_syscalls @ check upper syscall limit
- badr lr, ret_fast_syscall @ return address
- ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
+ invoke_syscall tbl, scno, r10, ret_fast_syscall
add r1, sp, #S_OFF
2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
@@ -278,14 +276,8 @@ ENDPROC(vector_swi)
mov r1, scno
add r0, sp, #S_OFF
bl syscall_trace_enter
-
- badr lr, __sys_trace_return @ return address
- mov scno, r0 @ syscall number (possibly new)
- add r1, sp, #S_R0 + S_OFF @ pointer to regs
- cmp scno, #NR_syscalls @ check upper syscall limit
- ldmccia r1, {r0 - r6} @ have to reload r0 - r6
- stmccia sp, {r4, r5} @ and update the stack args
- ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
+ mov scno, r0
+ invoke_syscall tbl, scno, r10, __sys_trace_return, reload=1
cmp scno, #-1 @ skip the syscall?
bne 2b
add sp, sp, #S_OFF @ restore stack
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index 0f07579af472..773424843d6e 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -378,6 +378,31 @@
#endif
.endm
+ .macro invoke_syscall, table, nr, tmp, ret, reload=0
+#ifdef CONFIG_CPU_SPECTRE
+ mov \tmp, \nr
+ cmp \tmp, #NR_syscalls @ check upper syscall limit
+ movcs \tmp, #0
+ csdb
+ badr lr, \ret @ return address
+ .if \reload
+ add r1, sp, #S_R0 + S_OFF @ pointer to regs
+ ldmccia r1, {r0 - r6} @ reload r0-r6
+ stmccia sp, {r4, r5} @ update stack arguments
+ .endif
+ ldrcc pc, [\table, \tmp, lsl #2] @ call sys_* routine
+#else
+ cmp \nr, #NR_syscalls @ check upper syscall limit
+ badr lr, \ret @ return address
+ .if \reload
+ add r1, sp, #S_R0 + S_OFF @ pointer to regs
+ ldmccia r1, {r0 - r6} @ reload r0-r6
+ stmccia sp, {r4, r5} @ update stack arguments
+ .endif
+ ldrcc pc, [\table, \nr, lsl #2] @ call sys_* routine
+#endif
+ .endm
+
/*
* These are the registers used in the syscall handler, and allow us to
* have in theory up to 7 arguments to a function - r0 to r6.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-31 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be0fd711-c44b-dbe2-648f-08aa88c7aec4@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 11:27]:
> On Thursday 31 May 2018 09:36 AM, Rob Herring wrote:
> > On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
> >> --- a/arch/arm/boot/dts/dra76x.dtsi
> >> +++ b/arch/arm/boot/dts/dra76x.dtsi
> >> @@ -11,6 +11,25 @@
> >> / {
> >> compatible = "ti,dra762", "ti,dra7";
> >>
> >> + ocp {
> >> +
> >> + target-module at 0x42c00000 {
> >
> > Build your dtb with W=1 and fix warnings you add (drop '0x').
>
> Sure, Will fix this.
> >
> > This is a CAN bus controller? If so, then use 'can' for node name.
>
> Yes but I am using m_can along the lines of dcan in other boards (For
> example, see arch/arm/boot/dts/am33xx.dtsi:1046). Are you saying all CAN
> controllers should only be called can?
The module should be target-module at 42c00000 and the child(ren)
can at 1a00 or mcan at 1a00 if mcan is different from can.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-31 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2361da91-659d-1aaa-0ab8-d1473bc3a71a@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 10:22]:
> On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
> > Looks good to me except I think the reset won't do anything currently
> > with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
> >
> > Can you please check? It might be worth adding the reset function to
> > ti-sysc.c for non "ti,hwmods" case and that just might remove the
> > need for any hwmod code for this module.
> >
>
> If I understand correctly, this involves adding a (*reset_module) in
> ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
> similar to ti_sysc_idle_module(). Right?
Well try moving "ti,hwmods" to the module level first. Then reset will
happen with enable.
Then for simple cases we can add reset directly to ti-sysc.c without
pdata callbacks and and drop "ti,hwmods". For more complex cases we
need to use reset-simple for the RSTCTRL registers.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/4] arm64: capabilities: add nopti command line argument
From: Mark Langsdorf @ 2018-05-31 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b1b39e3-38ab-848a-a1d3-d23db85b0e14@arm.com>
On 05/30/2018 03:59 AM, Suzuki K Poulose wrote:
>
>
> Hi Mark,
>
> On 24/05/18 20:09, Mark Langsdorf wrote:
>> The x86 kernel and the documentation use 'nopti' as the kernel command
>> line argument to disable kernel page table isolation, so add nopti to
>> the arm64 kernel for compatibility.
>>
>> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
>> ---
>> ? Documentation/admin-guide/kernel-parameters.txt |? 6 +++---
>> ? arch/arm64/kernel/cpufeature.c????????????????? | 11 ++++++++++-
>> ? 2 files changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index f2040d4..a987725 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3342,8 +3342,8 @@
>> ????? pt.??????? [PARIDE]
>> ????????????? See Documentation/blockdev/paride.txt.
>> -??? pti=??????? [X86_64] Control Page Table Isolation of user and
>> -??????????? kernel address spaces.? Disabling this feature
>> +??? pti=??????? [X86_64, ARM64] Control Page Table Isolation of user
>> +??????????? and kernel address spaces.? Disabling this feature
>> ????????????? removes hardening, but improves performance of
>> ????????????? system calls and interrupts.
>
> ...
>
>> @@ -3354,7 +3354,7 @@
>> ????????????? Not specifying this option is equivalent to pti=auto.
>> -??? nopti??????? [X86_64]
>> +??? nopti??????? [X86_64, ARM64]
>> ????????????? Equivalent to pti=off
>> ????? pty.legacy_count=
>> diff --git a/arch/arm64/kernel/cpufeature.c
>> b/arch/arm64/kernel/cpufeature.c
>> index 9d1b06d..7c5d8712 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -934,10 +934,19 @@ static int __init parse_kpti(char *str)
>> ????? if (ret)
>> ????????? return ret;
>> -??? __kpti_forced = enabled ? 1 : -1;
>> +??? if (!__kpti_forced)
>> +??????? __kpti_forced = enabled ? 1 : -1;
>> ????? return 0;
>> ? }
>> ? __setup("kpti=", parse_kpti);
>
> The arm64 kernel parameter is named "kpti", while the Documentation
> update above says "pti". We may want to keep both in sync here.
Good point. I think I will add a new kpti entry for ARM64 in
kernel-parameters. Then the docs match the code, instead of trying to
match the code to the docs.
--Mark Langsdorf
^ permalink raw reply
* [PATCH 0/7] add non-strict mode support for arm-smmu-v3
From: Hanjun Guo @ 2018-05-31 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d65f87a4-db61-3cd2-1a6f-0322025840a8@arm.com>
Hi Robin,
On 2018/5/31 19:24, Robin Murphy wrote:
> On 31/05/18 08:42, Zhen Lei wrote:
>> In common, a IOMMU unmap operation follow the below steps:
>> 1. remove the mapping in page table of the specified iova range
>> 2. execute tlbi command to invalid the mapping which is cached in TLB
>> 3. wait for the above tlbi operation to be finished
>> 4. free the IOVA resource
>> 5. free the physical memory resource
>>
>> This maybe a problem when unmap is very frequently, the combination of tlbi
>> and wait operation will consume a lot of time. A feasible method is put off
>> tlbi and iova-free operation, when accumulating to a certain number or
>> reaching a specified time, execute only one tlbi_all command to clean up
>> TLB, then free the backup IOVAs. Mark as non-strict mode.
>>
>> But it must be noted that, although the mapping has already been removed in
>> the page table, it maybe still exist in TLB. And the freed physical memory
>> may also be reused for others. So a attacker can persistent access to memory
>> based on the just freed IOVA, to obtain sensible data or corrupt memory. So
>> the VFIO should always choose the strict mode.
>>
>> Some may consider put off physical memory free also, that will still follow
>> strict mode. But for the map_sg cases, the memory allocation is not controlled
>> by IOMMU APIs, so it is not enforceable.
>>
>> Fortunately, Intel and AMD have already applied the non-strict mode, and put
>> queue_iova() operation into the common file dma-iommu.c., and my work is based
>> on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to
>> unmap, but Intel and AMD IOMMU drivers are not.
>>
>> Below is the performance data of strict vs non-strict for NVMe device:
>> Randomly Read? IOPS: 146K(strict) vs 573K(non-strict)
>> Randomly Write IOPS: 143K(strict) vs 513K(non-strict)
>
> What hardware is this on? If it's SMMUv3 without MSIs (e.g. D05), then you'll still be using the rubbish globally-blocking sync implementation. If that is the case, I'd be very interested to see how much there is to gain from just improving that - I've had a patch kicking around for a while[1] (also on a rebased branch at [2]), but don't have the means for serious performance testing.
The hardware is the new D06 which the SMMU with MSIs,
it's not D05 :)
Thanks
Hanjun
^ permalink raw reply
* [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Tony Lindgren @ 2018-05-31 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b627ab6-59f1-4a4f-42d2-5d6846adfe0b@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 10:17]:
> Hi,
>
> On Wednesday 30 May 2018 08:27 PM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> >> The dra76x MCAN generic interconnect module has a its own
> >> format for the bits in the control registers.
> ...
> >> static int sysc_init_pdata(struct sysc *ddata)
> >> {
> >> struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
> >> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
> >> { .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
> >> { .compatible = "ti,sysc-usb-host-fs",
> >> .data = &sysc_omap4_usb_host_fs, },
> >> + { .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
> >> { },
> >> };
> >
> > Looks good to me. And presumably you checked that no other dra7 modules
> > use sysconfig register bit layout like this?
> >
>
> As far as I could see, Yes.
OK thanks for checking it.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2] arm64/drivers: avoid alloc memory on offline node
From: Hanjun Guo @ 2018-05-31 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527768879-88161-1-git-send-email-xiexiuqi@huawei.com>
Hi Xiuqi,
On 2018/5/31 20:14, Xie XiuQi wrote:
> A numa system may return node which is not online.
> For example, a numa node:
> 1) without memory
> 2) NR_CPUS is very small, and the cpus on the node are not brought up
I think adding detail info will be easy to be understood:
- NUMA node will be built if CPUs and (or) memory are valid on this NUMA node;
- But if we boot the system with memory-less node and also with CONFIG_NR_CPUS
less than CPUs in SRAT, for example, 64 CPUs total with 4 NUMA nodes, 16 CPUs
on each NUMA node, if we boot with CONFIG_NR_CPUS=48, then we will not built
numa node for node 3, but with devices on that numa node, alloc memory will
be panic because NUMA node 3 is not a valid node.
>
> In this situation, we use NUMA_NO_NODE to avoid oops.
[snip]
>
> Xie XiuQi (2):
> arm64: avoid alloc memory on offline node
> drivers: check numa node's online status in dev_to_node
I think we still missing devices like SMMU, ITS, so how about check
the numa node online in the core memory allocation such as kmalloc_node()?
Thanks
Hanjun
^ permalink raw reply
* [PATCH 00/12] introduce support for early platform drivers
From: Tony Lindgren @ 2018-05-31 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUY+-_72DHg9Tim2d4E24k5KskQxm52bHSyrSYLbZDr2g@mail.gmail.com>
* Geert Uytterhoeven <geert@linux-m68k.org> [180531 06:45]:
> Yes, they should all be drivers.
>
> Assuming clocksources, clockevents, or primary interrupt controllers are
> special, and thus forcing everyone to use OF_DECLARE for the whole
> subsystem, doesn't fly everywhere.
>
> Clockevents and interrupt controllers can have a module clock.
> All three can be part of a PM Domain, which requires a struct device to
> be handled properly.
I agree it sure would be nice to have all these as drivers. I believe
SoC specific clockevent using SoC specific clocks is the reason why some
clocks cannot currently be drivers.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] ARM: spectre-v1: add speculation barrier (csdb) macros
From: Mark Rutland @ 2018-05-31 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fONfc-000708-MX@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 02:31:12PM +0100, Russell King wrote:
> Add assembly and C macros for the new CSDB instruction.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Looks correct to me per the Cache Speculation Side-chaneels 2.1
document.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm/include/asm/assembler.h | 8 ++++++++
> arch/arm/include/asm/barrier.h | 13 +++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index bc8d4bbd82e2..ef1386b1af9b 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -447,6 +447,14 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
> .size \name , . - \name
> .endm
>
> + .macro csdb
> +#ifdef CONFIG_THUMB2_KERNEL
> + .inst.w 0xf3af8014
> +#else
> + .inst 0xe320f014
> +#endif
> + .endm
> +
> .macro check_uaccess, addr:req, size:req, limit:req, tmp:req, bad:req
> #ifndef CONFIG_CPU_USE_DOMAINS
> adds \tmp, \addr, #\size - 1
> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> index 40f5c410fd8c..3d9c1d4b7e75 100644
> --- a/arch/arm/include/asm/barrier.h
> +++ b/arch/arm/include/asm/barrier.h
> @@ -17,6 +17,12 @@
> #define isb(option) __asm__ __volatile__ ("isb " #option : : : "memory")
> #define dsb(option) __asm__ __volatile__ ("dsb " #option : : : "memory")
> #define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define CSDB ".inst.w 0xf3af8014"
> +#else
> +#define CSDB ".inst 0xe320f014"
> +#endif
> +#define csdb() __asm__ __volatile__(CSDB : : : "memory")
> #elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
> #define isb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
> : : "r" (0) : "memory")
> @@ -37,6 +43,13 @@
> #define dmb(x) __asm__ __volatile__ ("" : : : "memory")
> #endif
>
> +#ifndef CSDB
> +#define CSDB
> +#endif
> +#ifndef csdb
> +#define csdb()
> +#endif
> +
> #ifdef CONFIG_ARM_HEAVY_MB
> extern void (*soc_mb)(void);
> extern void arm_heavy_mb(void);
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4f2e6e6a-df3a-b645-093c-b4467b3aa843@microchip.com>
On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
<codrin.ciubotariu@microchip.com> wrote:
> On 31.05.2018 03:58, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>>>
>>> The I2S mux clock can be used to select the I2S input clock. The
>>> available parents are the peripheral and the generated clocks.
>>>
>>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>>> ---
>>> .../devicetree/bindings/clock/at91-clock.txt | 34
>>> ++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> index 51c259a..1c46b3c 100644
>>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> @@ -90,6 +90,8 @@ Required properties:
>>> "atmel,sama5d2-clk-audio-pll-pmc"
>>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>>> and can be used by peripheral clock or generic clock
>>> + "atmel,sama5d2-clk-i2s-mux":
>>> + at91 I2S clock source selection
>>
>>
>> Is this boolean or takes some values. If latter, what are valid values?
>
>
> This is the compatible string of the clock driver.
Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
still a plan to fix this?
>>> Required properties for SCKC node:
>>> - reg : defines the IO memory reserved for the SCKC.
>>> @@ -507,3 +509,35 @@ For example:
>>> atmel,clk-output-range = <0 83000000>;
>>> };
>>> };
>>> +
>>> +Required properties for I2S mux clocks:
>>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>>> +- name: device tree node describing a specific mux clock.
>>> + * #clock-cells : from common clock binding; shall be set to 0.
>>> + * clocks : shall be the mux clock parent phandles; shall be 2
>>> phandles:
>>> + peripheral and generated clock; the first phandle shall belong
>>> to the
>>> + peripheral clock and the second one shall belong to the
>>> generated
>>> + clock; "clock-indices" property can be user to specify
>>> + the correct order.
>>> + * reg: I2S bus id of the corresponding mux clock.
>>> + e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>>> +
>>> +For example:
>>> + i2s_clkmux {
>>
>>
>> What is this a child of?
>
>
> It is a child of PMC node, since both parent clocks are generated by PMC.
>
>>
>>> + compatible = "atmel,sama5d2-clk-i2s-mux";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>
>>
>> How do you address this block? My guess is you don't because it is just
>> part of some other block and you are just creating this node to
>> instantiate a driver. Just make the node for the actual h/w block a
>> clock provider and define the clock ids (0 and 1).
>
>
> This block is not addressed, but its children are. The register we access in
> this driver is not part of other block. It's a SFR register, accessed
> through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
> page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
> clock. Adding a clock-id property in the I2S node would be just like v3 of
> this series, with the difference that we use clock-id instead of alias id to
> set the clock parent, which is not how you suggested back then.
I wasn't suggesting a clock-id property, but a clock specifier (i.e.
make #clock-cells 1).
But AT91 clocks are all a mess, so I don't know what to tell you.
Rob
^ permalink raw reply
* [PATCH 2/3] ARM: spectre-v1: add array_index_mask_nospec() implementation
From: Mark Rutland @ 2018-05-31 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fONfh-00070F-Tw@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 02:31:17PM +0100, Russell King wrote:
> Add an implementation of the array_index_mask_nospec() function for
> mitigating Spectre variant 1 throughout the kernel.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> arch/arm/include/asm/barrier.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> index 3d9c1d4b7e75..a89adcf53b99 100644
> --- a/arch/arm/include/asm/barrier.h
> +++ b/arch/arm/include/asm/barrier.h
> @@ -76,6 +76,24 @@ extern void arm_heavy_mb(void);
> #define __smp_rmb() __smp_mb()
> #define __smp_wmb() dmb(ishst)
>
> +#ifdef CONFIG_CPU_SPECTRE
> +static inline unsigned long array_index_mask_nospec(unsigned long idx,
> + unsigned long sz)
> +{
> + unsigned long mask;
> +
> + asm( "cmp %1, %2\n"
> + " sbc %0, %1, %1\n"
> + CSDB
> + : "=r" (mask)
> + : "r" (idx), "Ir" (sz)
> + : "cc");
> +
> + return mask;
> +}
> +#define array_index_mask_nospec array_index_mask_nospec
> +#endif
I believe that the asm should be volatile, otherwise there are cases
where the compiler could remove an invocation that's redundant under
architectural execution, but required under speculation [1].
With that made volatile:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
[1] https://lkml.kernel.org/r/20180530060546.jnjoltsturoduohh at salmiak
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox