[PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Oleksii Kurochko]

Based on two patch series [1] and [2], the idea of which is to provide minimal
amount of things for a complete Xen build, a large amount of headers are the same
or almost the same, so it makes sense to move them to asm-generic.

Also, providing such stub headers should help future architectures to add
a full Xen build.

[1] https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
[2] https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/

Oleksii Kurochko (29):
  xen/asm-generic: introduce stub header spinlock.h
  xen/asm-generic: introduce stub header paging.h
  xen/asm-generic: introduce stub header cpufeature.h
  xen/asm-generic: introduce stub header device.h
  xen/asm-generic: introduce stub header event.h
  xen/asm-generic: introduce stub header grant_table.h
  xen/asm-generic: introduce stub header guest_atomics.h
  xen/asm-generic: introduce stub hypercall.h
  xen/asm-generic: introduce stub header iocap.h
  xen/asm-generic: introduce stub header iommu.h
  xen/asm-generic: introduce stub header mem_access.h
  xen/asm-generic: introduce stub header pci.h
  xen/asm-generic: introduce stub header random.h
  xen/asm-generic: introduce stub header setup.h
  xen/asm-generic: introduce stub header xenoprof.h
  xen/asm-generic: introduce stub header flushtlb.h
  xen/asm-generic: introduce stub header percpu.h
  xen/asm-generic: introduce stub header smp.h
  xen/asm-generic: introduce stub header hardirq.h
  xen/asm-generic: introduce stub header div64.h
  xen/asm-generic: introduce stub header altp2m.h
  xen/asm-generic: introduce stub header delay.h
  xen/asm-generic: introduce stub header domain.h
  xen/asm-generic: introduce stub header guest_access.h
  xen/asm-generic: introduce stub header irq.h
  xen/asm-generic: introduce stub header monitor.h
  xen/asm-generic: introduce stub header numa.h
  xen/asm-generic: introduce stub header p2m.h
  xen/asm-generic: introduce stub header softirq.h

 xen/include/asm-generic/altp2m.h        |  34 +++++++
 xen/include/asm-generic/cpufeature.h    |  23 +++++
 xen/include/asm-generic/delay.h         |  21 +++++
 xen/include/asm-generic/device.h        |  65 ++++++++++++++
 xen/include/asm-generic/div64.h         |  24 +++++
 xen/include/asm-generic/domain.h        |  53 +++++++++++
 xen/include/asm-generic/event.h         |  39 ++++++++
 xen/include/asm-generic/flushtlb.h      |  42 +++++++++
 xen/include/asm-generic/grant_table.h   |  14 +++
 xen/include/asm-generic/guest_access.h  |  31 +++++++
 xen/include/asm-generic/guest_atomics.h |  47 ++++++++++
 xen/include/asm-generic/hardirq.h       |  27 ++++++
 xen/include/asm-generic/hypercall.h     |  14 +++
 xen/include/asm-generic/iocap.h         |  17 ++++
 xen/include/asm-generic/iommu.h         |  17 ++++
 xen/include/asm-generic/irq.h           |  44 +++++++++
 xen/include/asm-generic/mem_access.h    |  14 +++
 xen/include/asm-generic/monitor.h       |  64 +++++++++++++
 xen/include/asm-generic/numa.h          |  35 ++++++++
 xen/include/asm-generic/p2m.h           | 115 ++++++++++++++++++++++++
 xen/include/asm-generic/paging.h        |  17 ++++
 xen/include/asm-generic/pci.h           |  18 ++++
 xen/include/asm-generic/percpu.h        |  35 ++++++++
 xen/include/asm-generic/random.h        |  20 +++++
 xen/include/asm-generic/setup.h         |  16 ++++
 xen/include/asm-generic/smp.h           |  30 +++++++
 xen/include/asm-generic/softirq.h       |  17 ++++
 xen/include/asm-generic/spinlock.h      |  23 +++++
 xen/include/asm-generic/xenoprof.h      |  14 +++
 29 files changed, 930 insertions(+)
 create mode 100644 xen/include/asm-generic/altp2m.h
 create mode 100644 xen/include/asm-generic/cpufeature.h
 create mode 100644 xen/include/asm-generic/delay.h
 create mode 100644 xen/include/asm-generic/device.h
 create mode 100644 xen/include/asm-generic/div64.h
 create mode 100644 xen/include/asm-generic/domain.h
 create mode 100644 xen/include/asm-generic/event.h
 create mode 100644 xen/include/asm-generic/flushtlb.h
 create mode 100644 xen/include/asm-generic/grant_table.h
 create mode 100644 xen/include/asm-generic/guest_access.h
 create mode 100644 xen/include/asm-generic/guest_atomics.h
 create mode 100644 xen/include/asm-generic/hardirq.h
 create mode 100644 xen/include/asm-generic/hypercall.h
 create mode 100644 xen/include/asm-generic/iocap.h
 create mode 100644 xen/include/asm-generic/iommu.h
 create mode 100644 xen/include/asm-generic/irq.h
 create mode 100644 xen/include/asm-generic/mem_access.h
 create mode 100644 xen/include/asm-generic/monitor.h
 create mode 100644 xen/include/asm-generic/numa.h
 create mode 100644 xen/include/asm-generic/p2m.h
 create mode 100644 xen/include/asm-generic/paging.h
 create mode 100644 xen/include/asm-generic/pci.h
 create mode 100644 xen/include/asm-generic/percpu.h
 create mode 100644 xen/include/asm-generic/random.h
 create mode 100644 xen/include/asm-generic/setup.h
 create mode 100644 xen/include/asm-generic/smp.h
 create mode 100644 xen/include/asm-generic/softirq.h
 create mode 100644 xen/include/asm-generic/spinlock.h
 create mode 100644 xen/include/asm-generic/xenoprof.h

-- 
2.41.0

[PATCH v1 01/29] xen/asm-generic: introduce stub header spinlock.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/spinlock.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 xen/include/asm-generic/spinlock.h

diff --git a/xen/include/asm-generic/spinlock.h b/xen/include/asm-generic/spinlock.h
new file mode 100644
index 0000000000..22a9ec5222
--- /dev/null
+++ b/xen/include/asm-generic/spinlock.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_SPINLOCK_H__
+#define __ASM_GENERIC_SPINLOCK_H__
+
+#define arch_lock_acquire_barrier() smp_mb()
+#define arch_lock_release_barrier() smp_mb()
+
+#define arch_lock_relax() cpu_relax()
+#define arch_lock_signal() do { \
+} while(0)
+
+#define arch_lock_signal_wmb() arch_lock_signal()
+
+#endif /* __ASM_GENERIC_SPINLOCK_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 01/29] xen/asm-generic: introduce stub header spinlock.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> The patch introduces stub header needed for full Xen build.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Hmm, looking here I think I need to take back what I said in reply
to the cover letter, taking this as an example.

> --- /dev/null
> +++ b/xen/include/asm-generic/spinlock.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_SPINLOCK_H__
> +#define __ASM_GENERIC_SPINLOCK_H__
> +
> +#define arch_lock_acquire_barrier() smp_mb()
> +#define arch_lock_release_barrier() smp_mb()
> +
> +#define arch_lock_relax() cpu_relax()
> +#define arch_lock_signal() do { \
> +} while(0)

Slightly easier (and without style violation) as ((void)0)?

> +#define arch_lock_signal_wmb() arch_lock_signal()

How's the WMB aspect represented in here? I think you need the x86
variant as the generic fallback.

Re: [PATCH v1 01/29] xen/asm-generic: introduce stub header spinlock.h

[Oleksii]

On Thu, 2023-09-14 at 17:35 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > The patch introduces stub header needed for full Xen build.
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> Hmm, looking here I think I need to take back what I said in reply
> to the cover letter, taking this as an example.
> 
> > --- /dev/null
> > +++ b/xen/include/asm-generic/spinlock.h
> > @@ -0,0 +1,23 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_SPINLOCK_H__
> > +#define __ASM_GENERIC_SPINLOCK_H__
> > +
> > +#define arch_lock_acquire_barrier() smp_mb()
> > +#define arch_lock_release_barrier() smp_mb()
> > +
> > +#define arch_lock_relax() cpu_relax()
> > +#define arch_lock_signal() do { \
> > +} while(0)
> 
> Slightly easier (and without style violation) as ((void)0)?
Thanks. It is much easier.

> 
> > +#define arch_lock_signal_wmb() arch_lock_signal()
> 
> How's the WMB aspect represented in here? I think you need the x86
> variant as the generic fallback.

Agree. I'll take x86 version in the next patch series.

~ Oleksii

[PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/paging.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 xen/include/asm-generic/paging.h

diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-generic/paging.h
new file mode 100644
index 0000000000..2aab63b536
--- /dev/null
+++ b/xen/include/asm-generic/paging.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_PAGING_H__
+#define __ASM_GENERIC_PAGING_H__
+
+#define paging_mode_translate(d)	(1)
+#define paging_mode_external(d)		(1)
+
+#endif /* __ASM_GENERIC_PAGING_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> The patch introduces stub header needed for full Xen build.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>  xen/include/asm-generic/paging.h | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 xen/include/asm-generic/paging.h
> 
> diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-generic/paging.h
> new file mode 100644
> index 0000000000..2aab63b536
> --- /dev/null
> +++ b/xen/include/asm-generic/paging.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_PAGING_H__
> +#define __ASM_GENERIC_PAGING_H__
> +
> +#define paging_mode_translate(d)	(1)
> +#define paging_mode_external(d)		(1)
> +
> +#endif /* __ASM_GENERIC_PAGING_H__ */

Looks okay, but wants accompanying by dropping (i.e. effectively moving)
Arm's respective header. The description than also wants adjusting (it
wasn't quite suitable anyway, as there's missing context).

Jan

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Julien Grall]

Hi,

On 19/10/2023 10:05, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>> The patch introduces stub header needed for full Xen build.
>>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> ---
>>   xen/include/asm-generic/paging.h | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>   create mode 100644 xen/include/asm-generic/paging.h
>>
>> diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-generic/paging.h
>> new file mode 100644
>> index 0000000000..2aab63b536
>> --- /dev/null
>> +++ b/xen/include/asm-generic/paging.h
>> @@ -0,0 +1,17 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __ASM_GENERIC_PAGING_H__
>> +#define __ASM_GENERIC_PAGING_H__
>> +
>> +#define paging_mode_translate(d)	(1)
>> +#define paging_mode_external(d)		(1)
This is more a question for Jan, in the past I recall you asked the 
macor to evaluate the argument. Shouldn't we do the same here?

Also, I think we want to take the opportunity to convert to true. 
Lastly, this seems to be using hard tab rather than soft tab. In Xen we 
use the latter (unless this is a file imported from Linux).

>> +
>> +#endif /* __ASM_GENERIC_PAGING_H__ */
> 
> Looks okay, but wants accompanying by dropping (i.e. effectively moving)
> Arm's respective header.

FWIW, I would be ok if the change is separate. I can help to write it also.

> The description than also wants adjusting (it
> wasn't quite suitable anyway, as there's missing context).

Cheers,

-- 
Julien Grall

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Jan Beulich]

On 19.10.2023 12:35, Julien Grall wrote:
> Hi,
> 
> On 19/10/2023 10:05, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> The patch introduces stub header needed for full Xen build.
>>>
>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>> ---
>>>   xen/include/asm-generic/paging.h | 17 +++++++++++++++++
>>>   1 file changed, 17 insertions(+)
>>>   create mode 100644 xen/include/asm-generic/paging.h
>>>
>>> diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-generic/paging.h
>>> new file mode 100644
>>> index 0000000000..2aab63b536
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/paging.h
>>> @@ -0,0 +1,17 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_PAGING_H__
>>> +#define __ASM_GENERIC_PAGING_H__
>>> +
>>> +#define paging_mode_translate(d)	(1)
>>> +#define paging_mode_external(d)		(1)
> This is more a question for Jan, in the past I recall you asked the 
> macor to evaluate the argument. Shouldn't we do the same here?

Would certainly be desirable, and iirc actually needed for one of the
Misra rules.

> Also, I think we want to take the opportunity to convert to true. 
> Lastly, this seems to be using hard tab rather than soft tab. In Xen we 
> use the latter (unless this is a file imported from Linux).

Oh, didn't even notice those; thanks for spotting. If we're at cosmetics,
the parentheses also aren't needed here in the expansions of the macros.

Jan

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Oleksii]

Hi, 
On Thu, 2023-10-19 at 11:35 +0100, Julien Grall wrote:
> Hi,
> 
> On 19/10/2023 10:05, Jan Beulich wrote:
> > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > The patch introduces stub header needed for full Xen build.
> > > 
> > > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > > ---
> > >   xen/include/asm-generic/paging.h | 17 +++++++++++++++++
> > >   1 file changed, 17 insertions(+)
> > >   create mode 100644 xen/include/asm-generic/paging.h
> > > 
> > > diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-
> > > generic/paging.h
> > > new file mode 100644
> > > index 0000000000..2aab63b536
> > > --- /dev/null
> > > +++ b/xen/include/asm-generic/paging.h
> > > @@ -0,0 +1,17 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > +#ifndef __ASM_GENERIC_PAGING_H__
> > > +#define __ASM_GENERIC_PAGING_H__
> > > +
> > > +#define paging_mode_translate(d)       (1)
> > > +#define paging_mode_external(d)                (1)
> This is more a question for Jan, in the past I recall you asked the 
> macor to evaluate the argument. Shouldn't we do the same here?
Could you please share a link?
I am not sure that I am in the context.

> 
> Also, I think we want to take the opportunity to convert to true. 
Sure, we can. I'll change definition to true.

> Lastly, this seems to be using hard tab rather than soft tab. In Xen
> we 
> use the latter (unless this is a file imported from Linux).
Thanks. I'll update tab.

> 
> > > +
> > > +#endif /* __ASM_GENERIC_PAGING_H__ */
> > 
> > Looks okay, but wants accompanying by dropping (i.e. effectively
> > moving)
> > Arm's respective header.
> 
> FWIW, I would be ok if the change is separate. I can help to write it
> also.
I would be glad if you could help.

> 
> > The description than also wants adjusting (it
> > wasn't quite suitable anyway, as there's missing context).
> 
> 
~ Oleksii

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Jan Beulich]

On 23.10.2023 11:35, Oleksii wrote:
> On Thu, 2023-10-19 at 11:35 +0100, Julien Grall wrote:
>> On 19/10/2023 10:05, Jan Beulich wrote:
>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>> The patch introduces stub header needed for full Xen build.
>>>>
>>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>>> ---
>>>>   xen/include/asm-generic/paging.h | 17 +++++++++++++++++
>>>>   1 file changed, 17 insertions(+)
>>>>   create mode 100644 xen/include/asm-generic/paging.h
>>>>
>>>> diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-
>>>> generic/paging.h
>>>> new file mode 100644
>>>> index 0000000000..2aab63b536
>>>> --- /dev/null
>>>> +++ b/xen/include/asm-generic/paging.h
>>>> @@ -0,0 +1,17 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>> +#ifndef __ASM_GENERIC_PAGING_H__
>>>> +#define __ASM_GENERIC_PAGING_H__
>>>> +
>>>> +#define paging_mode_translate(d)       (1)
>>>> +#define paging_mode_external(d)                (1)
>> This is more a question for Jan, in the past I recall you asked the 
>> macor to evaluate the argument. Shouldn't we do the same here?
> Could you please share a link?
> I am not sure that I am in the context.

There's no particular link to be provided, I think. It is simply good
practice to make sure macros evaluate each of the parameters exactly
once. This is simply to avoid surprises at use sites, where function-
like macro invocations - as that terminology says - look like
function invocations, where every argument expression is also
evaluated exactly once (and in unspecified order).

Jan

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Oleksii]

On Thu, 2023-10-19 at 11:05 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > The patch introduces stub header needed for full Xen build.
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> >  xen/include/asm-generic/paging.h | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >  create mode 100644 xen/include/asm-generic/paging.h
> > 
> > diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-
> > generic/paging.h
> > new file mode 100644
> > index 0000000000..2aab63b536
> > --- /dev/null
> > +++ b/xen/include/asm-generic/paging.h
> > @@ -0,0 +1,17 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_PAGING_H__
> > +#define __ASM_GENERIC_PAGING_H__
> > +
> > +#define paging_mode_translate(d)       (1)
> > +#define paging_mode_external(d)                (1)
> > +
> > +#endif /* __ASM_GENERIC_PAGING_H__ */
> 
> Looks okay, but wants accompanying by dropping (i.e. effectively
> moving)
> Arm's respective header. The description than also wants adjusting
> (it
> wasn't quite suitable anyway, as there's missing context).
If I understand you correctly, I'll re-use ARM's header, but I am not
sure I know how the description should be changed except that it can be
more specific regarding which one header is introduced.

~ Oleksii

Re: [PATCH v1 02/29] xen/asm-generic: introduce stub header paging.h

[Jan Beulich]

On 23.10.2023 11:40, Oleksii wrote:
> On Thu, 2023-10-19 at 11:05 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> The patch introduces stub header needed for full Xen build.
>>>
>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>> ---
>>>  xen/include/asm-generic/paging.h | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>  create mode 100644 xen/include/asm-generic/paging.h
>>>
>>> diff --git a/xen/include/asm-generic/paging.h b/xen/include/asm-
>>> generic/paging.h
>>> new file mode 100644
>>> index 0000000000..2aab63b536
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/paging.h
>>> @@ -0,0 +1,17 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_PAGING_H__
>>> +#define __ASM_GENERIC_PAGING_H__
>>> +
>>> +#define paging_mode_translate(d)       (1)
>>> +#define paging_mode_external(d)                (1)
>>> +
>>> +#endif /* __ASM_GENERIC_PAGING_H__ */
>>
>> Looks okay, but wants accompanying by dropping (i.e. effectively
>> moving)
>> Arm's respective header. The description than also wants adjusting
>> (it
>> wasn't quite suitable anyway, as there's missing context).
> If I understand you correctly, I'll re-use ARM's header, but I am not
> sure I know how the description should be changed except that it can be
> more specific regarding which one header is introduced.

