Re: [Xen-devel] [PATCH] libxc: add xc_domain_add_to_physmap_batch to wrap XENMEM_add_to_physmap_batch

[Zhongze Liu <blackskygg@xxxxxxxxx>]

Hi Jan,


2017-06-16 16:45 GMT+08:00 Jan Beulich <JBeulich@xxxxxxxx>:
>>>> On 16.06.17 at 06:55, <blackskygg@xxxxxxxxx> wrote:
>> currently there is no wrapper for XENMEM_add_to_physmap_batch in libxc.
>> add a wrapper to do that.
>
> It may help acceptance if you say why all of the sudden a wrapper
> is needed.
>

It's indeed a preparation for my GSoC project:
https://lists.xen.org/archives/html/xen-devel/2017-05/msg01288.html

Thanks for the suggestion.

>
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -1372,6 +1372,15 @@ int xc_domain_add_to_physmap(xc_interface *xch,
>>                               unsigned long idx,
>>                               xen_pfn_t gpfn);
>>
>> +int xc_domain_add_to_physmap_batch(xc_interface *xch,
>> +                                   uint32_t domid,
>> +                                   uint32_t foreign_domid,
>
> I'm not exactly sure what the libxc coding rules are, but I'd expect
> these both to be domid_t, ...
>

I was planning to make them domid_t, but according to the other
domid-parameters' types
in the file, and they are all uint32_t, so I finally decided on uint32_t.

>> +                                   unsigned int space,
>> +                                   uint16_t size,
>
> ... this one to be unsigned int, ...

In the xen_add_to_physmap_batch struct, both @space and @size are
uint16_t, so I think
I should have made @space uint16_t, too. I'll fix this. Or do you have
any good reasons to
make both of them unsigned int?

>
>> +                                   xen_ulong_t *idxs,
>> +                                   xen_pfn_t *gfpns,
>
> ... and these two to be pointers to const.
>

Yes, indeed. Sorry for this.

>
> Jan
>

Cheers,

Zhongze Liu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel