[PATCH] public: xen: Define missing guest handle for int32_t

[PATCH] public: xen: Define missing guest handle for int32_t

[Michal Orzel]

Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
for it. This results in a build failure. Example on Arm:

./include/public/arch-arm.h:205:41: error: unknown type name ‘__guest_handle_64_int32_t’
  205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
      |                                         ^~~~~~~~~~~~~~~~~~
./include/public/arch-arm.h:206:41: note: in expansion of macro ‘__XEN_GUEST_HANDLE’
  206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
      |                                         ^~~~~~~~~~~~~~~~~~
./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
  277 |     XEN_GUEST_HANDLE(int32_t) errs;

Fix it. Also, drop guest handle definition for int given no further use.

Fixes: afab29d0882f ("public: s/int/int32_t")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/include/public/xen.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b47d48d0e2d6..8fd0cec880d5 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -28,7 +28,6 @@
 /* Guest handles for primitive C types. */
 DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
-DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
 #if __XEN_INTERFACE_VERSION__ < 0x00040300
 DEFINE_XEN_GUEST_HANDLE(long);
@@ -36,6 +35,7 @@ __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
 #endif
 DEFINE_XEN_GUEST_HANDLE(void);
 
+DEFINE_XEN_GUEST_HANDLE(int32_t);
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
-- 
2.25.1

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Luca Fancellu]

Hi Michal,

> On 17 Apr 2024, at 13:14, Michal Orzel <michal.orzel@amd.com> wrote:
> 
> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> for it. This results in a build failure. Example on Arm:
> 
> ./include/public/arch-arm.h:205:41: error: unknown type name ‘__guest_handle_64_int32_t’
>  205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>      |                                         ^~~~~~~~~~~~~~~~~~
> ./include/public/arch-arm.h:206:41: note: in expansion of macro ‘__XEN_GUEST_HANDLE’
>  206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>      |                                         ^~~~~~~~~~~~~~~~~~
> ./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
>  277 |     XEN_GUEST_HANDLE(int32_t) errs;
> 
> Fix it. Also, drop guest handle definition for int given no further use.
> 
> Fixes: afab29d0882f ("public: s/int/int32_t")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> ---

I’ve build it for arm64, arm32 and x86

Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Julien Grall]

Hi Michal,

On 17/04/2024 13:14, Michal Orzel wrote:
> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> for it. This results in a build failure. Example on Arm:
> 
> ./include/public/arch-arm.h:205:41: error: unknown type name ‘__guest_handle_64_int32_t’
>    205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>        |                                         ^~~~~~~~~~~~~~~~~~
> ./include/public/arch-arm.h:206:41: note: in expansion of macro ‘__XEN_GUEST_HANDLE’
>    206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>        |                                         ^~~~~~~~~~~~~~~~~~
> ./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
>    277 |     XEN_GUEST_HANDLE(int32_t) errs;
> 
> Fix it. Also, drop guest handle definition for int given no further use.
> 
> Fixes: afab29d0882f ("public: s/int/int32_t")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

So it turned out that I committed v1 from Stefano. I was meant to commit 
the patch at all, but I think I started with a dirty staging :(. Sorry 
for that.

I have reverted Stefano's commit for now so we can take the correct patch.

Now, from my understanding, Andrew suggested on Matrix that this 
solution may actually be a good way to handle GUEST_HANLDEs (they were 
removed in v2). Maybe this can be folded in Stefano's patch?

Cheers,

-- 
Julien Grall

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

On Wed, 17 Apr 2024, Julien Grall wrote:
> Hi Michal,
> 
> On 17/04/2024 13:14, Michal Orzel wrote:
> > Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> > in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> > for it. This results in a build failure. Example on Arm:
> > 
> > ./include/public/arch-arm.h:205:41: error: unknown type name
> > ‘__guest_handle_64_int32_t’
> >    205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> >        |                                         ^~~~~~~~~~~~~~~~~~
> > ./include/public/arch-arm.h:206:41: note: in expansion of macro
> > ‘__XEN_GUEST_HANDLE’
> >    206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> >        |                                         ^~~~~~~~~~~~~~~~~~
> > ./include/public/memory.h:277:5: note: in expansion of macro
> > ‘XEN_GUEST_HANDLE’
> >    277 |     XEN_GUEST_HANDLE(int32_t) errs;
> > 
> > Fix it. Also, drop guest handle definition for int given no further use.
> > 
> > Fixes: afab29d0882f ("public: s/int/int32_t")
> > Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> So it turned out that I committed v1 from Stefano. I was meant to commit the
> patch at all, but I think I started with a dirty staging :(. Sorry for that.
> 
> I have reverted Stefano's commit for now so we can take the correct patch.
> 
> Now, from my understanding, Andrew suggested on Matrix that this solution may
> actually be a good way to handle GUEST_HANLDEs (they were removed in v2).
> Maybe this can be folded in Stefano's patch?

v1 together with Michal's fix is correct. Also v2 alone is correct, or
v2 with Michal's fix is also correct.

My preference is v2 with Michal's fix, they can be committed as separate
patches. Also the others options are fine.

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Jan Beulich]

On 17.04.2024 14:14, Michal Orzel wrote:
> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> for it. This results in a build failure. Example on Arm:
> 
> ./include/public/arch-arm.h:205:41: error: unknown type name ‘__guest_handle_64_int32_t’
>   205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>       |                                         ^~~~~~~~~~~~~~~~~~
> ./include/public/arch-arm.h:206:41: note: in expansion of macro ‘__XEN_GUEST_HANDLE’
>   206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>       |                                         ^~~~~~~~~~~~~~~~~~
> ./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
>   277 |     XEN_GUEST_HANDLE(int32_t) errs;
> 
> Fix it. Also, drop guest handle definition for int given no further use.

Such cannot be done like this. Consumers of the header may have grown their
own uses. The declaration needs to remain active for any consumers
supplying __XEN_INTERFACE_VERSION__ < 0x00041900. Which means you need to
bump __XEN_LATEST_INTERFACE_VERSION__ and wrap the handle type declaration
in #ifdef. Provided the removal of that handle type for newer interface
versions is really warranting all this effort.

Jan

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Michal Orzel]

