On Fri, 2020-07-03 at 17:02 +0100, Dr. David Alan Gilbert wrote: > * James Bottomley (j...@linux.ibm.com) wrote: > > On Fri, 2020-07-03 at 12:11 +0100, Dr. David Alan Gilbert wrote: > > > * Tobin Feldman-Fitzthum (to...@linux.vnet.ibm.com) wrote: > > > > [...] > > > > + input.trans_uaddr = (uint64_t)data; > > > > + input.trans_len = data_sz; > > > > + > > > > + input.guest_uaddr = (uint64_t)hva; > > > > > > Thanks for changing these; although it fails a 32bit build (which > > > is probably mostly pointless for SEV, but it fails the build > > > rather than building it out). The easy fix here seems to be: > > > (uint64_t)(uintptr_t) > > > > That's a pointer width issue. The recommended way to communicate > > to the compiler that we really want to cast a 32 bit pointer to a > > 64 bit value is actually to cast to unsigned long before casting to > > pointer, so > > > > (uint64_t)(unsigned long)hva > > > > Many other things work, of course, but if you follow the > > recommendation you (hopefully) don't trip future compiler warnings. > > OK, fair enough > (Out of curiosity can you explain why unsigned long not uintptr_t?)
You have to cast it to a matching variable size integer first, so both unsigned long and uintptr_t work because they're 64 bits on LP64 and 32 bits on ILP32. The only minor problem with uintptr_t is that the checker may or may not be programmed to know what it does and there's nothing more annoying than trying to get a warning message you know to be wrong fixed. James