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.
