Re: [Xen-devel] [PATCH v2 07/13] libx86: Introduce a helper to serialise cpuid_policy objects

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.07.18 at 12:39, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/07/18 10:45, Jan Beulich wrote:
>>>>> On 16.07.18 at 11:18, <wei.liu2@xxxxxxxxxx> wrote:
>>> On Fri, Jul 13, 2018 at 09:03:08PM +0100, Andrew Cooper wrote:
>>>> +#include <errno.h>
>>>>  #include <inttypes.h>
>>>>  #include <stdbool.h>
>>>>  #include <stddef.h>
>>>> @@ -23,6 +28,19 @@ static inline bool test_bit(unsigned int bit, const 
>>>> void 
>>> *vaddr)
>>>>      return addr[bit / 8] & (1u << (bit % 8));
>>>>  }
>>>>  
>>>> +/* memcpy(), but with copy_to_guest_offset()'s API. */
>>>> +#define copy_to_buffer_offset(dst, index, src, nr)      \
>>>> +({                                                      \
>>>> +    const typeof(*(dst)) *src_ = (src);                 \
>>> I think you mean typeof(*(src)) here?
>> To follow copy_to_guest_offset()'s model there's more needed here,
>> I think: dst and src want to point to similar type objects / arrays (i.e.
>> the macro wants to enforce this).
> 
> This wrapper needs to be just enough to compile for userspace.  It
> doesn't need all the features and misfeatures of the hypervisor
> implementation.
> 
> Remember that the code gets compiled twice, so there is no chance of
> errors actually slipping in.

Well, yes, people would certainly be expected to test both parts of
the build before submitting a change. But someone focusing on the
hypervisor might not always re-build the tools after each step (or
respectively vice versa), yet it would be nice if an issue was noticable
right away even when doing just one of the two builds.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel