On 09/09/2025 12:57, Juergen Gross wrote:

On 09.09.25 11:07, David Hildenbrand wrote:

quoted

On 08.09.25 09:39, Kevin Brodsky wrote:

quoted

[...]

Note: it is difficult to provide a default definition of
lazy_mmu_state_t for architectures implementing lazy_mmu, because
that definition would need to be available in
arch/x86/include/asm/paravirt_types.h and adding a new generic
  #include there is very tricky due to the existing header soup.

Yeah, I was wondering about exactly that.

In particular because LAZY_MMU_DEFAULT etc resides somewehere
compeltely different.

Which raises the question: is using a new type really of any benefit
here?

Can't we just use an "enum lazy_mmu_state" and call it a day?

The comment about the "header soup" made me look into this problem:

It seems some of the "#include <asm/paravirt.h>" instances in the code
base can just be dropped.

For the remaining cases I'd like to suggest a reorg of the related
headers:
Instead of having the non-paravirt definition in one header and the
paravirt
ones in paravirt.h, maybe it would be better to have only the paravirt
generic definitions in paravirt.h and the specific functions in the
header
defining the non-paravirt variant. This would probably resolve the
problem
with the "soup", as paravirt.h wouldn't rely on so many other headers.

I'm just preparing a patch doing the removal of the not needed
includes, but
I'd be willing to address the disentangling as noted above.

Thoughts?

I don't know enough about these headers to express an informed opinion,
but it does sound like a useful cleanup. Do you think it would allow
<asm/paravirt_types.h> to include <linux/mm_types.h>? This is what we
would need to have a generic definition of lazy_mmu_state_t (which could
be overridden by defining some __HAVE_ARCH macro in <asm/mmu.h>).

- Kevin