[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aOU8MbqQ0ZnHgRr8@google.com>
Date: Tue, 7 Oct 2025 09:13:37 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Ackerley Tng <ackerleytng@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>, Claudio Imbrenda <imbrenda@...ux.ibm.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, David Hildenbrand <david@...hat.com>,
Fuad Tabba <tabba@...gle.com>
Subject: Re: [PATCH v2 01/13] KVM: Rework KVM_CAP_GUEST_MEMFD_MMAP into KVM_CAP_GUEST_MEMFD_FLAGS
On Tue, Oct 07, 2025, Ackerley Tng wrote:
> Sean Christopherson <seanjc@...gle.com> writes:
> >> In this model, conditionally valid flags are always set,
> >
> > I followed everything except this snippet.
>
> I meant "conditionally valid" as in if GUEST_MEMFD_FLAG_BAR was valid
> only when GUEST_MEMFD_FLAG_FOO is set, then with this model, when
> KVM_CAP_GUEST_MEMFD_FLAGS is queried, would KVM return
> GUEST_MEMFD_FLAG_MMAP | GUEST_MEMFD_FLAG_FOO | GUEST_MEMFD_FLAG_BAR,
> where GUEST_MEMFD_FLAG_BAR is the conditionally valid flag?
Oh, conditional on other flags (or lack thereof). Yes, the capability would simply
enumerate all supported flags, it would not try to communicate which combinations
of flags are valid.
Powered by blists - more mailing lists