It was added by commit 137e5531351d ("vfio/pci: Add sriov_configure
support") and actually unnecessary. Remove it.
Signed-off-by: Zenghui Yu
---
drivers/vfio/pci/vfio_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_p
ually used, so it shouldn't be that important. Remove
it.
Signed-off-by: Zenghui Yu
---
drivers/vfio/pci/vfio_pci_config.c | 7 ---
drivers/vfio/pci/vfio_pci_private.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_conf
hing worse would
happen. But let's be careful.
Signed-off-by: Zenghui Yu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index c1
Use the ktime_us_delta() helper to measure the driver probe time. Given the
helpers already returns an s64 value, let's drop the unnecessary casting to
s64 as well. There is no functional change.
Signed-off-by: Zenghui Yu
---
drivers/base/dd.c | 5 ++---
1 file changed, 2 insertions(+), 3
ate the vfio_bar_fixup() on the bardirty so that it can return
immediately if !bardirty.
Suggested-by: Alex Williamson
Signed-off-by: Zenghui Yu
---
* From v1:
- Per Alex's suggestion, let vfio_bar_fixup() test vdev->bardirty to
avoid doing work if bardirty is false, instead of re
It was added by commit 137e5531351d ("vfio/pci: Add sriov_configure
support") but duplicates a forward declaration earlier in the file.
Remove it.
Signed-off-by: Zenghui Yu
Reviewed-by: Cornelia Huck
---
* From v1:
- Clarify the commit message per Alex's suggestion.
- Add Corn
Hi Cornelia,
On 2020/9/21 18:21, Cornelia Huck wrote:
On Mon, 21 Sep 2020 12:51:16 +0800
Zenghui Yu wrote:
Now we regenerate vconfig for all the BARs via vfio_bar_fixup(), every time
any offset of any of them are read. Though BARs aren't re-read regularly,
the regeneration can be avoid
A typo fix ("_RUNNNG" => "_RUNNING") in comment block of the uapi header.
Signed-off-by: Zenghui Yu
---
include/uapi/linux/vfio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 9204705023
On 2020/12/15 18:30, Geert Uytterhoeven wrote:
arch/arm64/kernel/smp.c: In function ‘arch_show_interrupts’:
arch/arm64/kernel/smp.c:808:16: warning: unused variable ‘irq’
[-Wunused-variable]
808 | unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
|
ation in IRQ core layer for
msi_domain_prepare_irqs() API and it looks much neater to me.
Signed-off-by: Zenghui Yu
---
This was noticed when I was playing with the assigned devices on arm64 and
VFIO failed to enable MSI-X vectors for almost all VFs (CCed kvm list in
case others will hit the same issue). It tu
Hi Marc,
On 2020/12/19 1:38, Marc Zyngier wrote:
Hi Zenghui,
On Fri, 18 Dec 2020 06:00:39 +,
Zenghui Yu wrote:
Since commit 5fe71d271df8 ("irqchip/gic-v3-its: Tag ITS device as shared if
allocating for a proxy device"), some of the devices are wrongly marked as
"sha
We actually use dev_addr[26:13] as the index into dma_entry_hash. Given
that the code itself is clear enough, let's drop the hardcoded comment so
that we won't need to revisit it every time HASH_FN_{SHIFT,MASK} gets
updated.
Signed-off-by: Zenghui Yu
---
kernel/dma/debug.c | 5 +
1 file
in it, which is pretty bad and the kernel
happily kills itself because of a Current EL Data Abort (on arm64).
Moving the CMDQ uninitialization a bit early fixes the issue for me.
Signed-off-by: Zenghui Yu
---
I have almost zero knowledge about the hns3 driver. You can regard this
as a report and make
On 2020/10/23 14:22, Yunsheng Lin wrote:
On 2020/10/23 13:15, Zenghui Yu wrote:
When unbinding the hns3 driver with the HNS3 VF, I got the following
kernel panic:
[ 265.709989] Unable to handle kernel paging request at virtual address
800054627000
[ 265.717928] Mem abort info
tested it with QEMU. It'd be appreciated if others can test it
with other user tools.
Zenghui Yu (2):
KVM: arm64: vgic: Forbid invalid userspace Redistributor accesses
KVM: arm64: vgic: Forbid invalid userspace Distributor accesses
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 8
1 file changed
issue by informing userspace what had gone wrong (-ENXIO).
Reported-by: Keqian Zhu
Signed-off-by: Zenghui Yu
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 52d6f2
(-ENXIO).
Signed-off-by: Zenghui Yu
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 30e370585a27..6a9e5eb311f0 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch
When attaching a new group to the container, let's use the new helper
vfio_iommu_find_iommu_group() to check if it's already attached. There
is no functional change.
Also take this chance to add a missing blank line.
Signed-off-by: Zenghui Yu
---
drivers/vfio/vfio_iommu_type1.c | 17
c ;-)
[1] https://lore.kernel.org/kvmarm/c20865a267e44d1e2c0d52ce4e012...@kernel.org/
Fixes: ba7b3f1275fd ("KVM: arm/arm64: Revisit Redistributor TYPER last bit
computation")
Reported-by: Keqian Zhu
Signed-off-by: Zenghui Yu
---
This may be the easiest way to fix the issue and
Hi Marc,
On 2020/11/16 1:04, Marc Zyngier wrote:
Hi Zenghui,
On 2020-11-13 14:28, Zenghui Yu wrote:
It's expected that users will access registers in the redistributor *if*
the RD has been initialized properly. Unfortunately userspace can be
bogus
enough to access registers before setting
Hi Marc,
On 2020/11/16 22:10, Marc Zyngier wrote:
My take is that only if the "[Re]Distributor base address" is specified
in the system memory map, will the user-provided kvm_device_attr.offset
make sense. And we can then handle the access to the register which is
defined by "base address +
On 2020/11/17 16:49, Marc Zyngier wrote:
Hi Zenghui,
On 2020-11-16 14:57, Zenghui Yu wrote:
Hi Marc,
On 2020/11/16 22:10, Marc Zyngier wrote:
My take is that only if the "[Re]Distributor base address" is specified
in the system memory map, will the user-provided kvm_device_attr.o
Hi Shameer,
On 2020/11/30 18:26, Shameer Kolothum wrote:
At present, the support for GICv2 backward compatibility on GICv3/v4
hardware is determined based on whether DT/ACPI provides a memory
mapped phys base address for GIC virtual CPU interface register(GICV).
This creates a problem that a
On 2019/8/30 16:42, Steven Price wrote:
Implement the service call for configuring a shared structure between a
VCPU and the hypervisor in which the hypervisor can write the time
stolen from the VCPU's execution time by other tasks on the host.
The hypervisor allocates memory which is placed at
Hi Marc,
On 2019/8/6 18:01, Marc Zyngier wrote:
Add the required support for the ESPI range, which behave exactly like
the SPIs of old, only with new funky INTIDs.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 85 --
Hi Marc,
On 2019/8/6 18:01, Marc Zyngier wrote:
gic_configure_irq is currently passed the (re)distributor address,
to which it applies an a fixed offset to get to the configuration
registers. This offset is constant across all GICs, or rather it was
until to v3.1...
An easy way out is for the
On 2020/8/18 11:49, Hanjun Guo wrote:
On 2020/8/17 18:59, Zenghui Yu wrote:
Since commit d2e1a003af56 ("ACPI/IORT: Don't call iommu_ops->add_device
directly"), we use the IOMMU core API to replace a direct invoke of the
specified callback. The parameter @ops has therefore became
Since commit d2e1a003af56 ("ACPI/IORT: Don't call iommu_ops->add_device
directly"), we use the IOMMU core API to replace a direct invoke of the
specified callback. The parameter @ops has therefore became unused. Let's
drop it.
Signed-off-by: Zenghui Yu
---
drivers/acpi/arm
Since commit 8212688600ed ("ACPI/IORT: Fix build error when IOMMU_SUPPORT
is disabled"), iort_fwspec_iommu_ops() and iort_add_device_replay() are not
needed anymore when CONFIG_IOMMU_API is not selected. Let's remove them.
Signed-off-by: Zenghui Yu
---
drivers/acpi/arm64/iort.c | 4 --
* From v1 [1]:
- As pointed out by Hanjun, remove two now unused inline functions.
Compile tested with CONFIG_IOMMU_API is not selected.
[1] https://lore.kernel.org/r/20200817105946.1511-1-yuzeng...@huawei.com
Zenghui Yu (2):
ACPI/IORT: Drop the unused @ops of iort_add_device_replay
Since commit d2e1a003af56 ("ACPI/IORT: Don't call iommu_ops->add_device
directly"), we use the IOMMU core API to replace a direct invoke of the
specified callback. The parameter @ops has therefore became unused. Let's
drop it.
Signed-off-by: Zenghui Yu
---
drivers/acpi/arm
Hi Alex,
On 2020/9/18 6:07, Alex Williamson wrote:
On Thu, 17 Sep 2020 13:35:37 +0200
Cornelia Huck wrote:
On Thu, 17 Sep 2020 11:31:28 +0800
Zenghui Yu wrote:
It isn't clear what purpose the @bardirty serves. It might be used to avoid
the unnecessary vfio_bar_fixup() invoking on a user
On 2020/9/18 6:22, Alex Williamson wrote:
On Thu, 17 Sep 2020 11:31:27 +0800
Zenghui Yu wrote:
It was added by commit 137e5531351d ("vfio/pci: Add sriov_configure
support") and actually unnecessary. Remove it.
Looks correct, but I might clarify as:
s/unnecessary/duplicates
On 2020/9/19 10:11, Alex Williamson wrote:
On Sat, 19 Sep 2020 09:54:00 +0800
Zenghui Yu wrote:
Hi Alex,
On 2020/9/18 6:07, Alex Williamson wrote:
On Thu, 17 Sep 2020 13:35:37 +0200
Cornelia Huck wrote:
On Thu, 17 Sep 2020 11:31:28 +0800
Zenghui Yu wrote:
It isn't clear what
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
Add a new specific DMA_FAULT region aiming to exposed nested mode
translation faults.
The region has a ring buffer that contains the actual fault
records plus a header allowing to handle it (tail/head indices,
max capacity, entry size). At the
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
Register an IOMMU fault handler which records faults in
the DMA FAULT region ring buffer. In a subsequent patch, we
will add the signaling of a specific eventfd to allow the
userspace to be notified whenever a new fault as shown up.
Signed-off-by:
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
The VFIO API was enhanced to support nested stage control: a bunch of
new iotcls, one DMA FAULT region and an associated specific IRQ.
Let's document the process to follow to set up nested mode.
Signed-off-by: Eric Auger
[...]
+The userspace
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
From: "Liu, Yi L"
This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
which aims to pass the virtual iommu guest configuration
to the host. This latter takes the form of the so-called
PASID table.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi
nction - kvm_pmu_vcpu_init()
for this basic setup. Oh, and the KASAN BUG will get fixed this way.
[1] https://www.spinics.net/lists/kvm-arm/msg36700.html
Fixes: 80f393a23be6 ("KVM: arm/arm64: Support chained PMU counters")
Suggested-by: Andrew Murray
Suggested-by: Julien Thierry
Cc: Mar
(...), 1020).
Signed-off-by: Zenghui Yu
---
Hi Marc,
I still see "GICv3: 992 SPIs implemented" on the host. I go back to
https://patchwork.kernel.org/patch/11078623/ and it seems that we
failed to make the GIC_LINE_NR correct at that time.
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file
of ERR_PTR() in kernel.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Zenghui Yu
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm
On 2020/5/9 17:56, Hanjun Guo wrote:
On 2020/5/9 17:34, Zenghui Yu wrote:
Since commit bc8648d49a95 ("ACPI/IORT: Handle PCI aliases properly for
IOMMUs"), __get_pci_rid() has become actually unused and can be removed.
Signed-off-by: Zenghui Yu
Looks good to me,
Acked-by: Hanjun
Hi Alex,
On 2020/5/30 18:46, Alexandru Elisei wrote:
Hi,
On 4/20/20 5:10 PM, Alexandru Elisei wrote:
[ For some unknown reasons, I had missed your reply one month ago.
Sorry, I'm going to fix my email settings ... ]
Hi,
On 4/15/20 8:28 AM, Zenghui Yu wrote:
stage2_unmap_vm
Hi,
On 2020/5/29 9:55, Ali Saidi wrote:
If an interrupt is disabled the ITS driver has sent a discard removing
the DeviceID and EventID from the ITT. After this occurs it can't be
moved to another collection with a MOVI and a command error occurs if
attempted. Before issuing the MOVI command
helps to get the v4.1
board back to life!
Fixes: 96806229ca03 ("irqchip/gic-v4.1: Add support for VPENDBASER's
Dirty+Valid signaling")
Signed-off-by: Zenghui Yu
---
drivers/irqchip/irq-gic-v3-its.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/
On 2019/8/12 18:39, Steven Price wrote:
On 09/08/2019 14:51, Zenghui Yu wrote:
[...]
Hi Steven,
Since userspace is not involved yet (right?), no one will create the
PV_TIME device for guest (and no one will specify the IPA of the shared
stolen time region), and I guess we will get
On 2019/8/6 18:01, Marc Zyngier wrote:
GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs),
^^
legacy?
Zenghui
meaning we can't just leave the old 16 hardcoded everywhere.
We also need to add the infrastructure to discover the number of
Hi Steven,
On 2019/8/21 23:36, Steven Price wrote:
Enable paravirtualization features when running under a hypervisor
supporting the PV_TIME_ST hypercall.
For each (v)CPU, we ask the hypervisor for the location of a shared
page which the hypervisor will use to report stolen time to us. We set
Hi Steven,
Only one comment, at the bottom.
On 2019/8/21 23:36, Steven Price wrote:
Implement the service call for configuring a shared structure between a
VCPU and the hypervisor in which the hypervisor can write the time
stolen from the VCPU's execution time by other tasks on the host.
The
Hi Marc,
On 2020/6/30 21:37, Zenghui Yu wrote:
Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1 enabled
box, I get the following kernel splat:
[0.053766] BUG: sleeping function called from invalid context at
mm/slab.h:567
[0.053767] in_atomic(): 1, irqs_disabled(): 128
Hi Marc,
On 2020/7/17 19:07, Marc Zyngier wrote:
On Thu, 09 Jul 2020 14:49:59 +0100,
Zenghui Yu wrote:
The GICv4.1 spec tells us that it's CONSTRAINED UNPREDICTABLE to issue a
register-based invalidation operation for a vPEID not mapped to that RD,
or another RD within the same CommonLPIAff
exclusion between vPE
affinity change and RD access")
Cc: sta...@vger.kernel.org
Signed-off-by: Zenghui Yu
---
* From v1:
- Add a proper Fixes: tag
- Cc stable
drivers/irqchip/irq-gic-v3-its.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/irq
The is_fwnode_irqchip() helper will check if the fwnode_handle is empty.
There is no need to perform a redundant check outside of it.
Signed-off-by: Zenghui Yu
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq
Fix typo in the comment on top of __irq_domain_add().
Signed-off-by: Zenghui Yu
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index a453e22..db7b713 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel
Hi James,
On 2019/6/12 20:48, James Morse wrote:
Hi,
On 12/06/2019 10:08, Zenghui Yu wrote:
In current KVM/ARM code, no one will invoke trace_kvm_mmio_emulate().
Remove this TRACE_EVENT definition.
Oooer. We can't just go removing these things, they are visible to user-space.
I recall
Since commit bc8648d49a95 ("ACPI/IORT: Handle PCI aliases properly for
IOMMUs"), __get_pci_rid() has become actually unused and can be removed.
Signed-off-by: Zenghui Yu
---
drivers/acpi/arm64/iort.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c
Zyngier
Signed-off-by: Suzuki K Poulose
Signed-off-by: Zenghui Yu
---
virt/kvm/arm/mmu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index e3b9ee268823..557f36866d1c 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
This series was originally posted by Suzuki K Poulose a year ago [*],
with the aim of cleaning up the handling of the stage2 huge mapping for
THP. I think this still helps to make the current code cleaner, so
rebase it on top of kvmarm/master and repost it for acceptance.
Thanks!
[*]
Dall
Signed-off-by: Suzuki K Poulose
Signed-off-by: Zenghui Yu
---
virt/kvm/arm/mmu.c | 115 +++--
1 file changed, 60 insertions(+), 55 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 557f36866d1c..93a770fd2b5e 100644
--- a/virt/kvm
LPI idx). Remove it, and make the set_bit explicit by comment.
Signed-off-by: Zenghui Yu
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 472053c..7c69176 100644
Hi All,
Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1 enabled
box, I get the following kernel splat:
[0.053766] BUG: sleeping function called from invalid context at
mm/slab.h:567
[0.053767] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid:
0, name: swapper/1
Hi Marc,
On 2020/6/29 22:01, Marc Zyngier wrote:
Hi Zenghui,
On 2020-06-29 10:39, Zenghui Yu wrote:
Hi All,
Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1 enabled
box, I get the following kernel splat:
[0.053766] BUG: sleeping function called from invalid context at
mm
Hi Marc,
Sorry to ping you in the merge window, but ...
On 2020/6/5 13:23, Zenghui Yu wrote:
readx_poll_timeout() can sleep if @sleep_us is specified by the caller,
and is therefore unsafe to be used inside the atomic context, which is
this case when we use it to poll the GICR_VPENDBASER.Dirty
: 5e5168461c22 ("irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER)
allocation")
Signed-off-by: Zenghui Yu
---
drivers/irqchip/irq-gic-v3-its.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 6a
of them.
Signed-off-by: Zenghui Yu
---
Compile tested on top of mainline.
include/linux/irqchip/arm-gic-v3.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index 6c36b6cc3edf..f6d092fdb93d 100644
--- a/include
Hi All,
I had seen the following lockdep splat when booting a guest on my
Kunpeng 920 with GICv4 enabled. I can also trigger the same splat
on v5.5 so it should already exist in the kernel for a while. I'm
not sure what the exact problem is and hope someone can have a look!
Thanks,
Zenghui
[
On 2020/7/9 18:54, Salil Mehta wrote:
Hi Yuzenghui,
I will try to reproduce it today at our platform. Just one question is it easily
reproducible or is a rare occurrence?
Salil, it's 100% reproducible once you start a guest. You don't even
need to assign hostdev to the VM.
Thanks,
Zenghui
n vPE affinity change and RD access") tried to address the
race between the RD accesses and the vPE affinity change, but somehow
forgot to take GICR_INVALLR into account. Let's take the vpe_lock before
evaluating vpe->col_idx to fix it.
Signed-off-by: Zenghui Yu
---
drivers/irqchip/irq-gic-
it down
after drm_dev_register() which will follow the "Display driver example"
documented by commit de99f0600a79 ("drm/drv: DOC: Add driver example
code").
Signed-off-by: Zenghui Yu
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +++--
1 file changed, 3 insertions(+),
ping for this obvious fix...
On 2020/5/28 21:08, Zenghui Yu wrote:
ERR_PTR() is used in the kernel to encode an usual *negative* errno code
into a pointer. Passing a positive value (ENOMEM) to it will break the
following IS_ERR() check.
Though memory allocation is unlikely to fail, it's still
Hi Marc,
On 2019/2/14 18:46, Marc Zyngier wrote:
On Sun, 10 Feb 2019 05:24:10 +,
Zenghui Yu wrote:
In current logic, its_parse_indirect_baser() will be invoked twice
when allocating Device tables. Add a *break* to omit the unnecessary
and annoying (might be ...) invoking.
Signed-off
In current logic, its_parse_indirect_baser() will be invoked twice
when allocating Device tables. Add a *break* to omit the unnecessary
and annoying (might be ...) invoking.
Signed-off-by: Zenghui Yu
---
drivers/irqchip/irq-gic-v3-its.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
According to ARM IHI 0069C (ID070116), we should use GITS_TYPER's
bits [7:4] as ITT_entry_size.
Signed-off-by: Zenghui Yu
---
include/linux/irqchip/arm-gic-v3.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm
dent. It's hard for me to say
whether this patch is doing the right thing and how does the RWP waiting
affect the system, thus RFC.
Signed-off-by: Zenghui Yu
---
drivers/irqchip/irq-gic-v3.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c
Hi Andre,
On 2019/5/13 16:37, Andre Przywara wrote:
On Mon, 13 May 2019 04:15:54 +
Zenghui Yu wrote:
Hi,
As per ARM IHI 0069D, GICD_CTLR's RWP field tracks updates to:
GICD_CTLR's Group Enable bits, for transitions from 1 to 0 only
GICD_CTLR's ARE bits, E1NWF bit and DS
Fix gcc warning:
pmu-events/jevents.c: In function ‘save_arch_std_events’:
pmu-events/jevents.c:417:15: warning: unused variable ‘sb’ [-Wunused-variable]
struct stat *sb = data;
^~
Signed-off-by: Zenghui Yu
---
tools/perf/pmu-events/jevents.c | 1 -
1 file changed, 1 deletion
he
group of private IRQs"), we should also take the creating order of the
VGIC and VCPUs into consideration.
Cc: Eric Auger
Cc: Marc Zyngier
Cc: Andre Przywara
Cc: Christoffer Dall
Signed-off-by: Zenghui Yu
---
virt/kvm/arm/vgic/vgic-init.c | 16 +++-
1 file changed, 11 insert
() as notrace and it seems works
fine now. But I have no idea about what the issue is exactly, and
you can regard this patch as a report then :)
Can someone give a look at it and provide some explanations ?
Thanks!
Cc: Julien Thierry
Cc: Steven Rostedt
Signed-off-by: Zenghui Yu
---
drivers/ir
Hi Marc,
On 2019/3/29 21:58, Marc Zyngier wrote:
Hi Zenghui,
On 29/03/2019 13:23, Zenghui Yu wrote:
Enable pseudo NMI together with function_graph tracer, will lead
the system to a hang. This is easy to reproduce,
1) Set "irqchip.gicv3_pseudo_nmi=1" on the kernel command line
Hi Steven,
On 2019/3/29 22:53, Steven Rostedt wrote:
On Fri, 29 Mar 2019 13:58:40 +
Marc Zyngier wrote:
On the other hand, if you can generate pseudo-NMIs, you could end-up
tracing gic_handle_irq whilst being inside the tracing code with
interrupts being notionally disabled (and that
On Fri, Mar 29, 2019 at 11:46 PM Steven Rostedt wrote:
>
> On Fri, 29 Mar 2019 23:35:59 +0800
> Zenghui Yu wrote:
>
> > Hi Steven,
> >
> > On 2019/3/29 22:53, Steven Rostedt wrote:
> > > On Fri, 29 Mar 2019 13:58:40 +
> > > Marc Zyngier w
Hi Suzuki,
On 2019/3/14 18:55, Suzuki K Poulose wrote:
Hi Zheng,
On Wed, Mar 13, 2019 at 05:45:31PM +0800, Zheng Xiang wrote:
On 2019/3/13 2:18, Marc Zyngier wrote:
Hi Zheng,
On 12/03/2019 15:30, Zheng Xiang wrote:
Hi Marc,
On 2019/3/12 19:32, Marc Zyngier wrote:
Hi Zheng,
On
-off-by: Zenghui Yu
---
Atfer looking into https://patchwork.codeaurora.org/patch/647985/ , the
"vma_pagesize = PAGE_SIZE" logic was not intended to be deleted. As far
as I can tell, we used to have "hugetlb" to force the PTE mapping, but
we have "vma_pagesize" cu
I think there're still some problems in this patch... Details below.
On Sat, Mar 2, 2019 at 11:39 AM Zenghui Yu wrote:
>
> The idea behind this is: we don't want to keep tracking of huge pages when
> logging_active is true, which will result in performance degradation. We
> still
Hi Marc, Suzuki,
On 2019/3/5 1:34, Marc Zyngier wrote:
Hi Zenghui, Suzuki,
On 04/03/2019 17:13, Suzuki K Poulose wrote:
Hi Zenghui,
On Sun, Mar 03, 2019 at 11:14:38PM +0800, Zenghui Yu wrote:
I think there're still some problems in this patch... Details below.
On Sat, Mar 2, 2019 at 11:39
On 2019/3/5 19:13, Suzuki K Poulose wrote:
Hi Zenghui,
On 05/03/2019 11:09, Zenghui Yu wrote:
Hi Marc, Suzuki,
On 2019/3/5 1:34, Marc Zyngier wrote:
Hi Zenghui, Suzuki,
On 04/03/2019 17:13, Suzuki K Poulose wrote:
Hi Zenghui,
On Sun, Mar 03, 2019 at 11:14:38PM +0800, Zenghui Yu wrote
Hi Marc,
On 2019/2/10 13:24, Zenghui Yu wrote:
In current logic, its_parse_indirect_baser() will be invoked twice
when allocating Device tables. Add a *break* to omit the unnecessary
and annoying (might be ...) invoking.
Forgot to add:
Fixes: 32bd44dc19de ("irqchip/gic-v3-its
As linux-5.0 is coming up soon, the howto.rst document can be
updated for the new kernel version. Change all 4.x references
to 5.x now.
Signed-off-by: Zenghui Yu
---
Documentation/process/howto.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
On Sun, Feb 24, 2019 at 8:53 PM Greg KH wrote:
>
> On Sun, Feb 24, 2019 at 04:43:20PM +0800, Zenghui Yu wrote:
> > As linux-5.0 is coming up soon, the howto.rst document can be
> > updated for the new kernel version. Change all 4.x references
> > to 5.x now.
> >
As linux-5.0 is coming up soon, the howto.rst document can be
updated for the new kernel version. Change all 4.x references
to 5.x now.
Signed-off-by: Zenghui Yu
---
Documentation/process/howto.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
Hi Jon,
On Tue, Feb 26, 2019 at 2:26 AM Jonathan Corbet wrote:
>
> On Sun, 24 Feb 2019 23:45:23 +0800
> Zenghui Yu wrote:
>
> > As linux-5.0 is coming up soon, the howto.rst document can be
> > updated for the new kernel version. Change all 4.x references
> >
As linux-5.0 is coming up soon, the howto.rst document can be
updated for the new kernel version. Instead of changing all 4.x
references to 5.x, this time we git rid of all explicit version
numbers and rework some kernel trees' name to keep the docs
current and real.
Signed-off-by: Zenghui Yu
On 2019/1/31 20:48, Marc Zyngier wrote:
On 31/01/2019 11:19, Zenghui Yu wrote:
According to ARM IHI 0069C (ID070116), we should use GITS_TYPER's
bits [7:4] as ITT_entry_size.
Signed-off-by: Zenghui Yu
---
include/linux/irqchip/arm-gic-v3.h | 2 +-
1 file changed, 1 insertion(+), 1
s exactly this that needs to be fixed:
> > > https://groups.google.com/d/msg/kasan-dev/g8A8PLKCyoE/vXnirYEnCAAJ
> > > And this commit already fixes it.
> >
> > Has that been sent in my direction? I can't find it.
> >
> > If sending it please add
> >
> &g
On Sun, Jan 20, 2019 at 12:45 AM Dmitry Vyukov wrote:
>
> On Sat, Jan 19, 2019 at 5:37 PM Dmitry Vyukov wrote:
> >
> > On Fri, Jan 18, 2019 at 6:45 PM Zenghui Yu wrote:
> > >
> > > Hi, All!
> > >
> > > I compiled the latest kernel a
On Mon, Jan 21, 2019 at 2:28 AM Zenghui Yu wrote:
>
> On Sun, Jan 20, 2019 at 12:45 AM Dmitry Vyukov wrote:
> >
> > On Sat, Jan 19, 2019 at 5:37 PM Dmitry Vyukov wrote:
> > >
> > > On Fri, Jan 18, 2019 at 6:45 PM Zenghui Yu wrote:
> > > >
> &
Update various words, including the wrong parameter name and the vague
description of the usage of "slot" field.
Signed-off-by: Zenghui Yu
---
Documentation/virt/kvm/api.rst | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/Documentation/virt/kvm
On 2021/2/24 4:56, Eric Auger wrote:
@@ -1936,7 +1950,12 @@ static void arm_smmu_tlb_inv_range_domain(unsigned long
iova, size_t size,
},
};
- if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
+ if (ext_asid >= 0) { /* guest stage 1 invalidation */
+
Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
In preparation for vSVA, let's accept userspace provided configs
with more than one CD. We check the max CD against the host iommu
capability and also the format (linear versus 2 level).
Signed-off-by: Eric Auger
Signed-off-by: Shameer Kolothum
Per SMMUv3 spec, there is no Size and Addr field in the PREFETCH_CONFIG
command and they're not used by the driver. Remove them.
We can add them back if we're going to use PREFETCH_ADDR in the future.
Signed-off-by: Zenghui Yu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 --
drivers
1 - 100 of 116 matches
Mail list logo
