On Fri, Aug 11, 2023 at 3:12 PM Anish Moorthy <amoorthy@xxxxxxxxxx> wrote: > > On Wed, Jun 14, 2023 at 10:35 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > > +inline void kvm_populate_efault_info(struct kvm_vcpu *vcpu, > > > > Tagging a globally visible, non-static function as "inline" is odd, to say the > > least. > > I think my eyes glaze over whenever I read the words "translation > unit" (my brain certainly does) so I'll have to take your word for it. > IIRC last time I tried to mark this function "static" the compiler > yelled at me, so removing the "inline" it is. > >... > On Mon, Aug 14, 2023 at 5:43 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > Can you point me at your branch? That should be easy to resolve, but it's all > but impossible to figure out what's going wrong without being able to see the > full code. Sure: https://github.com/anlsh/linux/tree/suffd-kvm-staticinline. Don't worry about this unless you're bored though: I only called out my change because I wanted to make sure the final signature was fine. If you say it should be static inline then I can take a more concerted stab at learning/figuring out what's going on here. > > Btw, do you actually know the size of the union in the run struct? I > > started checking it but stopped when I realized that it includes > > arch-dependent structs. > > 256 bytes, though how much of that is actually free for the "speculative" idea... > > /* Fix the size of the union. */ > char padding[256]; > > Well fudge. PPC's KVM_EXIT_OSI actually uses all 256 bytes. And KVM_EXIT_SYSTEM_EVENT > is closer to the limit than I'd like > > On the other hand, despite burning 2048 bytes for kvm_sync_regs, all of kvm_run > is only 2352 bytes, i.e. we have plenty of room in the 4KiB page. So we could > throw the "speculative" exits in a completely different union. But that would > be cumbersome for userspace. Haha, well it's a good thing we checked. What about an extra union would be cumbersome for userspace though? From an API perspective it doesn't seem like splitting the current struct or adding an extra one would be all too different- is it something about needing to recompile things due to the struct size change?
