On Wed, Feb 07, 2024 at 02:56:33PM +, Gowans, James wrote:
> 2. Tell VFIO to avoid mapping the memory in again after live update
> because it already exists.
> https://github.com/jgowans/qemu/commit/6e4f17f703eaf2a6f1e4cb2576d61683eaee02b0
> (the above flag should only be set *after* live updat
On Wed, Feb 07, 2024 at 02:45:42PM +, Gowans, James wrote:
> Hi Jason,
>
> Thanks for this great feedback on the approach - it's exactly the sort
> of thing we were looking for.
>
> On Mon, 2024-02-05 at 13:42 -0400, Jason Gunthorpe wrote:
> >
> > On Mon, Feb 05, 2024 at 12:01:45PM +, Ja
On Mon, 2024-02-05 at 10:10 -0700, Alex Williamson wrote:
> > * Needing to drive and re-hydrate the IOMMU page tables by defining
> > an IOMMU file.
> > Really we should move the abstraction one level up and make the
> > whole VFIO
> > container persistent via a pkernfs file. That way you’d "just"
Hi Jason,
Thanks for this great feedback on the approach - it's exactly the sort
of thing we were looking for.
On Mon, 2024-02-05 at 13:42 -0400, Jason Gunthorpe wrote:
>
> On Mon, Feb 05, 2024 at 12:01:45PM +, James Gowans wrote:
>
> > The main aspect we’re looking for feedback/opinions on
> Also, the question of a hard separation between
> persistent memory and ephemeral memory, compared to allowing
> arbitrary pages to
> be persisted. Pkernfs does it via a hard separation defined at boot
> time, other
> approaches could make the carving out of persistent pages dynamic.
Speaking
On Mon, Feb 05, 2024 at 12:01:45PM +, James Gowans wrote:
> The main aspect we’re looking for feedback/opinions on here is the concept of
> putting all persistent state in a single filesystem: combining guest RAM and
> IOMMU pgtables in one store. Also, the question of a hard separation betwee
On Mon, 5 Feb 2024 12:01:45 +
James Gowans wrote:
> This RFC is to solicit feedback on the approach of implementing support for
> live
> update via an in-memory filesystem responsible for storing all live update
> state
> as files in the filesystem.
>
> Hypervisor live update is a mechanis
This RFC is to solicit feedback on the approach of implementing support for live
update via an in-memory filesystem responsible for storing all live update state
as files in the filesystem.
Hypervisor live update is a mechanism to support updating a hypervisor via kexec
in a way that has limited i
