On 2021/4/17 17:10, Marc Zyngier wrote:
On Sat, 17 Apr 2021 09:59:39 +0100,
Zenghui Yu wrote:
On 2021/3/30 22:54, Marc Zyngier wrote:
+PTP_KVM support for arm/arm64
+=
+
+PTP_KVM is used for high precision time sync between host and guests.
+It relies
On 2021/3/30 22:54, Marc Zyngier wrote:
#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1
I think it'd be better to keep this definition together with other
wa Function IDs. It's only a cosmetic comment anyway.
Zenghui
On 2021/3/30 22:54, Marc Zyngier wrote:
- u64 cycles;
- ktime_t real;
- ktime_t raw;
- unsigned intclock_was_set_seq;
- u8 cs_was_changed_seq;
+ u64 cycles;
+ ktime_t real;
On 2021/3/30 22:54, Marc Zyngier wrote:
+PTP_KVM support for arm/arm64
+=
+
+PTP_KVM is used for high precision time sync between host and guests.
+It relies on transferring the wall clock and counter value from the
+host to the guest using a KVM-specific hypercall.
+
On 2021/3/30 22:54, Marc Zyngier wrote:
+int kvm_arch_ptp_init(void)
+{
+ int ret;
+
+ ret = kvm_arm_hyp_service_available(ARM_SMCCC_KVM_FUNC_PTP);
+ if (ret <= 0)
kvm_arm_hyp_service_available() returns boolean. Maybe write as ?
bool ret;
ret =
Hi Eric,
On 2021/2/24 5:06, Eric Auger wrote:
+/*
+ * VFIO_IOMMU_SET_PASID_TABLE - _IOWR(VFIO_TYPE, VFIO_BASE + 18,
+ * struct vfio_iommu_type1_set_pasid_table)
+ *
+ * The SET operation passes a PASID table to the host while the
+ * UNSET operation detaches the one
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
Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest
Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
+static int
+arm_smmu_cache_invalidate(struct iommu_domain *domain, struct device *dev,
+ struct iommu_cache_invalidate_info *inv_info)
+{
+ struct arm_smmu_cmdq_ent cmd = {.opcode = CMDQ_OP_TLBI_NSNH_ALL};
+
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
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 */
+
The ena.rst documentation referred to end_start_xmit() when it should refer
to ena_start_xmit(). Fix the typo.
Signed-off-by: Zenghui Yu
---
Documentation/networking/device_drivers/ethernet/amazon/ena.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation
e will otherwise see confusing kernel log under the command failure from
guest side. Fix it.
Fixes: 24f27d32ab6b ("iommu/vt-d: Enlightened PASID allocation")
Signed-off-by: Zenghui Yu
---
drivers/iommu/intel/pasid.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
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
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]);
|
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
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 06fde695ee76429634c1e8c8c1154035aa61191e
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/06fde695ee76429634c1e8c8c1154035aa61191e
Author:Zenghui Yu
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
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
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
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
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 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 +
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
(-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
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
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
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
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
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
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:
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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-
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
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
[
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(+),
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
: 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
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 31dbb6b1d025506b3b8b8b74e9b697df47b9f696
Gitweb:
https://git.kernel.org/tip/31dbb6b1d025506b3b8b8b74e9b697df47b9f696
Author:Zenghui Yu
AuthorDate:Fri, 05 Jun 2020 13:23:45 +08:00
Committer
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 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
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,
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
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/
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
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
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
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
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!
[*]
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: c107d613f9204ff9c7624c229938153d7492c56e
Gitweb:
https://git.kernel.org/tip/c107d613f9204ff9c7624c229938153d7492c56e
Author:Zenghui Yu
AuthorDate:Wed, 18 Sep 2019 06:57:30
Committer
(...), 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
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 342be1068d9b5b1fd364d270b4f731764e23de2b
Gitweb:
https://git.kernel.org/tip/342be1068d9b5b1fd364d270b4f731764e23de2b
Author:Zenghui Yu
AuthorDate:Sat, 27 Jul 2019 06:14:22
Committer
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 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 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
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 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
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 --
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
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
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
Commit-ID: 3a1d24ca9573fbc74a3d32c972c333b161e0e9dc
Gitweb: https://git.kernel.org/tip/3a1d24ca9573fbc74a3d32c972c333b161e0e9dc
Author: Zenghui Yu
AuthorDate: Sat, 6 Jul 2019 04:41:12 +
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jul 2019 10:40:20 +0200
irq/irqdomain: Fix
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
Commit-ID: 8e8f515d567f9ec1d960e9fdb117d39753b7504d
Gitweb: https://git.kernel.org/tip/8e8f515d567f9ec1d960e9fdb117d39753b7504d
Author: Zenghui Yu
AuthorDate: Wed, 15 May 2019 11:19:29 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 May 2019 16:36:49 -0300
perf jevents
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
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
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
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
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 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
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
() 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 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
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
1 - 100 of 116 matches
Mail list logo