Re: [PATCH v1 2/2] s390/kvm: Move bitfields for dat tables

[Heiko Carstens <hca@linux.ibm.com>]

On Thu, Jul 11, 2024 at 06:23:48PM +0200, Claudio Imbrenda wrote:
> On Thu, 11 Jul 2024 17:16:23 +0200
> Alexander Gordeev <agordeev@linux.ibm.com> wrote:
> > Hi Claudio,
> > 
> > > Once in a separate header, the structs become available everywhere. One
> > > possible usecase is to merge them in the s390 
> > > definitions, which is left as an exercise for the reader.  
> > 
> > Is my understanding correct that you potentially see page_table_entry::val /
> > region?_table_entry.*::val / segment_table_entry.* merged with pte_t::pte /
> > p?d_t::p?d?
> 
> that depends on how you want to do the merge
> 
> you could do:
> 
> typedef union {
> 	unsigned long pte;
> 	union page_table_entry hw;
> 	union page_table_entry_softbits sw;
> } pte_t;
> 
> then you would have pte_t::pte and pte_t::hw::val; unfortunately it's
> not possible to anonymously merge a named type.. 
> 
> this would be great but can't be done*:
> 
> typedef union {
> 	unsigned long pte;
> 	union page_table_entry;
> } pte_t;
> 
> [*] gcc actually supports it with an additional feature switch, but
> it's not standard C and I seriously doubt we should even think about
> doing it
> 
> another possibility is a plain
> 
> typedef union page_table_entry pte_t;
> 
> and then fix pte_val() and similar, but then you won't have the
> softbits.
> 
> 
> in the end, it's up to you how you want to merge them. I will
> have my own unions that I will use only inside KVM, that's enough for
> me.

We discussed this, and I really don't think we want this for the software
defined bits. In general I do like the idea of having bit fields and let
gcc do the decoding. But we have so many masks we use every for ptes and
friends that a single assignment won't work in most cases. So we eiter have
to do several assignments (which sometimes is a no-go when block concurrent
updates are required), or we have to stay with using both the existing
defines plus the new unions - which makes things even more complicated.

There might be uses cases where the hardware structures are also useful for
s390 core code, but I don't think we should go the route outlined above.