Re: [PATCH v5 00/12] Make RamDiscardManager work with multiple sources & virtio-mem

Hi Peter

On Mon, Jun 22, 2026 at 11:28=E2=80=AFPM Peter Xu <[email protected]> wrote=
:
>
> On Mon, Jun 22, 2026 at 03:53:33PM +0400, Marc-Andr=C3=A9 Lureau wrote:
> > Hi Peter
> >
> > On Fri, Jun 19, 2026 at 7:13=E2=80=AFPM Peter Xu <[email protected]> wr=
ote:
> > >
> > > On Fri, Jun 19, 2026 at 12:11:48AM +0400, Marc-Andr=C3=A9 Lureau wrot=
e:
> > > > Hi
> > > >
> > > > On Thu, Jun 4, 2026 at 5:46=E2=80=AFPM Marc-Andr=C3=A9 Lureau
> > > > <[email protected]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > This is an attempt to fix the incompatibility of virtio-mem with =
confidential
> > > > > VMs. The solution implements what was discussed earlier with D. H=
ildenbrand:
> > > > > https://patchwork.ozlabs.org/project/qemu-devel/patch/20250407074=
[email protected]/#3502238
> > > > >
> > > > > The first patches are misc cleanups. Then some code refactoring t=
o have split a
> > > > > manager/source. And finally, the manager learns to deal with mult=
iple sources.
> > > > >
> > > > > This has been tested together with the Linux kernel series from
> > > > > Zhenzhong Duan [1] for TDX guests.
> > > > >
> > > > > (help fix https://issues.redhat.com/browse/RHEL-131968)
> > > >
> > > > Can the patch 1-11 be queued or are we missing something?
> > > > (RFC patch 12 can be dropped for now)
> > >
> > > Likely yes.. one thing to double check with you before I do: We don't=
 need
> > > the kernel series, do we?  Since when unplug, I expect with the trunc=
ation
> > > approach that this series proposed, KVM will emit TDH.MEM.PAGE.REMOVE=
 then
> > > unaccept is done (?).
> >
> > > Say, what happens if we run QEMU with this series applied, but withou=
t the
> > > kernel series?
> >
> > The kernel series is needed at least for PAGE.ACCEPT. Without it, QEMU
> > will have KVM_RUN return EIO, and finish into assert (while tearing
> > down ioeventfd).
>
> Could you elaborate a bit more on why ACCEPT would fail?
>
> I used to ask the event flow here:
>
> https://lore.kernel.org/qemu-devel/[email protected]/
>
> If AUG existed, then why ACCEPT would fail?
>
> PS: I didn't read a lot of what a Linux guest would do; I know there're
> some lazy accept approach, but IIUC it's only a matter of time to ACCEPT,
> not correctness.  My understanding is if we properly notify these new slo=
ts
> with AUG, then it should be able to ACCEPT?

Yes, it will, but it needs the kernel patches to do it (or virtio-mem
will let the guest access un-accepted pages and qemu will crash). I
submitted a few proposals before Zhenzhong Duan proposed the last
iteration.

> >
> > > What confused me a bit is the dependency of this series v.s. the kern=
el
> > > one.  It seems to use different approaches, but then I don't understa=
nd why
> > > this series was tested with the kernel change.
> >
> > My understanding is that the kernel may perform TDG.MEM.PAGE.RELEASE.
> > That depends on TDX config TDCS_CONFIG_PAGE_RELEASE which qemu/kvm
> > doesnt currently control. I don't know whether this is then
> > redundant/needless with qemu doing discard on the guest_memfd..
>
> The problem is if this series depends on the kernel series, should we the=
n
> wait for the kernel solution be accepted first in case it'll change?

I don't think qemu needs to wait for the kernel to be fixed.
Furthermore, this series is not tdx/sev/etc specific

>
> But obviously I still don't yet fully understand how this whole thing
> works.. :(

I am also slow, because I don't focus on this most of the time.
Someone with more experience and dedication would handle it better.