Hi Jan,

On 18/04/2024 09:26, Jan Beulich wrote:
> 
> 
> On 17.04.2024 14:14, Michal Orzel wrote:
>> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
>> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
>> for it. This results in a build failure. Example on Arm:
>>
>> ./include/public/arch-arm.h:205:41: error: unknown type name ‘__guest_handle_64_int32_t’
>>   205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>>       |                                         ^~~~~~~~~~~~~~~~~~
>> ./include/public/arch-arm.h:206:41: note: in expansion of macro ‘__XEN_GUEST_HANDLE’
>>   206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>>       |                                         ^~~~~~~~~~~~~~~~~~
>> ./include/public/memory.h:277:5: note: in expansion of macro ‘XEN_GUEST_HANDLE’
>>   277 |     XEN_GUEST_HANDLE(int32_t) errs;
>>
>> Fix it. Also, drop guest handle definition for int given no further use.
> 
> Such cannot be done like this. Consumers of the header may have grown their
> own uses. The declaration needs to remain active for any consumers
> supplying __XEN_INTERFACE_VERSION__ < 0x00041900. Which means you need to
> bump __XEN_LATEST_INTERFACE_VERSION__ and wrap the handle type declaration
> in #ifdef. Provided the removal of that handle type for newer interface
> versions is really warranting all this effort.
I think we could just leave this guest handle definition as is then.

~Michal

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Julien Grall]

Hi Stefano,

