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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26D53C433FE for ; Mon, 18 Oct 2021 10:32:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0D25E60E97 for ; Mon, 18 Oct 2021 10:32:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230376AbhJRKed (ORCPT ); Mon, 18 Oct 2021 06:34:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229491AbhJRKec (ORCPT ); Mon, 18 Oct 2021 06:34:32 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36E54C06161C for ; Mon, 18 Oct 2021 03:32:21 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id b189-20020a1c1bc6000000b0030da052dd4fso8056637wmb.3 for ; Mon, 18 Oct 2021 03:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Gy0sHksnt+PEnqqXO6xICRTdN60Lc9eTfBQpwKge7yw=; b=O4of8n6X9NBPN4KWNWUJs/0mWzTc116qBuKDx3ncFthvjhtsyL5DV2kBO0oVRG2oIh R23RzUj3/dJp4qwHQHvuk/y2x51na6lRlbVwxnC+9CRpBOCwDAH4UlgfsJbVmB2x5lRg G2j+W0EWHRCCZkLvZP6GgzrSINGeENXTpyB0hfVC98NkB9ys1AwlyGsqdfPTfp4b0JkN y5IHHrIP08Poykj/HOb4KUgeMZLIBJ66URZVb6eYlcauxcx9uNn0wIvWtyoNmHgmuqPj 7OosgV3O9JTZndiBJb0m0eNQEc5ibTOxG49zYgd1cERqKbT87xl5CKEuPRsyq6VOnQv9 fJ0w== 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=Gy0sHksnt+PEnqqXO6xICRTdN60Lc9eTfBQpwKge7yw=; b=dIfIiANwNDlpkItJ/foXt8FW9aVzt6/8AJBxLF30eT+VrCCdbOCNLC4YtcLUsva6G8 qoz+lOU2m+b2EOE+U7d0icTsu1Uzx1nKGAU99j4EqM5mca4M+/fQ+Vxmq1N9pIVwH8/a ailwNHd/ytY4OVsCKZIogGzaHaQvry3M/RyYn11AE8u6r7wLjBD5qYWPQ45rkgOKGTCA oy9wbNDW35hxtcI8bptstWh5hR50Fv/mkuHwSvU8zwtmyHOaB+rrurkrJndqRWrS4++r AnX6m+y8ZWP0COr5iKIbG8Be+hV2mmuUJsRw9lsYzHHRvZn6PuOmoehXGH2C8HHhljbz 9PAg== X-Gm-Message-State: AOAM531LIbS5QMF8iMmOlpmYfB4PrGylDqunO/0+YQrwuccGE9XMf21m 6uSKn9d48mZeB8q3b19caevJyA== X-Google-Smtp-Source: ABdhPJz+FBDbOuFngAsn1vKBnLFL7clNmJbT3DoPREC11e6c1F2lUuWQ/TmDO8FETn0vXuk/SALxwg== X-Received: by 2002:a1c:1d13:: with SMTP id d19mr29804562wmd.190.1634553139612; Mon, 18 Oct 2021 03:32:19 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:ba81:6f1b:ab2e:f120]) by smtp.gmail.com with ESMTPSA id d24sm11609621wmb.35.2021.10.18.03.32.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Oct 2021 03:32:19 -0700 (PDT) Date: Mon, 18 Oct 2021 11:32:13 +0100 From: Quentin Perret To: Marc Zyngier Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Fuad Tabba , David Brazdil , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 16/16] KVM: arm64: pkvm: Unshare guest structs during teardown Message-ID: References: <20211013155831.943476-1-qperret@google.com> <20211013155831.943476-17-qperret@google.com> <87h7dhupfa.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h7dhupfa.wl-maz@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 16 Oct 2021 at 13:25:45 (+0100), Marc Zyngier wrote: > At this stage, the old thread may have been destroyed and the memory > recycled. What happens if, in the interval, that memory gets shared > again in another context? My guts feeling is that either the sharing > fails, or the unshare above breaks something else (the refcounting > doesn't save us if the sharing is not with HYP). Aha, yes, that's a good point. The problematic scenario would be: a vcpu runs in the context of task A, then blocks. Then task A is destroyed, but the vcpu isn't (possibly because e.g. userspace intends to run it in the context of another task or something along those lines). But the thread_info and fpsimd_state of task A remain shared with the hypervisor until the next vcpu run, even though the memory has been freed by the host, and is possibly reallocated to another guest in the meantime. So yes, at this point sharing/donating this memory range with a new guest will fail, and confuse the host massively :/ > In any case, I wonder whether we need a notification from the core > code that a thread for which we have a HYP mapping is gone so that we > can mop up the mapping at that point. That's similar to what we have > for MMU notifiers and S2 PTs. > > This is doable by hooking into fpsimd_release_task() and extending > thread_struct to track the sharing with HYP. I've been looking into this, but struggled to find a good way to avoid all the races. Specifically, handling the case where a vcpu and the task which last ran it get destroyed at the same time isn't that easy to handle: you end up having to maintain pointers from the task to the vcpu and vice versa, but I have no obvious idea to update them both in a non-racy way (other than having a one big lock to serialize all those changes, but that would mean serializing all task destructions so that really doesn't scale). Another option is to take a refcount on 'current' from kvm_arch_vcpu_run_map_fp() before sharing thread-specific structs with the hyp and release the refcount of the previous task after unsharing. But that means we'll have to also drop the refcount when the vcpu gets destroyed, as well as explicitly unshare at that point. Shouldn't be too bad I think. Thoughts? Thanks, Quentin 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67C25C4332F for ; Mon, 18 Oct 2021 10:32:24 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D4C9060FED for ; Mon, 18 Oct 2021 10:32:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D4C9060FED Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5EA1E4B28A; Mon, 18 Oct 2021 06:32:23 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP4lFDcEPPoM; Mon, 18 Oct 2021 06:32:22 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5262E4B27D; Mon, 18 Oct 2021 06:32:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D35BB4B1E6 for ; Mon, 18 Oct 2021 06:32:21 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6euCnfV5lF5v for ; Mon, 18 Oct 2021 06:32:20 -0400 (EDT) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id B57DC4B1DC for ; Mon, 18 Oct 2021 06:32:20 -0400 (EDT) Received: by mail-wm1-f42.google.com with SMTP id g2so8282920wme.4 for ; Mon, 18 Oct 2021 03:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Gy0sHksnt+PEnqqXO6xICRTdN60Lc9eTfBQpwKge7yw=; b=O4of8n6X9NBPN4KWNWUJs/0mWzTc116qBuKDx3ncFthvjhtsyL5DV2kBO0oVRG2oIh R23RzUj3/dJp4qwHQHvuk/y2x51na6lRlbVwxnC+9CRpBOCwDAH4UlgfsJbVmB2x5lRg G2j+W0EWHRCCZkLvZP6GgzrSINGeENXTpyB0hfVC98NkB9ys1AwlyGsqdfPTfp4b0JkN y5IHHrIP08Poykj/HOb4KUgeMZLIBJ66URZVb6eYlcauxcx9uNn0wIvWtyoNmHgmuqPj 7OosgV3O9JTZndiBJb0m0eNQEc5ibTOxG49zYgd1cERqKbT87xl5CKEuPRsyq6VOnQv9 fJ0w== 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=Gy0sHksnt+PEnqqXO6xICRTdN60Lc9eTfBQpwKge7yw=; b=TagPe7e2R229u/nXCMoKBPDAtXSo3rQVo9JyyxiDxDG75Cb84Ut0CDVmq+8D9o7h7O UxyrpY3/OEQL8+yk9+uKswl4n87mVPlnEp7r56pGwGZaUy/UtTdJQCv8BMThRugM/lns 9qAypVYie8C8BDeMK5fFxj/ivxzNF5fsHuwEfq8s4sTdTYs6kPhZTfUTjtJUbIMq4jdz eVSteq0iT9W7QY7DXXnYZKRV+oBkhe8pkMZsRH9USLBdci1h/EenetoigwGF5QCSJH4k 9gTHRDpOb7qjgT6NJgEZ1Fbjs6kxKRpIKbVDYBVQ6U+GicZJDDLr0jrdy8fH5DRciOe2 H7XQ== X-Gm-Message-State: AOAM530VSbsSS68WBo36l6s7XhNlrz+LCNpP35Vb7tp+RujFeA4T3JhI frIfIXFtjtVN7CQjv1DbOa/DXQ== X-Google-Smtp-Source: ABdhPJz+FBDbOuFngAsn1vKBnLFL7clNmJbT3DoPREC11e6c1F2lUuWQ/TmDO8FETn0vXuk/SALxwg== X-Received: by 2002:a1c:1d13:: with SMTP id d19mr29804562wmd.190.1634553139612; Mon, 18 Oct 2021 03:32:19 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:ba81:6f1b:ab2e:f120]) by smtp.gmail.com with ESMTPSA id d24sm11609621wmb.35.2021.10.18.03.32.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Oct 2021 03:32:19 -0700 (PDT) Date: Mon, 18 Oct 2021 11:32:13 +0100 From: Quentin Perret To: Marc Zyngier Subject: Re: [PATCH 16/16] KVM: arm64: pkvm: Unshare guest structs during teardown Message-ID: References: <20211013155831.943476-1-qperret@google.com> <20211013155831.943476-17-qperret@google.com> <87h7dhupfa.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87h7dhupfa.wl-maz@kernel.org> Cc: kernel-team@android.com, Will Deacon , Catalin Marinas , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Saturday 16 Oct 2021 at 13:25:45 (+0100), Marc Zyngier wrote: > At this stage, the old thread may have been destroyed and the memory > recycled. What happens if, in the interval, that memory gets shared > again in another context? My guts feeling is that either the sharing > fails, or the unshare above breaks something else (the refcounting > doesn't save us if the sharing is not with HYP). Aha, yes, that's a good point. The problematic scenario would be: a vcpu runs in the context of task A, then blocks. Then task A is destroyed, but the vcpu isn't (possibly because e.g. userspace intends to run it in the context of another task or something along those lines). But the thread_info and fpsimd_state of task A remain shared with the hypervisor until the next vcpu run, even though the memory has been freed by the host, and is possibly reallocated to another guest in the meantime. So yes, at this point sharing/donating this memory range with a new guest will fail, and confuse the host massively :/ > In any case, I wonder whether we need a notification from the core > code that a thread for which we have a HYP mapping is gone so that we > can mop up the mapping at that point. That's similar to what we have > for MMU notifiers and S2 PTs. > > This is doable by hooking into fpsimd_release_task() and extending > thread_struct to track the sharing with HYP. I've been looking into this, but struggled to find a good way to avoid all the races. Specifically, handling the case where a vcpu and the task which last ran it get destroyed at the same time isn't that easy to handle: you end up having to maintain pointers from the task to the vcpu and vice versa, but I have no obvious idea to update them both in a non-racy way (other than having a one big lock to serialize all those changes, but that would mean serializing all task destructions so that really doesn't scale). Another option is to take a refcount on 'current' from kvm_arch_vcpu_run_map_fp() before sharing thread-specific structs with the hyp and release the refcount of the previous task after unsharing. But that means we'll have to also drop the refcount when the vcpu gets destroyed, as well as explicitly unshare at that point. Shouldn't be too bad I think. Thoughts? Thanks, Quentin _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18CDEC433EF for ; Mon, 18 Oct 2021 10:58:50 +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 CB7EE61353 for ; Mon, 18 Oct 2021 10:58:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CB7EE61353 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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=zJZRxHcqh0tye2h2F6yaQJINXFhSeQs6omLvEc2Ze2A=; b=MQkr9B49U82hOm cfwoZhvzi5nekUZQhmg6odPT5oS5IjWBBRP+g3xFAnipBCdGEYljRc6mH1Bq6Wp63PCpiJ/zyxSzj K9br6ums/4FAu653kFooGtu9onjTThmxO0scHMI6kBz+F+g29nX2GVTAmyGVM/MMZYdVH8hFHxIat VOF1D9tXeF8ba4IcbJoWw5kGQqRX2K+FmZ7R/B0kdmByH+hCvHvrTxzZkQWMd2Y8+TSeOEWkqvuym 7IJuly5Bd84pCEwD0CBwOS64cWj24/+xXMNeZdO2MbDhrMJcNjNEGjk/+rDdLH22Vaqz6dh3Dewca /ptcsG8ZmeXTzAYI3VCQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mcQKC-00FAqV-7W; Mon, 18 Oct 2021 10:57:00 +0000 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mcPwP-00F26i-10 for linux-arm-kernel@lists.infradead.org; Mon, 18 Oct 2021 10:32:26 +0000 Received: by mail-wm1-x32d.google.com with SMTP id l38-20020a05600c1d2600b0030d80c3667aso8048955wms.5 for ; Mon, 18 Oct 2021 03:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Gy0sHksnt+PEnqqXO6xICRTdN60Lc9eTfBQpwKge7yw=; b=O4of8n6X9NBPN4KWNWUJs/0mWzTc116qBuKDx3ncFthvjhtsyL5DV2kBO0oVRG2oIh R23RzUj3/dJp4qwHQHvuk/y2x51na6lRlbVwxnC+9CRpBOCwDAH4UlgfsJbVmB2x5lRg G2j+W0EWHRCCZkLvZP6GgzrSINGeENXTpyB0hfVC98NkB9ys1AwlyGsqdfPTfp4b0JkN y5IHHrIP08Poykj/HOb4KUgeMZLIBJ66URZVb6eYlcauxcx9uNn0wIvWtyoNmHgmuqPj 7OosgV3O9JTZndiBJb0m0eNQEc5ibTOxG49zYgd1cERqKbT87xl5CKEuPRsyq6VOnQv9 fJ0w== 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=Gy0sHksnt+PEnqqXO6xICRTdN60Lc9eTfBQpwKge7yw=; b=5DzdR3rQyhN5yk/d/eP3Y+Glo1Wp14sMhUCoyAgAV9uBr0GGjz3/L1ELTnKNP+0qk0 yWmbYGB0BHboKFjXvoDIJGRaYQmtVVCesM0M0hejG9DHQIHN16rik8z1dl4V/DsjPTTA J/UL++bPn872DcsDgym7Yo6cBep+wstnAUtksQoiPsCzzKRtz1oyDCF2sJXApmmW4PWN zf1vsOpDbYVzU3MMSek1qIzmznZLzVZRG73ckNIq0N8uIalrWieZr0Hgd87/IxJTc2Si hBn28I51c3k8hqxnmHI7wym4CB+C7GdCe9zvqW5mAJVMQb6LBGRDKQfdORTLTbsvEGrb RoOw== X-Gm-Message-State: AOAM531hlrQavUIUgMbVXNEe8YbZrNgRISIq4vjeuDhUH6tP+jaDjOFz jsGjCw7RXNN3cjhZvx+NWSu/ag== X-Google-Smtp-Source: ABdhPJz+FBDbOuFngAsn1vKBnLFL7clNmJbT3DoPREC11e6c1F2lUuWQ/TmDO8FETn0vXuk/SALxwg== X-Received: by 2002:a1c:1d13:: with SMTP id d19mr29804562wmd.190.1634553139612; Mon, 18 Oct 2021 03:32:19 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:ba81:6f1b:ab2e:f120]) by smtp.gmail.com with ESMTPSA id d24sm11609621wmb.35.2021.10.18.03.32.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Oct 2021 03:32:19 -0700 (PDT) Date: Mon, 18 Oct 2021 11:32:13 +0100 From: Quentin Perret To: Marc Zyngier Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Fuad Tabba , David Brazdil , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 16/16] KVM: arm64: pkvm: Unshare guest structs during teardown Message-ID: References: <20211013155831.943476-1-qperret@google.com> <20211013155831.943476-17-qperret@google.com> <87h7dhupfa.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87h7dhupfa.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211018_033225_121660_27B37575 X-CRM114-Status: GOOD ( 19.56 ) 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 Saturday 16 Oct 2021 at 13:25:45 (+0100), Marc Zyngier wrote: > At this stage, the old thread may have been destroyed and the memory > recycled. What happens if, in the interval, that memory gets shared > again in another context? My guts feeling is that either the sharing > fails, or the unshare above breaks something else (the refcounting > doesn't save us if the sharing is not with HYP). Aha, yes, that's a good point. The problematic scenario would be: a vcpu runs in the context of task A, then blocks. Then task A is destroyed, but the vcpu isn't (possibly because e.g. userspace intends to run it in the context of another task or something along those lines). But the thread_info and fpsimd_state of task A remain shared with the hypervisor until the next vcpu run, even though the memory has been freed by the host, and is possibly reallocated to another guest in the meantime. So yes, at this point sharing/donating this memory range with a new guest will fail, and confuse the host massively :/ > In any case, I wonder whether we need a notification from the core > code that a thread for which we have a HYP mapping is gone so that we > can mop up the mapping at that point. That's similar to what we have > for MMU notifiers and S2 PTs. > > This is doable by hooking into fpsimd_release_task() and extending > thread_struct to track the sharing with HYP. I've been looking into this, but struggled to find a good way to avoid all the races. Specifically, handling the case where a vcpu and the task which last ran it get destroyed at the same time isn't that easy to handle: you end up having to maintain pointers from the task to the vcpu and vice versa, but I have no obvious idea to update them both in a non-racy way (other than having a one big lock to serialize all those changes, but that would mean serializing all task destructions so that really doesn't scale). Another option is to take a refcount on 'current' from kvm_arch_vcpu_run_map_fp() before sharing thread-specific structs with the hyp and release the refcount of the previous task after unsharing. But that means we'll have to also drop the refcount when the vcpu gets destroyed, as well as explicitly unshare at that point. Shouldn't be too bad I think. Thoughts? Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel