[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuCGnaTMPcStRMrc@google.com>
Date: Tue, 10 Sep 2024 10:49:17 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@...el.com>, Xiaoyao Li <xiaoyao.li@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>, Isaku Yamahata <isaku.yamahata@...el.com>,
"sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
"tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>, Kai Huang <kai.huang@...el.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 02/25] KVM: TDX: Define TDX architectural definitions
On Tue, Sep 10, 2024, Paolo Bonzini wrote:
> On 8/29/24 21:46, Edgecombe, Rick P wrote:
> > > This leads to another topic that defining all the TDX structure in this
> > > patch seems unfriendly for review. It seems better to put the
> > > introduction of definition and its user in a single patch.
> >
> > Yea.
>
> I don't know, it's easier to check a single patch against the manual. I
> don't have any objection to leaving everything here instead of scattering it
> over multiple patches, in fact I think I prefer it.
+1. There is so much to understand with TDX that trying to provide some form of
temporal locality between architectural definitions and the first code to use a
given definition seems futile/pointless.
Powered by blists - more mailing lists