[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e5e5cb0ff43e52f630ec5c890204174be2582c5.camel@intel.com>
Date: Fri, 16 Dec 2022 00:31:52 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "isaku.yamahata@...il.com" <isaku.yamahata@...il.com>
CC: "Christopherson,, Sean" <seanjc@...gle.com>,
"Shahar, Sagi" <sagis@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Aktas, Erdem" <erdemaktas@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"dmatlack@...gle.com" <dmatlack@...gle.com>
Subject: Re: [PATCH v10 056/108] KVM: TDX: don't request
KVM_REQ_APIC_PAGE_RELOAD
On Thu, 2022-12-15 at 16:11 -0800, Isaku Yamahata wrote:
> > Btw2, by saying above, does it make sense to split patch "[PATCH v10
> > 105/108]
> > KVM: TDX: Add methods to ignore accesses to CPU state" based on category
> > such as
> > MMU/interrupt, etc? Particularly, in that patch, some callbacks have WARN()
> > or
> > KVM_BUG_ON() against TD guest, but some don't. The logic behind those
> > decisions
> > highly depend on previous patches. To me, it makes more sense to just move
> > logic related things together.
>
> Ok, I'll split it up to cpu states/KVM MMU/interrupt parts.
If I recall correctly, originally (long time ago before starting to upstream),
what we did was we have a patch to make all kvm_x86_ops callback KVM_BUG_ON()
for TDX guest, then we fix those KVM_BUG_ON() in later patches in separate
patches.
We don't need to do the exact same way, but this also seems reasonable to me.
For instance, at the beginning we can mark KVM_BUG_ON() for all callbacks which
reads/writes CPU states (which is reasonable anyway), and in later patches we
remove the KVM_BUG_ON() if needed when handling specific logic.
Simply my 2cents above. Just for your reference. My real comment is we should
put relevant parts together so it's easy to review.
Powered by blists - more mailing lists