Well, first of all context is missing in "full Xen build" - PPC has recently
reached that point already, and both Arm and x86 have been fully building
for quite some time. And then, as said elsewhere, imo headers needed solely
for building (but being otherwise non-functional) shouldn't be introduced.
At which point it may make sense to give a pointer as to where the
definitions are needed, and clarify why what is introduced is sufficient /
appropriate as fallback for a certain "common" default case of operation.

Jan

[PATCH v1 03/29] xen/asm-generic: introduce stub header cpufeature.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/cpufeature.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 xen/include/asm-generic/cpufeature.h

diff --git a/xen/include/asm-generic/cpufeature.h b/xen/include/asm-generic/cpufeature.h
new file mode 100644
index 0000000000..86e2a8b455
--- /dev/null
+++ b/xen/include/asm-generic/cpufeature.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_CPUFEATURE_H__
+#define __ASM_GENERIC_CPUFEATURE_H__
+
+#ifndef __ASSEMBLY__
+
+static inline int cpu_nr_siblings(unsigned int cpu)
+{
+    return 1;
+}
+
+#endif
+
+#endif /* __ASM_GENERIC_CPUFEATURE_H__  */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 03/29] xen/asm-generic: introduce stub header cpufeature.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/cpufeature.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_CPUFEATURE_H__
> +#define __ASM_GENERIC_CPUFEATURE_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +static inline int cpu_nr_siblings(unsigned int cpu)
> +{
> +    return 1;
> +}
> +
> +#endif
> +
> +#endif /* __ASM_GENERIC_CPUFEATURE_H__  */

I'm not convinced an arch can get away without such a header. Certainly
RISC-V and PPC can't, with all their ISA extensions that already exist
(part of which will want making use of, others may simply want exposing
to guests).

Jan

Re: [PATCH v1 03/29] xen/asm-generic: introduce stub header cpufeature.h

[Oleksii]

On Thu, 2023-10-19 at 11:11 +0200, Jan Beulich wrote:
> I'm not convinced an arch can get away without such a header.
> Certainly
> RISC-V and PPC can't, with all their ISA extensions that already
> exist
> (part of which will want making use of, others may simply want
> exposing
> to guests).
Yes, it looks like you are right. I forgot about a considerable amount
of ISA.

By this patch series, I tried to move headers to asm-generic to build
minimal Xen without introducing the stub cpu_nr_siblings(unsigned int
cpu) for each new arch. But taking into account that likely this header
will be re-introduced for an arch, there is probably no sense to have
it in asm-generic.

~ Oleksii

[PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/device.h | 65 ++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 xen/include/asm-generic/device.h

diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
new file mode 100644
index 0000000000..66e69ecd78
--- /dev/null
+++ b/xen/include/asm-generic/device.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_DEVICE_H__
+#define __ASM_GENERIC_DEVICE_H__
+
+struct dt_device_node;
+
+enum device_type
+{
+    DEV_DT,
+    DEV_PCI,
+};
+
+struct device {
+    enum device_type type;
+#ifdef CONFIG_HAS_DEVICE_TREE
+    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
+#endif
+};
+
+enum device_class
+{
+    DEVICE_SERIAL,
+    DEVICE_IOMMU,
+    DEVICE_GIC,
+    DEVICE_PCI_HOSTBRIDGE,
+    /* Use for error */
+    DEVICE_UNKNOWN,
+};
+
+struct device_desc {
+    /* Device name */
+    const char *name;
+    /* Device class */
+    enum device_class class;
+    /* List of devices supported by this driver */
+    const struct dt_device_match *dt_match;
+    /*
+     * Device initialization.
+     *
+     * -EAGAIN is used to indicate that device probing is deferred.
+     */
+    int (*init)(struct dt_device_node *dev, const void *data);
+};
+
+typedef struct device device_t;
+
+#define DT_DEVICE_START(_name, _namestr, _class)                    \
+static const struct device_desc __dev_desc_##_name __used           \
+__section(".dev.info") = {                                          \
+    .name = _namestr,                                               \
+    .class = _class,                                                \
+
+#define DT_DEVICE_END                                               \
+};
+
+#endif /* __ASM_GENERIC_DEVICE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/device.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_DEVICE_H__
> +#define __ASM_GENERIC_DEVICE_H__
> +
> +struct dt_device_node;
> +
> +enum device_type
> +{
> +    DEV_DT,
> +    DEV_PCI,
> +};

Are both of these really generic?

> +struct device {
> +    enum device_type type;
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
> +#endif
> +};
> +
> +enum device_class
> +{
> +    DEVICE_SERIAL,
> +    DEVICE_IOMMU,
> +    DEVICE_GIC,

This one certainly is Arm-specific.

> +    DEVICE_PCI_HOSTBRIDGE,

And this one's PCI-specific.

Overall same question as before: Are you expecting that RISC-V is going to
get away without a customized header? I wouldn't think so.

Jan

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Julien Grall]

Hi,

On 19/10/2023 10:14, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-generic/device.h
>> @@ -0,0 +1,65 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __ASM_GENERIC_DEVICE_H__
>> +#define __ASM_GENERIC_DEVICE_H__
>> +
>> +struct dt_device_node;
>> +
>> +enum device_type
>> +{
>> +    DEV_DT,
>> +    DEV_PCI,
>> +};
> 
> Are both of these really generic?

I think can be re-used for RISC-V to have an abstract view a device. 
This is for instance used in the IOMMU code where both PCI and platform 
(here called DT) can be assigned to a domain. The driver will need to 
know the difference, but the common layer doesn't need to.

>> +struct device {
>> +    enum device_type type;
>> +#ifdef CONFIG_HAS_DEVICE_TREE
>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>> +#endif
>> +};
>> +
>> +enum device_class
>> +{
>> +    DEVICE_SERIAL,
>> +    DEVICE_IOMMU,
>> +    DEVICE_GIC,
> 
> This one certainly is Arm-specific.

This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)

> 
>> +    DEVICE_PCI_HOSTBRIDGE,
> 
> And this one's PCI-specific.

Are you suggesting to #ifdef it? If so, I don't exactly see the value here.

> 
> Overall same question as before: Are you expecting that RISC-V is going to
> get away without a customized header? I wouldn't think so.

I think it can be useful. Most likely you will have multiple drivers for 
a class and you may want to initialize certain device class early than 
others. See how it is used in device_init().

Cheers,

-- 
Julien Grall

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 19.10.2023 12:42, Julien Grall wrote:
> On 19/10/2023 10:14, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/device.h
>>> @@ -0,0 +1,65 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>> +#define __ASM_GENERIC_DEVICE_H__
>>> +
>>> +struct dt_device_node;
>>> +
>>> +enum device_type
>>> +{
>>> +    DEV_DT,
>>> +    DEV_PCI,
>>> +};
>>
>> Are both of these really generic?
> 
> I think can be re-used for RISC-V to have an abstract view a device. 
> This is for instance used in the IOMMU code where both PCI and platform 
> (here called DT) can be assigned to a domain. The driver will need to 
> know the difference, but the common layer doesn't need to.

Question to me is whether DT and PCI can be considered "common", which
is a prereq for being used here.

>>> +struct device {
>>> +    enum device_type type;
>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>> +#endif
>>> +};
>>> +
>>> +enum device_class
>>> +{
>>> +    DEVICE_SERIAL,
>>> +    DEVICE_IOMMU,
>>> +    DEVICE_GIC,
>>
>> This one certainly is Arm-specific.
> 
> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
> 
>>
>>> +    DEVICE_PCI_HOSTBRIDGE,
>>
>> And this one's PCI-specific.
> 
> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.

What to do with it is secondary to me. I was questioning its presence here.

>> Overall same question as before: Are you expecting that RISC-V is going to
>> get away without a customized header? I wouldn't think so.
> 
> I think it can be useful. Most likely you will have multiple drivers for 
> a class and you may want to initialize certain device class early than 
> others. See how it is used in device_init().

I'm afraid I don't see how your reply relates to the question of such a
fallback header being sensible to have, or whether instead RISC-V will
need its own private header anyway.

Jan

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Julien Grall]

Hi Jan,

On 19/10/2023 11:53, Jan Beulich wrote:
> On 19.10.2023 12:42, Julien Grall wrote:
>> On 19/10/2023 10:14, Jan Beulich wrote:
>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>> --- /dev/null
>>>> +++ b/xen/include/asm-generic/device.h
>>>> @@ -0,0 +1,65 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>>> +#define __ASM_GENERIC_DEVICE_H__
>>>> +
>>>> +struct dt_device_node;
>>>> +
>>>> +enum device_type
>>>> +{
>>>> +    DEV_DT,
>>>> +    DEV_PCI,
>>>> +};
>>>
>>> Are both of these really generic?
>>
>> I think can be re-used for RISC-V to have an abstract view a device.
>> This is for instance used in the IOMMU code where both PCI and platform
>> (here called DT) can be assigned to a domain. The driver will need to
>> know the difference, but the common layer doesn't need to.
> 
> Question to me is whether DT and PCI can be considered "common", which
> is a prereq for being used here.

I think it can. See more below.

> 
>>>> +struct device {
>>>> +    enum device_type type;
>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>> +#endif
>>>> +};
>>>> +
>>>> +enum device_class
>>>> +{
>>>> +    DEVICE_SERIAL,
>>>> +    DEVICE_IOMMU,
>>>> +    DEVICE_GIC,
>>>
>>> This one certainly is Arm-specific.
>>
>> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
>>
>>>
>>>> +    DEVICE_PCI_HOSTBRIDGE,
>>>
>>> And this one's PCI-specific.
>>
>> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.
> 
> What to do with it is secondary to me. I was questioning its presence here.
> 
>>> Overall same question as before: Are you expecting that RISC-V is going to
>>> get away without a customized header? I wouldn't think so.
>>
>> I think it can be useful. Most likely you will have multiple drivers for
>> a class and you may want to initialize certain device class early than
>> others. See how it is used in device_init().
> 
> I'm afraid I don't see how your reply relates to the question of such a
> fallback header being sensible to have, or whether instead RISC-V will
> need its own private header anyway.

My point is that RISC-V will most likely duplicate what Arm did (they 
are already copying the dom0less code). So the header would end up to be 
duplicated. This is not ideal and therefore we want to share the header.

I don't particularly care whether it lives in asm-generic or somewhere. 
I just want to avoid the duplication.

Cheers,

-- 
Julien Grall

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 19.10.2023 12:57, Julien Grall wrote:
> On 19/10/2023 11:53, Jan Beulich wrote:
>> On 19.10.2023 12:42, Julien Grall wrote:
>>> On 19/10/2023 10:14, Jan Beulich wrote:
>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/include/asm-generic/device.h
>>>>> @@ -0,0 +1,65 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>>>> +#define __ASM_GENERIC_DEVICE_H__
>>>>> +
>>>>> +struct dt_device_node;
>>>>> +
>>>>> +enum device_type
>>>>> +{
>>>>> +    DEV_DT,
>>>>> +    DEV_PCI,
>>>>> +};
>>>>
>>>> Are both of these really generic?
>>>
>>> I think can be re-used for RISC-V to have an abstract view a device.
>>> This is for instance used in the IOMMU code where both PCI and platform
>>> (here called DT) can be assigned to a domain. The driver will need to
>>> know the difference, but the common layer doesn't need to.
>>
>> Question to me is whether DT and PCI can be considered "common", which
>> is a prereq for being used here.
> 
> I think it can. See more below.
> 
>>
>>>>> +struct device {
>>>>> +    enum device_type type;
>>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>>> +#endif
>>>>> +};
>>>>> +
>>>>> +enum device_class
>>>>> +{
>>>>> +    DEVICE_SERIAL,
>>>>> +    DEVICE_IOMMU,
>>>>> +    DEVICE_GIC,
>>>>
>>>> This one certainly is Arm-specific.
>>>
>>> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
>>>
>>>>
>>>>> +    DEVICE_PCI_HOSTBRIDGE,
>>>>
>>>> And this one's PCI-specific.
>>>
>>> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.
>>
>> What to do with it is secondary to me. I was questioning its presence here.
>>
>>>> Overall same question as before: Are you expecting that RISC-V is going to
>>>> get away without a customized header? I wouldn't think so.
>>>
>>> I think it can be useful. Most likely you will have multiple drivers for
>>> a class and you may want to initialize certain device class early than
>>> others. See how it is used in device_init().
>>
>> I'm afraid I don't see how your reply relates to the question of such a
>> fallback header being sensible to have, or whether instead RISC-V will
>> need its own private header anyway.
> 
> My point is that RISC-V will most likely duplicate what Arm did (they 
> are already copying the dom0less code). So the header would end up to be 
> duplicated. This is not ideal and therefore we want to share the header.
> 
> I don't particularly care whether it lives in asm-generic or somewhere. 
> I just want to avoid the duplication.

Avoiding duplication is one goal, which I certainly appreciate. The header
as presented here is, however, only a subset of Arm's if I'm not mistaken.
If moving all of Arm's code here, I then wonder whether that really can
count as "generic".

Avoiding duplication could e.g. be achieved by making RISC-V symlink Arm's
header.

Jan

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Julien Grall]

On 19/10/2023 12:01, Jan Beulich wrote:
> On 19.10.2023 12:57, Julien Grall wrote:
>> On 19/10/2023 11:53, Jan Beulich wrote:
>>> On 19.10.2023 12:42, Julien Grall wrote:
>>>> On 19/10/2023 10:14, Jan Beulich wrote:
>>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>>> --- /dev/null
>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>> @@ -0,0 +1,65 @@
>>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>>>>> +#define __ASM_GENERIC_DEVICE_H__
>>>>>> +
>>>>>> +struct dt_device_node;
>>>>>> +
>>>>>> +enum device_type
>>>>>> +{
>>>>>> +    DEV_DT,
>>>>>> +    DEV_PCI,
>>>>>> +};
>>>>>
>>>>> Are both of these really generic?
>>>>
>>>> I think can be re-used for RISC-V to have an abstract view a device.
>>>> This is for instance used in the IOMMU code where both PCI and platform
>>>> (here called DT) can be assigned to a domain. The driver will need to
>>>> know the difference, but the common layer doesn't need to.
>>>
>>> Question to me is whether DT and PCI can be considered "common", which
>>> is a prereq for being used here.
>>
>> I think it can. See more below.
>>
>>>
>>>>>> +struct device {
>>>>>> +    enum device_type type;
>>>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>>>> +#endif
>>>>>> +};
>>>>>> +
>>>>>> +enum device_class
>>>>>> +{
>>>>>> +    DEVICE_SERIAL,
>>>>>> +    DEVICE_IOMMU,
>>>>>> +    DEVICE_GIC,
>>>>>
>>>>> This one certainly is Arm-specific.
>>>>
>>>> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
>>>>
>>>>>
>>>>>> +    DEVICE_PCI_HOSTBRIDGE,
>>>>>
>>>>> And this one's PCI-specific.
>>>>
>>>> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.
>>>
>>> What to do with it is secondary to me. I was questioning its presence here.
>>>
>>>>> Overall same question as before: Are you expecting that RISC-V is going to
>>>>> get away without a customized header? I wouldn't think so.
>>>>
>>>> I think it can be useful. Most likely you will have multiple drivers for
>>>> a class and you may want to initialize certain device class early than
>>>> others. See how it is used in device_init().
>>>
>>> I'm afraid I don't see how your reply relates to the question of such a
>>> fallback header being sensible to have, or whether instead RISC-V will
>>> need its own private header anyway.
>>
>> My point is that RISC-V will most likely duplicate what Arm did (they
>> are already copying the dom0less code). So the header would end up to be
>> duplicated. This is not ideal and therefore we want to share the header.
>>
>> I don't particularly care whether it lives in asm-generic or somewhere.
>> I just want to avoid the duplication.
> 
> Avoiding duplication is one goal, which I certainly appreciate. The header
> as presented here is, however, only a subset of Arm's if I'm not mistaken.
> If moving all of Arm's code here, I then wonder whether that really can
> count as "generic".

 From previous discussion, I recalled that we seemed to agree that if 
applies for most the architecture, then it should be considered common.

> 
> Avoiding duplication could e.g. be achieved by making RISC-V symlink Arm's
> header.

Ewwwwww. Removing the fact I dislike it, I can see some issues with this 
approach in term of review. Who is responsible to review for any changes 
here? Surely, we don't only want to the Arm folks to review.

Cheers,

-- 
Julien Grall

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 19.10.2023 13:07, Julien Grall wrote:
> 
> 
> On 19/10/2023 12:01, Jan Beulich wrote:
>> On 19.10.2023 12:57, Julien Grall wrote:
>>> On 19/10/2023 11:53, Jan Beulich wrote:
>>>> On 19.10.2023 12:42, Julien Grall wrote:
>>>>> On 19/10/2023 10:14, Jan Beulich wrote:
>>>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>>>> --- /dev/null
>>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>>> @@ -0,0 +1,65 @@
>>>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>>>>>> +#define __ASM_GENERIC_DEVICE_H__
>>>>>>> +
>>>>>>> +struct dt_device_node;
>>>>>>> +
>>>>>>> +enum device_type
>>>>>>> +{
>>>>>>> +    DEV_DT,
>>>>>>> +    DEV_PCI,
>>>>>>> +};
>>>>>>
>>>>>> Are both of these really generic?
>>>>>
>>>>> I think can be re-used for RISC-V to have an abstract view a device.
>>>>> This is for instance used in the IOMMU code where both PCI and platform
>>>>> (here called DT) can be assigned to a domain. The driver will need to
>>>>> know the difference, but the common layer doesn't need to.
>>>>
>>>> Question to me is whether DT and PCI can be considered "common", which
>>>> is a prereq for being used here.
>>>
>>> I think it can. See more below.
>>>
>>>>
>>>>>>> +struct device {
>>>>>>> +    enum device_type type;
>>>>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>>>>> +#endif
>>>>>>> +};
>>>>>>> +
>>>>>>> +enum device_class
>>>>>>> +{
>>>>>>> +    DEVICE_SERIAL,
>>>>>>> +    DEVICE_IOMMU,
>>>>>>> +    DEVICE_GIC,
>>>>>>
>>>>>> This one certainly is Arm-specific.
>>>>>
>>>>> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
>>>>>
>>>>>>
>>>>>>> +    DEVICE_PCI_HOSTBRIDGE,
>>>>>>
>>>>>> And this one's PCI-specific.
>>>>>
>>>>> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.
>>>>
>>>> What to do with it is secondary to me. I was questioning its presence here.
>>>>
>>>>>> Overall same question as before: Are you expecting that RISC-V is going to
>>>>>> get away without a customized header? I wouldn't think so.
>>>>>
>>>>> I think it can be useful. Most likely you will have multiple drivers for
>>>>> a class and you may want to initialize certain device class early than
>>>>> others. See how it is used in device_init().
>>>>
>>>> I'm afraid I don't see how your reply relates to the question of such a
>>>> fallback header being sensible to have, or whether instead RISC-V will
>>>> need its own private header anyway.
>>>
>>> My point is that RISC-V will most likely duplicate what Arm did (they
>>> are already copying the dom0less code). So the header would end up to be
>>> duplicated. This is not ideal and therefore we want to share the header.
>>>
>>> I don't particularly care whether it lives in asm-generic or somewhere.
>>> I just want to avoid the duplication.
>>
>> Avoiding duplication is one goal, which I certainly appreciate. The header
>> as presented here is, however, only a subset of Arm's if I'm not mistaken.
>> If moving all of Arm's code here, I then wonder whether that really can
>> count as "generic".
> 
>  From previous discussion, I recalled that we seemed to agree that if 
> applies for most the architecture, then it should be considered common.

Hmm, not my recollection - a certain amount of "does this make sense from
an abstract perspective" should also be applied.

>> Avoiding duplication could e.g. be achieved by making RISC-V symlink Arm's
>> header.
> 
> Ewwwwww. Removing the fact I dislike it, I can see some issues with this 
> approach in term of review. Who is responsible to review for any changes 
> here? Surely, we don't only want to the Arm folks to review.

That could be achieved by an F: entry in the RISC-V section of ./MAINTAINERS.

Jan

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Julien Grall]

Hi Jan,

On 19/10/2023 12:14, Jan Beulich wrote:
> On 19.10.2023 13:07, Julien Grall wrote:
>>
>>
>> On 19/10/2023 12:01, Jan Beulich wrote:
>>> On 19.10.2023 12:57, Julien Grall wrote:
>>>> On 19/10/2023 11:53, Jan Beulich wrote:
>>>>> On 19.10.2023 12:42, Julien Grall wrote:
>>>>>> On 19/10/2023 10:14, Jan Beulich wrote:
>>>>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>>>> @@ -0,0 +1,65 @@
>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>>>>>>> +#define __ASM_GENERIC_DEVICE_H__
>>>>>>>> +
>>>>>>>> +struct dt_device_node;
>>>>>>>> +
>>>>>>>> +enum device_type
>>>>>>>> +{
>>>>>>>> +    DEV_DT,
>>>>>>>> +    DEV_PCI,
>>>>>>>> +};
>>>>>>>
>>>>>>> Are both of these really generic?
>>>>>>
>>>>>> I think can be re-used for RISC-V to have an abstract view a device.
>>>>>> This is for instance used in the IOMMU code where both PCI and platform
>>>>>> (here called DT) can be assigned to a domain. The driver will need to
>>>>>> know the difference, but the common layer doesn't need to.
>>>>>
>>>>> Question to me is whether DT and PCI can be considered "common", which
>>>>> is a prereq for being used here.
>>>>
>>>> I think it can. See more below.
>>>>
>>>>>
>>>>>>>> +struct device {
>>>>>>>> +    enum device_type type;
>>>>>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>>>>>> +#endif
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +enum device_class
>>>>>>>> +{
>>>>>>>> +    DEVICE_SERIAL,
>>>>>>>> +    DEVICE_IOMMU,
>>>>>>>> +    DEVICE_GIC,
>>>>>>>
>>>>>>> This one certainly is Arm-specific.
>>>>>>
>>>>>> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
>>>>>>
>>>>>>>
>>>>>>>> +    DEVICE_PCI_HOSTBRIDGE,
>>>>>>>
>>>>>>> And this one's PCI-specific.
>>>>>>
>>>>>> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.
>>>>>
>>>>> What to do with it is secondary to me. I was questioning its presence here.
>>>>>
>>>>>>> Overall same question as before: Are you expecting that RISC-V is going to
>>>>>>> get away without a customized header? I wouldn't think so.
>>>>>>
>>>>>> I think it can be useful. Most likely you will have multiple drivers for
>>>>>> a class and you may want to initialize certain device class early than
>>>>>> others. See how it is used in device_init().
>>>>>
>>>>> I'm afraid I don't see how your reply relates to the question of such a
>>>>> fallback header being sensible to have, or whether instead RISC-V will
>>>>> need its own private header anyway.
>>>>
>>>> My point is that RISC-V will most likely duplicate what Arm did (they
>>>> are already copying the dom0less code). So the header would end up to be
>>>> duplicated. This is not ideal and therefore we want to share the header.
>>>>
>>>> I don't particularly care whether it lives in asm-generic or somewhere.
>>>> I just want to avoid the duplication.
>>>
>>> Avoiding duplication is one goal, which I certainly appreciate. The header
>>> as presented here is, however, only a subset of Arm's if I'm not mistaken.
>>> If moving all of Arm's code here, I then wonder whether that really can
>>> count as "generic".
>>
>>   From previous discussion, I recalled that we seemed to agree that if
>> applies for most the architecture, then it should be considered common.
> 
> Hmm, not my recollection - a certain amount of "does this make sense from
> an abstract perspective" should also be applied.
> 
>>> Avoiding duplication could e.g. be achieved by making RISC-V symlink Arm's
>>> header.
>>
>> Ewwwwww. Removing the fact I dislike it, I can see some issues with this
>> approach in term of review. Who is responsible to review for any changes
>> here? Surely, we don't only want to the Arm folks to review.
> 
> That could be achieved by an F: entry in the RISC-V section of ./MAINTAINERS.

This works for one arch. But if PPC needs the same, then this is another 
symbolic link.

At which point, how would this be different from asm-generic? We need to 
have a way to share common headers that doesn't involve one arch to 
symlink headers from another arch.

Cheers,

-- 
Julien Grall

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 19.10.2023 13:27, Julien Grall wrote:
> Hi Jan,
> 
> On 19/10/2023 12:14, Jan Beulich wrote:
>> On 19.10.2023 13:07, Julien Grall wrote:
>>>
>>>
>>> On 19/10/2023 12:01, Jan Beulich wrote:
>>>> On 19.10.2023 12:57, Julien Grall wrote:
>>>>> On 19/10/2023 11:53, Jan Beulich wrote:
>>>>>> On 19.10.2023 12:42, Julien Grall wrote:
>>>>>>> On 19/10/2023 10:14, Jan Beulich wrote:
>>>>>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>>>>> @@ -0,0 +1,65 @@
>>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>>>>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>>>>>>>> +#define __ASM_GENERIC_DEVICE_H__
>>>>>>>>> +
>>>>>>>>> +struct dt_device_node;
>>>>>>>>> +
>>>>>>>>> +enum device_type
>>>>>>>>> +{
>>>>>>>>> +    DEV_DT,
>>>>>>>>> +    DEV_PCI,
>>>>>>>>> +};
>>>>>>>>
>>>>>>>> Are both of these really generic?
>>>>>>>
>>>>>>> I think can be re-used for RISC-V to have an abstract view a device.
>>>>>>> This is for instance used in the IOMMU code where both PCI and platform
>>>>>>> (here called DT) can be assigned to a domain. The driver will need to
>>>>>>> know the difference, but the common layer doesn't need to.
>>>>>>
>>>>>> Question to me is whether DT and PCI can be considered "common", which
>>>>>> is a prereq for being used here.
>>>>>
>>>>> I think it can. See more below.
>>>>>
>>>>>>
>>>>>>>>> +struct device {
>>>>>>>>> +    enum device_type type;
>>>>>>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>>>> +    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>>>>>>> +#endif
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +enum device_class
>>>>>>>>> +{
>>>>>>>>> +    DEVICE_SERIAL,
>>>>>>>>> +    DEVICE_IOMMU,
>>>>>>>>> +    DEVICE_GIC,
>>>>>>>>
>>>>>>>> This one certainly is Arm-specific.
>>>>>>>
>>>>>>> This could be renamed to DEVICE_IC (or INTERRUPT_CONTROLLER)
>>>>>>>
>>>>>>>>
>>>>>>>>> +    DEVICE_PCI_HOSTBRIDGE,
>>>>>>>>
>>>>>>>> And this one's PCI-specific.
>>>>>>>
>>>>>>> Are you suggesting to #ifdef it? If so, I don't exactly see the value here.
>>>>>>
>>>>>> What to do with it is secondary to me. I was questioning its presence here.
>>>>>>
>>>>>>>> Overall same question as before: Are you expecting that RISC-V is going to
>>>>>>>> get away without a customized header? I wouldn't think so.
>>>>>>>
>>>>>>> I think it can be useful. Most likely you will have multiple drivers for
>>>>>>> a class and you may want to initialize certain device class early than
>>>>>>> others. See how it is used in device_init().
>>>>>>
>>>>>> I'm afraid I don't see how your reply relates to the question of such a
>>>>>> fallback header being sensible to have, or whether instead RISC-V will
>>>>>> need its own private header anyway.
>>>>>
>>>>> My point is that RISC-V will most likely duplicate what Arm did (they
>>>>> are already copying the dom0less code). So the header would end up to be
>>>>> duplicated. This is not ideal and therefore we want to share the header.
>>>>>
>>>>> I don't particularly care whether it lives in asm-generic or somewhere.
>>>>> I just want to avoid the duplication.
>>>>
>>>> Avoiding duplication is one goal, which I certainly appreciate. The header
>>>> as presented here is, however, only a subset of Arm's if I'm not mistaken.
>>>> If moving all of Arm's code here, I then wonder whether that really can
>>>> count as "generic".
>>>
>>>   From previous discussion, I recalled that we seemed to agree that if
>>> applies for most the architecture, then it should be considered common.
>>
>> Hmm, not my recollection - a certain amount of "does this make sense from
>> an abstract perspective" should also be applied.
>>
>>>> Avoiding duplication could e.g. be achieved by making RISC-V symlink Arm's
>>>> header.
>>>
>>> Ewwwwww. Removing the fact I dislike it, I can see some issues with this
>>> approach in term of review. Who is responsible to review for any changes
>>> here? Surely, we don't only want to the Arm folks to review.
>>
>> That could be achieved by an F: entry in the RISC-V section of ./MAINTAINERS.
> 
> This works for one arch. But if PPC needs the same, then this is another 
> symbolic link.
> 
> At which point, how would this be different from asm-generic? We need to 
> have a way to share common headers

... which are sufficiently arch-agnostic.

> that doesn't involve one arch to symlink headers from another arch.

Whether to use symlinks or #include "../../arch/..." or yet something else is
a matter of mechanics.

Jan

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Julien Grall]

Hi,

On 19/10/2023 12:41, Jan Beulich wrote:
> On 19.10.2023 13:27, Julien Grall wrote:
>> that doesn't involve one arch to symlink headers from another arch.
> 
> Whether to use symlinks or #include "../../arch/..." or yet something else is
> a matter of mechanics.

#include "../../arch/../" is pretty much in the same category. This is 
simply hiding the fact they could be in asm-generic.

Anyway, I have shared my view. Let see what the others thinks.

Cheers,

-- 
Julien Grall

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Oleksii]

On Thu, 2023-10-19 at 13:12 +0100, Julien Grall wrote:
> Hi,
> 
> On 19/10/2023 12:41, Jan Beulich wrote:
> > On 19.10.2023 13:27, Julien Grall wrote:
> > > that doesn't involve one arch to symlink headers from another
> > > arch.
> > 
> > Whether to use symlinks or #include "../../arch/..." or yet
> > something else is
> > a matter of mechanics.
> 
> #include "../../arch/../" is pretty much in the same category. This
> is 
> simply hiding the fact they could be in asm-generic.
> 
> Anyway, I have shared my view. Let see what the others thinks.
I have the same point: if something is shared at least between two
arch, it should go to ASM-generic.

And that is the reason why I pushed device.h header to asm-generic.
It is needed to rename some stuff (e.g... GIC ) in it or add some
ifdefs.

~ Oleksii

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 23.10.2023 12:17, Oleksii wrote:
> On Thu, 2023-10-19 at 13:12 +0100, Julien Grall wrote:
>> Hi,
>>
>> On 19/10/2023 12:41, Jan Beulich wrote:
>>> On 19.10.2023 13:27, Julien Grall wrote:
>>>> that doesn't involve one arch to symlink headers from another
>>>> arch.
>>>
>>> Whether to use symlinks or #include "../../arch/..." or yet
>>> something else is
>>> a matter of mechanics.
>>
>> #include "../../arch/../" is pretty much in the same category. This
>> is 
>> simply hiding the fact they could be in asm-generic.
>>
>> Anyway, I have shared my view. Let see what the others thinks.
> I have the same point: if something is shared at least between two
> arch, it should go to ASM-generic.

I continue to disagree: What if one pair of arch-es shares one set
of things, and another shares another set? You can't fit both pairs
then with a single fallback header (unless of course you make it a
big #if / #else / #endif, which I'm inclined to say isn't the goal
with headers put in asm-generic/).

Jan

> And that is the reason why I pushed device.h header to asm-generic.
> It is needed to rename some stuff (e.g... GIC ) in it or add some
> ifdefs.
> 
> ~ Oleksii

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Julien Grall]

Hi Jan,

On 23/10/2023 11:33, Jan Beulich wrote:
> On 23.10.2023 12:17, Oleksii wrote:
>> On Thu, 2023-10-19 at 13:12 +0100, Julien Grall wrote:
>>> Hi,
>>>
>>> On 19/10/2023 12:41, Jan Beulich wrote:
>>>> On 19.10.2023 13:27, Julien Grall wrote:
>>>>> that doesn't involve one arch to symlink headers from another
>>>>> arch.
>>>>
>>>> Whether to use symlinks or #include "../../arch/..." or yet
>>>> something else is
>>>> a matter of mechanics.
>>>
>>> #include "../../arch/../" is pretty much in the same category. This
>>> is
>>> simply hiding the fact they could be in asm-generic.
>>>
>>> Anyway, I have shared my view. Let see what the others thinks.
>> I have the same point: if something is shared at least between two
>> arch, it should go to ASM-generic.
> 
> I continue to disagree: What if one pair of arch-es shares one set
> of things, and another shares another set? You can't fit both pairs
> then with a single fallback header (unless of course you make it a
> big #if / #else / #endif, which I'm inclined to say isn't the goal
> with headers put in asm-generic/).

TBH, I would expect that if RISC-V and Arm are using the same headers, 
then PPC would likely use it as well. So this would qualify to be in 
asm-generic/.

Now, I don't think we have to resolve the case where we have have two 
arch using one set of headers and the other another sets. We can cross 
that line once we have an example.

Cheers,

-- 
Julien Grall

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Oleksii]

On Thu, 2023-10-19 at 11:14 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/device.h
> > @@ -0,0 +1,65 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_DEVICE_H__
> > +#define __ASM_GENERIC_DEVICE_H__
> > +
> > +struct dt_device_node;
> > +
> > +enum device_type
> > +{
> > +    DEV_DT,
> > +    DEV_PCI,
> > +};
> 
> Are both of these really generic?
> 
> > +struct device {
> > +    enum device_type type;
> > +#ifdef CONFIG_HAS_DEVICE_TREE
> > +    struct dt_device_node *of_node; /* Used by drivers imported
> > from Linux */
> > +#endif
> > +};
> > +
> > +enum device_class
> > +{
> > +    DEVICE_SERIAL,
> > +    DEVICE_IOMMU,
> > +    DEVICE_GIC,
> 
> This one certainly is Arm-specific.
Yes, but the definition of GIC sounds common, so I decided to leave it.
But it can be changed.

> 
> > +    DEVICE_PCI_HOSTBRIDGE,
> 
> And this one's PCI-specific.
> 
> Overall same question as before: Are you expecting that RISC-V is
> going to
> get away without a customized header? I wouldn't think so.
At least right now, I am using the same header device.h as in ARM, and
there wasn't a need for a customized version of the header.

~ Oleksii

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Jan Beulich]

On 23.10.2023 12:12, Oleksii wrote:
> On Thu, 2023-10-19 at 11:14 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/device.h
>>> @@ -0,0 +1,65 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_DEVICE_H__
>>> +#define __ASM_GENERIC_DEVICE_H__
>>> +
>>> +struct dt_device_node;
>>> +
>>> +enum device_type
>>> +{
>>> +    DEV_DT,
>>> +    DEV_PCI,
>>> +};
>>
>> Are both of these really generic?
>>
>>> +struct device {
>>> +    enum device_type type;
>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>> +    struct dt_device_node *of_node; /* Used by drivers imported
>>> from Linux */
>>> +#endif
>>> +};
>>> +
>>> +enum device_class
>>> +{
>>> +    DEVICE_SERIAL,
>>> +    DEVICE_IOMMU,
>>> +    DEVICE_GIC,
>>
>> This one certainly is Arm-specific.
> Yes, but the definition of GIC sounds common, so I decided to leave it.
> But it can be changed.
> 
>>
>>> +    DEVICE_PCI_HOSTBRIDGE,
>>
>> And this one's PCI-specific.
>>
>> Overall same question as before: Are you expecting that RISC-V is
>> going to
>> get away without a customized header? I wouldn't think so.
> At least right now, I am using the same header device.h as in ARM,

Are you? I just double checked, and I can't see yours matching theirs.
First example of a difference is them having struct dev_archdata.

Jan

> and
> there wasn't a need for a customized version of the header.
> 
> ~ Oleksii
> 

Re: [PATCH v1 04/29] xen/asm-generic: introduce stub header device.h

[Oleksii]

On Mon, 2023-10-23 at 12:35 +0200, Jan Beulich wrote:
> On 23.10.2023 12:12, Oleksii wrote:
> > On Thu, 2023-10-19 at 11:14 +0200, Jan Beulich wrote:
> > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/device.h
> > > > @@ -0,0 +1,65 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +#ifndef __ASM_GENERIC_DEVICE_H__
> > > > +#define __ASM_GENERIC_DEVICE_H__
> > > > +
> > > > +struct dt_device_node;
> > > > +
> > > > +enum device_type
> > > > +{
> > > > +    DEV_DT,
> > > > +    DEV_PCI,
> > > > +};
> > > 
> > > Are both of these really generic?
> > > 
> > > > +struct device {
> > > > +    enum device_type type;
> > > > +#ifdef CONFIG_HAS_DEVICE_TREE
> > > > +    struct dt_device_node *of_node; /* Used by drivers
> > > > imported
> > > > from Linux */
> > > > +#endif
> > > > +};
> > > > +
> > > > +enum device_class
> > > > +{
> > > > +    DEVICE_SERIAL,
> > > > +    DEVICE_IOMMU,
> > > > +    DEVICE_GIC,
> > > 
> > > This one certainly is Arm-specific.
> > Yes, but the definition of GIC sounds common, so I decided to leave
> > it.
> > But it can be changed.
> > 
> > > 
> > > > +    DEVICE_PCI_HOSTBRIDGE,
> > > 
> > > And this one's PCI-specific.
> > > 
> > > Overall same question as before: Are you expecting that RISC-V is
> > > going to
> > > get away without a customized header? I wouldn't think so.
> > At least right now, I am using the same header device.h as in ARM,
> 
> Are you? I just double checked, and I can't see yours matching
> theirs.
> First example of a difference is them having struct dev_archdata.
I just tried to commit minimum for now.

It is how device.h is looked ( but still I have to align with ARM's
version, I used older version of it for some reason I don't remember )
now:
I just tried to commit to the minimum for now.

It is how device.h looks ( but still, I have to align it with ARM's
version. I used an older version of it for some reason I don't remember
) now:
https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/include/asm/device.h?ref_type=heads

> 

~ Oleksii

[PATCH v1 05/29] xen/asm-generic: introduce stub header event.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/event.h | 39 +++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 xen/include/asm-generic/event.h

diff --git a/xen/include/asm-generic/event.h b/xen/include/asm-generic/event.h
new file mode 100644
index 0000000000..d25ba36aad
--- /dev/null
+++ b/xen/include/asm-generic/event.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_EVENT_H__
+#define __ASM_GENERIC_EVENT_H__
+
+#include <xen/sched.h>
+
+static inline void vcpu_mark_events_pending(struct vcpu *v)
+{
+}
+
+static inline int vcpu_event_delivery_is_enabled(struct vcpu *v)
+{
+    return 0;
+}
+
+static inline int local_events_need_delivery(void)
+{
+    return 0;
+}
+
+static inline void local_event_delivery_enable(void)
+{
+}
+
+static inline bool arch_virq_is_global(unsigned int virq)
+{
+    return true;
+}
+
+#endif /* __ASM_GENERIC_EVENT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 05/29] xen/asm-generic: introduce stub header event.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/event.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_EVENT_H__
> +#define __ASM_GENERIC_EVENT_H__
> +
> +#include <xen/sched.h>
> +
> +static inline void vcpu_mark_events_pending(struct vcpu *v)
> +{
> +}

While this will satisfy callers from a build perspective, no port
will be functional with an implementation like this. Yet the
generic headers need to provide the required functionality, not
just build stubs.

Going further in the series, I won't repeat this kind of comment.
Unless others disagree, my view is that headers put here should
be of use beyond initial bring-up of a new port.

Jan

Re: [PATCH v1 05/29] xen/asm-generic: introduce stub header event.h

[Oleksii]

On Thu, 2023-10-19 at 11:18 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/event.h
> > @@ -0,0 +1,39 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_EVENT_H__
> > +#define __ASM_GENERIC_EVENT_H__
> > +
> > +#include <xen/sched.h>
> > +
> > +static inline void vcpu_mark_events_pending(struct vcpu *v)
> > +{
> > +}
> 
> While this will satisfy callers from a build perspective, no port
> will be functional with an implementation like this. Yet the
> generic headers need to provide the required functionality, not
> just build stubs.
It makes sense but then we will have the similar patches when new
architecture is introduced.

> 
> Going further in the series, I won't repeat this kind of comment.
> Unless others disagree, my view is that headers put here should
> be of use beyond initial bring-up of a new port.
> 
Then we have two options here:
1. leave only declaration of the function.
2. remove it from asm-generic.

~ Oleksii

Re: [PATCH v1 05/29] xen/asm-generic: introduce stub header event.h

[Jan Beulich]

On 23.10.2023 12:23, Oleksii wrote:
> On Thu, 2023-10-19 at 11:18 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/event.h
>>> @@ -0,0 +1,39 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_EVENT_H__
>>> +#define __ASM_GENERIC_EVENT_H__
>>> +
>>> +#include <xen/sched.h>
>>> +
>>> +static inline void vcpu_mark_events_pending(struct vcpu *v)
>>> +{
>>> +}
>>
>> While this will satisfy callers from a build perspective, no port
>> will be functional with an implementation like this. Yet the
>> generic headers need to provide the required functionality, not
>> just build stubs.
> It makes sense but then we will have the similar patches when new
> architecture is introduced.
> 
>>
>> Going further in the series, I won't repeat this kind of comment.
>> Unless others disagree, my view is that headers put here should
>> be of use beyond initial bring-up of a new port.
>>
> Then we have two options here:
> 1. leave only declaration of the function.

Which would then require a stub to be introduced in the arch, or else
linking will fail (unless all calls can be compile-time eliminated,
which I doubt would be the case here).

As before a requirement (imo) is that headers introduced into
asm-generic/ are functional. An arch would introduce its own instance
if it wants to do certain things better, or if it has further needs.

Jan

> 2. remove it from asm-generic.
> 
> ~ Oleksii

[PATCH v1 06/29] xen/asm-generic: introduce stub header grant_table.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/grant_table.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 xen/include/asm-generic/grant_table.h

diff --git a/xen/include/asm-generic/grant_table.h b/xen/include/asm-generic/grant_table.h
new file mode 100644
index 0000000000..bd8d85f1ff
--- /dev/null
+++ b/xen/include/asm-generic/grant_table.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_GRANTTABLE_H__
+#define __ASM_GENERIC_GRANTTABLE_H__
+
+#endif /* __ASM_GENERIC_GRANTTABLE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 06/29] xen/asm-generic: introduce stub header grant_table.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/grant_table.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_GRANTTABLE_H__
> +#define __ASM_GENERIC_GRANTTABLE_H__
> +
> +#endif /* __ASM_GENERIC_GRANTTABLE_H__ */

This isn't going to work with CONFIG_GRANT_TABLE=y, is it?

Jan

Re: [PATCH v1 06/29] xen/asm-generic: introduce stub header grant_table.h

[Oleksii]

On Thu, 2023-10-19 at 11:19 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/grant_table.h
> > @@ -0,0 +1,14 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_GRANTTABLE_H__
> > +#define __ASM_GENERIC_GRANTTABLE_H__
> > +
> > +#endif /* __ASM_GENERIC_GRANTTABLE_H__ */
> 
> This isn't going to work with CONFIG_GRANT_TABLE=y, is it?
Yes, it won't work with CONFIG_GRANT_TABLE=y. Missed that as
CONFIG_GRANT_TABLE is disabled for RISC-V.

It looks like it should be moved to arch specific folder but as I
mentioned before I don't see a lot of sense to introduce an empty
header for new arch each time when it will be needed to enable full Xen
build.

~ Oleksii

Re: [PATCH v1 06/29] xen/asm-generic: introduce stub header grant_table.h

[Jan Beulich]

On 23.10.2023 12:32, Oleksii wrote:
> On Thu, 2023-10-19 at 11:19 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/grant_table.h
>>> @@ -0,0 +1,14 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_GRANTTABLE_H__
>>> +#define __ASM_GENERIC_GRANTTABLE_H__
>>> +
>>> +#endif /* __ASM_GENERIC_GRANTTABLE_H__ */
>>
>> This isn't going to work with CONFIG_GRANT_TABLE=y, is it?
> Yes, it won't work with CONFIG_GRANT_TABLE=y. Missed that as
> CONFIG_GRANT_TABLE is disabled for RISC-V.
> 
> It looks like it should be moved to arch specific folder but as I
> mentioned before I don't see a lot of sense to introduce an empty
> header for new arch each time when it will be needed to enable full Xen
> build.

Here I'm okay with an almost empty header in asm-generic/, so long as
it properly rejects CONFIG_GRANT_TABLE=y (indicating in the diagnostic
that for this to build an arch needs to have its own header).

However, then the question again arises where it wouldn't be possible
to have xen/grant_table.h avoid including asm/grant_table.h when
!CONFIG_GRANT_TABLE, eliminating the question whether to have a fallback
header in asm-generic/. If that's not possible, the reason may be a good
thing to put in the description here.

Jan

[PATCH v1 07/29] xen/asm-generic: introduce stub header guest_atomics.h

[Oleksii Kurochko]

The patch introduces stub header needed for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/guest_atomics.h | 47 +++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 xen/include/asm-generic/guest_atomics.h

diff --git a/xen/include/asm-generic/guest_atomics.h b/xen/include/asm-generic/guest_atomics.h
new file mode 100644
index 0000000000..6c4e79350a
--- /dev/null
+++ b/xen/include/asm-generic/guest_atomics.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_GUEST_ATOMICS_H
+#define __ASM_GENERIC_GUEST_ATOMICS_H
+
+#define guest_testop(name)                                                  \
+static inline int guest_##name(struct domain *d, int nr, volatile void *p)  \
+{                                                                           \
+    (void) d;                                                               \
+    (void) nr;                                                              \
+    (void) p;                                                               \
+                                                                            \
+    return 0;                                                               \
+}
+
+#define guest_bitop(name)                                                   \
+static inline void guest_##name(struct domain *d, int nr, volatile void *p) \
+{                                                                           \
+    (void) d;                                                               \
+    (void) nr;                                                              \
+    (void) p;                                                               \
+}
+
+guest_bitop(set_bit)
+guest_bitop(clear_bit)
+guest_bitop(change_bit)
+
+#undef guest_bitop
+
+guest_testop(test_and_set_bit)
+guest_testop(test_and_clear_bit)
+guest_testop(test_and_change_bit)
+
+#undef guest_testop
+
+
+#define guest_test_bit(d, nr, p) ((void)(d), test_bit(nr, p))
+
+#endif /* __ASM_GENERIC_GUEST_ATOMICS_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

[PATCH v1 08/29] xen/asm-generic: introduce stub hypercall.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/hypercall.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 xen/include/asm-generic/hypercall.h

diff --git a/xen/include/asm-generic/hypercall.h b/xen/include/asm-generic/hypercall.h
new file mode 100644
index 0000000000..d89196fb3e
--- /dev/null
+++ b/xen/include/asm-generic/hypercall.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_HYPERCALL_H__
+#define __ASM_GENERIC_HYPERCALL_H__
+
+#endif /* __ASM_GENERIC_HYPERCALL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 08/29] xen/asm-generic: introduce stub hypercall.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/hypercall.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_HYPERCALL_H__
> +#define __ASM_GENERIC_HYPERCALL_H__
> +
> +#endif /* __ASM_GENERIC_HYPERCALL_H__ */

This lacks the "should not be included directly" guard that x86 and Arm
headers have.

Jan

Re: [PATCH v1 08/29] xen/asm-generic: introduce stub hypercall.h

[Oleksii]

On Thu, 2023-10-19 at 11:24 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/hypercall.h
> > @@ -0,0 +1,14 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_HYPERCALL_H__
> > +#define __ASM_GENERIC_HYPERCALL_H__
> > +
> > +#endif /* __ASM_GENERIC_HYPERCALL_H__ */
> 
> This lacks the "should not be included directly" guard that x86 and
> Arm
> headers have.
Thanks. I'll add it.

~ Oleksii

[PATCH v1 09/29] xen/asm-generic: introduce stub header iocap.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/iocap.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 xen/include/asm-generic/iocap.h

diff --git a/xen/include/asm-generic/iocap.h b/xen/include/asm-generic/iocap.h
new file mode 100644
index 0000000000..dd7cb45488
--- /dev/null
+++ b/xen/include/asm-generic/iocap.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_IOCAP_H__
+#define __ASM_GENERIC_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#endif /* __ASM_GENERIC_IOCAP_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 09/29] xen/asm-generic: introduce stub header iocap.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/iocap.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_IOCAP_H__
> +#define __ASM_GENERIC_IOCAP_H__
> +
> +#define cache_flush_permitted(d)                        \
> +    (!rangeset_is_empty((d)->iomem_caps))
> +
> +#endif /* __ASM_GENERIC_IOCAP_H__ */

This again wants to eliminate Arm's header in exchange.

Jan

Re: [PATCH v1 09/29] xen/asm-generic: introduce stub header iocap.h

[Oleksii]

On Thu, 2023-10-19 at 11:25 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/iocap.h
> > @@ -0,0 +1,17 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_IOCAP_H__
> > +#define __ASM_GENERIC_IOCAP_H__
> > +
> > +#define cache_flush_permitted(d)                        \
> > +    (!rangeset_is_empty((d)->iomem_caps))
> > +
> > +#endif /* __ASM_GENERIC_IOCAP_H__ */
> 
> This again wants to eliminate Arm's header in exchange.
Basically yes.

The situation is the same as with device.h [1].

So let's get to the same page about [1] and then I'll apply
the solution for this header too.

[1]https://lore.kernel.org/xen-devel/48c3c78d-465f-8102-87a3-cef3a5d4838c@suse.com/

~ Oleksii

[PATCH v1 10/29] xen/asm-generic: introduce stub header iommu.h

[Oleksii Kurochko]

The patch introduces stub header necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/iommu.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 xen/include/asm-generic/iommu.h

diff --git a/xen/include/asm-generic/iommu.h b/xen/include/asm-generic/iommu.h
new file mode 100644
index 0000000000..b08550e6b3
--- /dev/null
+++ b/xen/include/asm-generic/iommu.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_IOMMU_H__
+#define __ASM_GENERIC_IOMMU_H__
+
+struct arch_iommu {
+};
+
+#endif /* __ASM_IOMMU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 10/29] xen/asm-generic: introduce stub header iommu.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/iommu.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_IOMMU_H__
> +#define __ASM_GENERIC_IOMMU_H__
> +
> +struct arch_iommu {
> +};
> +
> +#endif /* __ASM_IOMMU_H__ */
This one's perhaps slightly more "interesting": Yes, we have a
HAS_PASSTHROUGH Kconfig option, which both Arm and x86 select. But it
is in principle possible to support guests without any kind of IOMMU
(permitting solely emulated and PV devices). In which case what's
(imo) needed here in addition is

#ifdef CONFIG_HAS_PASSTHROUGH
# error
#endif

Jan

Re: [PATCH v1 10/29] xen/asm-generic: introduce stub header iommu.h

[Oleksii]

On Thu, 2023-10-19 at 11:44 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/iommu.h
> > @@ -0,0 +1,17 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_IOMMU_H__
> > +#define __ASM_GENERIC_IOMMU_H__
> > +
> > +struct arch_iommu {
> > +};
> > +
> > +#endif /* __ASM_IOMMU_H__ */
> This one's perhaps slightly more "interesting": Yes, we have a
> HAS_PASSTHROUGH Kconfig option, which both Arm and x86 select. But it
> is in principle possible to support guests without any kind of IOMMU
> (permitting solely emulated and PV devices). In which case what's
> (imo) needed here in addition is
> 
> #ifdef CONFIG_HAS_PASSTHROUGH
> # error
> #endif
I am not 100% sure but not all platform has support of IOMMU.

And I thought that passthrough it is when a device is fully committed
to  a guest domain with all MMIO things. So it is a question of
properly mapping MMIO to guest domain. Am I right?

~ Oleksii

Re: [PATCH v1 10/29] xen/asm-generic: introduce stub header iommu.h

[Jan Beulich]

On 23.10.2023 12:43, Oleksii wrote:
> On Thu, 2023-10-19 at 11:44 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/iommu.h
>>> @@ -0,0 +1,17 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_IOMMU_H__
>>> +#define __ASM_GENERIC_IOMMU_H__
>>> +
>>> +struct arch_iommu {
>>> +};
>>> +
>>> +#endif /* __ASM_IOMMU_H__ */
>> This one's perhaps slightly more "interesting": Yes, we have a
>> HAS_PASSTHROUGH Kconfig option, which both Arm and x86 select. But it
>> is in principle possible to support guests without any kind of IOMMU
>> (permitting solely emulated and PV devices). In which case what's
>> (imo) needed here in addition is
>>
>> #ifdef CONFIG_HAS_PASSTHROUGH
>> # error
>> #endif
> I am not 100% sure but not all platform has support of IOMMU.
> 
> And I thought that passthrough it is when a device is fully committed
> to  a guest domain with all MMIO things. So it is a question of
> properly mapping MMIO to guest domain. Am I right?

Yes. And do you expect you will get away with such a stub implementation
when you actually start supporting pass-through on RISC-V?

Jan

Re: [PATCH v1 10/29] xen/asm-generic: introduce stub header iommu.h

[Oleksii]

On Mon, 2023-10-23 at 12:47 +0200, Jan Beulich wrote:
> On 23.10.2023 12:43, Oleksii wrote:
> > On Thu, 2023-10-19 at 11:44 +0200, Jan Beulich wrote:
> > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/iommu.h
> > > > @@ -0,0 +1,17 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +#ifndef __ASM_GENERIC_IOMMU_H__
> > > > +#define __ASM_GENERIC_IOMMU_H__
> > > > +
> > > > +struct arch_iommu {
> > > > +};
> > > > +
> > > > +#endif /* __ASM_IOMMU_H__ */
> > > This one's perhaps slightly more "interesting": Yes, we have a
> > > HAS_PASSTHROUGH Kconfig option, which both Arm and x86 select.
> > > But it
> > > is in principle possible to support guests without any kind of
> > > IOMMU
> > > (permitting solely emulated and PV devices). In which case what's
> > > (imo) needed here in addition is
> > > 
> > > #ifdef CONFIG_HAS_PASSTHROUGH
> > > # error
> > > #endif
> > I am not 100% sure but not all platform has support of IOMMU.
> > 
> > And I thought that passthrough it is when a device is fully
> > committed
> > to  a guest domain with all MMIO things. So it is a question of
> > properly mapping MMIO to guest domain. Am I right?
> 
> Yes. And do you expect you will get away with such a stub
> implementation
> when you actually start supporting pass-through on RISC-V?
No, it will be changed. It was added to asm-generic because of the
build purpose for the full Xen build ( the same header with the same
content is used for PPC ).

But yeah, taking into account about device.h header in this patch
series looks like this patch will be arch-specific.

~ Oleksii

[PATCH v1 11/29] xen/asm-generic: introduce stub header mem_access.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/mem_access.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 xen/include/asm-generic/mem_access.h

diff --git a/xen/include/asm-generic/mem_access.h b/xen/include/asm-generic/mem_access.h
new file mode 100644
index 0000000000..d2a0b545a4
--- /dev/null
+++ b/xen/include/asm-generic/mem_access.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_MEM_ACCESS
+#define __ASM_GENERIC_MEM_ACCESS
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 11/29] xen/asm-generic: introduce stub header mem_access.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/mem_access.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_MEM_ACCESS
> +#define __ASM_GENERIC_MEM_ACCESS
> +
> +#endif

Does xen/mem_access.h actually need to include asm/mem_access.h when
!CONFIG_MEM_ACCESS? Without that, I don't think this header is needed.

Jan

Re: [PATCH v1 11/29] xen/asm-generic: introduce stub header mem_access.h

[Oleksii]

On Thu, 2023-10-19 at 11:51 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/mem_access.h
> > @@ -0,0 +1,14 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_MEM_ACCESS
> > +#define __ASM_GENERIC_MEM_ACCESS
> > +
> > +#endif
> 
> Does xen/mem_access.h actually need to include asm/mem_access.h when
> !CONFIG_MEM_ACCESS? Without that, I don't think this header is
> needed.
Yes, it won't needed. I'll update xen/mem_access.h header and push a
separate patch.

Thanks.

~ Oleksii

[PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/pci.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 xen/include/asm-generic/pci.h

diff --git a/xen/include/asm-generic/pci.h b/xen/include/asm-generic/pci.h
new file mode 100644
index 0000000000..b577ee105f
--- /dev/null
+++ b/xen/include/asm-generic/pci.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_PCI_H__
+#define __ASM_GENERIC_PCI_H__
+
+struct arch_pci_dev {
+};
+
+#endif /* __ASM_GENERIC_PCI_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
-- 
2.41.0

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/pci.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_PCI_H__
> +#define __ASM_GENERIC_PCI_H__
> +
> +struct arch_pci_dev {
> +};
> +
> +#endif /* __ASM_GENERIC_PCI_H__ */

While more involved, I still wonder whether xen/pci.h could also avoid
including asm/pci.h when !HAS_PCI. Of course there's more than just the
#include which then would need #ifdef-ing out.

Jan

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Oleksii]

On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
> While more involved, I still wonder whether xen/pci.h could also
> avoid
> including asm/pci.h when !HAS_PCI. Of course there's more than just
> the
> #include which then would need #ifdef-ing out.
It looks like we can get with #ifdef-ing. I'll push a separate patch
for xen/pci.h.

It will probably need to remove usage of <asm/pci.h> everywhere or
#ifdef-ing it too.
Which option will be better?

~ Oleksii

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Jan Beulich]

On 23.10.2023 12:50, Oleksii wrote:
> On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
>> While more involved, I still wonder whether xen/pci.h could also
>> avoid
>> including asm/pci.h when !HAS_PCI. Of course there's more than just
>> the
>> #include which then would need #ifdef-ing out.
> It looks like we can get with #ifdef-ing. I'll push a separate patch
> for xen/pci.h.
> 
> It will probably need to remove usage of <asm/pci.h> everywhere or
> #ifdef-ing it too.
> Which option will be better?

What's "everywhere" here? The only non-arch-dependent use I can spot
is in xen/pci.h.

Jan

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Oleksii]

On Mon, 2023-10-23 at 13:58 +0200, Jan Beulich wrote:
> On 23.10.2023 12:50, Oleksii wrote:
> > On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
> > > While more involved, I still wonder whether xen/pci.h could also
> > > avoid
> > > including asm/pci.h when !HAS_PCI. Of course there's more than
> > > just
> > > the
> > > #include which then would need #ifdef-ing out.
> > It looks like we can get with #ifdef-ing. I'll push a separate
> > patch
> > for xen/pci.h.
> > 
> > It will probably need to remove usage of <asm/pci.h> everywhere or
> > #ifdef-ing it too.
> > Which option will be better?
> 
> What's "everywhere" here? The only non-arch-dependent use I can spot
> is in xen/pci.h.
It looks you are right.

I wrote everywhere because of "xen/drivers/passthrough/vtd/quirks.c"
but it is arch-dependent. So  , yes, only xen/pci.h should be updated.

~ Oleksii

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Oleksii]

Hello Jan,

On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/pci.h
> > @@ -0,0 +1,18 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_PCI_H__
> > +#define __ASM_GENERIC_PCI_H__
> > +
> > +struct arch_pci_dev {
> > +};
> > +
> > +#endif /* __ASM_GENERIC_PCI_H__ */
> 
> While more involved, I still wonder whether xen/pci.h could also
> avoid
> including asm/pci.h when !HAS_PCI. Of course there's more than just
> the
> #include which then would need #ifdef-ing out.
> 
> Jan

It looks like we can do that but only one question should be resolved.
In ARM case, in <asm/pci.h> there is !HAS_PCI branch:

#else   /*!CONFIG_HAS_PCI*/

struct arch_pci_dev { };

static always_inline bool is_pci_passthrough_enabled(void)
{
    return false;
}

struct pci_dev;

static inline void arch_pci_init_pdev(struct pci_dev *pdev) {}

static inline int pci_get_host_bridge_segment(const struct
dt_device_node *node,
                                              uint16_t *segment)
{
    ASSERT_UNREACHABLE();
    return -EINVAL;
}

static inline int pci_get_new_domain_nr(void)
{
    ASSERT_UNREACHABLE();
    return -1;
}

#endif  /*!CONFIG_HAS_PCI*/

And if is_pci_passthrough_enabled(), arch_pci_init_pdev() is used by
all architrectures but pci_get_host_bridge_segment() and
pci_get_new_domain_nr() is ARM specific.
Does it make sense to add them to <xen/pci.h> and ifdef them?

~ Oleksii

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Jan Beulich]

On 30.10.2023 17:34, Oleksii wrote:
> Hello Jan,
> 
> On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/pci.h
>>> @@ -0,0 +1,18 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ASM_GENERIC_PCI_H__
>>> +#define __ASM_GENERIC_PCI_H__
>>> +
>>> +struct arch_pci_dev {
>>> +};
>>> +
>>> +#endif /* __ASM_GENERIC_PCI_H__ */
>>
>> While more involved, I still wonder whether xen/pci.h could also
>> avoid
>> including asm/pci.h when !HAS_PCI. Of course there's more than just
>> the
>> #include which then would need #ifdef-ing out.
>>
>> Jan
> 
> It looks like we can do that but only one question should be resolved.
> In ARM case, in <asm/pci.h> there is !HAS_PCI branch:
> 
> #else   /*!CONFIG_HAS_PCI*/
> 
> struct arch_pci_dev { };
> 
> static always_inline bool is_pci_passthrough_enabled(void)
> {
>     return false;
> }
> 
> struct pci_dev;
> 
> static inline void arch_pci_init_pdev(struct pci_dev *pdev) {}
> 
> static inline int pci_get_host_bridge_segment(const struct
> dt_device_node *node,
>                                               uint16_t *segment)
> {
>     ASSERT_UNREACHABLE();
>     return -EINVAL;
> }
> 
> static inline int pci_get_new_domain_nr(void)
> {
>     ASSERT_UNREACHABLE();
>     return -1;
> }
> 
> #endif  /*!CONFIG_HAS_PCI*/
> 
> And if is_pci_passthrough_enabled(), arch_pci_init_pdev() is used by
> all architrectures but pci_get_host_bridge_segment() and
> pci_get_new_domain_nr() is ARM specific.
> Does it make sense to add them to <xen/pci.h> and ifdef them?

Counter question: Is the arch_pci_init_pdev() stub actually needed?
The sole caller looks to be in a file which is only built when HAS_PCI=y.

For the Arm-only stubs (which are called from Arm-specific code afaics)
all it would take is that the respective .c files include asm/pci.h
(possibly alongside xen/pci.h).

Jan

Re: [PATCH v1 12/29] xen/asm-generic: introduce stub header pci.h

[Oleksii]

On Mon, 2023-10-30 at 17:43 +0100, Jan Beulich wrote:
> On 30.10.2023 17:34, Oleksii wrote:
> > Hello Jan,
> > 
> > On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
> > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/pci.h
> > > > @@ -0,0 +1,18 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +#ifndef __ASM_GENERIC_PCI_H__
> > > > +#define __ASM_GENERIC_PCI_H__
> > > > +
> > > > +struct arch_pci_dev {
> > > > +};
> > > > +
> > > > +#endif /* __ASM_GENERIC_PCI_H__ */
> > > 
> > > While more involved, I still wonder whether xen/pci.h could also
> > > avoid
> > > including asm/pci.h when !HAS_PCI. Of course there's more than
> > > just
> > > the
> > > #include which then would need #ifdef-ing out.
> > > 
> > > Jan
> > 
> > It looks like we can do that but only one question should be
> > resolved.
> > In ARM case, in <asm/pci.h> there is !HAS_PCI branch:
> > 
> > #else   /*!CONFIG_HAS_PCI*/
> > 
> > struct arch_pci_dev { };
> > 
> > static always_inline bool is_pci_passthrough_enabled(void)
> > {
> >     return false;
> > }
> > 
> > struct pci_dev;
> > 
> > static inline void arch_pci_init_pdev(struct pci_dev *pdev) {}
> > 
> > static inline int pci_get_host_bridge_segment(const struct
> > dt_device_node *node,
> >                                               uint16_t *segment)
> > {
> >     ASSERT_UNREACHABLE();
> >     return -EINVAL;
> > }
> > 
> > static inline int pci_get_new_domain_nr(void)
> > {
> >     ASSERT_UNREACHABLE();
> >     return -1;
> > }
> > 
> > #endif  /*!CONFIG_HAS_PCI*/
> > 
> > And if is_pci_passthrough_enabled(), arch_pci_init_pdev() is used
> > by
> > all architrectures but pci_get_host_bridge_segment() and
> > pci_get_new_domain_nr() is ARM specific.
> > Does it make sense to add them to <xen/pci.h> and ifdef them?
> 
> Counter question: Is the arch_pci_init_pdev() stub actually needed?
> The sole caller looks to be in a file which is only built when
> HAS_PCI=y.
You are right. It seems that there is no need for pci_init_pdev() stub.

> 
> For the Arm-only stubs (which are called from Arm-specific code
> afaics)
> all it would take is that the respective .c files include asm/pci.h
> (possibly alongside xen/pci.h).
We can do in that way.

Thanks.

~ Oleksii

[PATCH v1 13/29] xen/asm-generic: introduce stub header random.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/random.h | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 xen/include/asm-generic/random.h

diff --git a/xen/include/asm-generic/random.h b/xen/include/asm-generic/random.h
new file mode 100644
index 0000000000..cd2307e70b
--- /dev/null
+++ b/xen/include/asm-generic/random.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_RANDOM_H__
+#define __ASM_GENERIC_RANDOM_H__
+
+static inline unsigned int arch_get_random(void)
+{
+    return 0;
+}
+
+#endif /* __ASM_GENERIC_RANDOM_H__ */
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

[PATCH v1 14/29] xen/asm-generic: introduce stub header setup.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/setup.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 xen/include/asm-generic/setup.h

diff --git a/xen/include/asm-generic/setup.h b/xen/include/asm-generic/setup.h
new file mode 100644
index 0000000000..37feac222f
--- /dev/null
+++ b/xen/include/asm-generic/setup.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_SETUP_H__
+#define __ASM_GENERIC_SETUP_H__
+
+#define max_init_domid (0)
+
+#endif /* __ASM_GENERIC_SETUP_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

[PATCH v1 15/29] xen/asm-generic: introduce stub header xenoprof.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/xenoprof.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 xen/include/asm-generic/xenoprof.h

diff --git a/xen/include/asm-generic/xenoprof.h b/xen/include/asm-generic/xenoprof.h
new file mode 100644
index 0000000000..8ee3408b77
--- /dev/null
+++ b/xen/include/asm-generic/xenoprof.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_XENOPROF_H__
+#define __ASM_GENERIC_XENOPROF_H__
+
+#endif /* __ASM_GENERIC_XENOPROF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 15/29] xen/asm-generic: introduce stub header xenoprof.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/xenoprof.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_XENOPROF_H__
> +#define __ASM_GENERIC_XENOPROF_H__
> +
> +#endif /* __ASM_GENERIC_XENOPROF_H__ */

I've made a patch to move #include-s in xen/xenoprof.h, dropping Arm's
header (and none going to be needed for RISC-V or PPC). I'll send that
patch in due course.

Jan

Re: [PATCH v1 15/29] xen/asm-generic: introduce stub header xenoprof.h

[Oleksii]

On Thu, 2023-10-19 at 12:09 +0200, Jan Beulich wrote:
> I've made a patch to move #include-s in xen/xenoprof.h, dropping
> Arm's
> header (and none going to be needed for RISC-V or PPC). I'll send
> that
> patch in due course.
Could you please share a link with me? I can't find for some reason...

~ Oleksii

Re: [PATCH v1 15/29] xen/asm-generic: introduce stub header xenoprof.h

[Jan Beulich]

On 23.10.2023 13:17, Oleksii wrote:
> On Thu, 2023-10-19 at 12:09 +0200, Jan Beulich wrote:
>> I've made a patch to move #include-s in xen/xenoprof.h, dropping
>> Arm's
>> header (and none going to be needed for RISC-V or PPC). I'll send
>> that
>> patch in due course.
> Could you please share a link with me? I can't find for some reason...

I said "I'll send"; I didn't do, yet. I don't really like sending minor
patches while the tree is closed anyway.

Jan

[PATCH v1 16/29] xen/asm-generic: introduce stub header flushtlb.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/flushtlb.h | 42 ++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 xen/include/asm-generic/flushtlb.h

diff --git a/xen/include/asm-generic/flushtlb.h b/xen/include/asm-generic/flushtlb.h
new file mode 100644
index 0000000000..79e4773179
--- /dev/null
+++ b/xen/include/asm-generic/flushtlb.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_FLUSHTLB_H__
+#define __ASM_GENERIC_FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp) {}
+
+#define tlbflush_current_time() (0)
+
+static inline void page_set_tlbflush_timestamp(struct page_info *page)
+{
+    BUG();
+}
+
+/* Flush specified CPUs' TLBs */
+void arch_flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __ASM_GENERIC_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 16/29] xen/asm-generic: introduce stub header flushtlb.h

