From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0BA3C433EF for ; Mon, 13 Sep 2021 07:29:36 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8F06A60FDA for ; Mon, 13 Sep 2021 07:29:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8F06A60FDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4H0sWRFgDqS+ujnXxDMtuWFzZmWf0sbbfLIjw6AAZ7Q=; b=bShJXPaA2hL0ac NxSW8rs/S3023hFsKOzl3pZrEBhJZYa7z6Q99wOPvpMte9vRYvx3vegtC2x09gAoGSPrpitO7mUz/ JbPx4C0TeKCZxMygBczWWkeVU1FOHvToX/+9X4jsqQ8sJoegTEz8VNTnv8iwwlmMzPp6Ao8SGKMpl OJGbthypADlzjh1PGGDQ1u/N75lJvRk2BFjVIV8q/FvVCC3Jpe+JaKnz6Bzn5Dej3RxQkmCqw892Q VrgJJIIhMhRRnFb8/JB5FcWow9SiKAlNkT7DYv6hA/QAxqsPE1siZPH2/gmQCO731KuohoziC1DMk 0cANmUmIaOVtHOcE4KjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mPgLn-000WXU-TI; Mon, 13 Sep 2021 07:26:00 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mPgLj-000WWo-6i for linux-arm-kernel@lists.infradead.org; Mon, 13 Sep 2021 07:25:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631517952; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ycK/tCqEmqie6iTs/9nBScnQKNEMyPZZHddjJC00ddA=; b=dCt6VWUDbdoGj8fBD4ddZguKYZY+zHzG+wQRT/qHSflWpelodGSmhy9s/mlgxwBFjTGhZ8 cBAMuShJb1q90+A5HAZrGAW5fv79Hng8fqQJU7GTrsWXZf5qsqfiaF80GxKRfOzACvn01A QlpPA+Mm3MGGBUpFA/cTJnYXlGZ04R0= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-581-vIEYv68bM2m5GhxkHHfl0Q-1; Mon, 13 Sep 2021 03:25:49 -0400 X-MC-Unique: vIEYv68bM2m5GhxkHHfl0Q-1 Received: by mail-ed1-f69.google.com with SMTP id s15-20020a056402520f00b003cad788f1f6so4439294edd.22 for ; Mon, 13 Sep 2021 00:25:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ycK/tCqEmqie6iTs/9nBScnQKNEMyPZZHddjJC00ddA=; b=DX9OcjYK3hYt8QohiHprw3gAxULClnS/n+9xAtCYm8D7TqPkNgVdHQhF0DRKyrQ5+h ZX4ukgFyPMbV6wTkK7PoNW1HtL5QA+2dZQPT0KU7VFMioHv5xa+h0B3d04g8tLvpH35F 4VSkmpBV2xkyjRGrHOX5t+VR8No2zkmy2oGRBGBV3hgRjbPVP9TcjfYBMNbTrVEcTeRK SWPpVoD4/88wO6AJwOT2d99ciD+Rg8bc7KdHichiQ8s3ld9SeMTX/8MYzwms/av0Ko7h 1VSihvhzA4A7yVmFECvRtCzBrNc7SbCysCxj0d4lsq01zwV1Qz2bfIiWsQWUum7d6KYn ie1g== X-Gm-Message-State: AOAM530bDko+VH4uJExHYhIQKULXulEprw4d0l7NAAqaFDixatjsmZph TyRKWTr8Sgn9YbWFMxK6ND7V86q0FM7PvrTZG8WNdTlvOc0vPG2B5DqmjUdzp2bDSJBnP59+wt/ /pdeKGyKf9/um0j8YUXDdVPdR/wznarIHyBc= X-Received: by 2002:a50:d4dc:: with SMTP id e28mr11571609edj.106.1631517948190; Mon, 13 Sep 2021 00:25:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNxTQ2vLqD78w1qZ/yyGrwNlAgo4kC8ZoLROpW9R1ep9CmZ5X0HutmNcr1ZAX/1oPEj6kYKw== X-Received: by 2002:a50:d4dc:: with SMTP id e28mr11571587edj.106.1631517947927; Mon, 13 Sep 2021 00:25:47 -0700 (PDT) Received: from gator.home (cst2-174-132.cust.vodafone.cz. [31.30.174.132]) by smtp.gmail.com with ESMTPSA id m10sm2962374ejx.76.2021.09.13.00.25.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Sep 2021 00:25:47 -0700 (PDT) Date: Mon, 13 Sep 2021 09:25:45 +0200 From: Andrew Jones To: Raghavendra Rao Ananta Cc: Paolo Bonzini , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Reiji Watanabe , Jing Zhang , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v4 09/18] KVM: arm64: selftests: Add guest support to get the vcpuid Message-ID: <20210913072545.vmmlejgg6jtsz4pm@gator.home> References: <20210909013818.1191270-1-rananta@google.com> <20210909013818.1191270-10-rananta@google.com> <20210909075643.fhngqu6tqrpe33gl@gator> <20210910081001.4gljsvmcovvoylwt@gator> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=drjones@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210913_002555_378105_7DEE0CDD X-CRM114-Status: GOOD ( 46.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 10, 2021 at 11:03:58AM -0700, Raghavendra Rao Ananta wrote: > On Fri, Sep 10, 2021 at 1:10 AM Andrew Jones wrote: > > > > On Thu, Sep 09, 2021 at 10:10:56AM -0700, Raghavendra Rao Ananta wrote: > > > On Thu, Sep 9, 2021 at 12:56 AM Andrew Jones wrote: > > > > > > > > On Thu, Sep 09, 2021 at 01:38:09AM +0000, Raghavendra Rao Ananta wrote: > > ... > > > > > + for (i = 0; i < KVM_MAX_VCPUS; i++) { > > > > > + vcpuid = vcpuid_map[i].vcpuid; > > > > > + GUEST_ASSERT_1(vcpuid != VM_VCPUID_MAP_INVAL, mpidr); > > > > > > > > We don't want this assert if it's possible to have sparse maps, which > > > > it probably isn't ever going to be, but... > > > > > > > If you look at the way the array is arranged, the element with > > > VM_VCPUID_MAP_INVAL acts as a sentinel for us and all the proper > > > elements would lie before this. So, I don't think we'd have a sparse > > > array here. > > > > If we switch to my suggestion of adding map entries at vcpu-add time and > > removing them at vcpu-rm time, then the array may become sparse depending > > on the order of removals. > > > Oh, I get it now. But like you mentioned, we add entries to the map > while the vCPUs are getting added and then sync_global_to_guest() > later. This seems like a lot of maintainance, unless I'm interpreting > it wrong or not seeing an advantage. The advantage is that you don't need to create all vcpus before calling the map init function. While it's true that we'll still require a call after adding all vcpus if we want to export the map to the guest, i.e. sync_global_to_guest, we'll never have to worry about the map being out of synch wrt vcpus on the host side, and there's no need to call sync_global_to_guest at all when the test needs the map, but the guest doesn't need to access it. > I like your idea of coming up an arch-independent interface, however. > So I modified it similar to the familiar ucall interface that we have > and does everything in one shot to avoid any confusion: Right, ucall_init does call sync_global_to_guest, but it's the only lib function so far. Everything else exported to the guest must be done explicitly. > > diff --git a/tools/testing/selftests/kvm/include/kvm_util.h > b/tools/testing/selftests/kvm/include/kvm_util.h > index 010b59b13917..0e87cb0c980b 100644 > --- a/tools/testing/selftests/kvm/include/kvm_util.h > +++ b/tools/testing/selftests/kvm/include/kvm_util.h > @@ -400,4 +400,24 @@ uint64_t get_ucall(struct kvm_vm *vm, uint32_t > vcpu_id, struct ucall *uc); > int vm_get_stats_fd(struct kvm_vm *vm); > int vcpu_get_stats_fd(struct kvm_vm *vm, uint32_t vcpuid); > > +#define VM_CPUID_MAP_INVAL -1 > + > +struct vm_cpuid_map { > + uint64_t hw_cpuid; > + int vcpuid; > +}; > + > +/* > + * Create a vcpuid:hw_cpuid map and export it to the guest > + * > + * Input Args: > + * vm - KVM VM. > + * > + * Output Args: None > + * > + * Must be called after all the vCPUs are added to the VM > + */ > +void vm_cpuid_map_init(struct kvm_vm *vm); > +int guest_get_vcpuid(void); > + > #endif /* SELFTEST_KVM_UTIL_H */ > diff --git a/tools/testing/selftests/kvm/lib/aarch64/processor.c > b/tools/testing/selftests/kvm/lib/aarch64/processor.c > index db64ee206064..e796bb3984a6 100644 > --- a/tools/testing/selftests/kvm/lib/aarch64/processor.c > +++ b/tools/testing/selftests/kvm/lib/aarch64/processor.c > @@ -16,6 +16,8 @@ > > static vm_vaddr_t exception_handlers; > > +static struct vm_cpuid_map cpuid_map[KVM_MAX_VCPUS]; > + > static uint64_t page_align(struct kvm_vm *vm, uint64_t v) > { > return (v + vm->page_size) & ~(vm->page_size - 1); > @@ -426,3 +428,42 @@ void vm_install_exception_handler(struct kvm_vm > *vm, int vector, > assert(vector < VECTOR_NUM); > handlers->exception_handlers[vector][0] = handler; > } > + > +void vm_cpuid_map_init(struct kvm_vm *vm) > +{ > + int i = 0; > + struct vcpu *vcpu; > + struct vm_cpuid_map *map; > + > + TEST_ASSERT(!list_empty(&vm->vcpus), "vCPUs must have been created\n"); > + > + list_for_each_entry(vcpu, &vm->vcpus, list) { > + map = &cpuid_map[i++]; > + map->vcpuid = vcpu->id; > + get_reg(vm, vcpu->id, > KVM_ARM64_SYS_REG(SYS_MPIDR_EL1), &map->hw_cpuid); > + map->hw_cpuid &= MPIDR_HWID_BITMASK; > + } > + > + if (i < KVM_MAX_VCPUS) > + cpuid_map[i].vcpuid = VM_CPUID_MAP_INVAL; > + > + sync_global_to_guest(vm, cpuid_map); > +} > + > +int guest_get_vcpuid(void) > +{ > + int i, vcpuid; > + uint64_t mpidr = read_sysreg(mpidr_el1) & MPIDR_HWID_BITMASK; > + > + for (i = 0; i < KVM_MAX_VCPUS; i++) { > + vcpuid = cpuid_map[i].vcpuid; > + > + /* Was this vCPU added to the VM after the map was > initialized? */ > + GUEST_ASSERT_1(vcpuid != VM_CPUID_MAP_INVAL, mpidr); > + > + if (mpidr == cpuid_map[i].hw_cpuid) > + return vcpuid; > + } > + > + /* We should not be reaching here */ > + GUEST_ASSERT_1(0, mpidr); > + return -1; > +} > > This would ensure that we don't have a sparse array and can use the > last non-vCPU element as a sentinal node. > If you still feel preparing the map as and when the vCPUs are created > makes more sense, I can go for it. Yup, I think that's still my preference. We don't really need a sentinel node for such a small array. We can just do static struct vm_cpuid_map cpuid_map[KVM_MAX_VCPUS] = { [0 ... KVM_MAX_VCPUS - 1] = VM_CPUID_MAP_INVAL }; to ensure all invalid nodes are invalid. After a full loop if we didn't find a valid entry, then we assert, which easily supports a sparse array. Also, please don't forget that guest_get_vcpuid() can be common for all architectures. We just need an arch-specific call for get_hw_cpuid(). Thanks, drew > > Regards, > Raghavendra > > Thanks, > > drew > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel