From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Ackerley Tng <ackerleytng@google.com>,
Fuad Tabba <tabba@google.com>, Xiaoyao Li <xiaoyao.li@intel.com>,
Binbin Wu <binbin.wu@linux.intel.com>,
Shivank Garg <shivankg@amd.com>, Yan Zhao <yan.y.zhao@intel.com>
Subject: Re: [PATCH 0/3] KVM: Kconfig fixes for the VM-wide private memory attribute
Date: Tue, 20 Oct 2026 21:57:53 -0700 [thread overview]
Message-ID: <athGUdkDw6rSatUW@google.com> (raw)
In-Reply-To: <20261020131447.122096-1-pbonzini@redhat.com>
On Tue, Oct 20, 2026, Paolo Bonzini wrote:
> A late review of the guest_memfd attributes changes...
>
> With Linux 7.4 the "private" memory attribute was moved from the VM
> to the individual guest_memfd file descriptor. The old semantics are
> available for backwards compatibility via CONFIG_KVM_VM_MEMORY_ATTRIBUTES,
> and disabled by default.
>
> This change has two problems: first, it ties support for VM memory
> attributes entirely to a backwards compatibility symbol for distros.
> Second, it is incompatible with all released versions of QEMU (and
> perhaps most other VMMs?), thus the default is arguably not the
> right one.
I was hoping we could go with a stick approach, but given how painful double-allocating
is, hopefully a carrot will work too. :-)
prev parent reply other threads:[~2026-10-21 4:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 13:14 [PATCH 0/3] KVM: Kconfig fixes for the VM-wide private memory attribute Paolo Bonzini
2026-10-20 13:14 ` [PATCH 1/3] KVM: split CONFIG_KVM_PRIVATE_MEMATTR_VM out of KVM_VM_MEMORY_ATTRIBUTES Paolo Bonzini
2026-10-21 7:01 ` Xiaoyao Li
2026-10-21 12:48 ` Ackerley Tng
2026-10-20 13:14 ` [PATCH 2/3] KVM: x86: leave the legacy private attribute in for TDX and SEV Paolo Bonzini
2026-10-21 7:05 ` Xiaoyao Li
2026-10-21 12:53 ` Ackerley Tng
2026-10-20 13:14 ` [PATCH 3/3] KVM: always make in-place conversion a compile-time constant when possible Paolo Bonzini
2026-10-21 7:07 ` Xiaoyao Li
2026-10-21 7:12 ` Paolo Bonzini
2026-10-21 12:36 ` Ackerley Tng
2026-10-21 4:57 ` Sean Christopherson [this message]
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=athGUdkDw6rSatUW@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shivankg@amd.com \
--cc=tabba@google.com \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.