[Jiamei Xie]

Hi Oleksii

On 2023/9/14 22:56, Oleksii Kurochko wrote:
> The patch introduces header stub necessry for full Xen build.
>
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>   xen/include/asm-generic/flushtlb.h | 42 ++++++++++++++++++++++++++++++
>   1 file changed, 42 insertions(+)
>   create mode 100644 xen/include/asm-generic/flushtlb.h
>
> diff --git a/xen/include/asm-generic/flushtlb.h b/xen/include/asm-generic/flushtlb.h
> new file mode 100644
> index 0000000000..79e4773179
> --- /dev/null
> +++ b/xen/include/asm-generic/flushtlb.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_FLUSHTLB_H__
> +#define __ASM_GENERIC_FLUSHTLB_H__
> +
> +#include <xen/cpumask.h>
> +
> +/*
> + * Filter the given set of CPUs, removing those that definitely flushed their
> + * TLB since @page_timestamp.
> + */
> +/* XXX lazy implementation just doesn't clear anything.... */
> +static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp) {}
> +
> +#define tlbflush_current_time() (0)
> +
> +static inline void page_set_tlbflush_timestamp(struct page_info *page)
> +{
> +    BUG();
> +}
> +
> +/* Flush specified CPUs' TLBs */
> +void arch_flush_tlb_mask(const cpumask_t *mask);
> +
> +#endif /* __ASM_GENERIC_FLUSHTLB_H__ */
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> +
> +
It's duplicated.
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: BSD
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

Re: [PATCH v1 16/29] xen/asm-generic: introduce stub header flushtlb.h

[Oleksii]

Hello Jiamei,

On Fri, 2023-09-15 at 13:15 +0800, Jiamei Xie wrote:
> Hi Oleksii
...
> 
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: "BSD"
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> > +
> > +
> It's duplicated.
Thanks. I'll remove duplication.
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: BSD
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */

~ Oleksii

[PATCH v1 17/29] xen/asm-generic: introduce stub header percpu.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/percpu.h | 35 ++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 xen/include/asm-generic/percpu.h

diff --git a/xen/include/asm-generic/percpu.h b/xen/include/asm-generic/percpu.h
new file mode 100644
index 0000000000..d1069adb61
--- /dev/null
+++ b/xen/include/asm-generic/percpu.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_PERCPU_H__
+#define __ASM_GENERIC_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+
+#define per_cpu(var, cpu)  \
+    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
+
+#define this_cpu(var) \
+    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[get_processor_id()]))
+
+#define per_cpu_ptr(var, cpu)  \
+    (*RELOC_HIDE(var, __per_cpu_offset[cpu]))
+#define this_cpu_ptr(var) \
+    (*RELOC_HIDE(var, get_processor_id()))
+
+#endif
+
+#endif /* __ASM_GENERIC_PERCPU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 17/29] xen/asm-generic: introduce stub header percpu.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/percpu.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_PERCPU_H__
> +#define __ASM_GENERIC_PERCPU_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <xen/types.h>
> +
> +extern char __per_cpu_start[], __per_cpu_data_end[];
> +extern unsigned long __per_cpu_offset[NR_CPUS];
> +void percpu_init_areas(void);
> +
> +#define per_cpu(var, cpu)  \
> +    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> +
> +#define this_cpu(var) \
> +    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[get_processor_id()]))
> +
> +#define per_cpu_ptr(var, cpu)  \
> +    (*RELOC_HIDE(var, __per_cpu_offset[cpu]))
> +#define this_cpu_ptr(var) \
> +    (*RELOC_HIDE(var, get_processor_id()))
> +
> +#endif
> +
> +#endif /* __ASM_GENERIC_PERCPU_H__ */

This looks okay, just one request: Please use smp_processor_id(). You
may have seen on the Matrix channel that there's the intention to do
away with the get_processor_id() alias that's used in only very few
places.

Jan

Re: [PATCH v1 17/29] xen/asm-generic: introduce stub header percpu.h

[Oleksii]

On Thu, 2023-10-19 at 12:39 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/percpu.h
> > @@ -0,0 +1,35 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_PERCPU_H__
> > +#define __ASM_GENERIC_PERCPU_H__
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#include <xen/types.h>
> > +
> > +extern char __per_cpu_start[], __per_cpu_data_end[];
> > +extern unsigned long __per_cpu_offset[NR_CPUS];
> > +void percpu_init_areas(void);
> > +
> > +#define per_cpu(var, cpu)  \
> > +    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> > +
> > +#define this_cpu(var) \
> > +    (*RELOC_HIDE(&per_cpu__##var,
> > __per_cpu_offset[get_processor_id()]))
> > +
> > +#define per_cpu_ptr(var, cpu)  \
> > +    (*RELOC_HIDE(var, __per_cpu_offset[cpu]))
> > +#define this_cpu_ptr(var) \
> > +    (*RELOC_HIDE(var, get_processor_id()))
> > +
> > +#endif
> > +
> > +#endif /* __ASM_GENERIC_PERCPU_H__ */
> 
> This looks okay, just one request: Please use smp_processor_id(). You
> may have seen on the Matrix channel that there's the intention to do
> away with the get_processor_id() alias that's used in only very few
> places.
Thanks. I'll update the patch.

~ Oleksii

[PATCH v1 18/29] xen/asm-generic: introduce stub header smp.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/smp.h | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 xen/include/asm-generic/smp.h

diff --git a/xen/include/asm-generic/smp.h b/xen/include/asm-generic/smp.h
new file mode 100644
index 0000000000..5d6b7185f1
--- /dev/null
+++ b/xen/include/asm-generic/smp.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_SMP_H
+#define __ASM_GENERIC_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/cpumask.h>
+#include <xen/percpu.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+/*
+ * Do we, for platform reasons, need to actually keep CPUs online when we
+ * would otherwise prefer them to be off?
+ */
+#define park_offline_cpus false
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 18/29] xen/asm-generic: introduce stub header smp.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> The patch introduces header stub necessry for full Xen build.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Assuming you expect RISC-V to get away without its own smp.h, just
one remark:

> --- /dev/null
> +++ b/xen/include/asm-generic/smp.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_SMP_H
> +#define __ASM_GENERIC_SMP_H
> +
> +#ifndef __ASSEMBLY__
> +#include <xen/cpumask.h>
> +#include <xen/percpu.h>
> +#endif

This #endif need moving ...

> +DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
> +DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);

... at least down here, if #includ-ing by assembly files is really
necessary to permit. Preferably the #ifndef would be dropped, though.

Jan

Re: [PATCH v1 18/29] xen/asm-generic: introduce stub header smp.h

[Oleksii]

On Thu, 2023-10-19 at 12:58 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > The patch introduces header stub necessry for full Xen build.
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> Assuming you expect RISC-V to get away without its own smp.h, just
> one remark:
Not really, I've introduced only things necessary for Xen's full build.

It looks like we have a situation as with device.h header ( in this
patch series) . Probably smp.h header should be only in an arch-
specific folder. I'll apply to smp.h the same solution as for device.h
when we get to the same page on it.

Except what I introduced in this patch other functions and macros will
be in smp.h. Such as:

raw_smp_processor_id
smp_processor_id
extern void smp_clear_cpu_maps (void);
extern void smp_init_cpus(void);
extern unsigned int smp_get_max_cpus(void);
void smp_setup_processor_id(unsigned long boot_cpu_id);

/*
 * Mapping between linux logical cpu index and hartid.
 */
extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
#define cpuid_to_hartid_map(cpu) __cpuid_to_hartid_map[cpu]

#define cpu_physical_id(cpu) cpuid_to_hartid_map(cpu)

Mostly all of the header can be generic but again all the mentioned
above functions are used only for RISC-V and ARM. ( probably I missed
something ).

> 
> > --- /dev/null
> > +++ b/xen/include/asm-generic/smp.h
> > @@ -0,0 +1,30 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_SMP_H
> > +#define __ASM_GENERIC_SMP_H
> > +
> > +#ifndef __ASSEMBLY__
> > +#include <xen/cpumask.h>
> > +#include <xen/percpu.h>
> > +#endif
> 
> This #endif need moving ...
> 
> > +DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
> > +DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
> 
> ... at least down here, if #includ-ing by assembly files is really
> necessary to permit. Preferably the #ifndef would be dropped, though.
> 
> Jan

~ Oleksii

[PATCH v1 19/29] xen/asm-generic: introduce stub header hardirq.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/hardirq.h | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 xen/include/asm-generic/hardirq.h

diff --git a/xen/include/asm-generic/hardirq.h b/xen/include/asm-generic/hardirq.h
new file mode 100644
index 0000000000..b4b71a7315
--- /dev/null
+++ b/xen/include/asm-generic/hardirq.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_HARDIRQ_H
+#define __ASM_GENERIC_HARDIRQ_H
+
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_GENERIC_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 19/29] xen/asm-generic: introduce stub header hardirq.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> The patch introduces header stub necessry for full Xen build.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

I agree this one can be generalized from Arm's, but ...

> --- /dev/null
> +++ b/xen/include/asm-generic/hardirq.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_HARDIRQ_H
> +#define __ASM_GENERIC_HARDIRQ_H
> +
> +#include <xen/smp.h>
> +
> +typedef struct {
> +        unsigned long __softirq_pending;
> +        unsigned int __local_irq_count;
> +} __cacheline_aligned irq_cpustat_t;

... where is __cacheline_aligned going to come from without inclusion
of xen/cache.h (as Arm has it)?

Jan

Re: [PATCH v1 19/29] xen/asm-generic: introduce stub header hardirq.h

[Oleksii]

On Thu, 2023-10-19 at 13:04 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > The patch introduces header stub necessry for full Xen build.
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> I agree this one can be generalized from Arm's, but ...
> 
> > --- /dev/null
> > +++ b/xen/include/asm-generic/hardirq.h
> > @@ -0,0 +1,27 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_HARDIRQ_H
> > +#define __ASM_GENERIC_HARDIRQ_H
> > +
> > +#include <xen/smp.h>
> > +
> > +typedef struct {
> > +        unsigned long __softirq_pending;
> > +        unsigned int __local_irq_count;
> > +} __cacheline_aligned irq_cpustat_t;
> 
> ... where is __cacheline_aligned going to come from without inclusion
> of xen/cache.h (as Arm has it)?
xen/cache.h should be added. thanks.

~ Oleksii

[PATCH v1 20/29] xen/asm-generic: introduce stub header div64.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/div64.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 xen/include/asm-generic/div64.h

diff --git a/xen/include/asm-generic/div64.h b/xen/include/asm-generic/div64.h
new file mode 100644
index 0000000000..9f9c20878b
--- /dev/null
+++ b/xen/include/asm-generic/div64.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_DIV64
+#define __ASM_GENERIC_DIV64
+
+#include <xen/types.h>
+
+# define do_div(n,base) ({                                      \
+        uint32_t __base = (base);                               \
+        uint32_t __rem;                                         \
+        __rem = ((uint64_t)(n)) % __base;                       \
+        (n) = ((uint64_t)(n)) / __base;                         \
+        __rem;                                                  \
+ })
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 20/29] xen/asm-generic: introduce stub header div64.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/div64.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_DIV64
> +#define __ASM_GENERIC_DIV64
> +
> +#include <xen/types.h>
> +
> +# define do_div(n,base) ({                                      \
> +        uint32_t __base = (base);                               \
> +        uint32_t __rem;                                         \
> +        __rem = ((uint64_t)(n)) % __base;                       \
> +        (n) = ((uint64_t)(n)) / __base;                         \
> +        __rem;                                                  \
> + })

While I'm fine with having just the BITS_PER_LONG == 64 implementation
here, this then still needs to have the #if retained that Arm has. Only
with that will it then be fine to have a blank between # and define.

There are style issues though: A blank is missing after the comma,
and according to recent agreement leading underscores should not be
used for symbols like the ones here anymore (I also wonder whether
"base" is really a good name for the symbol; "divisor" may be more to
the point). There are also excess parentheses around the two cast
expressions.

Jan

Re: [PATCH v1 20/29] xen/asm-generic: introduce stub header div64.h

[Oleksii]

On Thu, 2023-10-19 at 13:12 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/div64.h
> > @@ -0,0 +1,24 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_DIV64
> > +#define __ASM_GENERIC_DIV64
> > +
> > +#include <xen/types.h>
> > +
> > +# define do_div(n,base) ({                                      \
> > +        uint32_t __base = (base);                               \
> > +        uint32_t __rem;                                         \
> > +        __rem = ((uint64_t)(n)) % __base;                       \
> > +        (n) = ((uint64_t)(n)) / __base;                         \
> > +        __rem;                                                  \
> > + })
> 
> While I'm fine with having just the BITS_PER_LONG == 64
> implementation
> here, this then still needs to have the #if retained that Arm has.
> Only
> with that will it then be fine to have a blank between # and define.
> 
> There are style issues though: A blank is missing after the comma,
> and according to recent agreement leading underscores should not be
> used for symbols like the ones here anymore (I also wonder whether
> "base" is really a good name for the symbol; "divisor" may be more to
> the point). There are also excess parentheses around the two cast
> expressions.
Thanks. I'll take mentioned into account.

~ Oleskii

[PATCH v1 21/29] xen/asm-generic: introduce stub header altp2m.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/altp2m.h | 34 ++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 xen/include/asm-generic/altp2m.h

diff --git a/xen/include/asm-generic/altp2m.h b/xen/include/asm-generic/altp2m.h
new file mode 100644
index 0000000000..e73cc8a04f
--- /dev/null
+++ b/xen/include/asm-generic/altp2m.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_ALTP2M_H
+#define __ASM_GENERIC_ALTP2M_H
+
+#include <xen/bug.h>
+
+struct domain;
+struct vcpu;
+
+/* Alternate p2m on/off per domain */
+static inline bool altp2m_active(const struct domain *d)
+{
+    /* Not implemented on GENERIC. */
+    return false;
+}
+
+/* Alternate p2m VCPU */
+static inline uint16_t altp2m_vcpu_idx(const struct vcpu *v)
+{
+    /* Not implemented on GENERIC, should not be reached. */
+    BUG();
+    return 0;
+}
+
+#endif /* __ASM_GENERIC_ALTP2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 21/29] xen/asm-generic: introduce stub header altp2m.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> The patch introduces header stub necessry for full Xen build.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>  xen/include/asm-generic/altp2m.h | 34 ++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>  create mode 100644 xen/include/asm-generic/altp2m.h

While odd to be needed, this looks largely okay for the moment. Just
one remark:

> --- /dev/null
> +++ b/xen/include/asm-generic/altp2m.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_ALTP2M_H
> +#define __ASM_GENERIC_ALTP2M_H
> +
> +#include <xen/bug.h>
> +
> +struct domain;
> +struct vcpu;
> +
> +/* Alternate p2m on/off per domain */
> +static inline bool altp2m_active(const struct domain *d)
> +{
> +    /* Not implemented on GENERIC. */
> +    return false;
> +}
> +
> +/* Alternate p2m VCPU */
> +static inline uint16_t altp2m_vcpu_idx(const struct vcpu *v)

uint16_t is what x86 wants, but even on Arm it's suspicious. For a
generic header I'd say make it unsigned int, thus also eliminating
the question whether xen/types.h should be included here.

Jan

Re: [PATCH v1 21/29] xen/asm-generic: introduce stub header altp2m.h

[Oleksii]

On Thu, 2023-10-19 at 13:27 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > The patch introduces header stub necessry for full Xen build.
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> >  xen/include/asm-generic/altp2m.h | 34
> > ++++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> >  create mode 100644 xen/include/asm-generic/altp2m.h
> 
> While odd to be needed, this looks largely okay for the moment. Just
> one remark:
> 
> > --- /dev/null
> > +++ b/xen/include/asm-generic/altp2m.h
> > @@ -0,0 +1,34 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_ALTP2M_H
> > +#define __ASM_GENERIC_ALTP2M_H
> > +
> > +#include <xen/bug.h>
> > +
> > +struct domain;
> > +struct vcpu;
> > +
> > +/* Alternate p2m on/off per domain */
> > +static inline bool altp2m_active(const struct domain *d)
> > +{
> > +    /* Not implemented on GENERIC. */
> > +    return false;
> > +}
> > +
> > +/* Alternate p2m VCPU */
> > +static inline uint16_t altp2m_vcpu_idx(const struct vcpu *v)
> 
> uint16_t is what x86 wants, but even on Arm it's suspicious. For a
> generic header I'd say make it unsigned int, thus also eliminating
> the question whether xen/types.h should be included here.

Thanks. I'll make sure to update the patch accordingly.

~ Oleksii

[PATCH v1 22/29] xen/asm-generic: introduce stub header delay.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/delay.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 xen/include/asm-generic/delay.h

diff --git a/xen/include/asm-generic/delay.h b/xen/include/asm-generic/delay.h
new file mode 100644
index 0000000000..1e68c6cacb
--- /dev/null
+++ b/xen/include/asm-generic/delay.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _ASM_GENERIC_DELAY_H
+#define _ASM_GENERIC_DELAY_H
+
+#include <xen/lib.h>
+
+static inline void udelay(unsigned long usecs)
+{
+    BUG();
+}
+
+#endif /* _ASM_GENERIC_DELAY_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 22/29] xen/asm-generic: introduce stub header delay.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> The patch introduces header stub necessry for full Xen build.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>  xen/include/asm-generic/delay.h | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>  create mode 100644 xen/include/asm-generic/delay.h

Besides the implementation below not being acceptable, imo we should do
away with asm/delay.h altogether. x86 can rename __udelay() to udelay(),
and then the declaration can move to xen/delay.h.

Jan

Re: [PATCH v1 22/29] xen/asm-generic: introduce stub header delay.h

[Oleksii]

On Thu, 2023-10-19 at 13:30 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > The patch introduces header stub necessry for full Xen build.
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> >  xen/include/asm-generic/delay.h | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 xen/include/asm-generic/delay.h
> 
> Besides the implementation below not being acceptable, imo we should
> do
> away with asm/delay.h altogether. x86 can rename __udelay() to
> udelay(),
> and then the declaration can move to xen/delay.h.
> 
It makes sense. I'll do that.

~ Oleksii

Re: [PATCH v1 22/29] xen/asm-generic: introduce stub header delay.h

[Oleksii]

Instead of introducing stub header for delay.h it was decided to remove
<asm/delay.h> in a separate patch:
https://lore.kernel.org/xen-devel/3d55bce44bd6ab9973cbe0ea2fc136cc44d35df2.1698759633.git.oleksii.kurochko@gmail.com/T/#u

~ Oleksii

[PATCH v1 23/29] xen/asm-generic: introduce stub header domain.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/domain.h | 53 ++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 xen/include/asm-generic/domain.h

diff --git a/xen/include/asm-generic/domain.h b/xen/include/asm-generic/domain.h
new file mode 100644
index 0000000000..b2d244d121
--- /dev/null
+++ b/xen/include/asm-generic/domain.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_DOMAIN_H__
+#define __ASM_GENERIC_DOMAIN_H__
+
+#include <xen/xmalloc.h>
+#include <public/hvm/params.h>
+
+struct hvm_domain
+{
+    uint64_t              params[HVM_NR_PARAMS];
+};
+
+#define is_domain_direct_mapped(d) ((void)(d), 0)
+
+struct arch_vcpu_io {
+};
+
+struct arch_vcpu {
+};
+
+struct arch_domain {
+    struct hvm_domain hvm;
+};
+
+#include <xen/sched.h>
+
+static inline struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+}
+
+static inline void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
+struct guest_memory_policy {};
+static inline void update_guest_memory_policy(struct vcpu *v,
+                                              struct guest_memory_policy *gmp)
+{}
+
+static inline void arch_vcpu_block(struct vcpu *v) {}
+
+#endif /* __ASM_GENERIC_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

[PATCH v1 24/29] xen/asm-generic: introduce stub header guest_access.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/guest_access.h | 31 ++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 xen/include/asm-generic/guest_access.h

diff --git a/xen/include/asm-generic/guest_access.h b/xen/include/asm-generic/guest_access.h
new file mode 100644
index 0000000000..b865d37f4e
--- /dev/null
+++ b/xen/include/asm-generic/guest_access.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_GUEST_ACCESS_H__
+#define __ASM_GENERIC_GUEST_ACCESS_H__
+
+#include <xen/mm.h>
+
+unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len);
+unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len);
+
+#define __raw_copy_to_guest raw_copy_to_guest
+#define __raw_copy_from_guest raw_copy_from_guest
+
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+struct domain;
+unsigned long copy_to_guest_phys(struct domain *d,
+                                 paddr_t gpa,
+                                 void *buf,
+                                 unsigned int len);
+
+#endif /* __ASM_GENERIC_GUEST_ACCESS_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

[PATCH v1 25/29] xen/asm-generic: introduce stub header irq.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/irq.h | 44 +++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 xen/include/asm-generic/irq.h

diff --git a/xen/include/asm-generic/irq.h b/xen/include/asm-generic/irq.h
new file mode 100644
index 0000000000..5f68cbd10d
--- /dev/null
+++ b/xen/include/asm-generic/irq.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_IRQ_H__
+#define __ASM_GENERIC_IRQ_H__
+
+#include <xen/lib.h>
+#include <xen/device_tree.h>
+#include <public/device_tree_defs.h>
+
+/* TODO */
+#define nr_irqs 0U
+#define nr_static_irqs 0
+#define arch_hwdom_irqs(domid) 0U
+
+#define domain_pirq_to_irq(d, pirq) (pirq)
+
+#define arch_evtchn_bind_pirq(d, pirq) ((void)((d) + (pirq)))
+
+struct arch_pirq {
+};
+
+struct arch_irq_desc {
+    unsigned int type;
+};
+
+static inline void arch_move_irqs(struct vcpu *v)
+{
+    BUG();
+}
+
+static inline int platform_get_irq(const struct dt_device_node *device, int index)
+{
+    BUG();
+}
+
+#endif /* __ASM_GENERIC_IRQ_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 25/29] xen/asm-generic: introduce stub header irq.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/irq.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_IRQ_H__
> +#define __ASM_GENERIC_IRQ_H__
> +
> +#include <xen/lib.h>
> +#include <xen/device_tree.h>
> +#include <public/device_tree_defs.h>

While Julien and I are still discussing this aspect, my view is that DT
things may not appear in generic headers. At least the #include-s here
aren't necessary anyway, afaict.

> +/* TODO */
> +#define nr_irqs 0U
> +#define nr_static_irqs 0

Earlier comments apply (at least) here.

Jan

[PATCH v1 26/29] xen/asm-generic: introduce stub header monitor.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/monitor.h | 64 +++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 xen/include/asm-generic/monitor.h

diff --git a/xen/include/asm-generic/monitor.h b/xen/include/asm-generic/monitor.h
new file mode 100644
index 0000000000..c61fe738a8
--- /dev/null
+++ b/xen/include/asm-generic/monitor.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * include/asm-GENERIC/monitor.h
+ *
+ * Arch-specific monitor_op domctl handler.
+ *
+ * Copyright (c) 2015 Tamas K Lengyel (tamas@tklengyel.com)
+ * Copyright (c) 2016, Bitdefender S.R.L.
+ *
+ */
+
+#ifndef __ASM_GENERIC_MONITOR_H__
+#define __ASM_GENERIC_MONITOR_H__
+
+#include <xen/sched.h>
+#include <public/domctl.h>
+
+static inline
+void arch_monitor_allow_userspace(struct domain *d, bool allow_userspace)
+{
+}
+
+static inline
+int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
+{
+    /* No arch-specific monitor ops on GENERIC. */
+    return -EOPNOTSUPP;
+}
+
+int arch_monitor_domctl_event(struct domain *d,
+                              struct xen_domctl_monitor_op *mop);
+
+static inline
+int arch_monitor_init_domain(struct domain *d)
+{
+    /* No arch-specific domain initialization on GENERIC. */
+    return 0;
+}
+
+static inline
+void arch_monitor_cleanup_domain(struct domain *d)
+{
+    /* No arch-specific domain cleanup on GENERIC. */
+}
+
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+    uint32_t capabilities = 0;
+
+    return capabilities;
+}
+
+#endif /* __ASM_GENERIC_MONITOR_H__ */
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 26/29] xen/asm-generic: introduce stub header monitor.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/monitor.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* SPDX-License-Identifier: GPL-2.0 */

???

> +/*
> + * include/asm-GENERIC/monitor.h
> + *
> + * Arch-specific monitor_op domctl handler.
> + *
> + * Copyright (c) 2015 Tamas K Lengyel (tamas@tklengyel.com)
> + * Copyright (c) 2016, Bitdefender S.R.L.
> + *
> + */
> +
> +#ifndef __ASM_GENERIC_MONITOR_H__
> +#define __ASM_GENERIC_MONITOR_H__
> +
> +#include <xen/sched.h>
> +#include <public/domctl.h>

No need for this, I don't think?

> +static inline
> +void arch_monitor_allow_userspace(struct domain *d, bool allow_userspace)
> +{
> +}
> +
> +static inline
> +int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
> +{
> +    /* No arch-specific monitor ops on GENERIC. */
> +    return -EOPNOTSUPP;
> +}
> +
> +int arch_monitor_domctl_event(struct domain *d,
> +                              struct xen_domctl_monitor_op *mop);
> +
> +static inline
> +int arch_monitor_init_domain(struct domain *d)
> +{
> +    /* No arch-specific domain initialization on GENERIC. */
> +    return 0;
> +}
> +
> +static inline
> +void arch_monitor_cleanup_domain(struct domain *d)
> +{
> +    /* No arch-specific domain cleanup on GENERIC. */
> +}
> +
> +static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
> +{
> +    uint32_t capabilities = 0;
> +
> +    return capabilities;

Just "return 0"?

Jan

Re: [PATCH v1 26/29] xen/asm-generic: introduce stub header monitor.h

[Oleksii]

On Thu, 2023-10-19 at 13:35 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/monitor.h
> > @@ -0,0 +1,64 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/* SPDX-License-Identifier: GPL-2.0 */
> 
> ???
Oh, I'll drop SPDX-License-Identifier: GPL-2.0.
> 
> > +/*
> > + * include/asm-GENERIC/monitor.h
> > + *
> > + * Arch-specific monitor_op domctl handler.
> > + *
> > + * Copyright (c) 2015 Tamas K Lengyel (tamas@tklengyel.com)
> > + * Copyright (c) 2016, Bitdefender S.R.L.
> > + *
> > + */
> > +
> > +#ifndef __ASM_GENERIC_MONITOR_H__
> > +#define __ASM_GENERIC_MONITOR_H__
> > +
> > +#include <xen/sched.h>
> > +#include <public/domctl.h>
> 
> No need for this, I don't think?
Yes, I'll drop that too.
> 
> > +static inline
> > +void arch_monitor_allow_userspace(struct domain *d, bool
> > allow_userspace)
> > +{
> > +}
> > +
> > +static inline
> > +int arch_monitor_domctl_op(struct domain *d, struct
> > xen_domctl_monitor_op *mop)
> > +{
> > +    /* No arch-specific monitor ops on GENERIC. */
> > +    return -EOPNOTSUPP;
> > +}
> > +
> > +int arch_monitor_domctl_event(struct domain *d,
> > +                              struct xen_domctl_monitor_op *mop);
> > +
> > +static inline
> > +int arch_monitor_init_domain(struct domain *d)
> > +{
> > +    /* No arch-specific domain initialization on GENERIC. */
> > +    return 0;
> > +}
> > +
> > +static inline
> > +void arch_monitor_cleanup_domain(struct domain *d)
> > +{
> > +    /* No arch-specific domain cleanup on GENERIC. */
> > +}
> > +
> > +static inline uint32_t arch_monitor_get_capabilities(struct domain
> > *d)
> > +{
> > +    uint32_t capabilities = 0;
> > +
> > +    return capabilities;
> 
> Just "return 0"?
Thanks. I'll update that part.


~ Oleksii

[PATCH v1 27/29] xen/asm-generic: introduce stub header numa.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/numa.h | 35 ++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 xen/include/asm-generic/numa.h

diff --git a/xen/include/asm-generic/numa.h b/xen/include/asm-generic/numa.h
new file mode 100644
index 0000000000..028f7b3638
--- /dev/null
+++ b/xen/include/asm-generic/numa.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARCH_GENERIC_NUMA_H
+#define __ARCH_GENERIC_NUMA_H
+
+#include <xen/mm.h>
+
+typedef u8 nodeid_t;
+
+/* Fake one node for now. See also node_online_map. */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)   (cpu_online_map)
+
+extern mfn_t first_valid_mfn;
+
+#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn))
+#define node_start_pfn(nid) (mfn_x(first_valid_mfn))
+#define __node_distance(a, b) (20)
+
+static inline unsigned int arch_get_dma_bitsize(void)
+{
+    return 32;
+}
+
+#define arch_want_default_dmazone() (false)
+
+#endif /* __ARCH_GENERIC_NUMA_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 27/29] xen/asm-generic: introduce stub header numa.h

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/numa.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ARCH_GENERIC_NUMA_H
> +#define __ARCH_GENERIC_NUMA_H
> +
> +#include <xen/mm.h>
> +
> +typedef u8 nodeid_t;

If an 8-bit quantity, then uint8_t please.

> +/* Fake one node for now. See also node_online_map. */
> +#define cpu_to_node(cpu) 0
> +#define node_to_cpumask(node)   (cpu_online_map)

Looks like this really is fake NUMA then, with just a single node. That's
certainly in need of expressing in a comment.

> +extern mfn_t first_valid_mfn;
> +
> +#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn))
> +#define node_start_pfn(nid) (mfn_x(first_valid_mfn))
> +#define __node_distance(a, b) (20)

This also needs commenting, even if it ended up being "arbitrary".

> +static inline unsigned int arch_get_dma_bitsize(void)
> +{
> +    return 32;

Same here.

Jan

[PATCH v1 28/29] xen/asm-generic: introduce stub header p2m.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/p2m.h | 115 ++++++++++++++++++++++++++++++++++
 1 file changed, 115 insertions(+)
 create mode 100644 xen/include/asm-generic/p2m.h

diff --git a/xen/include/asm-generic/p2m.h b/xen/include/asm-generic/p2m.h
new file mode 100644
index 0000000000..554fd46608
--- /dev/null
+++ b/xen/include/asm-generic/p2m.h
@@ -0,0 +1,115 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_P2M_H__
+#define __ASM_GENERIC_P2M_H__
+
+#include <asm/page-bits.h>
+
+#define paddr_bits PADDR_BITS
+
+/*
+ * List of possible type for each page in the p2m entry.
+ * The number of available bit per page in the pte for this purpose is 4 bits.
+ * So it's possible to only have 16 fields. If we run out of value in the
+ * future, it's possible to use higher value for pseudo-type and don't store
+ * them in the p2m entry.
+ */
+typedef enum {
+    p2m_invalid = 0,    /* Nothing mapped here */
+    p2m_ram_rw,         /* Normal read/write guest RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */
+    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
+    p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area non-cacheable */
+    p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
+    p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
+    p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */
+    p2m_grant_map_rw,   /* Read/write grant mapping */
+    p2m_grant_map_ro,   /* Read-only grant mapping */
+    /* The types below are only used to decide the page attribute in the P2M */
+    p2m_iommu_map_rw,   /* Read/write iommu mapping */
+    p2m_iommu_map_ro,   /* Read-only iommu mapping */
+    p2m_max_real_type,  /* Types after this won't be store in the p2m */
+} p2m_type_t;
+
+#include <xen/p2m-common.h>
+
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    BUG();
+    return 1;
+}
+
+/* Look up a GFN and take a reference count on the backing page. */
+typedef unsigned int p2m_query_t;
+#define P2M_ALLOC    (1u<<0)   /* Populate PoD and paged-out entries */
+#define P2M_UNSHARE  (1u<<1)   /* Break CoW sharing */
+
+static inline struct page_info *get_page_from_gfn(
+    struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
+{
+    BUG();
+    return NULL;
+}
+
+static inline void memory_type_changed(struct domain *d)
+{
+    BUG();
+}
+
+
+static inline int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                                        unsigned int order)
+{
+    BUG();
+    return 1;
+}
+
+static inline int guest_physmap_add_entry(struct domain *d,
+                            gfn_t gfn,
+                            mfn_t mfn,
+                            unsigned long page_order,
+                            p2m_type_t t)
+{
+    BUG();
+    return 1;
+}
+
+/* Untyped version for RAM only, for compatibility */
+static inline int __must_check
+guest_physmap_add_page(struct domain *d, gfn_t gfn, mfn_t mfn,
+                       unsigned int page_order)
+{
+    return guest_physmap_add_entry(d, gfn, mfn, page_order, p2m_ram_rw);
+}
+
+static inline mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
+{
+    BUG();
+    return _mfn(0);
+}
+
+static inline bool arch_acquire_resource_check(struct domain *d)
+{
+    /*
+     * The reference counting of foreign entries in set_foreign_p2m_entry()
+     * is supported on GENERIC.
+     */
+    return true;
+}
+
+static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
+{
+    /* Not supported on GENERIC. */
+}
+
+#endif /* __ASM_GENERIC_P2M_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

[PATCH v1 29/29] xen/asm-generic: introduce stub header softirq.h

[Oleksii Kurochko]

The patch introduces header stub necessry for full Xen build.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/include/asm-generic/softirq.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 xen/include/asm-generic/softirq.h

diff --git a/xen/include/asm-generic/softirq.h b/xen/include/asm-generic/softirq.h
new file mode 100644
index 0000000000..83be855e50
--- /dev/null
+++ b/xen/include/asm-generic/softirq.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_SOFTIRQ_H__
+#define __ASM_GENERIC_SOFTIRQ_H__
+
+#define NR_ARCH_SOFTIRQS       0
+
+#define arch_skip_send_event_check(cpu) 0
+
+#endif /* __ASM_GENERIC_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.41.0

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Jan Beulich]

On 14.09.2023 16:56, Oleksii Kurochko wrote:
> Based on two patch series [1] and [2], the idea of which is to provide minimal
> amount of things for a complete Xen build, a large amount of headers are the same
> or almost the same, so it makes sense to move them to asm-generic.
> 
> Also, providing such stub headers should help future architectures to add
> a full Xen build.
> 
> [1] https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
> [2] https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
> 
> Oleksii Kurochko (29):
>   xen/asm-generic: introduce stub header spinlock.h

At the example of this, personally I think this goes too far. Headers in
asm-generic should be for the case where an arch elects to not implement
certain functionality. Clearly spinlocks are required uniformly.

Jan

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Oleksii]

