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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4C1CC001E0 for ; Wed, 2 Aug 2023 22:27:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231648AbjHBW10 (ORCPT ); Wed, 2 Aug 2023 18:27:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231296AbjHBW1I (ORCPT ); Wed, 2 Aug 2023 18:27:08 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1C7C2130 for ; Wed, 2 Aug 2023 15:25:52 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1b9c5e07c1bso3335805ad.2 for ; Wed, 02 Aug 2023 15:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691015152; x=1691619952; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8NueeIcQhehh0vZ2uhP2xsg4tdP5mDg1L1vXP1dHCgc=; b=GUpWx2WepTtZ4YY2yzF3h4EK/q9fEEmhWkTwAKSmxWpkvdx/gaS3duDWgs8n7YMwHb jvOLRKTzEIn7SyTtg+cyxeKK93LUTVCOwczhNw3gxnDQho0S/yCjOsDxOKDGvkdoNj5x M9y07zaPlh1Mh8kh0OveDsMrneIF7f5DT+4/KMTluFlt29g0ni9SF2fBg1qQpA6MEY4x 50L7LbW5lyygb7dWJdeJAif0Oj5RvWWho0ayhC+E+dJRqiOsrCesTyNrzvYYMoOV343x 5EAnGET/l9S2k99FF4N2BsLr1TMMuTsKzoVjjtiEVBr0UNrSDb4NYNLDiWcf9NJWly4G sVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691015152; x=1691619952; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8NueeIcQhehh0vZ2uhP2xsg4tdP5mDg1L1vXP1dHCgc=; b=Vd0NPbO7A/ktngaY/gcCcxjkh7czQE/EWwBK3oLojoVMhlSKmI0TY7nQYWBiHQjVV5 mwbJGt8bHQhA6BUXyMAoJ+yHhMnWH3Ggf1dvjZ1tfS0qk+MEAesG5q99x0QHVcszAOF9 dirwcwdi/kNkyERjThCB7pxAuIAiToYUHZwjYPFE3mSlvi5BwozeYQlKiNxprCpE4QXt i+6OGNpMjInM50iXmQHJT9SqXn+wbgoG6HgZKyUvHzLdQYhAxh4j6HIXenOW/xjJV2sy RjysEeGMR819zo17wdxtU9L8Y/OhGJ0oNvU3u5YXUWhTZ8f1aFD8hvgGV5Sf9UfIr+4G VSmA== X-Gm-Message-State: ABy/qLYndRBKcYDT8Z30NwoKxmllN7MNGAzeBzamrLQj50O53ewQUKxc 9/Yva3j2QHUCr0+uISugTDl6mksYv8zFlA== X-Google-Smtp-Source: APBJJlEbbwbyg8Np5bVXnweWNCTz1B78mvGq8ka6z/HQ71m8yvQmn4YpveS1tOHmuFw4GH7cOYoK8g== X-Received: by 2002:a17:902:9b94:b0:1bb:a6db:3fd0 with SMTP id y20-20020a1709029b9400b001bba6db3fd0mr14764149plp.69.1691015152060; Wed, 02 Aug 2023 15:25:52 -0700 (PDT) Received: from localhost ([192.55.55.51]) by smtp.gmail.com with ESMTPSA id b13-20020a170902b60d00b001bc16bc9f5fsm5977693pls.284.2023.08.02.15.25.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Aug 2023 15:25:51 -0700 (PDT) Date: Wed, 2 Aug 2023 15:25:45 -0700 From: Isaku Yamahata To: Xiaoyao Li Cc: Paolo Bonzini , Sean Christopherson , David Hildenbrand , Igor Mammedov , "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Marcelo Tosatti , Markus Armbruster , Eric Blake , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Peter Xu , Chao Peng , Michael Roth , isaku.yamahata@gmail.com, qemu-devel@nongnu.org, kvm@vger.kernel.org Subject: Re: [RFC PATCH 15/19] kvm: handle KVM_EXIT_MEMORY_FAULT Message-ID: <20230802222545.GC1807130@ls.amr.corp.intel.com> References: <20230731162201.271114-1-xiaoyao.li@intel.com> <20230731162201.271114-16-xiaoyao.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230731162201.271114-16-xiaoyao.li@intel.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Jul 31, 2023 at 12:21:57PM -0400, Xiaoyao Li wrote: > From: Chao Peng > > Currently only KVM_MEMORY_EXIT_FLAG_PRIVATE in flags is valid when > KVM_EXIT_MEMORY_FAULT happens. It indicates userspace needs to do > the memory conversion on the RAMBlock to turn the memory into desired > attribute, i.e., private/shared. > > Note, KVM_EXIT_MEMORY_FAULT makes sense only when the RAMBlock has > gmem memory backend. > > Signed-off-by: Chao Peng > Signed-off-by: Xiaoyao Li > --- > accel/kvm/kvm-all.c | 52 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c > index f9b5050b8885..72d50b923bf2 100644 > --- a/accel/kvm/kvm-all.c > +++ b/accel/kvm/kvm-all.c > @@ -3040,6 +3040,48 @@ static void kvm_eat_signals(CPUState *cpu) > } while (sigismember(&chkset, SIG_IPI)); > } > > +static int kvm_convert_memory(hwaddr start, hwaddr size, bool to_private) > +{ > + MemoryRegionSection section; > + void *addr; > + RAMBlock *rb; > + ram_addr_t offset; > + int ret = -1; > + > + section = memory_region_find(get_system_memory(), start, size); > + if (!section.mr) { > + return ret; > + } > + > + if (memory_region_can_be_private(section.mr)) { > + if (to_private) { > + ret = kvm_set_memory_attributes_private(start, size); > + } else { > + ret = kvm_set_memory_attributes_shared(start, size); > + } > + > + if (ret) { > + return ret; > + } > + > + addr = memory_region_get_ram_ptr(section.mr) + > + section.offset_within_region; > + rb = qemu_ram_block_from_host(addr, false, &offset); Here we have already section. section.mr->ram_block. We don't have to scan the existing RAMBlocks. Except that, looks good to me. Reviewed-by: Isaku Yamahata -- Isaku Yamahata