been for
> several years.
>
> Please consult the MAINTAINERS file for up-to-date addresses for
> current maintainers and reviewers, all of whom should be Cc'd on this
> email. I've now added them as well as Eric Auger who has written most
> of the ITS migration code, and the new
Hi,
On 10/12/22 18:59, Eric Ren wrote:
> Reproducer hints:
> 1. Create ARM virt VM with pxb-pcie bus which adds
>extra host bridges, with qemu command like:
>
> ```
> -device pxb-pcie,bus_nr=8,id=pci.x,numa_node=0,bus=pcie.0 \
> -device pcie-root-port,..,bus=pci.x \
> ...
> -device
On 10/5/22 11:41, Alexandru Elisei wrote:
> Hi,
>
> On Wed, Oct 05, 2022 at 10:21:12AM +0100, Alexandru Elisei wrote:
>> Hi Eric,
>>
>> On Tue, Oct 04, 2022 at 07:31:25PM +0200, Eric Auger wrote:
>>> Hi Alexandru,
>>>
>>> On 10/4/22 18:58,
Hi Alexandru,
On 10/5/22 11:21, Alexandru Elisei wrote:
> Hi Eric,
>
> On Tue, Oct 04, 2022 at 07:31:25PM +0200, Eric Auger wrote:
>> Hi Alexandru,
>>
>> On 10/4/22 18:58, Alexandru Elisei wrote:
>>> Hi Eric,
>>>
>>> On Tue, Oct 04, 2022
Hi Alexandru,
On 10/4/22 18:58, Alexandru Elisei wrote:
> Hi Eric,
>
> On Tue, Oct 04, 2022 at 06:20:23PM +0200, Eric Auger wrote:
>> Hi Ricardo, Marc,
>>
>> On 8/5/22 02:41, Ricardo Koller wrote:
>>> There are some tests that fail when running on bare metal (i
Hi Ricardo, Marc,
On 8/5/22 02:41, Ricardo Koller wrote:
> There are some tests that fail when running on bare metal (including a
> passthrough prototype). There are three issues with the tests. The
> first one is that there are some missing isb()'s between enabling event
> counting and the
you prefer I proceed?
Thanks
Eric
> On 2020/4/3 15:13, Eric Auger wrote:
>> Adds the following tests:
>> - event-counter-config: test event counter configuration
>> - basic-event-count:
>> - programs counters #0 and #1 to count 2 required events
>> (resp. CPU_C
ple of comments related to the register state
> before a sub-test.
>
> Signed-off-by: Ricardo Koller
Reviewed-by: Eric Auger
Eric
> ---
> arm/pmu.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arm/pmu.c b/arm/pmu.c
> index 76156f78..7c5bc259
gt; write_regn_el0(pmevcntr, 0, PRE_OVERFLOW);
> isb();
> mem_access_loop(addr, 200, pmu.pmcr_ro | PMU_PMCR_E);
> - report(expect_interrupts(0),
> - "no overflow interrupt expected on 32b boundary");
> + report(expect_interrupts(0x1),
>
vgic.vgic_model) {
> + case KVM_DEV_TYPE_ARM_VGIC_V3:
> + if (is_user) {
> + val = irq->pending_latch;
> + break;
> + }
> + fallthrough;
> + default:
> + val = irq_is_pending(irq);
> + break;
> + }
> }
>
> value |= ((u32)val << i);
Reviewed-by: Eric Auger
Thanks!
Eric
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
;
> Add a new vgic_uaccess_read_pending() accessor for userspace
> to use, build on top of the existing vgic_mmio_read_pending().
>
> Reported-by: Eric Auger
> Signed-off-by: Marc Zyngier
> Fixes: 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state from
>
Hi Marc,
On 6/2/22 10:30, Marc Zyngier wrote:
> Now that GICv2 has a proper userspace accessor for the pending state,
> switch GICv3 over to it, dropping the local version.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/kvm/vgic/vgic-mmio-v3.c | 40 ++
> 1 file
;
> Add a new vgic_uaccess_read_pending() accessor for userspace
> to use, build on top of the existing vgic_mmio_read_pending().
>
> Reported-by: Eric Auger
> Signed-off-by: Marc Zyngier
> Fixes: 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state from
> the HW&
rder to avoid more embarassing crashes and catch the offenders
> red-handed, add a warning to kvm_arch_timer_get_input_level() and
> return the state as non-pending. This avoids taking the system down,
> and still helps tracking down silly bugs.
>
> Signed-off-by: Marc Zyngier
Reviewed-by
Hi Ricardo,
On 5/4/22 19:01, Ricardo Koller wrote:
> On Tue, May 03, 2022 at 07:14:19PM +0200, Eric Auger wrote:
>> Hi Ricardo,
>>
>> On 4/27/22 20:48, Ricardo Koller wrote:
>>> Try to improve the predictability of ITS save/restores (and debuggability
>>>
nt vgic_its_restore_tables_v0(struct vgic_its
> *its)
> if (ret)
> return ret;
>
> - return vgic_its_restore_device_tables(its);
> + ret = vgic_its_restore_device_tables(its);
> + if (ret)
> + vgic_its_free_collection_list(its-&
Hi Ricardo,
On 4/27/22 20:48, Ricardo Koller wrote:
> Restoring a corrupted collection entry is being ignored and treated as
maybe precise what is a corrupted ITE (out of range id or not matching
guest RAM)
> success. More specifically, vgic_its_restore_cte failure is treated as
> success by
Hi Ricardo,
On 4/27/22 20:48, Ricardo Koller wrote:
> Try to improve the predictability of ITS save/restores (and debuggability
> of failed ITS saves) by failing early on restore when trying to read
> corrupted tables.
>
> Restoring the ITS tables does some checks for corrupted tables, but not as
the evend_id not correct, no use to look
the ite for instance.
> -
> if (its_cmd_get_command(its_cmd) == GITS_CMD_MAPTI)
> lpi_nr = its_cmd_get_physical_id(its_cmd);
> else
> @@ -1076,6 +1096,9 @@ static int vgic_its_cmd_handle_
Hi Gavin,
On 1/12/22 7:43 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 6:58 PM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_{COMPLETE, COMPLETE_AND_RESUME} hypercall.
>>> They are used by the guest to notify the
Hi Gavin,
On 1/12/22 7:43 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 6:58 PM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_{COMPLETE, COMPLETE_AND_RESUME} hypercall.
>>> They are used by the guest to notify the
Hi Gavin,
On 1/12/22 3:46 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 1:19 AM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_GET_INFO hypercall. It's used by the guest
>>> to retrieve various information abou
Hi Gavin,
On 1/12/22 3:54 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 2:47 AM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_ROUTING_SET hypercall. It's used by the
>>> guest to set route mode and affinity for the re
Hi gavin,
On 1/12/22 8:03 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 9:48 PM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports ioctl commands on VM to manage the various objects.
>>> It's primarily used by VMM to accomplish live
Hi Gavin,
On 1/11/22 10:20 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/9/21 11:45 PM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> Software Delegated Exception Interface (SDEI) provides a mechanism for
>>> registering and servicing system eve
Hi Gavin,
On 1/12/22 3:38 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 1:05 AM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_UNREGISTER hypercall. It's used by the
>>> guest to unregister SDEI event. The SDEI event
Hi Gavin,
On 1/13/22 8:13 AM, Gavin Shan wrote:
> Hi Shannon,
>
> On 1/13/22 3:02 PM, Gavin Shan wrote:
>> On 1/11/22 5:43 PM, Shannon Zhao wrote:
>>> On 2021/8/15 8:13, Gavin Shan wrote:
+static unsigned long kvm_sdei_hypercall_context(struct kvm_vcpu *vcpu)
+{
+ struct kvm
Hi Gavin,
On 1/13/22 8:02 AM, Gavin Shan wrote:
> Hi Shannon,
>
> On 1/11/22 5:43 PM, Shannon Zhao wrote:
>> On 2021/8/15 8:13, Gavin Shan wrote:
>>> +static unsigned long kvm_sdei_hypercall_context(struct kvm_vcpu *vcpu)
>>> +{
>>> + struct kvm *kvm = vcpu->kvm;
>>> + struct kvm_sdei_kvm
Hi Gavin,
On 1/12/22 3:33 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 7:16 PM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_CONTEXT hypercall. It's used by the guest
>>> to retrieved the original registers (R0 - R
Hi Gavin,
On 1/12/22 3:29 AM, Gavin Shan wrote:
> Hi Eric,
>
> On 11/10/21 12:02 AM, Eric Auger wrote:
>> On 8/15/21 2:13 AM, Gavin Shan wrote:
>>> This supports SDEI_EVENT_{ENABLE, DISABLE} hypercall. After SDEI
>>> event is registered by guest, it won't be deli
ff.
>
> Signed-off-by: Marc Zyngier
Reviewed-by: Eric Auger
Eric
> ---
> hw/arm/virt-acpi-build.c | 10 --
> hw/arm/virt.c| 7 +--
> include/hw/arm/virt.h| 1 +
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/hw/arm
gt; highmem is off.
>
> Reviewed-by: Andrew Jones
> Signed-off-by: Marc Zyngier
Reviewed-by: Eric Auger
Eric
> ---
> hw/arm/virt-acpi-build.c | 2 ++
> hw/arm/virt.c| 2 ++
> include/hw/arm/virt.h| 4 +++-
> 3 files changed, 7 insertions(+), 1 deletion(-)
&
lude highmem devices
> if they are outside of the PA range.
>
> Signed-off-by: Marc Zyngier
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> hw/arm/virt.c | 64 +--
> 1 file changed, 52 insertions(+), 12 deletions(-)
>
> diff -
Hi Marc,
On 1/14/22 3:07 PM, Marc Zyngier wrote:
> In order to only keep the highmem devices that actually fit in
> the PA range, check their location against the range and update
> highest_gpa if they fit. If they don't, mark them as disabled.
>
> Signed-off-by: Marc Zyngier
Re
the PA space being 32bit.
>
> Signed-off-by: Marc Zyngier
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> hw/arm/virt-acpi-build.c | 2 --
> hw/arm/virt.c| 5 +
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.
Hi Marc,
On 1/7/22 5:33 PM, Marc Zyngier wrote:
> In order to only keep the highmem devices that actually fit in
> the PA range, check their location against the range and update
> highest_gpa if they fit. If they don't, mark them them as disabled.
s/them them/them
>
> Signed-off-by: Marc Zyngier
Hi Marc,
On 1/10/22 4:45 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Mon, 10 Jan 2022 15:35:44 +0000,
> Eric Auger wrote:
>> Hi Marc,
>>
>> On 1/7/22 5:33 PM, Marc Zyngier wrote:
> [...]
>
>>> @@ -190,7 +191,8 @@ static inline int
>>>
Hi Marc,
On 1/7/22 5:33 PM, Marc Zyngier wrote:
> The highmem attribute is nothing but another way to express the
> PA range of a VM. To support HW that has a smaller PA range then
> what QEMU assumes, pass this PA range to the virt_set_memmap()
> function, allowing it to correctly exclude
Hi Marc,
On 1/7/22 5:33 PM, Marc Zyngier wrote:
> Just like we can control the enablement of the highmem PCIe region
> using highmem_ecam, let's add a control for the highmem GICv3
> redistributor region.
>
> Similarily to highmem_ecam, these redistributors are disabled when
> highmem is off.
>
>
memory
> crossing the 4GiB limit.
>
> Reviewed-by: Andrew Jones
> Signed-off-by: Marc Zyngier
Reviewed-by: Eric Auger
Eric
> ---
> hw/arm/virt.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 4d1
Hi Marc,
On 1/6/22 10:26 PM, Marc Zyngier wrote:
> On Wed, 05 Jan 2022 09:22:39 +,
> Eric Auger wrote:
>> Hi Marc,
>>
>> On 12/27/21 10:16 PM, Marc Zyngier wrote:
>>> Even when the VM is configured with highmem=off, the highest_gpa
>>> field incl
Hi Marc,
On 1/6/22 8:34 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Wed, 05 Jan 2022 09:41:19 +0000,
> Eric Auger wrote:
>> couldn't you simply introduce highmem_redist which is truly missing. You
>> could set it in virt_set_memmap() in case you skip extende
Hi Marc,
On 1/4/22 11:15 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Tue, 04 Jan 2022 15:31:33 +0000,
> Eric Auger wrote:
>> Hi Marc,
>>
>> On 12/27/21 4:53 PM, Marc Zyngier wrote:
>>> Hi Eric,
>>>
>>> Picking this up again after a stupidl
Hi Marc,
On 1/5/22 10:22 AM, Eric Auger wrote:
> Hi Marc,
>
> On 12/27/21 10:16 PM, Marc Zyngier wrote:
>> Even when the VM is configured with highmem=off, the highest_gpa
>> field includes devices that are above the 4GiB limit.
>> Similarily, nothing seem to chec
Hi Marc,
On 12/27/21 10:16 PM, Marc Zyngier wrote:
> Even when the VM is configured with highmem=off, the highest_gpa
> field includes devices that are above the 4GiB limit.
> Similarily, nothing seem to check that the memory is within
> the limit set by the highmem=off option.
>
> This leads to
Hi Marc,
On 12/27/21 4:53 PM, Marc Zyngier wrote:
> Hi Eric,
>
> Picking this up again after a stupidly long time...
>
> On Mon, 04 Oct 2021 13:00:21 +0100,
> Eric Auger wrote:
>> Hi Marc,
>>
>> On 10/3/21 6:46 PM, Marc Zyngier wrote:
>>> Curr
Hi Jason,
On 12/9/21 4:40 PM, Jason Gunthorpe wrote:
> On Thu, Dec 09, 2021 at 08:50:04AM +0100, Eric Auger wrote:
>
>>> The kernel API should accept the S1ContextPtr IPA and all the parts of
>>> the STE that relate to the defining the layout of what the S1Contex
Hi Kevin,
On 12/9/21 4:21 AM, Tian, Kevin wrote:
>> From: Jason Gunthorpe
>> Sent: Wednesday, December 8, 2021 8:56 PM
>>
>> On Wed, Dec 08, 2021 at 08:33:33AM +0100, Eric Auger wrote:
>>> Hi Baolu,
>>>
>>> On 12/8/21 3:44 AM, Lu Baolu wrot
Hi Jason,
On 12/8/21 1:56 PM, Jason Gunthorpe wrote:
> On Wed, Dec 08, 2021 at 08:33:33AM +0100, Eric Auger wrote:
>> Hi Baolu,
>>
>> On 12/8/21 3:44 AM, Lu Baolu wrote:
>>> Hi Eric,
>>>
>>> On 12/7/21 6:22 PM, Eric Auger wrote:
>>>> O
Hi Jason,
On 12/8/21 7:31 PM, Jason Gunthorpe wrote:
> On Wed, Dec 08, 2021 at 05:20:39PM +, Jean-Philippe Brucker wrote:
>> On Wed, Dec 08, 2021 at 08:56:16AM -0400, Jason Gunthorpe wrote:
>>> From a progress perspective I would like to start with simple 'page
>>> tables in userspace', ie no
Hi Baolu,
On 12/8/21 3:44 AM, Lu Baolu wrote:
> Hi Eric,
>
> On 12/7/21 6:22 PM, Eric Auger wrote:
>> On 12/6/21 11:48 AM, Joerg Roedel wrote:
>>> On Wed, Oct 27, 2021 at 12:44:20PM +0200, Eric Auger wrote:
>>>> Signed-off-by: Jean-Philippe Brucker
>>&
Hi Reiji,
On 12/8/21 6:57 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Tue, Dec 7, 2021 at 1:34 AM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 12/4/21 2:45 AM, Reiji Watanabe wrote:
>>> Hi Eric,
>>>
>>> On Thu, Dec 2, 2021 at 2:58 AM Er
Hi Zhangfei,
On 12/7/21 11:35 AM, Zhangfei Gao wrote:
>
>
> On 2021/12/7 下午6:27, Eric Auger wrote:
>> Hi Zhangfei,
>>
>> On 12/3/21 1:27 PM, Zhangfei Gao wrote:
>>> Hi, Eric
>>>
>>> On 2021/10/27 下午6:44, Eric Auger wrote:
>>>
3_v10
>> (use iommu=nested-smmuv3 ARM virt option)
>>
>> Guest dependency:
>> [1] [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node
>>
>> History:
>>
>> v15 -> v16:
>> - guest RIL must support RIL
>> - additional checks in the cache inv
Hi Zhangfei,
On 12/3/21 1:27 PM, Zhangfei Gao wrote:
>
> Hi, Eric
>
> On 2021/10/27 下午6:44, Eric Auger wrote:
>> This series brings the IOMMU part of HW nested paging support
>> in the SMMUv3.
>>
>> The SMMUv3 driver is adapted to support 2 nested stages.
>&
Hi Joerg,
On 12/6/21 11:48 AM, Joerg Roedel wrote:
> On Wed, Oct 27, 2021 at 12:44:20PM +0200, Eric Auger wrote:
>> Signed-off-by: Jean-Philippe Brucker
>> Signed-off-by: Liu, Yi L
>> Signed-off-by: Ashok Raj
>> Signed-off-by: Jacob Pan
>> Signed-off-by: Eric
Hi Reiji,
On 12/4/21 8:59 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Dec 2, 2021 at 5:02 AM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/30/21 2:29 AM, Reiji Watanabe wrote:
>>> Hi Eric,
>>>
>>> On Thu, Nov 25, 2021 at 7:35 AM
Hi Reiji,
On 12/4/21 2:45 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Dec 2, 2021 at 2:58 AM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> Extend sys_regs[] of kvm_cpu_context for ID registers and save ID
&
Hi Reiji,
On 12/4/21 5:35 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Dec 2, 2021 at 4:51 AM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> This patch lays the groundwork to make ID registers writable.
>
Hi
On 12/6/21 10:52 AM, Alexandru Elisei wrote:
> Hi,
>
> On Sat, Dec 04, 2021 at 09:39:59AM -0800, Reiji Watanabe wrote:
>> Hi Eric,
>>
>> On Sat, Dec 4, 2021 at 6:14 AM Eric Auger wrote:
>>>
>>> Hi Reiji,
>>>
>>> On 12/4/21 2:04
Hi Reiji,
On 12/4/21 2:04 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Dec 2, 2021 at 2:57 AM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/30/21 6:32 AM, Reiji Watanabe wrote:
>>> Hi Eric,
>>>
>>> On Thu, Nov 25, 2021 at 12:30 PM
On 11/30/21 6:39 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Nov 25, 2021 at 12:30 PM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> This patch adds id_reg_info for ID_DFR1_EL1 to make it writable
>
Hi Reiji,
On 11/30/21 2:29 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Nov 25, 2021 at 7:35 AM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> This patch adds id_reg_info for ID_AA64PFR0_EL1 to make it writab
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch lays the groundwork to make ID registers writable.
>
> Introduce struct id_reg_info for an ID register to manage the
> register specific control of its value for the guest, and provide set
> of functions commonly used for ID
On 11/25/21 7:40 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Wed, Nov 24, 2021 at 1:07 PM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> This patch lays the groundwork to make ID registers writable.
>
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> Extend sys_regs[] of kvm_cpu_context for ID registers and save ID
> registers' sanitized value in the array for the vCPU at the first
> vCPU reset. Use the saved ones when ID registers are read by
> userspace (via KVM_GET_ONE_REG) or the
Hi Reiji,
On 11/30/21 6:32 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Nov 25, 2021 at 12:30 PM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf,
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which
> means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally
> expose the value for the guest as it is. Since KVM doesn't support
> IMPLEMENTATION DEFINED PMU for the
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch adds id_reg_info for ID_DFR1_EL1 to make it writable
> by userspace.
>
> Signed-off-by: Reiji Watanabe
> ---
> arch/arm64/kvm/sys_regs.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/kvm/sys_regs.c
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch adds id_reg_info for ID_AA64DFR0_EL1 to make it writable
> by userspace.
>
> Return an error if userspace tries to set PMUVER field of the
> register to a value that conflicts with the PMU configuration.
>
> Since number of
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch adds id_reg_info for ID_AA64MMFR0_EL1 to make it
> writable by userspace.
>
> Since ID_AA64MMFR0_EL1 stage 2 granule size fields don't follow the
> standard ID scheme, we need a special handling to validate those fields.
>
>
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch adds id_reg_info for ID_AA64PFR0_EL1 to make it writable by
> userspace.
>
> The CSV2/CSV3 fields of the register were already writable and values
> that were written for them affected all vCPUs before. Now they only
> affect the
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch adds id_reg_info for ID_AA64MMFR0_EL1 to make it
> writable by userspace.
>
> Since ID_AA64MMFR0_EL1 stage 2 granule size fields don't follow the
> standard ID scheme, we need a special handling to validate those fields.
>
>
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch lays the groundwork to make ID registers writable.
>
> Introduce struct id_reg_info for an ID register to manage the
> register specific control of its value for the guest, and provide set
> of functions commonly used for ID
Hi Reiji,
On 11/19/21 5:47 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Nov 18, 2021 at 12:36 PM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> This patch lays the groundwork to make ID registers writ
Hi Reiji,
On 11/18/21 11:00 PM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Nov 18, 2021 at 12:37 PM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> Extend sys_regs[] of kvm_cpu_context for ID registers
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch adds id_reg_info for ID_DFR0_EL1 to make it writable
> by userspace.
>
> Return an error if userspace tries to set PerfMon field of the
> register to a value that conflicts with the PMU configuration.
>
> Signed-off-by: Reiji
Hi Reiji,
On 11/20/21 7:39 AM, Reiji Watanabe wrote:
> Hi Eric,
>
> On Thu, Nov 18, 2021 at 12:34 PM Eric Auger wrote:
>>
>> Hi Reiji,
>>
>> On 11/17/21 7:43 AM, Reiji Watanabe wrote:
>>> Introduce a test for aarch64 to validate basic behavior of
>
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> Extend sys_regs[] of kvm_cpu_context for ID registers and save ID
> registers' sanitized value in the array for the vCPU at the first
> vCPU reset. Use the saved ones when ID registers are read by
> userspace (via KVM_GET_ONE_REG) or the
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> This patch lays the groundwork to make ID registers writable.
>
> Introduce struct id_reg_info for an ID register to manage the
> register specific control of its value for the guest, and provide set
> of functions commonly used for ID
Hi Reiji,
On 11/17/21 7:43 AM, Reiji Watanabe wrote:
> Introduce a test for aarch64 to validate basic behavior of
> KVM_GET_ONE_REG and KVM_SET_ONE_REG for ID registers.
>
> This test runs only when KVM_CAP_ARM_ID_REG_CONFIGURABLE is supported.
That's great to get those tests along with the
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> The requested page might be not resident in memory during the stage-2
> page fault. For example, the requested page could be resident in swap
> device (file). In this case, disk I/O is issued in order to fetch the
> requested page and it could
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> This adds document to explain the interface for asynchronous page
> fault and how it works in general.
>
> Signed-off-by: Gavin Shan
> ---
> Documentation/virt/kvm/arm/apf.rst | 143 +++
>
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> We need put more stuff in the paravirtualization header files when
> the asynchronous page fault is supported. The generic header files
> can't meet the goal.
you need to explain why
This duplicate the generic header files to be
s/This
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> The main work of stage-2 page fault is handled by user_mem_abort().
> When asynchronous page fault is supported, one page fault need to
> be handled with two calls to this function. It means the page fault
> needs to be replayed asynchronously in
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> This uses the generic slot management mechanism for asynchronous
Now we have moved the hash table management in the generic code, Use
this latter ...
> page fault by enabling CONFIG_KVM_ASYNC_PF_SLOT because the private
> implementation is totally
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> It's not allowed to fire duplicate notification for same GFN on
> x86 platform, with help of a hash table. This mechanism is going
s/, with help of a hash table/this is achieved through a hash table
> to be used by arm64 and this makes the code
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> It's not allowed to fire duplicate notification for same GFN on
> x86 platform, with help of a hash table. This mechanism is going
s/, with help of a hash table/this is achieved through a hash table
> to be used by arm64 and this makes the code
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> This moves the definition of "struct kvm_async_pf" and the related
> functions after "struct kvm_vcpu" so that newly added inline functions
> in the subsequent patches can dereference "struct kvm_vcpu" properly.
> Otherwise, the unexpected build
Hi Gavin,
On 8/15/21 2:59 AM, Gavin Shan wrote:
> This adds inline helper kvm_check_async_pf_completion_queue() to
> check if there are pending completion in the queue. The empty stub
> is also added on !CONFIG_KVM_ASYNC_PF so that the caller needn't
> consider if CONFIG_KVM_ASYNC_PF is enabled.
Hi Gavin,
On 8/15/21 2:19 AM, Gavin Shan wrote:
> On 8/15/21 10:13 AM, Gavin Shan wrote:
>> This series intends to virtualize Software Delegated Exception Interface
>> (SDEI), which is defined by DEN0054A. It allows the hypervisor to deliver
>> NMI-alike event to guest and it's needed by
On 8/15/21 2:13 AM, Gavin Shan wrote:
> The injected SDEI event is to send notification to guest. The SDEI
> event might not be needed after it's injected. This introduces API
> to support cancellation on the injected SDEI event if it's not fired
> to the guest yet.
>
> This mechanism will be
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI event injection by implementing kvm_sdei_inject().
> It's called by kernel directly or VMM through ioctl command to inject
> SDEI event to the specific vCPU.
>
> Signed-off-by: Gavin Shan
> ---
> arch/arm64/include/asm/kvm_sdei.h
On 8/15/21 2:13 AM, Gavin Shan wrote:
> The SDEI functionality is ready to be exported so far. This adds
> new capability (KVM_CAP_ARM_SDEI) and exports it.
Need to be documented in
kvm/api.rst
as the rest of the API
Eric
>
> Signed-off-by: Gavin Shan
> ---
> arch/arm64/kvm/arm.c | 3
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports ioctl commands on VM to manage the various objects.
> It's primarily used by VMM to accomplish live migration. The ioctl
> commands introduced by this are highlighted as blow:
below
>
>* KVM_SDEI_CMD_GET_VERSION
> Retrieve the
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> The owner of the SDEI event, like asynchronous page fault, need
owner is not a terminology used in the SDEI spec
> know the state of injected SDEI event. This supports SDEI event
s/need know the state of injected/to know the state of the injected
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_CONTEXT hypercall. It's used by the guest
> to retrieved the original registers (R0 - R17) in its SDEI event
> handler. Those registers can be corrupted during the SDEI event
> delivery.
>
> Signed-off-by: Gavin Shan
>
s/Impment/Implement in the commit title
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This implement kvm_sdei_deliver() to support SDEI event delivery.
> The function is called when the request (KVM_REQ_SDEI) is raised.
> The following rules are taken according to the SDEI specification:
>
>* x0 -
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_{COMPLETE, COMPLETE_AND_RESUME} hypercall.
> They are used by the guest to notify the completion of the SDEI
> event in the handler. The registers are changed according to the
> SDEI specification as below:
>
>* x0 -
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_{PRIVATE, SHARED}_RESET. They are used by the
> guest to purge the private or shared SDEI events, which are registered
to reset all private SDEI event registrations of the calling PE (resp.
PRIVATE or SHARED)
> previously.
>
>
1 - 100 of 1636 matches
Mail list logo
