Re: [PATCH] KVM: arm64: cancel the return value check of kvm_arm_init_sve()
Hi Peng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kvmarm/next]
[also build test ERROR on v5.18-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Peng-Wu/KVM-arm64-cancel-the-return-value-check-of-kvm_arm_init_sve/20220520-165501
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next
config: arm64-allyesconfig
(https://download.01.org/0day-ci/archive/20220521/202205211307.mwdibnqs-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/4f7983bee8e912289335be279fb1f0a0abd6b31b
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Peng-Wu/KVM-arm64-cancel-the-return-value-check-of-kvm_arm_init_sve/20220520-165501
git checkout 4f7983bee8e912289335be279fb1f0a0abd6b31b
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/arm64/kvm/reset.c:46:6: error: conflicting types for
>> 'kvm_arm_init_sve'; have 'void(void)'
46 | void kvm_arm_init_sve(void)
| ^~~~
In file included from include/linux/kvm_host.h:45,
from arch/arm64/kvm/reset.c:13:
arch/arm64/include/asm/kvm_host.h:70:5: note: previous declaration of
'kvm_arm_init_sve' with type 'int(void)'
70 | int kvm_arm_init_sve(void);
| ^~~~
vim +46 arch/arm64/kvm/reset.c
45
> 46 void kvm_arm_init_sve(void)
47 {
48 if (system_supports_sve()) {
49 kvm_sve_max_vl = sve_max_virtualisable_vl();
50
51 /*
52 * The get_sve_reg()/set_sve_reg() ioctl interface will
need
53 * to be extended with multiple register slice support
in
54 * order to support vector lengths greater than
55 * VL_ARCH_MAX:
56 */
57 if (WARN_ON(kvm_sve_max_vl > VL_ARCH_MAX))
58 kvm_sve_max_vl = VL_ARCH_MAX;
59
60 /*
61 * Don't even try to make use of vector lengths that
62 * aren't available on all CPUs, for now:
63 */
64 if (kvm_sve_max_vl < sve_max_vl())
65 pr_warn("KVM: SVE vector length for guests
limited to %u bytes\n",
66 kvm_sve_max_vl);
67 }
68 }
69
--
0-DAY CI Kernel Test Service
https://01.org/lkp
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH kvmtool] aarch64: Give up with MTE for AArch32 guest
On Fri, 20 May 2022 13:38:44 +0100, Vladimir Murzin wrote: > KVM doesn't support combination of MTE and AArch32 guest, so do not > even try. > > Applied to kvmtool (master), thanks! [1/1] aarch64: Give up with MTE for AArch32 guest https://git.kernel.org/will/kvmtool/c/324cc0969b7c Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 kvmtool 12/12] arm64: Allow the user to specify the RAM base address
On Mon, 16 May 2022 16:55:26 +0100
Alexandru Elisei wrote:
Hi,
> Allow the user to specify the RAM base address by using -m/--mem size@addr
> command line argument. The base address must be above 2GB, as to not
> overlap with the MMIO I/O region.
Just started to play with this, in general the series looks good to me on
a first glance. I will review in anger next week.
Meanwhile: when you start kvmtool without explicitly specifying a ram size
on the command line, the code misses to initialise cfg.ram_addr, so it
stays at 0 and kvmtool reports:
Fatal: RAM address is below 2GB
One possible fix would be to initialise this in get_ram_size() to
kvm__arch_default_ram_address(), I guess, but you might find a better solution.
Cheers,
Andre
>
> Signed-off-by: Alexandru Elisei
> ---
> arm/aarch64/include/kvm/kvm-arch.h | 2 ++
> arm/aarch64/kvm.c | 5 -
> arm/kvm.c | 7 +--
> builtin-run.c | 29 +
> include/kvm/kvm-config.h | 1 +
> include/kvm/kvm.h | 12
> 6 files changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/arm/aarch64/include/kvm/kvm-arch.h
> b/arm/aarch64/include/kvm/kvm-arch.h
> index ff857ca6e7b4..02d09a413831 100644
> --- a/arm/aarch64/include/kvm/kvm-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-arch.h
> @@ -10,6 +10,8 @@ void kvm__arch_enable_mte(struct kvm *kvm);
>
> #define MAX_PAGE_SIZESZ_64K
>
> +#define ARCH_HAS_CFG_RAM_ADDRESS 1
> +
> #include "arm-common/kvm-arch.h"
>
> #endif /* KVM__KVM_ARCH_H */
> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> index af8e7eae0da2..14ffae9e39dc 100644
> --- a/arm/aarch64/kvm.c
> +++ b/arm/aarch64/kvm.c
> @@ -44,6 +44,9 @@ void kvm__arch_validate_cfg(struct kvm *kvm)
> die("RAM size 0x%llx exceeds maximum allowed 0x%llx",
> kvm->cfg.ram_size, ARM_LOMAP_MAX_MEMORY);
> }
> +
> + if (kvm->cfg.ram_addr < ARM_MEMORY_AREA)
> + die("RAM address is below %luGB", ARM_MEMORY_AREA >> 30);
> }
>
> u64 kvm__arch_default_ram_address(void)
> @@ -117,7 +120,7 @@ int kvm__get_vm_type(struct kvm *kvm)
> return 0;
>
> /* Otherwise, compute the minimal required IPA size */
> - max_ipa = ARM_MEMORY_AREA + kvm->cfg.ram_size - 1;
> + max_ipa = kvm->cfg.ram_addr + kvm->cfg.ram_size - 1;
> ipa_bits = max(32, fls_long(max_ipa));
> pr_debug("max_ipa %lx ipa_bits %d max_ipa_bits %d",
>max_ipa, ipa_bits, max_ipa_bits);
> diff --git a/arm/kvm.c b/arm/kvm.c
> index abcccfabf59e..d51cc15d8b1c 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -55,7 +55,7 @@ void kvm__init_ram(struct kvm *kvm)
> madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size,
> MADV_HUGEPAGE);
>
> - phys_start = ARM_MEMORY_AREA;
> + phys_start = kvm->cfg.ram_addr;
> phys_size = kvm->ram_size;
> host_mem= kvm->ram_start;
>
> @@ -65,6 +65,9 @@ void kvm__init_ram(struct kvm *kvm)
> "address 0x%llx [err %d]", phys_size, phys_start, err);
>
> kvm->arch.memory_guest_start = phys_start;
> +
> + pr_debug("RAM created at 0x%llx - 0x%llx",
> + phys_start, phys_start + phys_size - 1);
> }
>
> void kvm__arch_delete_ram(struct kvm *kvm)
> @@ -201,7 +204,7 @@ bool kvm__load_firmware(struct kvm *kvm, const char
> *firmware_filename)
>
> /* For default firmware address, lets load it at the begining of RAM */
> if (fw_addr == 0)
> - fw_addr = ARM_MEMORY_AREA;
> + fw_addr = kvm->arch.memory_guest_start;
>
> if (!validate_fw_addr(kvm, fw_addr))
> die("Bad firmware destination: 0x%016llx", fw_addr);
> diff --git a/builtin-run.c b/builtin-run.c
> index 57c58be55159..26e6e9974009 100644
> --- a/builtin-run.c
> +++ b/builtin-run.c
> @@ -131,12 +131,22 @@ static u64 parse_mem_option(const char *nptr, char
> **next)
> static int mem_parser(const struct option *opt, const char *arg, int unset)
> {
> struct kvm *kvm = opt->ptr;
> - char *next;
> + char *next, *nptr;
>
> kvm->cfg.ram_size = parse_mem_option(arg, &next);
> if (kvm->cfg.ram_size == 0)
> die("Invalid RAM size: %s", arg);
>
> + kvm->cfg.ram_addr = kvm__arch_default_ram_address();
> + if (kvm__arch_has_cfg_ram_address() && *next == '@') {
> + next++;
> + if (*next == '\0')
> + die("Missing memory address: %s", arg);
> +
> + nptr = next;
> + kvm->cfg.ram_addr = parse_mem_option(nptr, &next);
> + }
> +
> if (*next != '\0')
> die("Invalid memory specifier: %s", arg);
>
> @@ -147,15 +157,26 @@ static int mem_parser(const struct option *opt, const
> char *arg, int unset)
> #define OPT_ARCH_RUN(...)
> #endif
>
> +#ifdef ARCH_HAS_CFG_RAM_ADDRESS
> +#define MEM_OPT_HEL
Re: [PATCH 33/89] KVM: arm64: Handle guest stage-2 page-tables entirely at EL2
Hi,
On Thu, May 19, 2022 at 02:41:08PM +0100, Will Deacon wrote:
> Now that EL2 is able to manage guest stage-2 page-tables, avoid
> allocating a separate MMU structure in the host and instead introduce a
> new fault handler which responds to guest stage-2 faults by sharing
> GUP-pinned pages with the guest via a hypercall. These pages are
> recovered (and unpinned) on guest teardown via the page reclaim
> hypercall.
>
> Signed-off-by: Will Deacon
> ---
[..]
> +static int pkvm_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> + unsigned long hva)
> +{
> + struct kvm_hyp_memcache *hyp_memcache = &vcpu->arch.pkvm_memcache;
> + struct mm_struct *mm = current->mm;
> + unsigned int flags = FOLL_HWPOISON | FOLL_LONGTERM | FOLL_WRITE;
> + struct kvm_pinned_page *ppage;
> + struct kvm *kvm = vcpu->kvm;
> + struct page *page;
> + u64 pfn;
> + int ret;
> +
> + ret = topup_hyp_memcache(hyp_memcache, kvm_mmu_cache_min_pages(kvm));
> + if (ret)
> + return -ENOMEM;
> +
> + ppage = kmalloc(sizeof(*ppage), GFP_KERNEL_ACCOUNT);
> + if (!ppage)
> + return -ENOMEM;
> +
> + ret = account_locked_vm(mm, 1, true);
> + if (ret)
> + goto free_ppage;
> +
> + mmap_read_lock(mm);
> + ret = pin_user_pages(hva, 1, flags, &page, NULL);
When I implemented memory pinning via GUP for the KVM SPE series, I
discovered that the pages were regularly unmapped at stage 2 because of
automatic numa balancing, as change_prot_numa() ends up calling
mmu_notifier_invalidate_range_start().
I was curious how you managed to avoid that, I don't know my way around
pKVM and can't seem to find where that's implemented.
Thanks,
Alex
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 03/89] KVM: arm64: Return error from kvm_arch_init_vm() on allocation failure
Hi,
On Thu, May 19, 2022 at 02:40:38PM +0100, Will Deacon wrote:
> If we fail to allocate the 'supported_cpus' cpumask in kvm_arch_init_vm()
> then be sure to return -ENOMEM instead of success (0) on the failure
> path.
>
> Signed-off-by: Will Deacon
> ---
> arch/arm64/kvm/arm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 523bc934fe2f..775b52871b51 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -146,8 +146,10 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> if (ret)
> goto out_free_stage2_pgd;
>
> - if (!zalloc_cpumask_var(&kvm->arch.supported_cpus, GFP_KERNEL))
> + if (!zalloc_cpumask_var(&kvm->arch.supported_cpus, GFP_KERNEL)) {
> + ret = -ENOMEM;
> goto out_free_stage2_pgd;
> + }
> cpumask_copy(kvm->arch.supported_cpus, cpu_possible_mask);
>
> kvm_vgic_early_init(kvm);
Thank you for the fix:
Reviewed-by: Alexandru Elisei
This can go in independent of the series. I can send it after rc1 if you
prefer to focus on something else.
Thanks,
Alex
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH kvmtool] aarch64: Give up with MTE for AArch32 guest
Hi,
On Fri, May 20, 2022 at 02:48:10PM +0100, Vladimir Murzin wrote:
> Hi Alexandru,
>
> On 5/20/22 14:31, Alexandru Elisei wrote:
> > Hi Vladimir,
> >
> > When I run an --aarch32 guest with --debug this is the message that I'm
> > getting:
> >
> > Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:146: MTE capability not
> > available
> >
> > Would you mind elaborating on the merits of the message that you are
> > proposing:
> >
> > Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:124: MTE is incompatible
> > with AArch32
> >
> > Is it because it explains why the capability is not available?
>
> Hmm, without this patch I'm getting
>
> lkvm run -k /opt/kvm/guest-0/Image -d /opt/kvm/guest-0/fs.ext2 -c 4 -m 681
> --console virtio '--irqchip=gicv3' --params 'console=hvc earlycon
> swiotlb=1024' --aarch32 --debug
>
> + lkvm run -k /opt/kvm/guest-0/Image -m 681 -c 4 --name guest-115
> Info: (arm/aarch64/kvm.c) kvm__get_vm_type:76: max_ipa aa8f ipa_bits 32
> max_ipa_bits 40
> Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:104: MTE capability enabled
> Info: (arm/kvm.c) kvm__arch_load_kernel_image:118: Loaded kernel to
> 0x80008000 (17280980 bytes)
> Info: (arm/kvm.c) kvm__arch_load_kernel_image:134: Placing fdt at
> 0x8fe0 - 0x8fff
> Fatal: Unable to initialise vcpu
>
> with patch applied
>
> lkvm run -k /opt/kvm/guest-0/Image -d /opt/kvm/guest-0/fs.ext2 -c 4 -m 681
> --console virtio '--irqchip=gicv3' --params 'console=hvc earlycon
> swiotlb=1024' --aarch32 --debug
> + lkvm run -k /opt/kvm/guest-0/Image -d /opt/kvm/guest-0/fs.ext2 -c 4 -m 681
> --console virtio '--irqchip=gicv3' --params 'console=hvc earlycon
> swiotlb=1024' --aarch32 --debug
> # lkvm run -k /opt/kvm/guest-0/Image -m 681 -c 4 --name guest-114
> Info: (arm/aarch64/kvm.c) kvm__get_vm_type:76: max_ipa aa8f ipa_bits 32
> max_ipa_bits 40
> Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:92: MTE is incompatible with
> AArch32
> Info: (arm/kvm.c) kvm__arch_load_kernel_image:118: Loaded kernel to
> 0x80008000 (17280980 bytes)
> Info: (arm/kvm.c) kvm__arch_load_kernel_image:134: Placing fdt at
> 0x8fe0 - 0x8fff
> Info: (virtio/mmio.c) virtio_mmio_init:325:
> virtio-mmio.devices=0x200@0x300:36
> Info: (virtio/mmio.c) virtio_mmio_init:325:
> virtio-mmio.devices=0x200@0x3000200:37
> Info: (virtio/mmio.c) virtio_mmio_init:325:
> virtio-mmio.devices=0x200@0x3000400:38
>
> My host and guest kernel is 5.15, maybe I'm just missing some backport?
I'm embarassed now, I didn't check that MTE was enabled on the model.
Without this patch I am indeed seeing the error message:
Fatal: Unable to initialise vcpu
which goes away after I apply your patch.
>
> Cheers
> Vladimir
>
> >
> > Thanks,
> > Alex
> >
> > On Fri, May 20, 2022 at 01:38:44PM +0100, Vladimir Murzin wrote:
> >> KVM doesn't support combination of MTE and AArch32 guest, so do not
> >> even try.
> >>
> >> Signed-off-by: Vladimir Murzin
> >> ---
> >> arm/aarch64/kvm.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> >> index 1b992dd..f3fe854 100644
> >> --- a/arm/aarch64/kvm.c
> >> +++ b/arm/aarch64/kvm.c
> >> @@ -120,6 +120,11 @@ void kvm__arch_enable_mte(struct kvm *kvm)
> >>.cap = KVM_CAP_ARM_MTE,
> >>};
> >>
> >> + if (kvm->cfg.arch.aarch32_guest) {
> >> + pr_debug("MTE is incompatible with AArch32");
Nitpick: I think "MTE disabled because it is incompatible with AArch32" is
slightly better, as it better matches the disabled by user message below.
It's up to you if you want to change the patch, I don't have a preference
either way.
> >> + return;
> >> + }
> >> +
I checked and this also matches the documentation for KVM_CAP_ARM_MTE:
Tested-by: Alexandru Elisei
Reviewed-by: Alexandru Elisei
Thanks,
Alex
> >>if (kvm->cfg.arch.mte_disabled) {
> >>pr_debug("MTE disabled by user");
> >>return;
> >> --
> >> 2.25.1
> >>
>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH kvmtool] aarch64: Give up with MTE for AArch32 guest
Hi Alexandru,
On 5/20/22 14:31, Alexandru Elisei wrote:
> Hi Vladimir,
>
> When I run an --aarch32 guest with --debug this is the message that I'm
> getting:
>
> Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:146: MTE capability not
> available
>
> Would you mind elaborating on the merits of the message that you are
> proposing:
>
> Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:124: MTE is incompatible
> with AArch32
>
> Is it because it explains why the capability is not available?
Hmm, without this patch I'm getting
lkvm run -k /opt/kvm/guest-0/Image -d /opt/kvm/guest-0/fs.ext2 -c 4 -m 681
--console virtio '--irqchip=gicv3' --params 'console=hvc earlycon swiotlb=1024'
--aarch32 --debug
+ lkvm run -k /opt/kvm/guest-0/Image -m 681 -c 4 --name guest-115
Info: (arm/aarch64/kvm.c) kvm__get_vm_type:76: max_ipa aa8f ipa_bits 32
max_ipa_bits 40
Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:104: MTE capability enabled
Info: (arm/kvm.c) kvm__arch_load_kernel_image:118: Loaded kernel to
0x80008000 (17280980 bytes)
Info: (arm/kvm.c) kvm__arch_load_kernel_image:134: Placing fdt at 0x8fe0
- 0x8fff
Fatal: Unable to initialise vcpu
with patch applied
lkvm run -k /opt/kvm/guest-0/Image -d /opt/kvm/guest-0/fs.ext2 -c 4 -m 681
--console virtio '--irqchip=gicv3' --params 'console=hvc earlycon swiotlb=1024'
--aarch32 --debug
+ lkvm run -k /opt/kvm/guest-0/Image -d /opt/kvm/guest-0/fs.ext2 -c 4 -m 681
--console virtio '--irqchip=gicv3' --params 'console=hvc earlycon swiotlb=1024'
--aarch32 --debug
# lkvm run -k /opt/kvm/guest-0/Image -m 681 -c 4 --name guest-114
Info: (arm/aarch64/kvm.c) kvm__get_vm_type:76: max_ipa aa8f ipa_bits 32
max_ipa_bits 40
Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:92: MTE is incompatible with
AArch32
Info: (arm/kvm.c) kvm__arch_load_kernel_image:118: Loaded kernel to
0x80008000 (17280980 bytes)
Info: (arm/kvm.c) kvm__arch_load_kernel_image:134: Placing fdt at 0x8fe0
- 0x8fff
Info: (virtio/mmio.c) virtio_mmio_init:325:
virtio-mmio.devices=0x200@0x300:36
Info: (virtio/mmio.c) virtio_mmio_init:325:
virtio-mmio.devices=0x200@0x3000200:37
Info: (virtio/mmio.c) virtio_mmio_init:325:
virtio-mmio.devices=0x200@0x3000400:38
My host and guest kernel is 5.15, maybe I'm just missing some backport?
Cheers
Vladimir
>
> Thanks,
> Alex
>
> On Fri, May 20, 2022 at 01:38:44PM +0100, Vladimir Murzin wrote:
>> KVM doesn't support combination of MTE and AArch32 guest, so do not
>> even try.
>>
>> Signed-off-by: Vladimir Murzin
>> ---
>> arm/aarch64/kvm.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>> index 1b992dd..f3fe854 100644
>> --- a/arm/aarch64/kvm.c
>> +++ b/arm/aarch64/kvm.c
>> @@ -120,6 +120,11 @@ void kvm__arch_enable_mte(struct kvm *kvm)
>> .cap = KVM_CAP_ARM_MTE,
>> };
>>
>> +if (kvm->cfg.arch.aarch32_guest) {
>> +pr_debug("MTE is incompatible with AArch32");
>> +return;
>> +}
>> +
>> if (kvm->cfg.arch.mte_disabled) {
>> pr_debug("MTE disabled by user");
>> return;
>> --
>> 2.25.1
>>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH kvmtool] aarch64: Give up with MTE for AArch32 guest
Hi Vladimir,
When I run an --aarch32 guest with --debug this is the message that I'm
getting:
Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:146: MTE capability not
available
Would you mind elaborating on the merits of the message that you are
proposing:
Info: (arm/aarch64/kvm.c) kvm__arch_enable_mte:124: MTE is incompatible with
AArch32
Is it because it explains why the capability is not available?
Thanks,
Alex
On Fri, May 20, 2022 at 01:38:44PM +0100, Vladimir Murzin wrote:
> KVM doesn't support combination of MTE and AArch32 guest, so do not
> even try.
>
> Signed-off-by: Vladimir Murzin
> ---
> arm/aarch64/kvm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> index 1b992dd..f3fe854 100644
> --- a/arm/aarch64/kvm.c
> +++ b/arm/aarch64/kvm.c
> @@ -120,6 +120,11 @@ void kvm__arch_enable_mte(struct kvm *kvm)
> .cap = KVM_CAP_ARM_MTE,
> };
>
> + if (kvm->cfg.arch.aarch32_guest) {
> + pr_debug("MTE is incompatible with AArch32");
> + return;
> + }
> +
> if (kvm->cfg.arch.mte_disabled) {
> pr_debug("MTE disabled by user");
> return;
> --
> 2.25.1
>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH kvmtool] aarch64: Give up with MTE for AArch32 guest
KVM doesn't support combination of MTE and AArch32 guest, so do not
even try.
Signed-off-by: Vladimir Murzin
---
arm/aarch64/kvm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
index 1b992dd..f3fe854 100644
--- a/arm/aarch64/kvm.c
+++ b/arm/aarch64/kvm.c
@@ -120,6 +120,11 @@ void kvm__arch_enable_mte(struct kvm *kvm)
.cap = KVM_CAP_ARM_MTE,
};
+ if (kvm->cfg.arch.aarch32_guest) {
+ pr_debug("MTE is incompatible with AArch32");
+ return;
+ }
+
if (kvm->cfg.arch.mte_disabled) {
pr_debug("MTE disabled by user");
return;
--
2.25.1
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [GIT PULL] KVM/arm64 updates for 5.19
On 5/19/22 11:27, Marc Zyngier wrote:
Hi Paolo,
Here's the bulk of the KVM/arm64 updates for 5.19. Major features are
guard pages for the EL2 stacks, save/restore of the guest-visible
hypercall configuration and PSCI suspend support. Further details in
the tag description.
Note that this PR contains a shared branch with the arm64 tree
containing the SME patches to resolve conflicts with the WFxT support
branch.
Pulled, thanks. I solved the conflict for KVM_EXIT_SYSTEM_EVENT values
in your favor.
Paolo
Please pull,
M.
The following changes since commit 672c0c5173427e6b3e2a9bbb7be51ceeec78093a:
Linux 5.18-rc5 (2022-05-01 13:57:58 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-5.19
for you to fetch changes up to 5c0ad551e9aa6188f2bda0977c1cb6768a2b74ef:
Merge branch kvm-arm64/its-save-restore-fixes-5.19 into kvmarm-master/next
(2022-05-16 17:48:36 +0100)
KVM/arm64 updates for 5.19
- Add support for the ARMv8.6 WFxT extension
- Guard pages for the EL2 stacks
- Trap and emulate AArch32 ID registers to hide unsupported features
- Ability to select and save/restore the set of hypercalls exposed
to the guest
- Support for PSCI-initiated suspend in collaboration with userspace
- GICv3 register-based LPI invalidation support
- Move host PMU event merging into the vcpu data structure
- GICv3 ITS save/restore fixes
- The usual set of small-scale cleanups and fixes
Alexandru Elisei (3):
KVM: arm64: Hide AArch32 PMU registers when not available
KVM: arm64: Don't BUG_ON() if emulated register table is unsorted
KVM: arm64: Print emulated register table name when it is unsorted
Ard Biesheuvel (1):
KVM: arm64: Avoid unnecessary absolute addressing via literals
Fuad Tabba (4):
KVM: arm64: Wrapper for getting pmu_events
KVM: arm64: Repack struct kvm_pmu to reduce size
KVM: arm64: Pass pmu events to hyp via vcpu
KVM: arm64: Reenable pmu in Protected Mode
Kalesh Singh (6):
KVM: arm64: Introduce hyp_alloc_private_va_range()
KVM: arm64: Introduce pkvm_alloc_private_va_range()
KVM: arm64: Add guard pages for KVM nVHE hypervisor stack
KVM: arm64: Add guard pages for pKVM (protected nVHE) hypervisor stack
KVM: arm64: Detect and handle hypervisor stack overflows
KVM: arm64: Symbolize the nVHE HYP addresses
Marc Zyngier (30):
arm64: Expand ESR_ELx_WFx_ISS_TI to match its ARMv8.7 definition
arm64: Add RV and RN fields for ESR_ELx_WFx_ISS
arm64: Add HWCAP advertising FEAT_WFXT
arm64: Add wfet()/wfit() helpers
arm64: Use WFxT for __delay() when possible
KVM: arm64: Simplify kvm_cpu_has_pending_timer()
KVM: arm64: Introduce kvm_counter_compute_delta() helper
KVM: arm64: Handle blocking WFIT instruction
KVM: arm64: Offer early resume for non-blocking WFxT instructions
KVM: arm64: Expose the WFXT feature to guests
KVM: arm64: Fix new instances of 32bit ESRs
Merge remote-tracking branch 'arm64/for-next/sme' into kvmarm-master/next
Merge branch kvm-arm64/wfxt into kvmarm-master/next
Merge branch kvm-arm64/hyp-stack-guard into kvmarm-master/next
Merge branch kvm-arm64/aarch32-idreg-trap into kvmarm-master/next
Documentation: Fix index.rst after psci.rst renaming
irqchip/gic-v3: Exposes bit values for GICR_CTLR.{IR, CES}
KVM: arm64: vgic-v3: Expose GICR_CTLR.RWP when disabling LPIs
KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation
KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR
revision
KVM: arm64: vgic-v3: List M1 Pro/Max as requiring the SEIS workaround
KVM: arm64: Hide KVM_REG_ARM_*_BMAP_BIT_COUNT from userspace
KVM: arm64: pmu: Restore compilation when HW_PERF_EVENTS isn't selected
KVM: arm64: Fix hypercall bitmap writeback when vcpus have already run
Merge branch kvm-arm64/hcall-selection into kvmarm-master/next
Merge branch kvm-arm64/psci-suspend into kvmarm-master/next
Merge branch kvm-arm64/vgic-invlpir into kvmarm-master/next
Merge branch kvm-arm64/per-vcpu-host-pmu-data into kvmarm-master/next
Merge branch kvm-arm64/misc-5.19 into kvmarm-master/next
Merge branch kvm-arm64/its-save-restore-fixes-5.19 into
kvmarm-master/next
Mark Brown (25):
arm64/sme: Provide ABI documentation for SME
arm64/sme: System register and exception syndrome definitions
arm64/sme: Manually encode SME instructions
arm64/sme: Early CPU setup for SME
arm64/sme: Basic enumeration support
arm64/sme: Identify supported SME vector lengths at boot
arm64/sme: Implement sysctl to set the default vector length
arm64/sme: Im
[PATCH] Documentation: kvm: reorder ARM-specific section about KVM_SYSTEM_EVENT_SUSPEND
Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 52 +- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 3201933e52d9..6890c04ccde2 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6170,32 +6170,6 @@ Valid values for 'type' are: - KVM_SYSTEM_EVENT_SUSPEND -- the guest has requested a suspension of the VM. -For arm/arm64: --- - - KVM_SYSTEM_EVENT_SUSPEND exits are enabled with the - KVM_CAP_ARM_SYSTEM_SUSPEND VM capability. If a guest invokes the PSCI - SYSTEM_SUSPEND function, KVM will exit to userspace with this event - type. - - It is the sole responsibility of userspace to implement the PSCI - SYSTEM_SUSPEND call according to ARM DEN0022D.b 5.19 "SYSTEM_SUSPEND". - KVM does not change the vCPU's state before exiting to userspace, so - the call parameters are left in-place in the vCPU registers. - - Userspace is _required_ to take action for such an exit. It must - either: - -- Honor the guest request to suspend the VM. Userspace can request - in-kernel emulation of suspension by setting the calling vCPU's - state to KVM_MP_STATE_SUSPENDED. Userspace must configure the vCPU's - state according to the parameters passed to the PSCI function when - the calling vCPU is resumed. See ARM DEN0022D.b 5.19.1 "Intended use" - for details on the function parameters. - -- Deny the guest request to suspend the VM. See ARM DEN0022D.b 5.19.2 - "Caller responsibilities" for possible return values. - If KVM_CAP_SYSTEM_EVENT_DATA is present, the 'data' field can contain architecture specific information for the system-level event. Only the first `ndata` items (possibly zero) of the data array are valid. @@ -6211,6 +6185,32 @@ Previous versions of Linux defined a `flags` member in this struct. The field is now aliased to `data[0]`. Userspace can assume that it is only written if ndata is greater than 0. +For arm/arm64: +-- + +KVM_SYSTEM_EVENT_SUSPEND exits are enabled with the +KVM_CAP_ARM_SYSTEM_SUSPEND VM capability. If a guest invokes the PSCI +SYSTEM_SUSPEND function, KVM will exit to userspace with this event +type. + +It is the sole responsibility of userspace to implement the PSCI +SYSTEM_SUSPEND call according to ARM DEN0022D.b 5.19 "SYSTEM_SUSPEND". +KVM does not change the vCPU's state before exiting to userspace, so +the call parameters are left in-place in the vCPU registers. + +Userspace is _required_ to take action for such an exit. It must +either: + + - Honor the guest request to suspend the VM. Userspace can request + in-kernel emulation of suspension by setting the calling vCPU's + state to KVM_MP_STATE_SUSPENDED. Userspace must configure the vCPU's + state according to the parameters passed to the PSCI function when + the calling vCPU is resumed. See ARM DEN0022D.b 5.19.1 "Intended use" + for details on the function parameters. + + - Deny the guest request to suspend the VM. See ARM DEN0022D.b 5.19.2 + "Caller responsibilities" for possible return values. + :: /* KVM_EXIT_IOAPIC_EOI */ -- 2.31.1 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
