On Tue, Jun 04, 2024 at 12:14:42PM +0100, Marc Zyngier wrote: > On Mon, 03 Jun 2024 18:28:56 +0100, Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > Anyway, my _slight_ preference is towards keeping what I have if > > possible, with a giant comment explaining the reasoning behind it. But I > > can take your approach instead too. > > I think the only arguments for my own solution are: > > - slightly better codegen (no function call or inlining), and a > smaller .text section in switch.o, because the helpers are not > cheap: > > LLVM: > > 0 .text 00003ef8 (guest_hyp_*_traps_enabled) > 0 .text 00003d48 (bit ops) > > GCC: > 0 .text 00002624 (guest_hyp_*_traps_enabled) > 0 .text 000024b4 (bit ops) > Oh, that's spectacular :-) > Yes, LLVM is an absolute pig because of BTI... > > - tracking the guest's bits more precisely may make it easier to debug > > but these are pretty weak arguments, and I don't really care either > way at this precise moment. Yeah, so I think the right direction here is to combine our approaches, and do direct bit manipulation, but only on bit[0]. That way we still have an opportunity to document the very intentional simplification of trap state too. -- Thanks, Oliver
