lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Jun 2022 09:40:27 +0200
From:   Andrew Jones <drjones@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Marc Zyngier <maz@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
        kvm@...r.kernel.org, Vitaly Kuznetsov <vkuznets@...hat.com>,
        David Matlack <dmatlack@...gle.com>,
        Ben Gardon <bgardon@...gle.com>,
        Oliver Upton <oupton@...gle.com>, linux-kernel@...r.kernel.org,
        anup@...infault.org, Raghavendra Rao Ananta <rananta@...gle.com>,
        eric.auger@...hat.com
Subject: Re: [PATCH v2 000/144] KVM: selftests: Overhaul APIs, purge VCPU_ID

On Wed, Jun 08, 2022 at 11:20:06PM +0000, Sean Christopherson wrote:
> On Wed, Jun 08, 2022, Marc Zyngier wrote:
> > On 2022-06-07 16:27, Paolo Bonzini wrote:
> > > Marc, Christian, Anup, can you please give this a go?
> > 
> > Can you please, pretty please, once and for all, kill that alias you
> > seem to have for me and  email me on an address I actually can read?
> > 
> > I can't remember how many times you emailed me on my ex @arm.com address
> > over the past 2+years...
> > 
> > The same thing probably applies to Sean, btw.
> 
> Ha!  I was wondering how my old @intel address snuck in...
> 
> On the aarch64 side, with the following tweaks, courtesy of Raghu, all tests
> pass.  I'll work these into the next version, and hopefully also learn how to
> run on aarch64 myself...
> 
> Note, the i => 0 "fix" in test_v3_typer_accesses() is a direct revert of patch 3,
> "KVM: selftests: Fix typo in vgic_init test".  I'll just drop that patch unless
> someone figures out why doing the right thing causes the test to fail.

CCing Eric for that one.

> 
> diff --git a/tools/testing/selftests/kvm/aarch64/vgic_init.c b/tools/testing/selftests/kvm/aarch64/vgic_init.c
> index b91ea02a8a80..66b7e9c76370 100644
> --- a/tools/testing/selftests/kvm/aarch64/vgic_init.c
> +++ b/tools/testing/selftests/kvm/aarch64/vgic_init.c
> @@ -317,7 +317,7 @@ static void test_vgic_then_vcpus(uint32_t gic_dev_type)
> 
>         /* Add the rest of the VCPUs */
>         for (i = 1; i < NR_VCPUS; ++i)
> -               vm_vcpu_add(v.vm, i, guest_code);
> +               vcpus[i] = vm_vcpu_add(v.vm, i, guest_code);
> 
>         ret = run_vcpu(vcpus[3]);
>         TEST_ASSERT(ret == -EINVAL, "dist/rdist overlap detected on 1st vcpu run");
> @@ -424,7 +424,7 @@ static void test_v3_typer_accesses(void)
>                             KVM_DEV_ARM_VGIC_CTRL_INIT, NULL);
> 
>         for (i = 0; i < NR_VCPUS ; i++) {
> -               ret = v3_redist_reg_get(v.gic_fd, i, GICR_TYPER, &val);
> +               ret = v3_redist_reg_get(v.gic_fd, 0, GICR_TYPER, &val);
>                 TEST_ASSERT(!ret && !val, "read GICR_TYPER before rdist region setting");
>         }
> 
> @@ -654,11 +654,12 @@ static void test_v3_its_region(void)
>   */
>  int test_kvm_device(uint32_t gic_dev_type)
>  {
> +       struct kvm_vcpu *vcpus[NR_VCPUS];
>         struct vm_gic v;
>         uint32_t other;
>         int ret;
> 
> -       v.vm = vm_create_with_vcpus(NR_VCPUS, guest_code, NULL);
> +       v.vm = vm_create_with_vcpus(NR_VCPUS, guest_code, vcpus);
> 
>         /* try to create a non existing KVM device */
>         ret = __kvm_test_create_device(v.vm, 0);
> diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> index b3116c151d1c..17f7ef975d5c 100644
> --- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> +++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
> @@ -419,7 +419,7 @@ static void run_test(struct vcpu_config *c)
> 
>         check_supported(c);
> 
> -       vm = vm_create_barebones();
> +       vm = vm_create(1);

Hmm, looks like something, somewhere for AArch64 needs improving to avoid
strangeness like this. I'll look into it after we get this series merged.

>         prepare_vcpu_init(c, &init);
>         vcpu = aarch64_vcpu_add(vm, 0, &init, NULL);
>         finalize_vcpu(vcpu, c);
> 

Thanks,
drew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