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