| Message ID | 0fec827f-bb0b-4ea1-7757-9c27e9138be7@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | further population of xen/lib/ | expand |
Hi Jan, On 01/04/2021 11:19, Jan Beulich wrote: > These were built for 32-bit architectures only (the same code could, > with some tweaking, sensibly be used to provide TI-mode helpers on > 64-bit arch-es) - retain this property, while still avoiding to have > a CU without any contents at all. For this, Arm's CONFIG_64BIT gets > generalized. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > xen/arch/Kconfig | 2 ++ > xen/arch/arm/Kconfig | 12 +++--------- > xen/arch/x86/Kconfig | 1 + > xen/common/Makefile | 1 - > xen/lib/Makefile | 4 ++++ > xen/{common/lib.c => lib/divmod.c} | 2 -- > 6 files changed, 10 insertions(+), 12 deletions(-) > rename xen/{common/lib.c => lib/divmod.c} (99%) > > diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig > index d144d4c8d3ee..f16eb0df43af 100644 > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -1,3 +1,5 @@ > +config 64BIT > + bool > > config NR_CPUS > int "Maximum number of CPUs" > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 330bbf6232d4..ecfa6822e4d3 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -1,17 +1,11 @@ > -config 64BIT > - bool > - default "$(ARCH)" != "arm32" > - help > - Say yes to build a 64-bit Xen > - Say no to build a 32-bit Xen > - > config ARM_32 > def_bool y > - depends on !64BIT > + depends on "$(ARCH)" = "arm32" > > config ARM_64 > def_bool y > - depends on 64BIT > + depends on !ARM_32 > + select 64BIT > select HAS_FAST_MULTIPLY > > config ARM > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index f79e6634db3f..4d6911ffa467 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -1,5 +1,6 @@ > config X86_64 > def_bool y > + select 64BIT > > config X86 > def_bool y > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 71c1d466bd8f..e2a7e62d14bf 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -21,7 +21,6 @@ obj-y += kernel.o > obj-y += keyhandler.o > obj-$(CONFIG_KEXEC) += kexec.o > obj-$(CONFIG_KEXEC) += kimage.o > -obj-y += lib.o > obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o > obj-$(CONFIG_MEM_ACCESS) += mem_access.o > obj-y += memory.o > diff --git a/xen/lib/Makefile b/xen/lib/Makefile > index 0b274583ef0b..a5dc1442a422 100644 > --- a/xen/lib/Makefile > +++ b/xen/lib/Makefile > @@ -10,3 +10,7 @@ lib-y += rbtree.o > lib-y += sort.o > lib-$(CONFIG_X86) += xxhash32.o > lib-$(CONFIG_X86) += xxhash64.o > + > +lib32-y := divmod.o > +lib32-$(CONFIG_64BIT) := > +lib-y += $(lib32-y) > diff --git a/xen/common/lib.c b/xen/lib/divmod.c > similarity index 99% > rename from xen/common/lib.c > rename to xen/lib/divmod.c > index 5b8f49153dad..0be6ccc70096 100644 > --- a/xen/common/lib.c > +++ b/xen/lib/divmod.c > @@ -40,7 +40,6 @@ > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE. > */ > -#if BITS_PER_LONG == 32 In theory BITS_PER_LONG == 32 is not quite the same as 32-bit arch. Can you clarify whether this code is necessary on 64-bit arch where long is only 32-bit. Cheers?
On 01.04.2021 16:56, Julien Grall wrote: > On 01/04/2021 11:19, Jan Beulich wrote: >> --- a/xen/common/lib.c >> +++ b/xen/lib/divmod.c >> @@ -40,7 +40,6 @@ >> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF >> * SUCH DAMAGE. >> */ >> -#if BITS_PER_LONG == 32 > > In theory BITS_PER_LONG == 32 is not quite the same as 32-bit arch. Can > you clarify whether this code is necessary on 64-bit arch where long is > only 32-bit. Likely the compiler can get away without invoking these helpers, so the code would remain unused. I'm uncertain whether CONFIG_64BIT ought to be set for such an architecture, as we assume sizeof(long) == sizeof(void*), and hence pointers would then need to be 32-bit as well there. Jan
Hi Jan, On 01/04/2021 16:23, Jan Beulich wrote: > On 01.04.2021 16:56, Julien Grall wrote: >> On 01/04/2021 11:19, Jan Beulich wrote: >>> --- a/xen/common/lib.c >>> +++ b/xen/lib/divmod.c >>> @@ -40,7 +40,6 @@ >>> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF >>> * SUCH DAMAGE. >>> */ >>> -#if BITS_PER_LONG == 32 >> >> In theory BITS_PER_LONG == 32 is not quite the same as 32-bit arch. Can >> you clarify whether this code is necessary on 64-bit arch where long is >> only 32-bit. > > Likely the compiler can get away without invoking these helpers, so > the code would remain unused. I'm uncertain whether CONFIG_64BIT > ought to be set for such an architecture, as we assume sizeof(long) > == sizeof(void*), and hence pointers would then need to be 32-bit > as well there. This is a fair point. Would you mind to add a sentence explaining that in the commit message? With that: Acked-by: Julien Grall <jgrall@amazon.com> Cheers,
On 06.04.2021 21:34, Julien Grall wrote: > Hi Jan, > > On 01/04/2021 16:23, Jan Beulich wrote: >> On 01.04.2021 16:56, Julien Grall wrote: >>> On 01/04/2021 11:19, Jan Beulich wrote: >>>> --- a/xen/common/lib.c >>>> +++ b/xen/lib/divmod.c >>>> @@ -40,7 +40,6 @@ >>>> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF >>>> * SUCH DAMAGE. >>>> */ >>>> -#if BITS_PER_LONG == 32 >>> >>> In theory BITS_PER_LONG == 32 is not quite the same as 32-bit arch. Can >>> you clarify whether this code is necessary on 64-bit arch where long is >>> only 32-bit. >> >> Likely the compiler can get away without invoking these helpers, so >> the code would remain unused. I'm uncertain whether CONFIG_64BIT >> ought to be set for such an architecture, as we assume sizeof(long) >> == sizeof(void*), and hence pointers would then need to be 32-bit >> as well there. > > This is a fair point. Would you mind to add a sentence explaining that > in the commit message? I've added "Note that we imply "32-bit arch" to be the same as BITS_PER_LONG == 32, i.e. we aren't (not just here) prepared to have a 64-bit arch with BITS_PER_LONG == 32. Yet even if we supported such, likely the compiler would get away there without invoking these helpers, so the code would remain unused in practice." > With that: > > Acked-by: Julien Grall <jgrall@amazon.com> Thanks. Any chance to also get an ack on patch 1, so at least these two (or three, seeing that you also did ack patch 3) could go in before my re-posting of the series to add the one line commit message additions that you did ask for on all the str* and mem* patches? (Alternatively I could take the time and re-order the two.) Jan
On 07/04/2021 09:33, Jan Beulich wrote: > On 06.04.2021 21:34, Julien Grall wrote: >> Hi Jan, >> >> On 01/04/2021 16:23, Jan Beulich wrote: >>> On 01.04.2021 16:56, Julien Grall wrote: >>>> On 01/04/2021 11:19, Jan Beulich wrote: >>>>> --- a/xen/common/lib.c >>>>> +++ b/xen/lib/divmod.c >>>>> @@ -40,7 +40,6 @@ >>>>> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF >>>>> * SUCH DAMAGE. >>>>> */ >>>>> -#if BITS_PER_LONG == 32 >>>> >>>> In theory BITS_PER_LONG == 32 is not quite the same as 32-bit arch. Can >>>> you clarify whether this code is necessary on 64-bit arch where long is >>>> only 32-bit. >>> >>> Likely the compiler can get away without invoking these helpers, so >>> the code would remain unused. I'm uncertain whether CONFIG_64BIT >>> ought to be set for such an architecture, as we assume sizeof(long) >>> == sizeof(void*), and hence pointers would then need to be 32-bit >>> as well there. >> >> This is a fair point. Would you mind to add a sentence explaining that >> in the commit message? > > I've added > > "Note that we imply "32-bit arch" to be the same as BITS_PER_LONG == 32, > i.e. we aren't (not just here) prepared to have a 64-bit arch with > BITS_PER_LONG == 32. Yet even if we supported such, likely the compiler > would get away there without invoking these helpers, so the code would > remain unused in practice." Sounds fine to me. > >> With that: >> >> Acked-by: Julien Grall <jgrall@amazon.com> > > Thanks. Any chance to also get an ack on patch 1, so at least these two > (or three, seeing that you also did ack patch 3) could go in before my > re-posting of the series to add the one line commit message additions > that you did ask for on all the str* and mem* patches? (Alternatively I > could take the time and re-order the two.) I didn't ack #1 because I am not very familiar with the x86 constraints. If anyone with x86 background (maybe Roger?) is willing to review it, then I would be happy to give my ack. Cheers,
diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index d144d4c8d3ee..f16eb0df43af 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -1,3 +1,5 @@ +config 64BIT + bool config NR_CPUS int "Maximum number of CPUs" diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 330bbf6232d4..ecfa6822e4d3 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -1,17 +1,11 @@ -config 64BIT - bool - default "$(ARCH)" != "arm32" - help - Say yes to build a 64-bit Xen - Say no to build a 32-bit Xen - config ARM_32 def_bool y - depends on !64BIT + depends on "$(ARCH)" = "arm32" config ARM_64 def_bool y - depends on 64BIT + depends on !ARM_32 + select 64BIT select HAS_FAST_MULTIPLY config ARM diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index f79e6634db3f..4d6911ffa467 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -1,5 +1,6 @@ config X86_64 def_bool y + select 64BIT config X86 def_bool y diff --git a/xen/common/Makefile b/xen/common/Makefile index 71c1d466bd8f..e2a7e62d14bf 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -21,7 +21,6 @@ obj-y += kernel.o obj-y += keyhandler.o obj-$(CONFIG_KEXEC) += kexec.o obj-$(CONFIG_KEXEC) += kimage.o -obj-y += lib.o obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o obj-$(CONFIG_MEM_ACCESS) += mem_access.o obj-y += memory.o diff --git a/xen/lib/Makefile b/xen/lib/Makefile index 0b274583ef0b..a5dc1442a422 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -10,3 +10,7 @@ lib-y += rbtree.o lib-y += sort.o lib-$(CONFIG_X86) += xxhash32.o lib-$(CONFIG_X86) += xxhash64.o + +lib32-y := divmod.o +lib32-$(CONFIG_64BIT) := +lib-y += $(lib32-y) diff --git a/xen/common/lib.c b/xen/lib/divmod.c similarity index 99% rename from xen/common/lib.c rename to xen/lib/divmod.c index 5b8f49153dad..0be6ccc70096 100644 --- a/xen/common/lib.c +++ b/xen/lib/divmod.c @@ -40,7 +40,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -#if BITS_PER_LONG == 32 /* * Depending on the desired operation, we view a `long long' (aka quad_t) in @@ -391,7 +390,6 @@ s64 __ldivmod_helper(s64 a, s64 b, s64 *r) else return quot; } -#endif /* BITS_PER_LONG == 32 */ /* * Local variables:
These were built for 32-bit architectures only (the same code could, with some tweaking, sensibly be used to provide TI-mode helpers on 64-bit arch-es) - retain this property, while still avoiding to have a CU without any contents at all. For this, Arm's CONFIG_64BIT gets generalized. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- xen/arch/Kconfig | 2 ++ xen/arch/arm/Kconfig | 12 +++--------- xen/arch/x86/Kconfig | 1 + xen/common/Makefile | 1 - xen/lib/Makefile | 4 ++++ xen/{common/lib.c => lib/divmod.c} | 2 -- 6 files changed, 10 insertions(+), 12 deletions(-) rename xen/{common/lib.c => lib/divmod.c} (99%)