linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: David Hildenbrand <david@redhat.com>
Cc: <linux-coco@lists.linux.dev>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	KVM <kvm@vger.kernel.org>
Subject: Re: [Invitation] bi-weekly guest_memfd upstream call on 2024-11-14
Date: Wed, 13 Nov 2024 14:06:04 +0800	[thread overview]
Message-ID: <ZzRBzGJJJoezCge8@intel.com> (raw)
In-Reply-To: <6f2bfac2-d9e7-4e4a-9298-7accded16b4f@redhat.com>

On Tue, Nov 12, 2024 at 01:30:06PM +0100, David Hildenbrand wrote:
>Hi,
>
>the next guest_memfd upstream call will happen this Thursday, 2024-11-14
>at at 9:00 - 10:00am (GMT-08:00) Pacific Time - Vancouver.
>
>We'll be using the following Google meet:
>http://meet.google.com/wxp-wtju-jzw
>
>The meeting notes are linked from the google calendar invitation. If you
>want an invitation that also covers all future meetings, just write me a
>mail.
>
>In this meeting we'll discuss:
>* fbind() and NUMA mempolicy for guest_memfd
>* Persisting guest_memfd across reboot / guest_memfs
>* guest_memfd use cases for a PFN range allocator
>
>And we'll continue our discussion on:
>* Challenges with supporting huge pages
>* Challenges with shared vs. private conversion
>* guest_memfd as a "library"
>
>To put something to discuss onto the agenda, reply to this mail or add
>them to the "Topics/questions for next meeting(s)" section in the
>meeting notes as a comment.

Hi David,

We would like to discuss how to adapt the proposal for shared device assignment
[1] to recent guest_memfd changes, such as the support of in-place conversion.

With in-place conversion, QEMU can map shared memory and supply the virtual
address to VFIO to set up DMA mappings. From this perspective, in-place
conversion doesn't change or require any changes to the way QEMU interacts
with VFIO. So, the key for device assignment remains updating DMA mappings
accordingly during shared/private conversions. It seems that whether in-place
conversion is in use (i.e., whether shared memory is managed by guest_memfd or
not) doesn't require big changes to that proposal. Not sure if anyone thinks
otherwise. We want to align with you on the direction for device assignment
support for guest_memfd.
(I set aside the idea of letting KVM manage the IOMMU page table in the above
 analysis because we probably won't get that support in the near future)

Could you please add this topic to the agenda?

btw, the current time slot is not very convenient for us. If possible, could we
schedule the meeting one hour earlier, if this works for others? Two hours
earlier would be even better

[1]: https://lore.kernel.org/all/20240725072118.358923-1-chenyi.qiang@intel.com/


  reply	other threads:[~2024-11-13  6:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-12 12:30 David Hildenbrand
2024-11-13  6:06 ` Chao Gao [this message]
2024-11-13 15:04   ` David Hildenbrand
2024-11-14  2:27     ` Chao Gao
2024-12-24  4:21       ` Alexey Kardashevskiy
2024-12-24 11:27         ` David Hildenbrand
2024-12-27  4:21           ` Alexey Kardashevskiy
2024-11-27 16:43 ` [Invitation] bi-weekly guest_memfd upstream call on 2024-12-05 David Hildenbrand
2024-12-10 14:25   ` [Invitation] bi-weekly guest_memfd upstream call on 2024-12-12 David Hildenbrand
2024-12-11 13:53     ` Gowans, James
2025-01-08 10:45     ` [Invitation] bi-weekly guest_memfd upstream call on 2025-01-09 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=ZzRBzGJJJoezCge8@intel.com \
    --to=chao.gao@intel.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-mm@kvack.org \
    /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