On 17/04/2024 19:49, Stefano Stabellini wrote:
> On Wed, 17 Apr 2024, Julien Grall wrote:
>> Hi Michal,
>>
>> On 17/04/2024 13:14, Michal Orzel wrote:
>>> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
>>> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
>>> for it. This results in a build failure. Example on Arm:
>>>
>>> ./include/public/arch-arm.h:205:41: error: unknown type name
>>> ‘__guest_handle_64_int32_t’
>>>     205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>>>         |                                         ^~~~~~~~~~~~~~~~~~
>>> ./include/public/arch-arm.h:206:41: note: in expansion of macro
>>> ‘__XEN_GUEST_HANDLE’
>>>     206 | #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>>>         |                                         ^~~~~~~~~~~~~~~~~~
>>> ./include/public/memory.h:277:5: note: in expansion of macro
>>> ‘XEN_GUEST_HANDLE’
>>>     277 |     XEN_GUEST_HANDLE(int32_t) errs;
>>>
>>> Fix it. Also, drop guest handle definition for int given no further use.
>>>
>>> Fixes: afab29d0882f ("public: s/int/int32_t")
>>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> 
>> So it turned out that I committed v1 from Stefano. I was meant to commit the
>> patch at all, but I think I started with a dirty staging :(. Sorry for that.
>>
>> I have reverted Stefano's commit for now so we can take the correct patch.
>>
>> Now, from my understanding, Andrew suggested on Matrix that this solution may
>> actually be a good way to handle GUEST_HANLDEs (they were removed in v2).
>> Maybe this can be folded in Stefano's patch?
> 
> v1 together with Michal's fix is correct. Also v2 alone is correct, or
> v2 with Michal's fix is also correct.

I am slightly confused, v2 + Michal's fix means that 
XEN_GUEST_HANDLE(int) is removed and we introduce XEN_GUEST_INT(int32_t) 
with no user. So wouldn't this break the build?

> 
> My preference is v2 with Michal's fix, they can be committed as separate
> patches. Also the others options are fine.

I am fine if you want to commit them separately. However, I am not sure 
your suggestion about using v2 + Michal's fix is actually correct.

Cheers,

-- 
Julien Grall

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

On Mon, 22 Apr 2024, Julien Grall wrote:
> Hi Stefano,
> 
> On 17/04/2024 19:49, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2024, Julien Grall wrote:
> > > Hi Michal,
> > > 
> > > On 17/04/2024 13:14, Michal Orzel wrote:
> > > > Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> > > > in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> > > > for it. This results in a build failure. Example on Arm:
> > > > 
> > > > ./include/public/arch-arm.h:205:41: error: unknown type name
> > > > ‘__guest_handle_64_int32_t’
> > > >     205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ##
> > > > name
> > > >         |                                         ^~~~~~~~~~~~~~~~~~
> > > > ./include/public/arch-arm.h:206:41: note: in expansion of macro
> > > > ‘__XEN_GUEST_HANDLE’
> > > >     206 | #define XEN_GUEST_HANDLE(name)
> > > > __XEN_GUEST_HANDLE(name)
> > > >         |                                         ^~~~~~~~~~~~~~~~~~
> > > > ./include/public/memory.h:277:5: note: in expansion of macro
> > > > ‘XEN_GUEST_HANDLE’
> > > >     277 |     XEN_GUEST_HANDLE(int32_t) errs;
> > > > 
> > > > Fix it. Also, drop guest handle definition for int given no further use.
> > > > 
> > > > Fixes: afab29d0882f ("public: s/int/int32_t")
> > > > Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> > 
> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> > 
> > 
> > > So it turned out that I committed v1 from Stefano. I was meant to commit
> > > the
> > > patch at all, but I think I started with a dirty staging :(. Sorry for
> > > that.
> > > 
> > > I have reverted Stefano's commit for now so we can take the correct patch.
> > > 
> > > Now, from my understanding, Andrew suggested on Matrix that this solution
> > > may
> > > actually be a good way to handle GUEST_HANLDEs (they were removed in v2).
> > > Maybe this can be folded in Stefano's patch?
> > 
> > v1 together with Michal's fix is correct. Also v2 alone is correct, or
> > v2 with Michal's fix is also correct.
> 
> I am slightly confused, v2 + Michal's fix means that XEN_GUEST_HANDLE(int) is
> removed and we introduce XEN_GUEST_INT(int32_t) with no user. So wouldn't this

You are right I apologize. I looked at Michal's patch too quickly and
I thought it was just adding XEN_GUEST_INT(int32_t) without removing
anything.

In that case, if you are OK with it, please ack and commit v2 only.

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Jan Beulich]

On 26.04.2024 00:39, Stefano Stabellini wrote:
> On Mon, 22 Apr 2024, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 17/04/2024 19:49, Stefano Stabellini wrote:
>>> On Wed, 17 Apr 2024, Julien Grall wrote:
>>>> Hi Michal,
>>>>
>>>> On 17/04/2024 13:14, Michal Orzel wrote:
>>>>> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
>>>>> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
>>>>> for it. This results in a build failure. Example on Arm:
>>>>>
>>>>> ./include/public/arch-arm.h:205:41: error: unknown type name
>>>>> ‘__guest_handle_64_int32_t’
>>>>>     205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ##
>>>>> name
>>>>>         |                                         ^~~~~~~~~~~~~~~~~~
>>>>> ./include/public/arch-arm.h:206:41: note: in expansion of macro
>>>>> ‘__XEN_GUEST_HANDLE’
>>>>>     206 | #define XEN_GUEST_HANDLE(name)
>>>>> __XEN_GUEST_HANDLE(name)
>>>>>         |                                         ^~~~~~~~~~~~~~~~~~
>>>>> ./include/public/memory.h:277:5: note: in expansion of macro
>>>>> ‘XEN_GUEST_HANDLE’
>>>>>     277 |     XEN_GUEST_HANDLE(int32_t) errs;
>>>>>
>>>>> Fix it. Also, drop guest handle definition for int given no further use.
>>>>>
>>>>> Fixes: afab29d0882f ("public: s/int/int32_t")
>>>>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>>>
>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>>
>>>
>>>> So it turned out that I committed v1 from Stefano. I was meant to commit
>>>> the
>>>> patch at all, but I think I started with a dirty staging :(. Sorry for
>>>> that.
>>>>
>>>> I have reverted Stefano's commit for now so we can take the correct patch.
>>>>
>>>> Now, from my understanding, Andrew suggested on Matrix that this solution
>>>> may
>>>> actually be a good way to handle GUEST_HANLDEs (they were removed in v2).
>>>> Maybe this can be folded in Stefano's patch?
>>>
>>> v1 together with Michal's fix is correct. Also v2 alone is correct, or
>>> v2 with Michal's fix is also correct.
>>
>> I am slightly confused, v2 + Michal's fix means that XEN_GUEST_HANDLE(int) is
>> removed and we introduce XEN_GUEST_INT(int32_t) with no user. So wouldn't this
> 
> You are right I apologize. I looked at Michal's patch too quickly and
> I thought it was just adding XEN_GUEST_INT(int32_t) without removing
> anything.
> 
> In that case, if you are OK with it, please ack and commit v2 only.

Just to mention it: Committing would apparently be premature, as I can't spot
any response to comments I gave to the patch. I'm okay with those being
addressed verbally only, but imo they cannot be dropped on the floor.

Jan

Re: [PATCH] public: xen: Define missing guest handle for int32_t

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3094 bytes --]

On Fri, 26 Apr 2024, Jan Beulich wrote:
> On 26.04.2024 00:39, Stefano Stabellini wrote:
> > On Mon, 22 Apr 2024, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 17/04/2024 19:49, Stefano Stabellini wrote:
> >>> On Wed, 17 Apr 2024, Julien Grall wrote:
> >>>> Hi Michal,
> >>>>
> >>>> On 17/04/2024 13:14, Michal Orzel wrote:
> >>>>> Commit afab29d0882f ("public: s/int/int32_t") replaced int with int32_t
> >>>>> in XEN_GUEST_HANDLE() in memory.h but there is no guest handle defined
> >>>>> for it. This results in a build failure. Example on Arm:
> >>>>>
> >>>>> ./include/public/arch-arm.h:205:41: error: unknown type name
> >>>>> ‘__guest_handle_64_int32_t’
> >>>>>     205 | #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ##
> >>>>> name
> >>>>>         |                                         ^~~~~~~~~~~~~~~~~~
> >>>>> ./include/public/arch-arm.h:206:41: note: in expansion of macro
> >>>>> ‘__XEN_GUEST_HANDLE’
> >>>>>     206 | #define XEN_GUEST_HANDLE(name)
> >>>>> __XEN_GUEST_HANDLE(name)
> >>>>>         |                                         ^~~~~~~~~~~~~~~~~~
> >>>>> ./include/public/memory.h:277:5: note: in expansion of macro
> >>>>> ‘XEN_GUEST_HANDLE’
> >>>>>     277 |     XEN_GUEST_HANDLE(int32_t) errs;
> >>>>>
> >>>>> Fix it. Also, drop guest handle definition for int given no further use.
> >>>>>
> >>>>> Fixes: afab29d0882f ("public: s/int/int32_t")
> >>>>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> >>>
> >>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> >>>
> >>>
> >>>> So it turned out that I committed v1 from Stefano. I was meant to commit
> >>>> the
> >>>> patch at all, but I think I started with a dirty staging :(. Sorry for
> >>>> that.
> >>>>
> >>>> I have reverted Stefano's commit for now so we can take the correct patch.
> >>>>
> >>>> Now, from my understanding, Andrew suggested on Matrix that this solution
> >>>> may
> >>>> actually be a good way to handle GUEST_HANLDEs (they were removed in v2).
> >>>> Maybe this can be folded in Stefano's patch?
> >>>
> >>> v1 together with Michal's fix is correct. Also v2 alone is correct, or
> >>> v2 with Michal's fix is also correct.
> >>
> >> I am slightly confused, v2 + Michal's fix means that XEN_GUEST_HANDLE(int) is
> >> removed and we introduce XEN_GUEST_INT(int32_t) with no user. So wouldn't this
> > 
> > You are right I apologize. I looked at Michal's patch too quickly and
> > I thought it was just adding XEN_GUEST_INT(int32_t) without removing
> > anything.
> > 
> > In that case, if you are OK with it, please ack and commit v2 only.
> 
> Just to mention it: Committing would apparently be premature, as I can't spot
> any response to comments I gave to the patch. I'm okay with those being
> addressed verbally only, but imo they cannot be dropped on the floor.

I agree with your comments but I prefer to keep this patch smaller and
focused on doing one thing only. I don't want to mix non-mechanical
changes with the mechanical substitutions. For sure, there will be
follow ups to address your comments and other outstanding issues.