On 25.04.2024 10:51, Petr Beneš wrote:
> On Thu, Apr 25, 2024 at 8:19 AM Jan Beulich <jbeul...@suse.com> wrote:
>>
>> On 24.04.2024 22:42, Petr Beneš wrote:
>>> Introduce a new max_altp2m parameter to control the maximum number of altp2m
>>> views a domain can use. By default, if max_altp2m is unspecified and altp2m
>>> is
>>> enabled, the value is set to 10, reflecting the legacy behavior.
>>
>> Apart from the public header you don't even touch hypervisor code here. What
>> you say above therefore is limited in scope to the tool stack. I question
>> though that adding a new field without respecting it constitutes an overall
>> consistent change. In particular I'm curious how you mean to deal with this
>> for other than x86, where altp2m as a concept doesn't exist (yet).
>>
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -77,6 +77,7 @@ struct xen_domctl_createdomain {
>>> */
>>> uint32_t max_vcpus;
>>> uint32_t max_evtchn_port;
>>> + uint32_t max_altp2m;
>>> int32_t max_grant_frames;
>>> int32_t max_maptrack_frames;
>>
>> Such a struct layout change needs to be accompanied by an interface version
>> bump (which hasn't happened so far in this release cycle, afaics).
>
> So I should not include domctl.h changes in this commit and instead
> edit the commit message that it's merely a preparation for the
> following commit.
> Then, move the xen_domctl_createdomain field creation to the commit
> with the hypervisor changes (+ include interface version bump) and
> then create an additional commit that ties xl and xen together.
>
> Do I understand it correctly?
That's one way of approaching it, yes.
Jan
