Re: [PPC64] Remove another fixed address constraint
On Mon, Aug 01, 2005 at 08:45:02AM +0200, Olaf Hering wrote: > On Mon, Aug 01, David Gibson wrote: > > > Hrm.. definitely works here. Is this with any other patches? Can you > > send the .s file? That might help be debug it. > > It works with SLES9 gcc3, only gcc4 (or recent binutils) do not like > it. gcc4 can't be the problem; that's an assembler error. I am using: sneetch:~/kernel$ powerpc64-linux-as --version GNU assembler 2.15.94 20041116 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `powerpc-linux'. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Aug 01, David Gibson wrote: > Hrm.. definitely works here. Is this with any other patches? Can you > send the .s file? That might help be debug it. It works with SLES9 gcc3, only gcc4 (or recent binutils) do not like it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Aug 01, 2005 at 08:29:29AM +0200, Olaf Hering wrote:
> On Mon, Jul 25, David Gibson wrote:
>
> > Presently the LparMap, one of the structures the kernel shares with
> > the legacy iSeries hypervisor has a fixed offset address in head.S.
> > This patch changes this so the LparMap is a normally initialized
> > structure, without fixed address. This allows us to use macros to
> > compute some of the values in the structure, which wasn't previously
> > possible because the assembler always uses signed-% which gets the
> > wrong answers for the computations in question.
> >
> > Unfortunately, a gcc bug means that doing this requires another
> > structure (hvReleaseData) to be initialized in asm instead of C, but
> > on the whole the result is cleaner than before.
>
> I think this change caused this compile error in rc4:
>
> {standard input}: Assembler messages:
> {standard input}:254: Error: value of 40002080 too large for field of
> 4 bytes at 2108
> make[1]: *** [arch/ppc64/kernel/LparData.o] Error 1
>
> binutils-2.16.91.0.2
> gcc-4.0.2_20050727
Hrm.. definitely works here. Is this with any other patches? Can you
send the .s file? That might help be debug it.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Jul 25, David Gibson wrote:
> Presently the LparMap, one of the structures the kernel shares with
> the legacy iSeries hypervisor has a fixed offset address in head.S.
> This patch changes this so the LparMap is a normally initialized
> structure, without fixed address. This allows us to use macros to
> compute some of the values in the structure, which wasn't previously
> possible because the assembler always uses signed-% which gets the
> wrong answers for the computations in question.
>
> Unfortunately, a gcc bug means that doing this requires another
> structure (hvReleaseData) to be initialized in asm instead of C, but
> on the whole the result is cleaner than before.
I think this change caused this compile error in rc4:
{standard input}: Assembler messages:
{standard input}:254: Error: value of 40002080 too large for field of 4
bytes at 2108
make[1]: *** [arch/ppc64/kernel/LparData.o] Error 1
binutils-2.16.91.0.2
gcc-4.0.2_20050727
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Jul 25, David Gibson wrote:
Presently the LparMap, one of the structures the kernel shares with
the legacy iSeries hypervisor has a fixed offset address in head.S.
This patch changes this so the LparMap is a normally initialized
structure, without fixed address. This allows us to use macros to
compute some of the values in the structure, which wasn't previously
possible because the assembler always uses signed-% which gets the
wrong answers for the computations in question.
Unfortunately, a gcc bug means that doing this requires another
structure (hvReleaseData) to be initialized in asm instead of C, but
on the whole the result is cleaner than before.
I think this change caused this compile error in rc4:
{standard input}: Assembler messages:
{standard input}:254: Error: value of 40002080 too large for field of 4
bytes at 2108
make[1]: *** [arch/ppc64/kernel/LparData.o] Error 1
binutils-2.16.91.0.2
gcc-4.0.2_20050727
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Aug 01, 2005 at 08:29:29AM +0200, Olaf Hering wrote:
On Mon, Jul 25, David Gibson wrote:
Presently the LparMap, one of the structures the kernel shares with
the legacy iSeries hypervisor has a fixed offset address in head.S.
This patch changes this so the LparMap is a normally initialized
structure, without fixed address. This allows us to use macros to
compute some of the values in the structure, which wasn't previously
possible because the assembler always uses signed-% which gets the
wrong answers for the computations in question.
Unfortunately, a gcc bug means that doing this requires another
structure (hvReleaseData) to be initialized in asm instead of C, but
on the whole the result is cleaner than before.
I think this change caused this compile error in rc4:
{standard input}: Assembler messages:
{standard input}:254: Error: value of 40002080 too large for field of
4 bytes at 2108
make[1]: *** [arch/ppc64/kernel/LparData.o] Error 1
binutils-2.16.91.0.2
gcc-4.0.2_20050727
Hrm.. definitely works here. Is this with any other patches? Can you
send the .s file? That might help be debug it.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Aug 01, David Gibson wrote: Hrm.. definitely works here. Is this with any other patches? Can you send the .s file? That might help be debug it. It works with SLES9 gcc3, only gcc4 (or recent binutils) do not like it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PPC64] Remove another fixed address constraint
On Mon, Aug 01, 2005 at 08:45:02AM +0200, Olaf Hering wrote: On Mon, Aug 01, David Gibson wrote: Hrm.. definitely works here. Is this with any other patches? Can you send the .s file? That might help be debug it. It works with SLES9 gcc3, only gcc4 (or recent binutils) do not like it. gcc4 can't be the problem; that's an assembler error. I am using: sneetch:~/kernel$ powerpc64-linux-as --version GNU assembler 2.15.94 20041116 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `powerpc-linux'. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PPC64] Remove another fixed address constraint
Presently the LparMap, one of the structures the kernel shares with
the legacy iSeries hypervisor has a fixed offset address in head.S.
This patch changes this so the LparMap is a normally initialized
structure, without fixed address. This allows us to use macros to
compute some of the values in the structure, which wasn't previously
possible because the assembler always uses signed-% which gets the
wrong answers for the computations in question.
Unfortunately, a gcc bug means that doing this requires another
structure (hvReleaseData) to be initialized in asm instead of C, but
on the whole the result is cleaner than before.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/include/asm-ppc64/iSeries/LparMap.h
===
--- working-2.6.orig/include/asm-ppc64/iSeries/LparMap.h2005-07-06
10:30:53.0 +1000
+++ working-2.6/include/asm-ppc64/iSeries/LparMap.h 2005-07-25
15:28:42.0 +1000
@@ -49,19 +49,26 @@
* entry to map the Esid to the Vsid.
*/
+#define HvEsidsToMap 2
+#define HvRangesToMap 1
+
/* Hypervisor initially maps 32MB of the load area */
#define HvPagesToMap 8192
struct LparMap {
- u64 xNumberEsids; // Number of ESID/VSID pairs (1)
- u64 xNumberRanges; // Number of VA ranges to map (1)
- u64 xSegmentTableOffs; // Page number within load area of seg table
(0)
+ u64 xNumberEsids; // Number of ESID/VSID pairs
+ u64 xNumberRanges; // Number of VA ranges to map
+ u64 xSegmentTableOffs; // Page number within load area of seg table
u64 xRsvd[5];
- u64 xKernelEsid;// Esid used to map kernel load (0x0C)
- u64 xKernelVsid;// Vsid used to map kernel load (0x0C)
- u64 xPages; // Number of pages to be mapped (8192)
- u64 xOffset;// Offset from start of load area (0)
- u64 xVPN; // Virtual Page Number (0x000C)
+ struct {
+ u64 xKernelEsid;// Esid used to map kernel load
+ u64 xKernelVsid;// Vsid used to map kernel load
+ } xEsids[HvEsidsToMap];
+ struct {
+ u64 xPages; // Number of pages to be mapped
+ u64 xOffset;// Offset from start of load area
+ u64 xVPN; // Virtual Page Number
+ } xRanges[HvRangesToMap];
};
extern struct LparMap xLparMap;
Index: working-2.6/include/asm-ppc64/iSeries/HvReleaseData.h
===
--- working-2.6.orig/include/asm-ppc64/iSeries/HvReleaseData.h 2005-07-06
10:30:53.0 +1000
+++ working-2.6/include/asm-ppc64/iSeries/HvReleaseData.h 2005-07-25
15:28:42.0 +1000
@@ -39,6 +39,11 @@
* know that this PLIC does not support running an OS "that old".
*/
+#defineHVREL_TAGSINACTIVE 0x8000
+#define HVREL_32BIT0x4000
+#define HVREL_NOSHAREDPROCS0x2000
+#define HVREL_NOHMT0x1000
+
struct HvReleaseData {
u32 xDesc; /* Descriptor "HvRD" ebcdic x00-x03 */
u16 xSize; /* Size of this control block x04-x05 */
@@ -46,11 +51,7 @@
struct naca_struct *xSlicNacaAddr; /* Virt addr of SLIC NACA
x08-x0F */
u32 xMsNucDataOffset; /* Offset of Linux Mapping Data x10-x13 */
u32 xRsvd1; /* Reserved x14-x17 */
- u16 xTagsMode:1;/* 0 == tags active, 1 == tags inactive */
- u16 xAddressSize:1; /* 0 == 64-bit, 1 == 32-bit */
- u16 xNoSharedProcs:1; /* 0 == shared procs, 1 == no shared */
- u16 xNoHMT:1; /* 0 == allow HMT, 1 == no HMT */
- u16 xRsvd2:12; /* Reserved x18-x19 */
+ u16 xFlags;
u16 xVrmIndex; /* VRM Index of OS imagex1A-x1B */
u16 xMinSupportedPlicVrmIndex; /* Min PLIC level (soft) x1C-x1D */
u16 xMinCompatablePlicVrmIndex; /* Min PLIC levelP (hard) x1E-x1F */
Index: working-2.6/arch/ppc64/kernel/LparData.c
===
--- working-2.6.orig/arch/ppc64/kernel/LparData.c 2005-07-14
10:57:49.0 +1000
+++ working-2.6/arch/ppc64/kernel/LparData.c2005-07-25 15:09:55.0
+1000
@@ -33,17 +33,36 @@
* the hypervisor and Linux.
*/
+/*
+ * WARNING - magic here
+ *
+ * Ok, this is a horrid hack below, but marginally better than the
+ * alternatives. What we really want is just to initialize
+ * hvReleaseData in C as in the #if 0 section here. However, gcc
+ * refuses to believe that (u32) is a constant expression, so will
+ * not allow the xMsNucDataOffset field to be properly initialized.
+ * So, we declare hvReleaseData in inline asm instead. We use inline
+ * asm, rather than a .S
[PPC64] Remove another fixed address constraint
Presently the LparMap, one of the structures the kernel shares with
the legacy iSeries hypervisor has a fixed offset address in head.S.
This patch changes this so the LparMap is a normally initialized
structure, without fixed address. This allows us to use macros to
compute some of the values in the structure, which wasn't previously
possible because the assembler always uses signed-% which gets the
wrong answers for the computations in question.
Unfortunately, a gcc bug means that doing this requires another
structure (hvReleaseData) to be initialized in asm instead of C, but
on the whole the result is cleaner than before.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/include/asm-ppc64/iSeries/LparMap.h
===
--- working-2.6.orig/include/asm-ppc64/iSeries/LparMap.h2005-07-06
10:30:53.0 +1000
+++ working-2.6/include/asm-ppc64/iSeries/LparMap.h 2005-07-25
15:28:42.0 +1000
@@ -49,19 +49,26 @@
* entry to map the Esid to the Vsid.
*/
+#define HvEsidsToMap 2
+#define HvRangesToMap 1
+
/* Hypervisor initially maps 32MB of the load area */
#define HvPagesToMap 8192
struct LparMap {
- u64 xNumberEsids; // Number of ESID/VSID pairs (1)
- u64 xNumberRanges; // Number of VA ranges to map (1)
- u64 xSegmentTableOffs; // Page number within load area of seg table
(0)
+ u64 xNumberEsids; // Number of ESID/VSID pairs
+ u64 xNumberRanges; // Number of VA ranges to map
+ u64 xSegmentTableOffs; // Page number within load area of seg table
u64 xRsvd[5];
- u64 xKernelEsid;// Esid used to map kernel load (0x0C)
- u64 xKernelVsid;// Vsid used to map kernel load (0x0C)
- u64 xPages; // Number of pages to be mapped (8192)
- u64 xOffset;// Offset from start of load area (0)
- u64 xVPN; // Virtual Page Number (0x000C)
+ struct {
+ u64 xKernelEsid;// Esid used to map kernel load
+ u64 xKernelVsid;// Vsid used to map kernel load
+ } xEsids[HvEsidsToMap];
+ struct {
+ u64 xPages; // Number of pages to be mapped
+ u64 xOffset;// Offset from start of load area
+ u64 xVPN; // Virtual Page Number
+ } xRanges[HvRangesToMap];
};
extern struct LparMap xLparMap;
Index: working-2.6/include/asm-ppc64/iSeries/HvReleaseData.h
===
--- working-2.6.orig/include/asm-ppc64/iSeries/HvReleaseData.h 2005-07-06
10:30:53.0 +1000
+++ working-2.6/include/asm-ppc64/iSeries/HvReleaseData.h 2005-07-25
15:28:42.0 +1000
@@ -39,6 +39,11 @@
* know that this PLIC does not support running an OS that old.
*/
+#defineHVREL_TAGSINACTIVE 0x8000
+#define HVREL_32BIT0x4000
+#define HVREL_NOSHAREDPROCS0x2000
+#define HVREL_NOHMT0x1000
+
struct HvReleaseData {
u32 xDesc; /* Descriptor HvRD ebcdic x00-x03 */
u16 xSize; /* Size of this control block x04-x05 */
@@ -46,11 +51,7 @@
struct naca_struct *xSlicNacaAddr; /* Virt addr of SLIC NACA
x08-x0F */
u32 xMsNucDataOffset; /* Offset of Linux Mapping Data x10-x13 */
u32 xRsvd1; /* Reserved x14-x17 */
- u16 xTagsMode:1;/* 0 == tags active, 1 == tags inactive */
- u16 xAddressSize:1; /* 0 == 64-bit, 1 == 32-bit */
- u16 xNoSharedProcs:1; /* 0 == shared procs, 1 == no shared */
- u16 xNoHMT:1; /* 0 == allow HMT, 1 == no HMT */
- u16 xRsvd2:12; /* Reserved x18-x19 */
+ u16 xFlags;
u16 xVrmIndex; /* VRM Index of OS imagex1A-x1B */
u16 xMinSupportedPlicVrmIndex; /* Min PLIC level (soft) x1C-x1D */
u16 xMinCompatablePlicVrmIndex; /* Min PLIC levelP (hard) x1E-x1F */
Index: working-2.6/arch/ppc64/kernel/LparData.c
===
--- working-2.6.orig/arch/ppc64/kernel/LparData.c 2005-07-14
10:57:49.0 +1000
+++ working-2.6/arch/ppc64/kernel/LparData.c2005-07-25 15:09:55.0
+1000
@@ -33,17 +33,36 @@
* the hypervisor and Linux.
*/
+/*
+ * WARNING - magic here
+ *
+ * Ok, this is a horrid hack below, but marginally better than the
+ * alternatives. What we really want is just to initialize
+ * hvReleaseData in C as in the #if 0 section here. However, gcc
+ * refuses to believe that (u32)x is a constant expression, so will
+ * not allow the xMsNucDataOffset field to be properly initialized.
+ * So, we declare hvReleaseData in inline asm instead. We use inline
+ * asm, rather than a .S file,
