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 E35AFC433F5 for ; Mon, 1 Nov 2021 17:44:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C993060EBC for ; Mon, 1 Nov 2021 17:44:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231357AbhKARrc (ORCPT ); Mon, 1 Nov 2021 13:47:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231168AbhKARra (ORCPT ); Mon, 1 Nov 2021 13:47:30 -0400 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2804FC061764 for ; Mon, 1 Nov 2021 10:44:57 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id v138so40989148ybb.8 for ; Mon, 01 Nov 2021 10:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UQ6siRywOjbV4IU70GIWXbdJs7RhMmkbN5QW6jS9pb4=; b=Ai6GsO8fZzOL1OMi2wZJDrN49HYzmeiktfpXN4iIrk3IuRy0Kdnltpe7mYgLR3iukz iiFO3hNRFLIvtwkJo9wMpEopuqrf6vRqkF/lsGeewSbTk0a0rSAeUN0ze+wv56QzCtLt SYSsEE9rxBBuPdSUMVuq2iwXQWymsxN/nORbuQtHm3zwVybakhGjrVKQa9/RDSPHioSn XDdEU6mFynzoL+JP1CfQi7z0F7QeAg/yn0rLocwQk4hhdISAzf2ihIui8vklt/TH0lvh e4j2P+JulU6lTgzTUnR91TE46HoLBCcIP1gCjH1lVKdCKU+1JadWSjuPISJfM34xBuXS jcJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UQ6siRywOjbV4IU70GIWXbdJs7RhMmkbN5QW6jS9pb4=; b=vjwvKnXT8Zjjjet78DAagST1L7/yLFvYBdR2eFAl/gJRZ/yQESURVPzkNjkuNT02tX kMcN65KAW+H6Q270uLI9qMhThYNohr1FWax7k5UXBNIo+X2ntnjnZ/oICXz10J+5ngng X8tS4N2yDxWUiGTfHL8T+JYNG8LPp1vwPxHQplAsODi4Qv+sRdHGiv21pUKcGG1Vxb9W RyPp5C3ZmNMdkHP9ta7ALHwZzxCba9FZvMAv46GwMyBHgcW8AeV2eYX6Ug45ecsuuvRK +fCvLY5N2BHVuvnSknwBevkqot6k6PH2PJ3bBd2shfN4HTgz6lfQDaTHS+F5yoFfGfNO uMmA== X-Gm-Message-State: AOAM5316CtBcciXtBMAEP0LzEXTswoHbEf+er8cItCGY0RxQ2Wbx5L7x WHdgzRnmdqWe9htGN4VY/YZHM+mp+NY1XRgzDqGM+/+lC0qPcw== X-Google-Smtp-Source: ABdhPJza5BtmSB67tbjUlNOP3OKzukhq2aCN5qJ6BSYvDoIp0SIYfhYjSWmseE8hq+w7kur+r3Mmc4nFqLhndPbppXw= X-Received: by 2002:a25:c244:: with SMTP id s65mr35042546ybf.30.1635788695616; Mon, 01 Nov 2021 10:44:55 -0700 (PDT) MIME-Version: 1.0 References: <20211005234459.430873-1-michael.roth@amd.com> <20211005234459.430873-3-michael.roth@amd.com> <20211021033723.tfnhazbnlz4z5czl@amd.com> In-Reply-To: From: Mingwei Zhang Date: Mon, 1 Nov 2021 10:44:44 -0700 Message-ID: Subject: Re: [RFC 02/16] KVM: selftests: add hooks for managing encrypted guest memory To: Michael Roth Cc: linux-kselftest@vger.kernel.org, kvm , LKML , x86@kernel.org, Nathan Tempelman , Marc Orr , Steve Rutherford , Sean Christopherson , Brijesh Singh , Tom Lendacky , Varad Gautam , Shuah Khan , Vitaly Kuznetsov , David Woodhouse , Ricardo Koller , Jim Mattson , Wanpeng Li , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Oct 26, 2021 at 8:48 AM Mingwei Zhang wrote: > > On Wed, Oct 20, 2021 at 8:46 PM Michael Roth wrote: > > > > On Mon, Oct 18, 2021 at 08:00:00AM -0700, Mingwei Zhang wrote: > > > > +void vm_set_memory_encryption(struct kvm_vm *vm, bool enc_by_default, bool has_enc_bit, > > > > + uint8_t enc_bit) > > > > +{ > > > > + vm->memcrypt.enabled = true; > > > > + vm->memcrypt.enc_by_default = enc_by_default; > > > > + vm->memcrypt.has_enc_bit = has_enc_bit; > > > > + vm->memcrypt.enc_bit = enc_bit; > > > > +} > > > > + > > > > +struct sparsebit * > > > > +vm_get_encrypted_phy_pages(struct kvm_vm *vm, int slot, vm_paddr_t *gpa_start, > > > > + uint64_t *size) > > > > +{ > > > > + struct userspace_mem_region *region; > > > > + struct sparsebit *encrypted_phy_pages; > > > > + > > > > + if (!vm->memcrypt.enabled) > > > > + return NULL; > > > > + > > > > + region = memslot2region(vm, slot); > > > > + if (!region) > > > > + return NULL; > > > > + > > > > + encrypted_phy_pages = sparsebit_alloc(); > > > > + sparsebit_copy(encrypted_phy_pages, region->encrypted_phy_pages); > > > > > > Do we have to make a copy for the sparsebit? Why not just return the > > > pointer? By looking at your subsequent patches, I find that this data > > > structure seems to be just read-only? > > > > Yes, it's only intended to be used for read access. But I'll if I can > > enforce that without the need to use a copy. > > > > Understood. Thanks for the clarification. Yeah, I think both making a > copy and returning a const pointer should work. I will leave that to > you then. > > Thanks. > -Mingwei Reviewed-by: Mingwei Zhang Thanks. -Mingwei