Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Patrick Roy <roypat@amazon.co.uk>
To: David Hildenbrand <david@redhat.com>, Fuad Tabba <tabba@google.com>
Cc: <kvm@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<linux-mm@kvack.org>, <pbonzini@redhat.com>,
	<chenhuacai@kernel.org>, <mpe@ellerman.id.au>,
	<anup@brainfault.org>, <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,
	<seanjc@google.com>, <viro@zeniv.linux.org.uk>,
	<brauner@kernel.org>, <willy@infradead.org>,
	<akpm@linux-foundation.org>, <xiaoyao.li@intel.com>,
	<yilun.xu@intel.com>, <chao.p.peng@linux.intel.com>,
	<jarkko@kernel.org>, <amoorthy@google.com>, <dmatlack@google.com>,
	<yu.c.zhang@linux.intel.com>, <isaku.yamahata@intel.com>,
	<mic@digikod.net>, <vbabka@suse.cz>, <vannapurve@google.com>,
	<ackerleytng@google.com>, <mail@maciej.szmigiero.name>,
	<michael.roth@amd.com>, <wei.w.wang@intel.com>,
	<liam.merwick@oracle.com>, <isaku.yamahata@gmail.com>,
	<kirill.shutemov@linux.intel.com>, <suzuki.poulose@arm.com>,
	<steven.price@arm.com>, <quic_eberman@quicinc.com>,
	<quic_mnalajal@quicinc.com>, <quic_tsoni@quicinc.com>,
	<quic_svaddagi@quicinc.com>, <quic_cvanscha@quicinc.com>,
	<quic_pderrin@quicinc.com>, <quic_pheragu@quicinc.com>,
	<catalin.marinas@arm.com>, <james.morse@arm.com>,
	<yuzenghui@huawei.com>, <oliver.upton@linux.dev>,
	<maz@kernel.org>, <will@kernel.org>, <qperret@google.com>,
	<keirf@google.com>, <shuah@kernel.org>, <hch@infradead.org>,
	<jgg@nvidia.com>, <rientjes@google.com>, <jhubbard@nvidia.com>,
	<fvdl@google.com>, <hughd@google.com>, <jthoughton@google.com>
Subject: Re: [RFC PATCH v1 2/9] KVM: guest_memfd: Add guest_memfd support to kvm_(read|/write)_guest_page()
Date: Thu, 23 Jan 2025 15:22:21 +0000	[thread overview]
Message-ID: <5b2949bf-ab8b-46d4-9daf-71fe3e20b0c8@amazon.co.uk> (raw)
In-Reply-To: <fe154ef9-ac57-40ce-96d8-4e744d83d37e@redhat.com>

On Thu, 2025-01-23 at 14:18 +0000, David Hildenbrand wrote:
>>>>
>>>> That said, we could always have a userspace address dedicated to
>>>> mapping shared locations, and use that address when the necessity
>>>> arises. Or we could always require that memslots have a userspace
>>>> address, even if not used. I don't really have a strong preference.
>>>
>>> So, the simpler version where user space would simply mmap guest_memfd
>>> to provide the address via userspace_addr would at least work for the
>>> use case of paravirtualized time?
>>
>> fwiw, I'm currently prototyping something like this for x86 (although
>> not by putting the gmem address into userspace_addr, but by adding a new
>> field to memslots, so that memory attributes continue working), based on
>> what we talked about at the last guest_memfd sync meeting (the whole
>> "how to get MMIO emulation working for non-CoCo VMs in guest_memfd"
>> story).
> 
> Yes, I recall that discussion. Can you elaborate why the separate field
> is required to keep memory attributes working? (could it be sorted out
> differently, by reusing userspace_addr?).

The scenario I ran into was that within the same memslots, I wanted some
gfns to be backed by guest_memfd, and others by traditional memory, so
that KVM can GUP some parts of guest memory even if guest_memfd itself
is direct map removed.

It actually also has to do with paravirtual time, but on x86. Here, the
guest chooses where in guest memory the clock structure is placed via an
MSR write (so I can't a priori use a traditional memslot, like we can on
ARM).  KVM internally wants to GUP the hva that corresponds to the gfn
the guest chooses, but if the hva is in a mapping of direct map removed
gmem, that won't work. So what I did was just intercept the MSR write in
userspace, and clear KVM_MEMORY_ATTRIBUTES_PRIVATE for the gfn. But for
this, I need userspace_addr to not point to the guest_memfd hva.
Although maybe it'd be possible to instead reconfigure the memslots when
intercepting the MSR? Not sure where we stand on KVM_MEM_GUEST_MEMFD
memslots though.

