From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCFC4246EC7 for ; Thu, 16 Jan 2025 23:31:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737070284; cv=none; b=PTgvZdY0XmD8NImyRih9z84sFHe6l2YDtaSNvC3fJvHMvnUA4iOQ/cz7y9pTJdAf8+hUNHLNd6fIz4V6W3iZuXaBUKZ0Pn9ZzWFhD7RSdKIWz460aaFz4hqttgoMVI4MHZe7KRg9AR65P7FfcGZue6fTeT6YlvoJXrhMNxvgP4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737070284; c=relaxed/simple; bh=hEX2DsNI7E8IBqdPG0miIQfwwOlcMkiPPsnqKDxhtIE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YDs2Y6RlPU0Cu8fLqjOBlgDRc4am874h/OseR8Hq6lbNsZ02k9+P/6Y1MZLVDR6U2UDh5EtJDSPwft2hrCDjTHHp+fLyPqBESF5jZHy0xLUOMUh+Mwt77l2nDZXXyA3LSmYADHuzeZyi9LePIz/6n0u4iyf1Cjnbu07qsn53Cuo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=g9/vuNgT; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="g9/vuNgT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737070281; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2+aljsYXNR3zz+hPgKhn1NefTJFgn2NwxVBvLmGXKHY=; b=g9/vuNgTgIc4ZfVYRhzW8JSZUWRi/ipIcSeKnoLISsFpty2+1bMmrzVnkzJ6vrNJpIQxPM a3W/CcWtCtEkGKhollTpCuv7qa2qi1Akl5CGOCYI0KaGF5E+3VecRP8kkliR2AP9iERZ4O pDQ595LY20lr0Wr91bNxf+FNGwf6u+8= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-588-kOp1yn9SNlCxThZdG9hMIQ-1; Thu, 16 Jan 2025 18:31:20 -0500 X-MC-Unique: kOp1yn9SNlCxThZdG9hMIQ-1 X-Mimecast-MFC-AGG-ID: kOp1yn9SNlCxThZdG9hMIQ Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-46dd46d759eso27633421cf.2 for ; Thu, 16 Jan 2025 15:31:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737070280; x=1737675080; 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=2+aljsYXNR3zz+hPgKhn1NefTJFgn2NwxVBvLmGXKHY=; b=MmncRiclDEjG/HzqX0bE5zpEVP0QXLTrNHZv2Vz9RMUPmumh8rOCUE7072lIJtFy2i 7jmcqTgKT/9WT4BKwQMTwImDrUDMtGMty8FsGhm1/zIrX2hz4IHrubQiS/QdmGr/KdsC 6vycplifmIcRtv03eFqbLueU3H9osizUPUTZy+4CV2sN9aa3jsdFi5E3MN7VCv3rTaxd J9TIqnGtvDkLbcsQqlRxkf8/nttTXeAx5B8UnGcI6LH8BJ8dyE68nADZtUdiN8K472Xd 0Ag2YOyttZw9RS1Pw4UI+ESqXGhsw3PiSp1i1lq3BlgYHhmYVrxW0kL2VPV0W8SorT5h ugFA== X-Forwarded-Encrypted: i=1; AJvYcCWCLoVKiaSg40goHjf3ZuSXlUSNepcbbfgiazPL/Y2gLumoanT6jAq8xpqnAWvoVrGBWMUuXxJGQxR/amE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx9CJcS8zimq1HnzlwczEjNsU4ZaTd5jgWHoV1CESNliScqTtXc i/NMYQ3VZOIKnD2+8eJfL/fOlOIemtcUKzKhP2cgd4jzRw2d+gffojZUc3xNIBDN39oF9oeDgbV RL1506lyGIyJwTA9wdqis+R184NUM01zsfHIMOWBv9rHPM4x/+HJo8JH3vnZcog== X-Gm-Gg: ASbGncvkoN0jw1RKqiJRk+eK9mHwwmOJxFypDlDMNCkQl0y02BB7dEacTnPALxC6ev+ nLkMWMPOQNudvLccJX72JUCUeClP0wT7/GbfH45E9rY3I4zvqUw1dIFSOT6FMMhIXH4B1egIrIn CippeCAWXSHCn7/TF2kDPLckaXzDf1JxTChy1uJ1zKHp5eNUWqmTNRmcrDWM4Eqkyp8Tijwcnnk E2Kiz1Bag0fY9JzgOwxQhNSmYeDKJziu7TA9QmCKV4O7PT50RCfM5vM8Ssl0Ge+GvTVeDs7Xe/0 g9xxGu7HRdQW/XsYQw== X-Received: by 2002:ac8:5914:0:b0:467:7270:bc35 with SMTP id d75a77b69052e-46e12a3fadamr10765411cf.14.1737070280060; Thu, 16 Jan 2025 15:31:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IFDbPH5giaBGe/SQwST9bz+Qh0GVUALDsJUk5gRXMEShRz7wGoChR/Lc1daUotDAD4y7F9d0A== X-Received: by 2002:ac8:5914:0:b0:467:7270:bc35 with SMTP id d75a77b69052e-46e12a3fadamr10765061cf.14.1737070279738; Thu, 16 Jan 2025 15:31:19 -0800 (PST) Received: from x1n (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-46e104027d5sm5078961cf.58.2025.01.16.15.31.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 15:31:19 -0800 (PST) Date: Thu, 16 Jan 2025 18:31:15 -0500 From: Peter Xu To: James Houghton Cc: Paolo Bonzini , Sean Christopherson , Jonathan Corbet , Marc Zyngier , Oliver Upton , Yan Zhao , Nikita Kalyazin , Anish Moorthy , Peter Gonda , David Matlack , Wei W , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v1 00/13] KVM: Introduce KVM Userfault Message-ID: References: <20241204191349.1730936-1-jthoughton@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Jan 16, 2025 at 02:51:11PM -0800, James Houghton wrote: > I guess this might not work if QEMU *needs* to use HugeTLB for > whatever reason, but Google's hypervisor just needs 1G pages; it > doesn't matter where they come from really. I see now. Yes I suppose it works for QEMU too. [...] > > In that case, looks like userfaultfd can support CoCo on device emulations > > by sticking with virtual-address traps like before, at least from that > > specific POV. > > Yeah, I don't think the userfaultfd API needs to change to support > gmem, because it's going to be using the VMAs / user mappings of gmem. There's other things I am still thinking on how the notification could happen when CoCo is enabled, that especially when there's no vcpu context. The first thing is any PV interfaces, and what's currently in my mind is kvmclock. I suppose that could work like untrusted dmas, so that when the hypervisor wants to read/update the clock struct, it'll access a shared page and then the guest can move it from/to to a private page. Or I'm not sure whether such information is proven to be not sensitive data, so the guest can directly use a permanent shared page for such purpose (in which case should still be part of guest memory, hence access to it can be trapped just like other shared pages via userfaultfd). The other thing is after I read the SEV-TIO then I found it could be easy to implement page faults for trusted devices now. For example, the white paper said the host IOMMU will be responsible to translating trusted devices' DMA into GPA/GVA, I think it means KVM would somehow share the secondary pgtable to the IOMMU, and probably when DMA sees a missing page it can now easily generate a page fault to the secondary page table. However the question is this is a DMA op and it definitely also doesn't have a vcpu context. So the question is how to trap it. So.. maybe (fd, offset) support might still be needed at some point, which can be more future proof. But I don't think I have a solid mind yet. -- Peter Xu