linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Alexander Graf <graf@amazon.com>,
	 "Andersen, Tycho" <Tycho.Andersen@amd.com>,
	 Anthony Yznaga <anthony.yznaga@oracle.com>,
	 Baolu Lu <baolu.lu@linux.intel.com>,
	David Hildenbrand <david@kernel.org>,
	 David Matlack <dmatlack@google.com>,
	James Gowans <jgowans@amazon.com>,
	 Jason Gunthorpe <jgg@nvidia.com>,
	Mike Rapoport <rppt@kernel.org>,
	 Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	 Pasha Tatashin <tatashin@google.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	 Praveen Kumar <kpraveen.lkml@gmail.com>,
	Vipin Sharma <vipinsh@google.com>,
	 Vishal Annapurve <vannapurve@google.com>,
	 "Woodhouse, David" <dwmw@amazon.co.uk>
Cc: linux-mm@kvack.org, kexec@lists.infradead.org
Subject: [Hypervisor Live Update] Notes from February 23, 2026
Date: Sat, 28 Feb 2026 17:44:18 -0800 (PST)	[thread overview]
Message-ID: <8dff046d-a819-ac8e-c1fa-8b5a35740cbb@google.com> (raw)

Hi everybody,

Here are the notes from the last Hypervisor Live Update call that happened 
on Monday, February 23.  Thanks to everybody who was involved!

These notes are intended to bring people up to speed who could not attend 
the call as well as keep the conversation going in between meetings.

----->o-----
We briefly mentioned the luod design doc[1] and asked people for review, 
Pratyush noted that he would be taking a look at it.

----->o-----
Jork Loeser noted that he was looking at HyperV partition survival.  They 
donate pages to HyperV which is a concept that doesn't exist in KVM.  
These pages are removed from Linux entirely and cannot be accessed.  He 
was playing with stateless KHO and extended some features but is not ready 
to send the patches out for review.  He was wondering if there was a 
possibility of landing changes in 7.1.

Pratyush noted that stateless KHO should go into the tree independently.  
Any consumers of the radix tree can be independent and build on top of 
those patches.  He noted that he would be happy to review the patches when 
they come out.

----->o-----
Pratyush noted that there were no updates for versioning support.  There 
is a clear plan forward for it but it hasn't been implemented yet.

He said he updated the HugeTLB preservation support with the requested 
changes from the mailing list but doesn't have selftests done yet.  In two 
weeks, he was hoping that these would be posted to the list.

----->o-----
David Matlack noted for interrupt ordering that discussions are still 
ongoing with NV on the topic.  Right now the simple approach is being used 
for disabling interrupts on the device and then reenabling them after live 
update.

For VFIO, there hasn't been a lot of feedback yet.  He was going to ask 
Bjorn and Alex to take a look.

----->o-----
Sami sent out phase 1 of the IOMMU preservation series and is looking 
forward to the next phase.  He was asking people for review upstream.  
Sami is using the VFIO patch series as a dependency.

----->o-----
Ackerley Tng went through guest_memfd HugeTLB support; the link to the 
slides are included in the cover letter for participants.  He briefly 
touched on an introduction to guest_memfd as a guest-first memory provider 
to KVM.  He then discussed how guest_memfd simply wraps existing sources 
of memory like pages from the buddy allocator or HugeTLB pages.  The 
folios are put into the filemap.

Every page is individually tracked to be either shared or private.  
Confidential guests can request a private page to be shared with the host 
and vice versa.  For shared-to-private conversion, the userspace VMM makes 
sure that devices stop using the memory requested by checking refcounts 
and then sends the SET_MEMORY_ATTRIBUTES ioctl to guest_memfd; that unmaps 
the range from the userspace page tables and records the page as private 
before returning to the guest.

Refcounting for a HugeTLB page is taken for the entire hugepage so we 
cannot identify which page within the hugepage the refcount was taken for.  
For all private-to-shared conversions this requires splitting hugepages 
into pages.  Split folios have to be merged back together but may also 
out-live the guest_memfd; for example if the fd is closed the memory may 
finally be unpinned.  This requires tracking outside of KVM such as the 
original size of the folio and which memcg was charged for it.  This is 
also required for memory error handling.

For KHO preservation, for guest_memfd pages (not HugeTLB pages) we need to 
preserve the filemap and associated folios, mempolicy, and memory 
attributes from the Maple Tree.  For HugeTLB pages we must preserve the 
restructuring metadata.  It was noted that there is no memory failure 
tracking today, it could be a future extension.

Pratyush asked if we can disallow any conversions after prepare.  Ackerley 
said if this period is very short than this should be fine.  Pratyush also 
asked if we should associate the guest_memfd with the host VM which, 
today, we rely on the VMM to do.

For timelines, Ackerley suggested that we would be able to merge 
conversion support with private/shared tracking in March and then HugeTLB 
support without restructuring in June.  He was hoping to have 
restructuring support later this year.

----->o-----
NOTE!!  Daylight Savings Time starts on Sunday, March 8 so the time of the 
meeting may have changed for some participants.

Next meeting will be on Monday, March 9 at 8am PDT (UTC-7), everybody is
welcome: https://meet.google.com/rjn-dmzu-hgq

Topics for the next meeting:

 - stateless KHO patch status in Andrew's tree
 - determine if luod would become part of systemd and discussions with
   Luca; implementation and next steps
 - versioning support for luod to negotiate
 - HugeTLB preservation support
 - ordering issues when disabling interrupts based on feedback from NV
 - VFIO patch series review from the list 
 - phase 1 of IOMMU persistence patch series, then phase 2 status and
   updates
 - hitless replacement for iommu domains
 - guest_memfd HugeTLB enlightenment: conversion support, HugeTLB support
   without restructuring, and HugeTLB support with restructuring
 - live update related topics to propose for LSF/MM/BPF 2026
 - KHO enlightenment for ASI
 - later: update on PCI preservation series and next steps
 - later: testing methodology to allow downstream consumers to qualify
   that live update works from one version to another
 - later: reducing blackout window during live update, including deferred
   struct page initialization

Please let me know if you'd like to propose additional topics for
discussion, thank you!

[1] https://tinyurl.com/luoddesign


                 reply	other threads:[~2026-03-01  1:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=8dff046d-a819-ac8e-c1fa-8b5a35740cbb@google.com \
    --to=rientjes@google.com \
    --cc=Tycho.Andersen@amd.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=david@kernel.org \
    --cc=dmatlack@google.com \
    --cc=dwmw@amazon.co.uk \
    --cc=graf@amazon.com \
    --cc=jgg@nvidia.com \
    --cc=jgowans@amazon.com \
    --cc=kexec@lists.infradead.org \
    --cc=kpraveen.lkml@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=pratyush@kernel.org \
    --cc=rppt@kernel.org \
    --cc=tatashin@google.com \
    --cc=vannapurve@google.com \
    --cc=vipinsh@google.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