directly return with an invalid response.
Suggested-by: Kevin Tian
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 4 +-
drivers/vfio/vfio_iommu_type1.c | 357 +++-
include/linux/vfio.h| 1 +
3 files changed, 358 insertions(+), 4
dirty tracking support in the future.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 38 +++--
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 7df5711e743a
handler (a consolidated one) via
flags (set FAULT_REPORT_NESTED_L1), and further deliver the received
stage 1 faults in the handler to the guest through a newly added
vfio_device_ops callback.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 81
To avoid pinning pages when they are mapped in IOMMU page tables, we
add an MMU notifier to tell the addresses which are no longer valid
and try to unmap them.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 112 +++-
1 file changed, 109 insertions
is not supported since there may be
inflight page faults when disabling.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 223 +++-
include/uapi/linux/vfio.h | 6 +
2 files changed, 226 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio
To optimize for fewer page fault handlings, we can pre-map more pages
than requested at once.
Note that IOPF_PREMAP_LEN is just an arbitrary value for now, which we
could try further tuning.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 131
VFIO manages the DMA mapping itself. To support IOPF (on-demand paging)
for VFIO (IOMMU capable) devices, we add a VFIO page fault handler to
serve the reported page faults from the IOMMU driver.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 114
ve DMA Buffer Tracking
for Efficient Memory Management in Direct I/O. In USENIX ATC, 2020.
[3]
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210401154718.307519-1-jean-phili...@linaro.org/
[4] https://github.com/Linaro/uadk
Thanks,
Shenming
Shenming Lu (8):
iommu: Evolve the
not a clean way.
In addition, still take VFIO as an example, in nested mode, the 1st level
and 2nd level fault reporting may be configured separately and currently
each device can only register one iommu dev fault handler, so we add a
handler update interface for this.
Signed-off-by: Shenming Lu
ith break.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45cbfd4879a5..fd4213c41743 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/dri
On 2021/3/25 2:19, Marc Zyngier wrote:
> On Mon, 22 Mar 2021 14:01:52 +0800, Shenming Lu wrote:
>> In GICv4.1, migration has been supported except for (directly-injected)
>> VLPI. And GICv4.1 Spec explicitly gives a way to get the VLPI's pending
>> state (which was crucial
-off-by: Shenming Lu
---
Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst
b/Documentation/virt/kvm/devices/arm-vgic
efficient to parse the empty VPT. Let's
drop the setting of PTZ altogether.
Signed-off-by: Shenming Lu
---
drivers/irqchip/irq-gic-v3-its.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index
off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v3.c | 66 +++
1 file changed, 60 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 6f530925a231..41ecf219c333 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/ar
With GICv4.1 and the vPE unmapped, which indicates the invalidation
of any VPT caches associated with the vPE, we can get the VLPI state
by peeking at the VPT. So we add a function for this.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 19 +++
arch/arm64/kvm
From: Marc Zyngier
Since there may be a direct read from the CPU side to the VPT after
unmapping the vPE, we add a cache coherency maintenance at the end
of its_vpe_irq_domain_deactivate() to ensure the validity of the VPT
read later.
Signed-off-by: Marc Zyngier
Signed-off-by: Shenming Lu
t; to trigger
a VLPI to pending.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index ac029ba3d337..c1845d8f5f7e 100644
--- a/a
- Check all get_vlpi_state related conditions in save_pending_tables in one
place.
- Nit fixes.
v1 -> v2:
- Get the VLPI state from the KVM side.
- Nit fixes.
Thanks,
Shenming
Marc Zyngier (1):
irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping
Shenming Lu (4):
On 2021/3/18 20:32, Tian, Kevin wrote:
>> From: Shenming Lu
>> Sent: Thursday, March 18, 2021 7:54 PM
>>
>> On 2021/3/18 17:07, Tian, Kevin wrote:
>>>> From: Shenming Lu
>>>> Sent: Thursday, March 18, 2021 3:53 PM
>>>>
&g
On 2021/3/18 17:07, Tian, Kevin wrote:
>> From: Shenming Lu
>> Sent: Thursday, March 18, 2021 3:53 PM
>>
>> On 2021/2/4 14:52, Tian, Kevin wrote:>>> In reality, many
>>>>> devices allow I/O faulting only in selective contexts. However, there
>&
On 2021/2/4 14:52, Tian, Kevin wrote:>>> In reality, many
>>> devices allow I/O faulting only in selective contexts. However, there
>>> is no standard way (e.g. PCISIG) for the device to report whether
>>> arbitrary I/O fault is allowed. Then we may have to maintain device
>>> specific knowledge
On 2021/3/15 17:20, Marc Zyngier wrote:
> On 2021-03-15 09:11, Shenming Lu wrote:
>> On 2021/3/15 16:30, Marc Zyngier wrote:
>>> On 2021-03-13 08:38, Shenming Lu wrote:
>>>> From: Zenghui Yu
>>>>
>>>> When setting the forwarding path of a V
On 2021/3/15 16:30, Marc Zyngier wrote:
> On 2021-03-13 08:38, Shenming Lu wrote:
>> From: Zenghui Yu
>>
>> When setting the forwarding path of a VLPI (switch to the HW mode),
>> we can also transfer the pending state from irq->pending_latch to
>> VPT (especia
off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v3.c | 66 +++
1 file changed, 60 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 52915b342351..359d4dc35264 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/ar
-off-by: Shenming Lu
---
Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst
b/Documentation/virt/kvm/devices/arm-vgic
With GICv4.1 and the vPE unmapped, which indicates the invalidation
of any VPT caches associated with the vPE, we can get the VLPI state
by peeking at the VPT. So we add a function for this.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 19 +++
arch/arm64/kvm
efficient to parse the empty VPT. Let's
drop the setting of PTZ altogether.
Signed-off-by: Shenming Lu
---
drivers/irqchip/irq-gic-v3-its.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index
t; to trigger
a VLPI to pending.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index ac029ba3d337..3b82ab80c2f3 100644
--- a/a
- Nit fixes.
v1 -> v2:
- Get the VLPI state from the KVM side.
- Nit fixes.
Thanks,
Shenming
Marc Zyngier (1):
irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping
Shenming Lu (4):
irqchip/gic-v3-its: Drop the setting of PTZ altogether
KVM: arm64: GICv4.1: Add functi
From: Marc Zyngier
Since there may be a direct read from the CPU side to the VPT after
unmapping the vPE, we add a cache coherency maintenance at the end
of its_vpe_irq_domain_deactivate() to ensure the validity of the VPT
read later.
Signed-off-by: Marc Zyngier
Signed-off-by: Shenming Lu
On 2021/3/12 20:02, Marc Zyngier wrote:
> On Fri, 12 Mar 2021 11:34:07 +,
> Shenming Lu wrote:
>>
>> On 2021/3/12 19:10, Marc Zyngier wrote:
>>> On Fri, 12 Mar 2021 10:48:29 +,
>>> Shenming Lu wrote:
>>>>
>>>> On 2021/3/12 1
On 2021/3/12 19:10, Marc Zyngier wrote:
> On Fri, 12 Mar 2021 10:48:29 +,
> Shenming Lu wrote:
>>
>> On 2021/3/12 17:05, Marc Zyngier wrote:
>>> On Thu, 11 Mar 2021 12:32:07 +,
>>> Shenming Lu wrote:
>>>>
>>>> On 2021/3/11 1
On 2021/3/12 17:05, Marc Zyngier wrote:
> On Thu, 11 Mar 2021 12:32:07 +,
> Shenming Lu wrote:
>>
>> On 2021/3/11 17:14, Marc Zyngier wrote:
>>> On Wed, 27 Jan 2021 12:13:36 +,
>>> Shenming Lu wrote:
>>>>
>>>> From: Zenghui Yu
On 2021/3/12 17:02, Marc Zyngier wrote:
> On Thu, 11 Mar 2021 12:31:48 +,
> Shenming Lu wrote:
>>
>> On 2021/3/11 17:09, Marc Zyngier wrote:
>
>>> I have asked that question in the past: is it actually safe to remap
>>> the vPEs and expect them to be
On 2021/3/11 17:14, Marc Zyngier wrote:
> On Wed, 27 Jan 2021 12:13:36 +,
> Shenming Lu wrote:
>>
>> From: Zenghui Yu
>>
>> When setting the forwarding path of a VLPI (switch to the HW mode),
>> we could also transfer the pending state from irq-
On 2021/3/11 17:09, Marc Zyngier wrote:
> On Wed, 27 Jan 2021 12:13:35 +,
> Shenming Lu wrote:
>>
>> After pausing all vCPUs and devices capable of interrupting, in order
>> to save the information of all interrupts, besides flushing the pending
>> states in kv
On 2021/3/11 16:57, Marc Zyngier wrote:
> On Wed, 27 Jan 2021 12:13:34 +,
> Shenming Lu wrote:
>>
>> With GICv4.1 and the vPE unmapped, which indicates the invalidation
>> of any VPT caches associated with the vPE, we can get the VLPI state
>> by peeking at
Hi,
Sorry to bother again, I am really hoping a response for this series. :-)
Thanks,
Shenming
On 2021/2/26 16:58, Shenming Lu wrote:
> Hi Marc,
>
> Gentle ping. Does this series need any further modification? Wish you can
> pick it up. :-)
>
> Thanks,
> Shenming
&g
Hi Baolu,
On 2021/3/10 10:09, Lu Baolu wrote:
> Hi Shenming,
>
> On 3/9/21 2:22 PM, Shenming Lu wrote:
>> This patch follows the discussion here:
>>
>> https://lore.kernel.org/linux-acpi/YAaxjmJW+ZMvrhac@myrica/
>>
>> In order to support more s
handler (a combined one) via
flags (set IOPF_REPORT_NESTED_L1_CONCERNED), and further deliver
the received stage 1 faults in the handler to the guest through
a newly added vfio_device_ops callback.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 83
is not supported
since there may be inflight page faults when disabling.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 139 +++-
include/uapi/linux/vfio.h | 6 ++
2 files changed, 142 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio
To avoid pinning pages when they are mapped in IOMMU page tables,
we add an MMU notifier to tell the addresses which are no longer
valid and try to unmap them.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 68 +
1 file changed, 68 insertions
If IOPF enabled for the VFIO container, there is no need to
statically pin and map the entire DMA range, we can do it on
demand. And unmap according to the IOPF mapped bitmap when
removing vfio_dma.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 35
be interested in only one
level.
Signed-off-by: Shenming Lu
---
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 ++--
drivers/iommu/io-pgfault.c| 4 --
drivers/iommu/iommu.c | 56
VFIO manages the DMA mapping itself. To support IOPF for VFIO
devices, we add a VFIO page fault handler to serve the reported
page faults from the IOMMU driver. Besides, we can pre-map more
pages than requested at once to optimize for fewer page fault
handlings.
Signed-off-by: Shenming Lu
nts and suggestions are very welcome. :-)
Thanks,
Shenming
Shenming Lu (6):
iommu: Evolve to support more scenarios of using IOPF
vfio: Add an MMU notifier to avoid pinning
vfio: Add a page fault handler
vfio: VFIO_IOMMU_ENABLE_IOPF
vfio: No need to statically pin and map if IOPF enab
Hi Marc,
Gentle ping. Does this series need any further modification? Wish you can pick
it up. :-)
Thanks,
Shenming
On 2021/1/27 20:13, Shenming Lu wrote:
> Hi Marc, sorry for the late commit.
>
> In GICv4.1, migration has been supported except for (directly-injected)
> VLPI. And
> +static int vfio_pci_dma_fault_init(struct vfio_pci_device *vdev)
> +{
> + struct vfio_region_dma_fault *header;
> + struct iommu_domain *domain;
> + size_t size;
> + bool nested;
> + int ret;
> +
> + domain = iommu_get_domain_for_dev(>pdev->dev);
> + ret =
On 2021/2/9 19:06, Liu, Yi L wrote:
>> From: Tian, Kevin
>> Sent: Thursday, February 4, 2021 2:52 PM
>>
>>> From: Shenming Lu
>>> Sent: Tuesday, February 2, 2021 2:42 PM
>>>
>>> On 2021/2/1 15:56, Tian, Kevin wrote:
>>>>>
On 2021/2/7 16:20, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Friday, February 5, 2021 6:37 PM
>>
>> Hi,
>>
>> On Thu, Feb 04, 2021 at 06:52:10AM +, Tian, Kevin wrote:
>>> The static pinning and mapping problem in VFIO and possible
>> solutions
>>> have been discussed
On 2021/2/1 15:56, Tian, Kevin wrote:
>> From: Alex Williamson
>> Sent: Saturday, January 30, 2021 6:58 AM
>>
>> On Mon, 25 Jan 2021 17:03:58 +0800
>> Shenming Lu wrote:
>>
>>> Hi,
>>>
>>> The static pinning and mapping problem in
On 2021/1/30 6:57, Alex Williamson wrote:
> On Mon, 25 Jan 2021 17:03:58 +0800
> Shenming Lu wrote:
>
>> Hi,
>>
>> The static pinning and mapping problem in VFIO and possible solutions
>> have been discussed a lot [1, 2]. One of the solutions is to add I/O
>&
On 2021/1/30 6:42, Alex Williamson wrote:
> On Mon, 25 Jan 2021 17:04:01 +0800
> Shenming Lu wrote:
>
>> If IOMMU_DEV_FEAT_IOPF is set for the VFIO device, which means that
>> the delivering of page faults of this device from the IOMMU is enabled,
>> we register
On 2021/1/30 6:58, Alex Williamson wrote:
> On Mon, 25 Jan 2021 17:03:59 +0800
> Shenming Lu wrote:
>
>> When IOPF enabled, the pages are pinned and mapped on demand, we add
>> a bitmap to track them.
>>
>> Signed-off-by: Shenming Lu
>> ---
&
On 2021/1/28 1:42, Christoph Hellwig wrote:
> On Mon, Jan 25, 2021 at 05:04:00PM +0800, Shenming Lu wrote:
>> +EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler);
>
> This function is only used in vfio.c itself, so it should not be
> exported, but rather marked static.
> .
>
fixes.
Thanks,
Shenming
Shenming Lu (3):
KVM: arm64: GICv4.1: Add function to get VLPI state
KVM: arm64: GICv4.1: Try to save hw pending state in
save_pending_tables
KVM: arm64: GICv4.1: Give a chance to save VLPI's pending state
Zenghui Yu (1):
KVM: arm64: GICv4.1: Restore VLPI's pending
With GICv4.1 and the vPE unmapped, which indicates the invalidation
of any VPT caches associated with the vPE, we can get the VLPI state
by peeking at the VPT. So we add a function for this.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 19 +++
arch/arm64/kvm
off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v3.c | 61 +++
1 file changed, 55 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 52915b342351..06b1162b7a0a 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
++
t; to trigger
a VLPI to pending.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index ac029ba3d337..a3542af6f04a 100644
--- a/a
the UAPI).
Signed-off-by: Shenming Lu
---
Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst
b/Documentation/virt/kvm/devices
ver/20201116110030.32335-1-eric.au...@redhat.com/
Thanks,
Shenming
Shenming Lu (4):
vfio/type1: Add a bitmap to track IOPF mapped pages
vfio: Add a page fault handler
vfio: Try to enable IOPF for VFIO devices
vfio: Allow to pin and map dynamically
drivers/vfio/vfio.c |
When IOPF enabled, the pages are pinned and mapped on demand, we add
a bitmap to track them.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index
If IOPF enabled for the whole VFIO container, there is no need to
statically pin and map the entire DMA range, we can do it on demand.
And unmap and unpin according to the IOPF mapped bitmap when removing
the DMA mapping.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 20
VFIO manages the passthrough DMA mapping itself. In order to support
IOPF for VFIO devices, we need to add a VFIO page fault handler to
serve the reported page faults from the IOMMU driver.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 35
drivers/vfio
-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index ff7797260d0f..fd885d99ee0f 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -97,6 +97,7 @@ struct vfio_device
On 2021/1/5 21:47, Marc Zyngier wrote:
> On 2021-01-05 13:02, Shenming Lu wrote:
>> On 2021/1/5 17:13, Marc Zyngier wrote:
>>> On 2021-01-04 08:16, Shenming Lu wrote:
>>>> After pausing all vCPUs and devices capable of interrupting, in order
>>>> to save
On 2021/1/5 19:40, Marc Zyngier wrote:
> On 2021-01-05 09:13, Marc Zyngier wrote:
>> On 2021-01-04 08:16, Shenming Lu wrote:
>>> After pausing all vCPUs and devices capable of interrupting, in order
>>> to save the information of all interrupts, besides flushing the
On 2021/1/5 17:25, Marc Zyngier wrote:
> On 2021-01-04 08:16, Shenming Lu wrote:
>> From: Zenghui Yu
>>
>> When setting the forwarding path of a VLPI (switch to the HW mode),
>> we could also transfer the pending state from irq->pending_latch to
>> VPT (especia
On 2021/1/5 17:13, Marc Zyngier wrote:
> On 2021-01-04 08:16, Shenming Lu wrote:
>> After pausing all vCPUs and devices capable of interrupting, in order
>> to save the information of all interrupts, besides flushing the pending
>> states in kvm’s vgic, we also try to flus
Nit fixes.
Since there seems to be no better place to transfer the pending states
in patch 3, we just keep it unchanged.
Thanks,
Shenming
Shenming Lu (3):
KVM: arm64: GICv4.1: Add function to get VLPI state
KVM: arm64: GICv4.1: Try to save hw pending state in
save_pending_tables
KVM: ar
With GICv4.1 and the vPE unmapped, which indicates the invalidation
of any VPT caches associated with the vPE, we can get the VLPI state
by peeking at the VPT. So we add a function for this.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 24
arch/arm64
the vPEs first.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v3.c | 58 +++
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 9cdf39a94a63..a58c94127cb0 100644
--- a/arch
t; to trigger
a VLPI to pending.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index f211a7c32704..7945d6d09cdd 100644
--- a/arch/a
the UAPI).
Signed-off-by: Shenming Lu
---
Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst
b/Documentation/virt/kvm/devices
On 2020/12/31 20:22, Marc Zyngier wrote:
> On 2020-12-31 11:58, Shenming Lu wrote:
>> On 2020/12/31 16:57, Marc Zyngier wrote:
>>> Hi Shemming,
>>>
>>> On 2020-12-31 06:28, Shenming Lu wrote:
>>>> When the EnableLPIs bit is set to 0, any ITS LPI req
On 2020/12/31 16:57, Marc Zyngier wrote:
> Hi Shemming,
>
> On 2020-12-31 06:28, Shenming Lu wrote:
>> When the EnableLPIs bit is set to 0, any ITS LPI requests in the
>> Redistributor would be ignored. And this check is independent from
>> the ITS LPI translation. So
cache. Besides it seems that
by this the invalidating of the translation cache caused by the LPI
disabling is unnecessary.
Not sure if I have missed something... Thanks.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-its.c | 9 +
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4
On 2020/12/16 18:35, Auger Eric wrote:
> Hi Shenming,
>
> On 12/1/20 1:15 PM, Shenming Lu wrote:
>> On 2020/12/1 19:50, Marc Zyngier wrote:
>>> On 2020-12-01 11:40, Shenming Lu wrote:
>>>> On 2020/12/1 18:55, Marc Zyngier wrote:
>>>>> On
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 0b39498230ae53e6af981141be99f4c7d5144de6
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/0b39498230ae53e6af981141be99f4c7d5144de6
Author:Shenming Lu
On 2020/12/1 20:15, Shenming Lu wrote:
> On 2020/12/1 19:50, Marc Zyngier wrote:
>> On 2020-12-01 11:40, Shenming Lu wrote:
>>> On 2020/12/1 18:55, Marc Zyngier wrote:
>>>> On 2020-11-30 07:23, Shenming Lu wrote:
>>>>
>>>> Hi Shenming,
&g
On 2020/12/1 19:50, Marc Zyngier wrote:
> On 2020-12-01 11:40, Shenming Lu wrote:
>> On 2020/12/1 18:55, Marc Zyngier wrote:
>>> On 2020-11-30 07:23, Shenming Lu wrote:
>>>
>>> Hi Shenming,
>>>
>>>> We are pondering over this pro
On 2020/12/1 18:55, Marc Zyngier wrote:
> On 2020-11-30 07:23, Shenming Lu wrote:
>
> Hi Shenming,
>
>> We are pondering over this problem these days, but still don't get a
>> good solution...
>> Could you give us some advice on this?
>>
>> Or could w
On 2020/11/30 19:22, Marc Zyngier wrote:
> On 2020-11-28 14:18, Shenming Lu wrote:
>> In order to further reduce the impact of the wait delay of the
>> VPT analysis, we can delay the execution of the polling on the
>> GICR_VPENDBASER.Dirty bit (call it from k
On 2020/11/24 21:12, Shenming Lu wrote:
> On 2020/11/24 16:44, Marc Zyngier wrote:
>> On 2020-11-24 08:10, Shenming Lu wrote:
>>> On 2020/11/23 17:27, Marc Zyngier wrote:
>>>> On 2020-11-23 06:54, Shenming Lu wrote:
>>>>> From: Zenghui Yu
>>&
-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 16
arch/arm64/kvm/vgic/vgic.c | 3 +++
drivers/irqchip/irq-gic-v3-its.c | 16
drivers/irqchip/irq-gic-v4.c | 11 +++
include/kvm/arm_vgic.h | 3 +++
include/linux/irqchip
path.
Shenming Lu (2):
irqchip/gic-v4.1: Reduce the delay time of the poll on the
GICR_VPENDBASER.Dirty bit
KVM: arm64: Delay the execution of the polling on the
GICR_VPENDBASER.Dirty bit
arch/arm64/kvm/vgic/vgic-v4.c | 16
arch/arm64/kvm/vgic/vgic.c | 3
The 10 delay_us of the poll on the GICR_VPENDBASER.Dirty bit is too
high, which might greatly affect the total scheduling latency of a
vCPU in our measurement. So we reduce it to 1 to lessen the impact.
Signed-off-by: Shenming Lu
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1
On 2020/11/28 3:35, Marc Zyngier wrote:
> Shenming,
>
> Somehow this patch ended up in the wrong folder.
> Apologies for the delay reviewing it.>
> On 2020-09-23 07:35, Shenming Lu wrote:
>> Right after a vPE is made resident, the code starts polling the
>> G
On 2020/11/24 16:44, Marc Zyngier wrote:
> On 2020-11-24 08:10, Shenming Lu wrote:
>> On 2020/11/23 17:27, Marc Zyngier wrote:
>>> On 2020-11-23 06:54, Shenming Lu wrote:
>>>> From: Zenghui Yu
>>>>
>>>> When setting the forwarding path of
On 2020/11/24 16:26, Marc Zyngier wrote:
> On 2020-11-24 07:40, Shenming Lu wrote:
>> On 2020/11/23 17:18, Marc Zyngier wrote:
>>> On 2020-11-23 06:54, Shenming Lu wrote:
>>>> After pausing all vCPUs and devices capable of interrupting, in order
>>>
On 2020/11/23 17:27, Marc Zyngier wrote:
> On 2020-11-23 06:54, Shenming Lu wrote:
>> From: Zenghui Yu
>>
>> When setting the forwarding path of a VLPI, it is more consistent to
>
> I'm not sure it is more consistent. It is a *new* behaviour, because it only
> ma
On 2020/11/23 17:18, Marc Zyngier wrote:
> On 2020-11-23 06:54, Shenming Lu wrote:
>> After pausing all vCPUs and devices capable of interrupting, in order
> ^
> See my comment below about this.
>
>> to save the information of all interrupts, besi
On 2020/11/23 17:01, Marc Zyngier wrote:
> On 2020-11-23 06:54, Shenming Lu wrote:
>> From: Zenghui Yu
>>
>> Up to now, the irq_get_irqchip_state() callback of its_irq_chip
>> leaves unimplemented since there is no architectural way to get
>> the VLPI's p
rigger a VLPI to pending.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index b5fa73c9fd35..cc3ab9cea182 100644
--- a/arch/arm64/kvm
: Set the priority of VFIO VM state change handler explicitly:
https://patchwork.ozlabs.org/patch/1401280/
Shenming Lu (2):
KVM: arm64: GICv4.1: Try to save hw pending state in
save_pending_tables
KVM: arm64: GICv4.1: Give a chance to save VLPI's pending state
Zenghui Yu (2):
irqchip/gic
the vPEs first.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v3.c | 62 +++
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 9cdf39a94a63..e1b3aa4b2b12 100644
--- a/arch
the interfaces).
Signed-off-by: Shenming Lu
---
Documentation/virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst
b/Documentation/virt/kvm
any caching of the VPT, we can get the VLPI's pending state by
peeking at the VPT. So we implement the irq_get_irqchip_state()
callback of its_irq_chip to do it.
Signed-off-by: Zenghui Yu
Signed-off-by: Shenming Lu
---
drivers/irqchip/irq-gic-v3-its.c | 38
1 file
, this is mainly caused by the 10 us delay in
its_wait_vpt_parse_complete()
(the above difference is just about 10 us)...
What's your opinion about this?
Thanks,
Shenming
On 2020/9/23 14:35, Shenming Lu wrote:
> Right after a vPE is made resident, the code starts polling the
> GICR_VPENDBASER
niversal. Besides, we can delay the execution
of its_wait_vpt_parse_complete() (call it from kvm_vgic_flush_hwstate()
corresponding to vPE resident), giving the GIC a chance to work in
parallel with the CPU on the entry path.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c
1 - 100 of 101 matches
Mail list logo
