From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3C2020EE6 for ; Tue, 22 Aug 2023 23:17:25 +0000 (UTC) Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-56f75e70190so876760a12.3 for ; Tue, 22 Aug 2023 16:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692746245; x=1693351045; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=oFwVY5f5dTBaMzDscxqMGNrjI0xrE58qgkFcYAhYpMc=; b=75CU7MMPm59DuVURW4I5Awl+gGVby465miL42+4YWEZODWWEL1GIFpxXTJekpZnNnl N2+UnX2W4vOlRH75+HBCFSmi5KGyPUK+mTvBnhZwlFmzX9cCvSTIE7ZL1eAz9khnzhtP rknG3bjV6rcHOM9m2TBB2RUQgzFIUj/yrDi0u9in7pP+Djas/sZ1r/Eb7aIR9uP5sx0B hKeT31r+ZeTT5KpzX3mpjuNkpOeSLI6FVVRN8X1Q8PjrcDEOIGp6x27azlCmYj9H+sBZ V4N/le27vTaBzt7aJ4R4VYM2mXzinjZXff2aSp37hu/O48S1EavfVsSROouHe2adoqLg 7g2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692746245; x=1693351045; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oFwVY5f5dTBaMzDscxqMGNrjI0xrE58qgkFcYAhYpMc=; b=FEF78sPThQ3VhzR4BwNImszfGjcA4dBq8CDDeXFkN+wAdKJQ1V5RNoBU2iks+90kvl /PRhiaa4nUsaXhhL6d41ObG3DHJiCYLFz60/xOP5Czz5Qkgm5pmCFfU28sELtmy6TgSZ RvZOdKf8Ssig9C859ALoyclH1W+kuF/HOVmx+2OoaEK0SvsnC2cwuOB1kmPz2bnNOomM TR89NXps7XdGEX03tuo2dXaQ8OL5prQX/od7WfdyE5xg0JnDJe0QyTxmJeTQwcrGoKda sS8iFG3i3X+fz54nwSbJGQVDJ74GoKNwMS1aLL4JcZq85OG1u0KzNnaPXWmpXZe4DVsg 7Ytg== X-Gm-Message-State: AOJu0YzgqpyJyoRq/twdmMzUiapoi1sRySS1z+IxAfV6GsUPyo9nUJ/J 6TDRu1JXCDI2UjrhR6wpvqQxxignOrM= X-Google-Smtp-Source: AGHT+IH25EflXFYRsSAIONlQdF4yEYShAZMjZEb7bXaRk6krlSYytMpTmCeiKJi71iN2KbTqlbAvt/EfaUY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:fb03:b0:1bb:8c42:79f4 with SMTP id le3-20020a170902fb0300b001bb8c4279f4mr4246479plb.2.1692746245174; Tue, 22 Aug 2023 16:17:25 -0700 (PDT) Date: Tue, 22 Aug 2023 16:17:23 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <52c6a8a6-3a0a-83ba-173d-0833e16b64fd@amd.com> Message-ID: Subject: Re: [PATCH 4/8] KVM: gmem: protect kvm_mmu_invalidate_end() From: Sean Christopherson To: Ashish Kalra Cc: Mingwei Zhang , Jacky Li , isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Michael Roth , Paolo Bonzini , erdemaktas@google.com, Sagi Shahar , David Matlack , Kai Huang , Zhi Wang , chen.bo@intel.com, linux-coco@lists.linux.dev, Chao Peng , Ackerley Tng , Vishal Annapurve , Yuan Yao , Jarkko Sakkinen , Xu Yilun , Quentin Perret , wei.w.wang@intel.com, Fuad Tabba Content-Type: text/plain; charset="us-ascii" On Mon, Aug 21, 2023, Ashish Kalra wrote: > Hello Mingwei & Sean, > > On 8/18/2023 9:08 PM, Mingwei Zhang wrote: > The maximum hits are seen with shmem_fallocate and madvise, which we believe > are response to shared<->private > GHCB page-state-chage requests. discard=both handles discard both for > private and shared memory, so freeing shared memory > via fallocate(shared_memfd, FALLOC_FL_PUNCH_HOLE, ...) would trigger the > notifiers when freeing shared pages after guest converts a GPA to > private. > > Now, as with SNP+guest_memfd, guest private memory is not mapped in host > anymore, so i added a generic fix (instead of Sean's proposed patch of > checking for SNP guest inside sev_guest_memory_reclaimed()): > > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -593,6 +593,9 @@ static __always_inline int __kvm_handle_hva_range(struct > kvm *kvm, > unsigned long hva_start, hva_end; > > slot = container_of(node, struct kvm_memory_slot, > hva_node[slots->node_idx]); > + if (kvm_slot_can_be_private(slot)) { > + continue; > + } > hva_start = max(range->start, slot->userspace_addr); > hva_end = min(range->end, slot->userspace_addr + > (slot->npages << > PAGE_SHIFT)); ... > As expected, the SEV hook is not invoked for the guest private memory pages > (no more invalidation from shmem_fallocate() + madvise()). > > Isn't it better to skip invoking the KVM MMU invalidation notifier when the > invalidated range belongs to guest private memory ? Oooh, you're running into problems where KVM blasts both the private and shared mappings even though invalidations from the mmu_notifier are shared-only by definition. The answer is "yes", but simply skipping slots that _can_ be private is wrong, as KVM still needs to zap any shared mappings. I have a plan[*], but I completely spaced on incorporating the idea into the gmem RFC. I'll add that to the "list of todos for merging gmem", which I need to get sent out asap. https://lore.kernel.org/all/ZJX0hk+KpQP0KUyB@google.com > > In fact, AFAIC, SNP VM does not track whether each page is previously > > shared, isn't it? If a page was previously shared and was written by the > > host kernel or devices before it was changed to private. No one tracks it > > and dirty caches are there! > > The skipped invalidation here covered the case Mingwei mentioned above, > where the pages are changed from private->shared and subsequent freeing of > shared pages triggered the invalidation. > > But, then why are we concerned about this, i thought we have concerns about > the case where the dirty cache lines contain encrypted guest data ? Yes, that's my understanding as well (assuming by "this" you mean the case where the CPU cache has dirty lines for _shared_ addresses).