On 17.06.2024 15:36, Teddy Astie wrote:
> Le 13/06/2024 à 16:32, Jan Beulich a écrit :
>> On 13.06.2024 15:50, Teddy Astie wrote:
>>> @@ -214,6 +215,38 @@ struct xen_add_to_physmap_range {
>>> };
>>> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
>>>
>>> +/*
>>> + * With some legacy devices, certain guest-physical addresses cannot safely
>>> + * be used for other purposes, e.g. to map guest RAM. This hypercall
>>> + * enumerates those regions so the toolstack can avoid using them.
>>> + */
>>> +#define XENMEM_reserved_device_memory_map 27
>>> +struct xen_reserved_device_memory {
>>> + xen_pfn_t start_pfn;
>>> + xen_ulong_t nr_pages;
>>> +};
>>> +DEFINE_GUEST_HANDLE_STRUCT(xen_reserved_device_memory);
>>> +
>>> +struct xen_reserved_device_memory_map {
>>> +#define XENMEM_RDM_ALL 1 /* Request all regions (ignore dev union). */
>>> + /* IN */
>>> + uint32_t flags;
>>> + /*
>>> + * IN/OUT
>>> + *
>>> + * Gets set to the required number of entries when too low,
>>> + * signaled by error code -ERANGE.
>>> + */
>>> + unsigned int nr_entries;
>>> + /* OUT */
>>> + GUEST_HANDLE(xen_reserved_device_memory) buffer;
>>> + /* IN */
>>> + union {
>>> + struct physdev_pci_device pci;
>>> + } dev;
>>> +};
>>> +DEFINE_GUEST_HANDLE_STRUCT(xen_reserved_device_memory_map);
>>
>> This is a tools-only (i.e. unstable) sub-function in Xen; even the comment
>> at the top says "toolstack". It is therefore not suitable for use in a
>> kernel.
>>
> IMO this comment actually describes how the toolstack uses the
> hypercall, but I don't think it is actually reserved for toolstack use.
Well, the canonical version of the header is quite explicit about this,
by having the definition in a __XEN__ || __XEN_TOOLS__ section.
> Or maybe we should allow the kernel to use this hypercall as well.
That's an option to consider.
Jan
