On Thu, Feb 15, 2024 at 04:26:02PM -0800, Sean Christopherson wrote:
> On Thu, Feb 15, 2024, Oliver Upton wrote:
> > On Thu, Feb 15, 2024 at 01:33:48PM -0800, Sean Christopherson wrote:
> >
> > [...]
> >
> > > +/* TODO: Expand this madness to also support u8, u16, and u32 operands. */
> > > +#define vcpu_arch_put_guest(mem, val, rand) \
> > > +do { \
> > > + if (!is_forced_emulation_enabled || !(rand & 1)) { \
> > > + *mem = val; \
> > > + } else if (rand & 2) { \
> > > + __asm__ __volatile__(KVM_FEP "movq %1, %0" \
> > > + : "+m" (*mem) \
> > > + : "r" (val) : "memory"); \
> > > + } else { \
> > > + uint64_t __old = READ_ONCE(*mem); \
> > > + \
> > > + __asm__ __volatile__(KVM_FEP LOCK_PREFIX "cmpxchgq %[new], %[ptr]" \
> > > + : [ptr] "+m" (*mem), [old] "+a" (__old) \
> > > + : [new]"r" (val) : "memory", "cc"); \
> > > + } \
> > > +} while (0)
> > > +
> >
> > Last bit of bikeshedding then I'll go... Can you just use a C function
> > and #define it so you can still do ifdeffery to slam in a default
> > implementation?
>
> Yes, but the macro shenanigans aren't to create a default, they're to set the
> stage for expanding to other sizes without having to do:
>
> vcpu_arch_put_guest{8,16,32,64}()
>
> or if we like bytes instead of bits:
>
> vcpu_arch_put_guest{1,2,4,8}()
>
> I'm not completely against that approach; it's not _that_ much copy+paste
> boilerplate, but it's enough that I think that macros would be a clear win,
> especially if we want to expand what instructions are used.
Oh, I see what you're after. Yeah, macro shenanigans are the only way
out then. Wasn't clear to me if the interface you wanted w/ the selftest
was a u64 write that you cracked into multiple writes behind the
scenes.
Thanks for entertaining my questions :)
--
Thanks,
Oliver