But also conceptually, doesn't KVM_MEMORY_ATTRIBUTES_PRIVATE kinda loose
any meaning if userspace_addr also points towards gmem? E.g. no matter
what we set, we'd get gmem mapped into the guest.

> -- 
> Cheers,
> 
> David / dhildenb
> 

Best, 
Patrick

  reply	other threads:[~2025-01-23 15:22 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22 15:27 [RFC PATCH v1 0/9] KVM: Mapping of guest_memfd at the host and a software protected VM type Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 1/9] KVM: guest_memfd: Allow host to mmap guest_memfd() pages Fuad Tabba
2025-01-22 22:06   ` David Hildenbrand
2025-01-23  9:44     ` Fuad Tabba
2025-01-23 10:27       ` David Hildenbrand
2025-01-23 11:02         ` Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 2/9] KVM: guest_memfd: Add guest_memfd support to kvm_(read|/write)_guest_page() Fuad Tabba
2025-01-22 22:10   ` David Hildenbrand
2025-01-23  9:48     ` Fuad Tabba
2025-01-23 11:39       ` David Hildenbrand
2025-01-23 11:57         ` Patrick Roy
2025-01-23 12:28           ` Fuad Tabba
2025-01-23 13:57             ` Patrick Roy
2025-01-23 14:21               ` David Hildenbrand
2025-01-23 14:25                 ` Fuad Tabba
2025-01-23 14:18           ` David Hildenbrand
2025-01-23 15:22             ` Patrick Roy [this message]
2025-01-24 14:44               ` David Hildenbrand
2025-01-23 12:16         ` Fuad Tabba
2025-01-23 14:15           ` David Hildenbrand
2025-01-22 15:27 ` [RFC PATCH v1 3/9] KVM: guest_memfd: Add KVM capability to check if guest_memfd is host mappable Fuad Tabba
2025-01-23 11:42   ` David Hildenbrand
2025-01-23 11:46     ` Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 4/9] KVM: arm64: Skip VMA checks for slots without userspace address Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 5/9] KVM: arm64: Refactor user_mem_abort() calculation of force_pte Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 6/9] KVM: arm64: Handle guest_memfd()-backed guest page faults Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 7/9] KVM: arm64: Introduce KVM_VM_TYPE_ARM_SW_PROTECTED machine type Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 8/9] KVM: guest_memfd: selftests: guest_memfd mmap() test when mapping is allowed Fuad Tabba
2025-01-22 15:27 ` [RFC PATCH v1 9/9] KVM: arm64: Enable mapping guest_memfd in arm64 Fuad Tabba
2025-01-22 15:35 ` [RFC PATCH v1 0/9] KVM: Mapping of guest_memfd at the host and a software protected VM type David Hildenbrand
2025-01-22 15:41   ` David Hildenbrand
2025-01-22 17:16     ` Fuad Tabba
2025-01-22 21:42       ` David Hildenbrand
2025-01-23  9:09         ` Fuad Tabba
2025-01-23  9:14           ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b2949bf-ab8b-46d4-9daf-71fe3e20b0c8@amazon.co.uk \
    --to=roypat@amazon.co.uk \
    --cc=ackerleytng@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=amoorthy@google.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=brauner@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=chenhuacai@kernel.org \
    --cc=david@redhat.com \
    --cc=dmatlack@google.com \
    --cc=fvdl@google.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=isaku.yamahata@gmail.com \
    --cc=isaku.yamahata@intel.com \
    --cc=james.morse@arm.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=jthoughton@google.com \
    --cc=keirf@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=liam.merwick@oracle.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mail@maciej.szmigiero.name \
    --cc=maz@kernel.org \
    --cc=mic@digikod.net \
    --cc=michael.roth@amd.com \
    --cc=mpe@ellerman.id.au \
    --cc=oliver.upton@linux.dev \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pbonzini@redhat.com \
    --cc=qperret@google.com \
    --cc=quic_cvanscha@quicinc.com \
    --cc=quic_eberman@quicinc.com \
    --cc=quic_mnalajal@quicinc.com \
    --cc=quic_pderrin@quicinc.com \
    --cc=quic_pheragu@quicinc.com \
    --cc=quic_svaddagi@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=shuah@kernel.org \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=vannapurve@google.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wei.w.wang@intel.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=xiaoyao.li@intel.com \
    --cc=yilun.xu@intel.com \
    --cc=yu.c.zhang@linux.intel.com \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox