On Wed, 2023-06-14 at 00:38 +0000, Huang, Kai wrote: > On Tue, 2023-06-13 at 17:24 -0700, Dave Hansen wrote: > > On 6/13/23 16:18, Huang, Kai wrote: > > > On Tue, 2023-06-13 at 07:25 -0700, Hansen, Dave wrote: > > > > On 6/12/23 17:51, Huang, Kai wrote: > > > > > If we introduce a helper to mark a page as TDX private page, > > > > Let me get this right: you have working, functional code for a > > > > highly-unlikely scenario (kernel bugs or even more rare hardware > > > > errors). But, you want to optimize this super-rare case? It's not fast > > > > enough? > > > > > > > > Is there any other motivation here that I'm missing? > > > > > > > No it's not about speed. The motivation is to have a common code to yield less > > > line of code, though I don't have clear number of how many LoC can be reduced. > > > > OK, so ... ballpark. How many lines of code are we going to _save_ for > > this super-rare case? 10? 100? 1000? > > ~50 LoC I guess, certainly < 100. > > > > > The upside is saving X lines of code ... somewhere. The downside is > > adding Y lines of code ... somewhere else and maybe breaking things in > > the process. > > > > You've evidently done _some_ kind of calculus in your head to make this > > tradeoff worthwhile. I'd love to hear what your calculus is, even if > > it's just a gut feel. > > > > Could you share your logic here, please? > > The logic is the whole tdx_is_private_mem() function in the next patch (#MC > handling one) can be significantly reduced from 100 -> ~10, and we roughly needs > some more code (<50 LoC) to mark PAMT as private. > Apologize, should be "we roughly need some more code (<50 LoC) to mark PAMT and Secure-EPT and TDX guest private pages as TDX private pages". But now we only have PAMT.
