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 5803EC77B7D for ; Sat, 6 May 2023 01:18:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231404AbjEFBSJ (ORCPT ); Fri, 5 May 2023 21:18:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229742AbjEFBSI (ORCPT ); Fri, 5 May 2023 21:18:08 -0400 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 376FB5FE9 for ; Fri, 5 May 2023 18:18:07 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-50bc075d6b2so4688293a12.0 for ; Fri, 05 May 2023 18:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683335885; x=1685927885; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9xWunwBjreINeCb0tO4bVmW1S3dLtRxVeicO2rC/ju8=; b=6gF+SduOYgncFnt7ZoiU1yx51SAGT7MsKJ8qMRLCFbcZLolcmF75btB31W65qIZKqG RcwwpNxWFCNe6YCvsTUo5bO8745sK8NoXqJLZQYb1yL9bWX6xxNGHV/8cAtsND72KXUT +R5EXLe7k15qKVOt9ir0LkDHmRWKDxRZ4IiinvbaIAwrS3+7iZZsXhpsj41lajkfxaGx OmPjbVrffr7ffl54AIh2BBVarNlhvD0ZNVDStiGuh8fb8EV9+kNsdliptmErMyCjQWF0 YI081B68yYJtReicH84crcE1AYrOaCc6CtpHxDf+oTFdQuckCpxwLrpZ73i5EeHCf77N tXfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683335885; x=1685927885; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9xWunwBjreINeCb0tO4bVmW1S3dLtRxVeicO2rC/ju8=; b=j+GeKhf4RmBtYrIXiTkL/yoPA69CyoDaaI725fPnFnnHm+bJ6FFlisBmMec1VKKsbY spKWrVcQ26rJCKUPEI/bjWjLycSJq4XuQyIxMsJgNAR8bbzIYxS4Weg9+08HnJ795jo2 XYYC6cIYfqm18KFmkYhviIxjeI4Kd+L2XF6cUWqcdwZwo5NgFLbumiKGHlhVICdJt1uP W4MyqHt79pZzqkXD90wn+NYn3M2UFXpRNECp62bl6XsezyP2jk+nZsFlUQO8P/JYLuUl iZsWAZ1EHM4EoPAQD7AsIalRpOcK2LyyDMEFYNF2bLzww37mWzGKj4YNUoMp/dr9WZgK yj3Q== X-Gm-Message-State: AC+VfDxLO899G0BSx1hTC6/QVFnayj5TsJY4WHQIcZRddcdj6AG6Ozlk DLNEnhs/lE6Uj3CQ77gDj1TkRTq7EAqS8vi0fA3zhA== X-Google-Smtp-Source: ACHHUZ7u4889MI8XKPWoYqh+hmmV7kq1hmv0/5hgbUWSzYNJEMPiTmCrxeOzedFVKJlWbn8rSBaDbniD+gAkIxH/I1E= X-Received: by 2002:aa7:c0d7:0:b0:50b:d53d:7ceb with SMTP id j23-20020aa7c0d7000000b0050bd53d7cebmr2386748edp.40.1683335885503; Fri, 05 May 2023 18:18:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vishal Annapurve Date: Fri, 5 May 2023 18:17:54 -0700 Message-ID: Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) To: Sean Christopherson Cc: Ackerley Tng , david@redhat.com, chao.p.peng@linux.intel.com, pbonzini@redhat.com, vkuznets@redhat.com, jmattson@google.com, joro@8bytes.org, mail@maciej.szmigiero.name, vbabka@suse.cz, yu.c.zhang@linux.intel.com, kirill.shutemov@linux.intel.com, dhildenb@redhat.com, qperret@google.com, tabba@google.com, michael.roth@amd.com, wei.w.wang@intel.com, rppt@kernel.org, liam.merwick@oracle.com, isaku.yamahata@gmail.com, jarkko@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, hughd@google.com, brauner@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, May 5, 2023 at 5:55=E2=80=AFPM Sean Christopherson wrote: > > ... > My preference is to make it a VM-scoped ioctl(), if it ends up being a KV= M ioctl() > and not a common syscall. If the file isn't tightly coupled to a single = VM, then > punching a hole is further complicated by needing to deal with invalidati= ng multiple > regions that are bound to different @kvm instances. It's not super compl= ex, but > AFAICT having the ioctl() be system-scoped doesn't add value, e.g. I don'= t think > having one VM own the memory will complicate even if/when we get to the p= oint where > VMs can share "private" memory, and the gmem code would still need to dea= l with > grabbing a module reference. Copyless migration would be a scenario where "private" memory may need to be shared between source and target VMs depending on how migration support is implemented. Regards, Vishal