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 C70F4C001E0 for ; Mon, 31 Jul 2023 21:34:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229537AbjGaVe4 (ORCPT ); Mon, 31 Jul 2023 17:34:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229469AbjGaVez (ORCPT ); Mon, 31 Jul 2023 17:34:55 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94C681FC9 for ; Mon, 31 Jul 2023 14:34:27 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d27ac992539so3727135276.3 for ; Mon, 31 Jul 2023 14:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690839264; x=1691444064; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=M5PijTkKav0RbsyrIfhOctghYsaDBtN0ksxtjkS2E3o=; b=C0RbbGvOmjlaHwoKOsVpABwkCgeBUojMJFqgHU3e7vn15TlMqi1/GNvhNBr/DnEblT S8ZKcXn9FhHXU6Yj2FL9z3P28LftMDsFJINcnv7hMEfCMCiavOoY20xAYb2rKktsEXOQ z5mBH169/JCPSbEIjZKLnQSMZ2Lld4QepdWvrkyww+Ss+NROk6emb1u+3nQvPpplchJb r3rGneDiJH1dEhxqhZbiyHtJIwY5il8SoHkjYv0GA2OczLFUEaI5dmW2MdSUO6wdGWBp FWCteCKEOMuivXPiXwICBYH89yRdMlkWwlrrSGNVh/UZS9rCQIXS+3ZUJNbqlJ3Kl2Wv AGPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690839264; x=1691444064; 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=M5PijTkKav0RbsyrIfhOctghYsaDBtN0ksxtjkS2E3o=; b=ZKCiquPxAjh9R6WNfLg/hvI7Ww/TqNx1ywSbuh9Y24RvFE7wmPVrQxPo0z5IOjFIdb a/T68B7Hvl8JV27Ty2YXChhebQI/IBchhyXLdnl3vMw+H3kv+A9LPKL0rpuUm215fcQN HBXERcjXopUMUGDuX6q4uYA5KAOIgYLUfOk98lWKzcADb3tddgx1E5sJXDbpTxCqNaaQ XkffwF1ei8SDDKlPC6KeUGleeEcBMoMD6pzxGpM5bOobOd7iHPqHlmXTkzo25BWoy6ef o0M6IDjxkPnn/xBuBLKcPgQNZuUBWGn0Exi8iAW/pAuKxx9OVsxGQ1i4xYzo4aPVLIwW hR0w== X-Gm-Message-State: ABy/qLbLGIOuo0gJ5vzPtkGtfMu5s+vjbNIzpC3cWRtffVXvCAgHD+wG UhizMEKFLi1v+oG3vy7WWTpzxGLJNyE= X-Google-Smtp-Source: APBJJlHV+T8Txgl9BRU07jWBBYiAgSiNRp0sLaahO8lqY0D8EU4ErMu5NzAPx8L+vujcfg4Us62xnatJqHs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:2042:0:b0:cb6:6c22:d0f8 with SMTP id g63-20020a252042000000b00cb66c22d0f8mr66923ybg.4.1690839263932; Mon, 31 Jul 2023 14:34:23 -0700 (PDT) Date: Mon, 31 Jul 2023 14:34:22 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230731162201.271114-1-xiaoyao.li@intel.com> <20230731162201.271114-5-xiaoyao.li@intel.com> Message-ID: Subject: Re: [RFC PATCH 04/19] memory: Introduce memory_region_can_be_private() From: Sean Christopherson To: Peter Xu Cc: Xiaoyao Li , Paolo Bonzini , 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?=" , Chao Peng , Michael Roth , isaku.yamahata@gmail.com, qemu-devel@nongnu.org, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Jul 31, 2023, Peter Xu wrote: > On Mon, Jul 31, 2023 at 12:21:46PM -0400, Xiaoyao Li wrote: > > +bool memory_region_can_be_private(MemoryRegion *mr) > > +{ > > + return mr->ram_block && mr->ram_block->gmem_fd >= 0; > > +} > > This is not really MAP_PRIVATE, am I right? If so, is there still chance > we rename it (it seems to be also in the kernel proposal all across..)? Yes and yes. > I worry it can be very confusing in the future against MAP_PRIVATE / > MAP_SHARED otherwise. Heh, it's already quite confusing at times. I'm definitely open to naming that doesn't collide with MAP_{PRIVATE,SHARED}, especially if someone can come with a naming scheme that includes a succinct way to describe memory that is shared between two or more VMs, but is accessible to _only_ those VMs.