From: Jason Gunthorpe <jgg@nvidia.com>
To: David Rientjes <rientjes@google.com>
Cc: Alexander Graf <graf@amazon.com>,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Dave Hansen <dave.hansen@intel.com>,
David Hildenbrand <david@redhat.com>,
David Matlack <dmatlack@google.com>,
Frank van der Linden <fvdl@google.com>,
James Gowans <jgowans@amazon.com>,
Junaid Shahid <junaids@google.com>,
Mike Rapoport <rppt@kernel.org>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Pasha Tatashin <tatashin@google.com>,
Pratyush Yadav <pratyush@kernel.org>,
Vipin Sharma <vipinsh@google.com>,
Vishal Annapurve <vannapurve@google.com>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
linux-mm@kvack.org, kexec@lists.infradead.org
Subject: Re: [Hypervisor Live Update] Notes from May 19, 2025
Date: Mon, 2 Jun 2025 10:11:00 -0300 [thread overview]
Message-ID: <20250602131100.GA233377@nvidia.com> (raw)
In-Reply-To: <958b2ec3-f5f1-b714-1256-1b06dcf7470f@google.com>
On Sat, May 31, 2025 at 08:16:14PM -0700, David Rientjes wrote:
> Pratyush asked about the relationship between KHO and LUO. Pasha noted
> that KHO provides a state machine and in RFC v2 of LUO, LUO can drive KHO
> which makes the KHO debugfs interface optional. KHO activate will cause
> LUO to switch to the prepared phase, for example. /dev/liveupdate
> continues to be the preferred mechanism. Think of KHO as preserving state
> across kexec whereas LUO provides the state machine.
IMHO LUO should superceed the statemachine in KHO and it's
debugfs. Just remove all the KHO stuff here. We don't need two things..
Jason
next prev parent reply other threads:[~2025-06-02 13:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-01 3:16 David Rientjes
2025-06-02 13:11 ` Jason Gunthorpe [this message]
2025-06-02 13:18 ` Pasha Tatashin
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=20250602131100.GA233377@nvidia.com \
--to=jgg@nvidia.com \
--cc=anthony.yznaga@oracle.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=dmatlack@google.com \
--cc=dwmw@amazon.co.uk \
--cc=fvdl@google.com \
--cc=graf@amazon.com \
--cc=jgowans@amazon.com \
--cc=junaids@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=pankaj.gupta.linux@gmail.com \
--cc=pratyush@kernel.org \
--cc=rientjes@google.com \
--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