On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
> On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > Based on two patch series [1] and [2], the idea of which is to
> > provide minimal
> > amount of things for a complete Xen build, a large amount of
> > headers are the same
> > or almost the same, so it makes sense to move them to asm-generic.
> > 
> > Also, providing such stub headers should help future architectures
> > to add
> > a full Xen build.
> > 
> > [1]
> > https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
> > [2]
> > https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
> > 
> > Oleksii Kurochko (29):
> >   xen/asm-generic: introduce stub header spinlock.h
> 
> At the example of this, personally I think this goes too far. Headers
> in
> asm-generic should be for the case where an arch elects to not
> implement
> certain functionality. Clearly spinlocks are required uniformly.
It makes sense. Then I will back to the option [2] where I introduced
all this headers as part of RISC-V architecture. 

~ Oleksii

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Oleksii]

On Mon, 2023-09-18 at 11:51 +0300, Oleksii wrote:
> On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
> > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > Based on two patch series [1] and [2], the idea of which is to
> > > provide minimal
> > > amount of things for a complete Xen build, a large amount of
> > > headers are the same
> > > or almost the same, so it makes sense to move them to asm-
> > > generic.
> > > 
> > > Also, providing such stub headers should help future
> > > architectures
> > > to add
> > > a full Xen build.
> > > 
> > > [1]
> > > https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
> > > [2]
> > > https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
> > > 
> > > Oleksii Kurochko (29):
> > >   xen/asm-generic: introduce stub header spinlock.h
> > 
> > At the example of this, personally I think this goes too far.
> > Headers
> > in
> > asm-generic should be for the case where an arch elects to not
> > implement
> > certain functionality. Clearly spinlocks are required uniformly.
> It makes sense. Then I will back to the option [2] where I introduced
> all this headers as part of RISC-V architecture.
And I will review the current patch series probably it is still can be
something moved to asm-generic.

> 
> ~ Oleksii

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Jan Beulich]

On 18.09.2023 10:51, Oleksii wrote:
> On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>> Based on two patch series [1] and [2], the idea of which is to
>>> provide minimal
>>> amount of things for a complete Xen build, a large amount of
>>> headers are the same
>>> or almost the same, so it makes sense to move them to asm-generic.
>>>
>>> Also, providing such stub headers should help future architectures
>>> to add
>>> a full Xen build.
>>>
>>> [1]
>>> https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
>>> [2]
>>> https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
>>>
>>> Oleksii Kurochko (29):
>>>   xen/asm-generic: introduce stub header spinlock.h
>>
>> At the example of this, personally I think this goes too far. Headers
>> in
>> asm-generic should be for the case where an arch elects to not
>> implement
>> certain functionality. Clearly spinlocks are required uniformly.
> It makes sense. Then I will back to the option [2] where I introduced
> all this headers as part of RISC-V architecture. 

You did see though that in a reply to my own mail I said I take back the
comment, at least as far as this header (and perhaps several others) are
concerned.

Jan

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Julien Grall]

Hi Jan,

On 18/09/2023 10:29, Jan Beulich wrote:
> On 18.09.2023 10:51, Oleksii wrote:
>> On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>> Based on two patch series [1] and [2], the idea of which is to
>>>> provide minimal
>>>> amount of things for a complete Xen build, a large amount of
>>>> headers are the same
>>>> or almost the same, so it makes sense to move them to asm-generic.
>>>>
>>>> Also, providing such stub headers should help future architectures
>>>> to add
>>>> a full Xen build.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
>>>> [2]
>>>> https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
>>>>
>>>> Oleksii Kurochko (29):
>>>>    xen/asm-generic: introduce stub header spinlock.h
>>>
>>> At the example of this, personally I think this goes too far. Headers
>>> in
>>> asm-generic should be for the case where an arch elects to not
>>> implement
>>> certain functionality. Clearly spinlocks are required uniformly.
>> It makes sense. Then I will back to the option [2] where I introduced
>> all this headers as part of RISC-V architecture.
> 
> You did see though that in a reply to my own mail I said I take back the
> comment,

I can't find a reply to our own mail in my inbox. Do you have a message-id?

? at least as far as this header (and perhaps several others) are
> concerned.

Do you have a list where you think they should be kept? Or are you 
planning to answer to all you disagree/agree one by one?

Cheers,

-- 
Julien Grall

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Jan Beulich]

On 18.09.2023 11:32, Julien Grall wrote:
> Hi Jan,
> 
> On 18/09/2023 10:29, Jan Beulich wrote:
>> On 18.09.2023 10:51, Oleksii wrote:
>>> On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>> Based on two patch series [1] and [2], the idea of which is to
>>>>> provide minimal
>>>>> amount of things for a complete Xen build, a large amount of
>>>>> headers are the same
>>>>> or almost the same, so it makes sense to move them to asm-generic.
>>>>>
>>>>> Also, providing such stub headers should help future architectures
>>>>> to add
>>>>> a full Xen build.
>>>>>
>>>>> [1]
>>>>> https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
>>>>> [2]
>>>>> https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
>>>>>
>>>>> Oleksii Kurochko (29):
>>>>>    xen/asm-generic: introduce stub header spinlock.h
>>>>
>>>> At the example of this, personally I think this goes too far. Headers
>>>> in
>>>> asm-generic should be for the case where an arch elects to not
>>>> implement
>>>> certain functionality. Clearly spinlocks are required uniformly.
>>> It makes sense. Then I will back to the option [2] where I introduced
>>> all this headers as part of RISC-V architecture.
>>
>> You did see though that in a reply to my own mail I said I take back the
>> comment,
> 
> I can't find a reply to our own mail in my inbox. Do you have a message-id?

Oh, sorry, I said so in reply to 01/29.

> ? at least as far as this header (and perhaps several others) are
>> concerned.
> 
> Do you have a list where you think they should be kept? Or are you 
> planning to answer to all you disagree/agree one by one?

I think this can only be one-by-one.

Jan

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Oleksii]

On Mon, 2023-09-18 at 11:29 +0200, Jan Beulich wrote:
> On 18.09.2023 10:51, Oleksii wrote:
> > On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
> > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > Based on two patch series [1] and [2], the idea of which is to
> > > > provide minimal
> > > > amount of things for a complete Xen build, a large amount of
> > > > headers are the same
> > > > or almost the same, so it makes sense to move them to asm-
> > > > generic.
> > > > 
> > > > Also, providing such stub headers should help future
> > > > architectures
> > > > to add
> > > > a full Xen build.
> > > > 
> > > > [1]
> > > > https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
> > > > [2]
> > > > https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
> > > > 
> > > > Oleksii Kurochko (29):
> > > >   xen/asm-generic: introduce stub header spinlock.h
> > > 
> > > At the example of this, personally I think this goes too far.
> > > Headers
> > > in
> > > asm-generic should be for the case where an arch elects to not
> > > implement
> > > certain functionality. Clearly spinlocks are required uniformly.
> > It makes sense. Then I will back to the option [2] where I
> > introduced
> > all this headers as part of RISC-V architecture. 
> 
> You did see though that in a reply to my own mail I said I take back
> the
> comment, at least as far as this header (and perhaps several others)
> are
> concerned.
> 
I missed that comment on the patch about spinlock.

Well, then, I don't fully understand the criteria.

What about empty headers or temporary empty headers?

For example, asm/xenoprof.h is empty for all arches except x86, so it
is a good candidate for asm-generic.
But asm/grant_table.h is empty for PPC and RISC-V for now but won't be
empty in the future. Does it make sense to put them to asm-generic? The
only benefit I see is that in future architecture if they follow the
same way of adding support for the arch to Xen, they will face the same
issue: building full Xen requires this empty header.

So, should I wait for some time on other patches of the patch series?

~ Oleksii

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Jan Beulich]

On 18.09.2023 14:05, Oleksii wrote:
> On Mon, 2023-09-18 at 11:29 +0200, Jan Beulich wrote:
>> On 18.09.2023 10:51, Oleksii wrote:
>>> On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
>>>> On 14.09.2023 16:56, Oleksii Kurochko wrote:
>>>>> Based on two patch series [1] and [2], the idea of which is to
>>>>> provide minimal
>>>>> amount of things for a complete Xen build, a large amount of
>>>>> headers are the same
>>>>> or almost the same, so it makes sense to move them to asm-
>>>>> generic.
>>>>>
>>>>> Also, providing such stub headers should help future
>>>>> architectures
>>>>> to add
>>>>> a full Xen build.
>>>>>
>>>>> [1]
>>>>> https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
>>>>> [2]
>>>>> https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
>>>>>
>>>>> Oleksii Kurochko (29):
>>>>>   xen/asm-generic: introduce stub header spinlock.h
>>>>
>>>> At the example of this, personally I think this goes too far.
>>>> Headers
>>>> in
>>>> asm-generic should be for the case where an arch elects to not
>>>> implement
>>>> certain functionality. Clearly spinlocks are required uniformly.
>>> It makes sense. Then I will back to the option [2] where I
>>> introduced
>>> all this headers as part of RISC-V architecture. 
>>
>> You did see though that in a reply to my own mail I said I take back
>> the
>> comment, at least as far as this header (and perhaps several others)
>> are
>> concerned.
>>
> I missed that comment on the patch about spinlock.
> 
> Well, then, I don't fully understand the criteria.
> 
> What about empty headers or temporary empty headers?
> 
> For example, asm/xenoprof.h is empty for all arches except x86, so it
> is a good candidate for asm-generic.

That's an example where I think it is wrong (or at least unnecessary) for
the xen/ header to include the asm/ one irrespective of the controlling
CONFIG_* setting. From what I can tell common code would build fine with
the #include moved; x86 code may require an adjustment or two. IOW this
is a case where I think preferably presence of an arch header was
required only when XENOPROF can actually be yet to y in Kconfig.

> But asm/grant_table.h is empty for PPC and RISC-V for now but won't be
> empty in the future. Does it make sense to put them to asm-generic? The
> only benefit I see is that in future architecture if they follow the
> same way of adding support for the arch to Xen, they will face the same
> issue: building full Xen requires this empty header.

Here I can see different ways of looking at it. Personally I'd prefer
stub headers to be used only if, for the foreseeable future, they are
intended to remain in use. grant_table.h pretty clearly doesn't fall in
this category. (You may want to peek at what's being done on the PPC
side. Nevertheless some of what's done there could likely benefit from
what you're doing here.)

> So, should I wait for some time on other patches of the patch series?

Well, afaic I'd prefer if I got a chance to look over at least some more
of the patches in this series. But you're of course free to submit a v2
at any time.

Jan

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Oleksii]

On Mon, 2023-09-18 at 14:38 +0200, Jan Beulich wrote:
> On 18.09.2023 14:05, Oleksii wrote:
> > On Mon, 2023-09-18 at 11:29 +0200, Jan Beulich wrote:
> > > On 18.09.2023 10:51, Oleksii wrote:
> > > > On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
> > > > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > > > Based on two patch series [1] and [2], the idea of which is
> > > > > > to
> > > > > > provide minimal
> > > > > > amount of things for a complete Xen build, a large amount
> > > > > > of
> > > > > > headers are the same
> > > > > > or almost the same, so it makes sense to move them to asm-
> > > > > > generic.
> > > > > > 
> > > > > > Also, providing such stub headers should help future
> > > > > > architectures
> > > > > > to add
> > > > > > a full Xen build.
> > > > > > 
> > > > > > [1]
> > > > > > https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
> > > > > > [2]
> > > > > > https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
> > > > > > 
> > > > > > Oleksii Kurochko (29):
> > > > > >   xen/asm-generic: introduce stub header spinlock.h
> > > > > 
> > > > > At the example of this, personally I think this goes too far.
> > > > > Headers
> > > > > in
> > > > > asm-generic should be for the case where an arch elects to
> > > > > not
> > > > > implement
> > > > > certain functionality. Clearly spinlocks are required
> > > > > uniformly.
> > > > It makes sense. Then I will back to the option [2] where I
> > > > introduced
> > > > all this headers as part of RISC-V architecture. 
> > > 
> > > You did see though that in a reply to my own mail I said I take
> > > back
> > > the
> > > comment, at least as far as this header (and perhaps several
> > > others)
> > > are
> > > concerned.
> > > 
> > I missed that comment on the patch about spinlock.
> > 
> > Well, then, I don't fully understand the criteria.
> > 
> > What about empty headers or temporary empty headers?
> > 
> > For example, asm/xenoprof.h is empty for all arches except x86, so
> > it
> > is a good candidate for asm-generic.
> 
> That's an example where I think it is wrong (or at least unnecessary)
> for
> the xen/ header to include the asm/ one irrespective of the
> controlling
> CONFIG_* setting. From what I can tell common code would build fine
> with
> the #include moved; x86 code may require an adjustment or two. IOW
> this
> is a case where I think preferably presence of an arch header was
> required only when XENOPROF can actually be yet to y in Kconfig.
> 
> > But asm/grant_table.h is empty for PPC and RISC-V for now but won't
> > be
> > empty in the future. Does it make sense to put them to asm-generic?
> > The
> > only benefit I see is that in future architecture if they follow
> > the
> > same way of adding support for the arch to Xen, they will face the
> > same
> > issue: building full Xen requires this empty header.
> 
> Here I can see different ways of looking at it. Personally I'd prefer
> stub headers to be used only if, for the foreseeable future, they are
> intended to remain in use. grant_table.h pretty clearly doesn't fall
> in
> this category. (You may want to peek at what's being done on the PPC
> side. Nevertheless some of what's done there could likely benefit
> from
> what you're doing here.)
> 
> > So, should I wait for some time on other patches of the patch
> > series?
> 
> Well, afaic I'd prefer if I got a chance to look over at least some
> more
> of the patches in this series. But you're of course free to submit a
> v2
> at any time.
I think that it will be better to wait for some time not to produce
unnecessary patches.

~ Oleksii

Re: [PATCH v1 00/29] Introduce stub headers necessary for full Xen build

[Oleksii]

On Fri, 2023-09-22 at 09:00 +0300, Oleksii wrote:
> On Mon, 2023-09-18 at 14:38 +0200, Jan Beulich wrote:
> > On 18.09.2023 14:05, Oleksii wrote:
> > > On Mon, 2023-09-18 at 11:29 +0200, Jan Beulich wrote:
> > > > On 18.09.2023 10:51, Oleksii wrote:
> > > > > On Thu, 2023-09-14 at 17:08 +0200, Jan Beulich wrote:
> > > > > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > > > > Based on two patch series [1] and [2], the idea of which
> > > > > > > is
> > > > > > > to
> > > > > > > provide minimal
> > > > > > > amount of things for a complete Xen build, a large amount
> > > > > > > of
> > > > > > > headers are the same
> > > > > > > or almost the same, so it makes sense to move them to
> > > > > > > asm-
> > > > > > > generic.
> > > > > > > 
> > > > > > > Also, providing such stub headers should help future
> > > > > > > architectures
> > > > > > > to add
> > > > > > > a full Xen build.
> > > > > > > 
> > > > > > > [1]
> > > > > > > https://lore.kernel.org/xen-devel/cover.1694543103.git.sanastasio@raptorengineering.com/
> > > > > > > [2]
> > > > > > > https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kurochko@gmail.com/
> > > > > > > 
> > > > > > > Oleksii Kurochko (29):
> > > > > > >   xen/asm-generic: introduce stub header spinlock.h
> > > > > > 
> > > > > > At the example of this, personally I think this goes too
> > > > > > far.
> > > > > > Headers
> > > > > > in
> > > > > > asm-generic should be for the case where an arch elects to
> > > > > > not
> > > > > > implement
> > > > > > certain functionality. Clearly spinlocks are required
> > > > > > uniformly.
> > > > > It makes sense. Then I will back to the option [2] where I
> > > > > introduced
> > > > > all this headers as part of RISC-V architecture. 
> > > > 
> > > > You did see though that in a reply to my own mail I said I take
> > > > back
> > > > the
> > > > comment, at least as far as this header (and perhaps several
> > > > others)
> > > > are
> > > > concerned.
> > > > 
> > > I missed that comment on the patch about spinlock.
> > > 
> > > Well, then, I don't fully understand the criteria.
> > > 
> > > What about empty headers or temporary empty headers?
> > > 
> > > For example, asm/xenoprof.h is empty for all arches except x86,
> > > so
> > > it
> > > is a good candidate for asm-generic.
> > 
> > That's an example where I think it is wrong (or at least
> > unnecessary)
> > for
> > the xen/ header to include the asm/ one irrespective of the
> > controlling
> > CONFIG_* setting. From what I can tell common code would build fine
> > with
> > the #include moved; x86 code may require an adjustment or two. IOW
> > this
> > is a case where I think preferably presence of an arch header was
> > required only when XENOPROF can actually be yet to y in Kconfig.
> > 
> > > But asm/grant_table.h is empty for PPC and RISC-V for now but
> > > won't
> > > be
> > > empty in the future. Does it make sense to put them to asm-
> > > generic?
> > > The
> > > only benefit I see is that in future architecture if they follow
> > > the
> > > same way of adding support for the arch to Xen, they will face
> > > the
> > > same
> > > issue: building full Xen requires this empty header.
> > 
> > Here I can see different ways of looking at it. Personally I'd
> > prefer
> > stub headers to be used only if, for the foreseeable future, they
> > are
> > intended to remain in use. grant_table.h pretty clearly doesn't
> > fall
> > in
> > this category. (You may want to peek at what's being done on the
> > PPC
> > side. Nevertheless some of what's done there could likely benefit
> > from
> > what you're doing here.)
> > 
> > > So, should I wait for some time on other patches of the patch
> > > series?
> > 
> > Well, afaic I'd prefer if I got a chance to look over at least some
> > more
> > of the patches in this series. But you're of course free to submit
> > a
> > v2
> > at any time.
> I think that it will be better to wait for some time not to produce
> unnecessary patches.
Hmm... but my gitlab CI told me that there is an issue with riscv64
build I'll double-check.

~ Oleksii