Message ID | alpine.DEB.1.10.1412100136320.19155@tp.orcam.me.uk |
---|---|
State | New |
Headers | show |
On 10 December 2014 at 18:53, Maciej W. Rozycki <macro@codesourcery.com> wrote: > Mechanically add new n32/n64 configuration files copying the relevant > preexisting ones, fixing the system emulation configuration build, that > breaks due to the lack of the respective configuration files, for the > `mipsn32' and `mipsn32el' targets on this occasion as well. > > Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com> > --- > To be applied first so as not to break the build and consequently > bisection with the configuration changes posted next. > > Maciej > > qemu-mips-configs.diff > Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak > Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak > Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak > Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak Some of these look weird. n32 and n64 are ABIs, right? We shouldn't have extra -softmmu configs for different ABIs, the guest can deal with those. The MIPS config name variants that are only ABI related should only result in new -linux-user binaries (where we need a binary per Linux syscall ABI). thanks -- PMM
On Wed, 10 Dec 2014, Peter Maydell wrote: > > Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak > > Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak > > Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak > > Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak > > Some of these look weird. n32 and n64 are ABIs, right? We > shouldn't have extra -softmmu configs for different ABIs, > the guest can deal with those. The MIPS config name variants > that are only ABI related should only result in new -linux-user > binaries (where we need a binary per Linux syscall ABI). This is a tricky change, the system emulation mode configuration also has an ELF loader (invoked with the -kernel option) and as such is also affected. There are three MIPS ELF flavours corresponding to the three ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is an ELF file header flag). The two ELF32 flavours are I think close enough to each other as far as executables (as opposed to intermediate objects) are concerned that a single QEMU binary might be able to handle them as it stands. Of course ELF32 ABI2 is incompatible to any 32-bit processors and such executables must be rejected when emulating a 32-bit processor. So with my proposal and -softmmu configs: - mipsn64|mipsn64el -- handle ELF64 (n64) binaries with only 64-bit processors available for emulation, - mipsn32|mipsn32el -- handle ELF32 (n32) binaries with only 64-bit processors available for emulation, - mips64|mips64el -- handle ELF32 (o32, maybe n32) binaries with both 32-bit and 64-bit processors available for emulation, - mips|mipsel -- handle ELF32 (o32) binaries with only 32-bit processors available for emulation (configuration optimised for 32-bit hosts). Each of them will be suitable for running different bare-metal applications. As I say, we may be able to come up with better target names, I am open to proposals. As noted in 0/3 ideally we'd handle all ELF flavours with a single binary. Then we could have two system configurations only, mips|mipsel (a limited configuration for 32-bit host optimisation) and mips64|mips64el (a full configuration). That could apply to both the system and the user emulation mode, although the effort required to handle the former is a subset of that for the latter, and also looks quite substantially smaller to me. The changes I propose here do not preclude it from happening in the future, they are merely intended to bring some order to what we have now. Does this explanation makes things addressed here a bit clearer to you? Maciej
On 10 December 2014 at 20:29, Maciej W. Rozycki <macro@codesourcery.com> wrote: > On Wed, 10 Dec 2014, Peter Maydell wrote: > >> > Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak >> > Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak >> > Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak >> > Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak >> >> Some of these look weird. n32 and n64 are ABIs, right? We >> shouldn't have extra -softmmu configs for different ABIs, >> the guest can deal with those. The MIPS config name variants >> that are only ABI related should only result in new -linux-user >> binaries (where we need a binary per Linux syscall ABI). > > This is a tricky change, the system emulation mode configuration also has > an ELF loader (invoked with the -kernel option) and as such is also > affected. There are three MIPS ELF flavours corresponding to the three > ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is > an ELF file header flag). The two ELF32 flavours are I think close enough > to each other as far as executables (as opposed to intermediate objects) > are concerned that a single QEMU binary might be able to handle them as it > stands. Of course ELF32 ABI2 is incompatible to any 32-bit processors and > such executables must be rejected when emulating a 32-bit processor. So this is only an issue because of the bare-metal ELF loading? We should make that handle the various bare metal EXEs correctly for the CPUs that each softmmu config currently supports. > As noted in 0/3 ideally we'd handle all ELF flavours with a single > binary. Then we could have two system configurations only, mips|mipsel (a > limited configuration for 32-bit host optimisation) and mips64|mips64el (a > full configuration). I think this is the right way to go. > That could apply to both the system and the user > emulation mode, although the effort required to handle the former is a > subset of that for the latter, and also looks quite substantially smaller > to me. User emulation is a harder problem, because we compile-time code in things like structure layouts and data type sizes. That's why we have one binary per ABI. System emulation really should not care about this anywhere near as much. > The changes I propose here do not preclude it from happening in > the future, they are merely intended to bring some order to what we have > now. The problem is that adding new QEMU executables is effectively extending our user-facing interface. We really shouldn't do that in the wrong way if we can avoid it (it's hard to undo later without breaking peoples' setups). thanks -- PMM
On Wed, 10 Dec 2014, Peter Maydell wrote: > > This is a tricky change, the system emulation mode configuration also has > > an ELF loader (invoked with the -kernel option) and as such is also > > affected. There are three MIPS ELF flavours corresponding to the three > > ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is > > an ELF file header flag). The two ELF32 flavours are I think close enough > > to each other as far as executables (as opposed to intermediate objects) > > are concerned that a single QEMU binary might be able to handle them as it > > stands. Of course ELF32 ABI2 is incompatible to any 32-bit processors and > > such executables must be rejected when emulating a 32-bit processor. > > So this is only an issue because of the bare-metal ELF loading? > We should make that handle the various bare metal EXEs correctly > for the CPUs that each softmmu config currently supports. > > > As noted in 0/3 ideally we'd handle all ELF flavours with a single > > binary. Then we could have two system configurations only, mips|mipsel (a > > limited configuration for 32-bit host optimisation) and mips64|mips64el (a > > full configuration). > > I think this is the right way to go. Except that apart from coming to an agreement someone has to make it happen yet. ;) > > That could apply to both the system and the user > > emulation mode, although the effort required to handle the former is a > > subset of that for the latter, and also looks quite substantially smaller > > to me. > > User emulation is a harder problem, because we compile-time code in > things like structure layouts and data type sizes. That's why we have > one binary per ABI. System emulation really should not care about > this anywhere near as much. We still need to come up with sensible target names and clean up the current situation. What I think is particularly important about this series is 3/3. And 2/3 defines a consistent set of macros to drive 3/3. > > The changes I propose here do not preclude it from happening in > > the future, they are merely intended to bring some order to what we have > > now. > > The problem is that adding new QEMU executables is effectively > extending our user-facing interface. We really shouldn't do that > in the wrong way if we can avoid it (it's hard to undo later > without breaking peoples' setups). Fair enough, I want to move forward though. Would it make you happy if I dropped the new -softmmu configs and made mipsn32|mipsn32el and mipsn64|mipsn64el only accept -user configs instead (failing gracefully rather than abruptly as mipsn32|mipsn32el do now)? Maciej
On 10 December 2014 at 22:14, Maciej W. Rozycki <macro@codesourcery.com> wrote: > On Wed, 10 Dec 2014, Peter Maydell wrote: >> > As noted in 0/3 ideally we'd handle all ELF flavours with a single >> > binary. Then we could have two system configurations only, mips|mipsel (a >> > limited configuration for 32-bit host optimisation) and mips64|mips64el (a >> > full configuration). >> >> I think this is the right way to go. > > Except that apart from coming to an agreement someone has to make it > happen yet. ;) Ah, but I'm happy with the current state of the codebase... >> > The changes I propose here do not preclude it from happening in >> > the future, they are merely intended to bring some order to what we have >> > now. >> >> The problem is that adding new QEMU executables is effectively >> extending our user-facing interface. We really shouldn't do that >> in the wrong way if we can avoid it (it's hard to undo later >> without breaking peoples' setups). > > Fair enough, I want to move forward though. Would it make you happy if I > dropped the new -softmmu configs and made mipsn32|mipsn32el and > mipsn64|mipsn64el only accept -user configs instead (failing gracefully > rather than abruptly as mipsn32|mipsn32el do now)? Er, I'm not sure what you mean there. Trying a softmmu config for mipsn32 or mipsn32el fails gracefully already: manooth$ (cd build/mips && ../../configure --target-list=mipsn32-softmmu) ERROR: Unknown target name 'mipsn32-softmmu' thanks -- PMM
On Wed, 10 Dec 2014, Peter Maydell wrote: > > Except that apart from coming to an agreement someone has to make it > > happen yet. ;) > > Ah, but I'm happy with the current state of the codebase... Ack. > > Fair enough, I want to move forward though. Would it make you happy if I > > dropped the new -softmmu configs and made mipsn32|mipsn32el and > > mipsn64|mipsn64el only accept -user configs instead (failing gracefully > > rather than abruptly as mipsn32|mipsn32el do now)? > > Er, I'm not sure what you mean there. Trying a softmmu config for > mipsn32 or mipsn32el fails gracefully already: > > manooth$ (cd build/mips && ../../configure --target-list=mipsn32-softmmu) > > ERROR: Unknown target name 'mipsn32-softmmu' It looks like the issue I had in mind has been fixed in a generic way then since I last checked. Previously a build error happened sometime along the process. Apologies for not double-checking with current trunk. I'll send updates. Maciej
On 10 December 2014 at 23:25, Maciej W. Rozycki <macro@codesourcery.com> wrote: > On Wed, 10 Dec 2014, Peter Maydell wrote: > >> > Except that apart from coming to an agreement someone has to make it >> > happen yet. ;) >> >> Ah, but I'm happy with the current state of the codebase... > > Ack. To clarify, that was a slightly tongue-in-cheek response, but I do actually feel strongly enough that we shouldn't create new wrong executables that I'd rather we left the bugs here unaddressed than try to fix them with a lot of new softmmu executables. >> Er, I'm not sure what you mean there. Trying a softmmu config for >> mipsn32 or mipsn32el fails gracefully already: >> >> manooth$ (cd build/mips && ../../configure --target-list=mipsn32-softmmu) >> >> ERROR: Unknown target name 'mipsn32-softmmu' > > It looks like the issue I had in mind has been fixed in a generic way > then since I last checked. Previously a build error happened sometime > along the process. Apologies for not double-checking with current trunk. > I'll send updates. Yes, we fixed configure to sanity check user target-list arguments some time last year. Note that the list of valid targets is driven by looking at what files exist in default-configs/, so you'll want to delete any stale or local files you have there from previous versions of this patchset. thanks -- PMM
On Thu, 11 Dec 2014, Peter Maydell wrote: > >> > Except that apart from coming to an agreement someone has to make it > >> > happen yet. ;) > >> > >> Ah, but I'm happy with the current state of the codebase... > > > > Ack. > > To clarify, that was a slightly tongue-in-cheek response, but I > do actually feel strongly enough that we shouldn't create new > wrong executables that I'd rather we left the bugs here unaddressed > than try to fix them with a lot of new softmmu executables. Sure, I have to clear the confusion I created here though. I have realised I ran all the earlier system emulation mode Linux testing with both o32 (ELF32) and n64 (ELF64) kernel images and just a single pair of QEMU executables for different endiannesses each. So the ELF loader already supports all ELF executables. So it's only the GDB stub's register width that has issues, as addressed here. Apologies for the wrong statements then, I misremembered things. > >> Er, I'm not sure what you mean there. Trying a softmmu config for > >> mipsn32 or mipsn32el fails gracefully already: > >> > >> manooth$ (cd build/mips && ../../configure --target-list=mipsn32-softmmu) > >> > >> ERROR: Unknown target name 'mipsn32-softmmu' > > > > It looks like the issue I had in mind has been fixed in a generic way > > then since I last checked. Previously a build error happened sometime > > along the process. Apologies for not double-checking with current trunk. > > I'll send updates. > > Yes, we fixed configure to sanity check user target-list arguments > some time last year. Note that the list of valid targets is driven > by looking at what files exist in default-configs/, so you'll want > to delete any stale or local files you have there from previous > versions of this patchset. That's what I figured out before sending v2. It looks to me like the cleanest way to handle it, you don't duplicate validity information in `configure'. Thanks for your review and hints, much appreciated. Maciej
Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ qemu-git-trunk/default-configs/mipsn32-softmmu.mak 2014-11-01 04:54:58.247518643 +0000 @@ -0,0 +1,36 @@ +# Default configuration for mipsn32-softmmu + +include pci.mak +include sound.mak +include usb.mak +CONFIG_ESP=y +CONFIG_VGA=y +CONFIG_VGA_PCI=y +CONFIG_VGA_ISA=y +CONFIG_VGA_ISA_MM=y +CONFIG_VGA_CIRRUS=y +CONFIG_VMWARE_VGA=y +CONFIG_SERIAL=y +CONFIG_PARALLEL=y +CONFIG_I8254=y +CONFIG_PCSPK=y +CONFIG_PCKBD=y +CONFIG_FDC=y +CONFIG_ACPI=y +CONFIG_APM=y +CONFIG_I8257=y +CONFIG_PIIX4=y +CONFIG_IDE_ISA=y +CONFIG_IDE_PIIX=y +CONFIG_NE2000_ISA=y +CONFIG_RC4030=y +CONFIG_DP8393X=y +CONFIG_DS1225Y=y +CONFIG_MIPSNET=y +CONFIG_PFLASH_CFI01=y +CONFIG_G364FB=y +CONFIG_I8259=y +CONFIG_JAZZ_LED=y +CONFIG_MC146818RTC=y +CONFIG_ISA_TESTDEV=y +CONFIG_EMPTY_SLOT=y Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ qemu-git-trunk/default-configs/mipsn32el-softmmu.mak 2014-11-01 04:55:10.747732265 +0000 @@ -0,0 +1,39 @@ +# Default configuration for mipsn32el-softmmu + +include pci.mak +include sound.mak +include usb.mak +CONFIG_ESP=y +CONFIG_VGA=y +CONFIG_VGA_PCI=y +CONFIG_VGA_ISA=y +CONFIG_VGA_ISA_MM=y +CONFIG_VGA_CIRRUS=y +CONFIG_VMWARE_VGA=y +CONFIG_SERIAL=y +CONFIG_PARALLEL=y +CONFIG_I8254=y +CONFIG_PCSPK=y +CONFIG_PCKBD=y +CONFIG_FDC=y +CONFIG_ACPI=y +CONFIG_APM=y +CONFIG_I8257=y +CONFIG_PIIX4=y +CONFIG_IDE_ISA=y +CONFIG_IDE_PIIX=y +CONFIG_IDE_VIA=y +CONFIG_NE2000_ISA=y +CONFIG_RC4030=y +CONFIG_DP8393X=y +CONFIG_DS1225Y=y +CONFIG_MIPSNET=y +CONFIG_PFLASH_CFI01=y +CONFIG_FULONG=y +CONFIG_G364FB=y +CONFIG_I8259=y +CONFIG_JAZZ_LED=y +CONFIG_MC146818RTC=y +CONFIG_VT82C686=y +CONFIG_ISA_TESTDEV=y +CONFIG_EMPTY_SLOT=y Index: qemu-git-trunk/default-configs/mipsn64-linux-user.mak =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ qemu-git-trunk/default-configs/mipsn64-linux-user.mak 2014-10-30 14:24:05.878953747 +0000 @@ -0,0 +1 @@ +# Default configuration for mipsn64-linux-user Index: qemu-git-trunk/default-configs/mipsn64-softmmu.mak =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ qemu-git-trunk/default-configs/mipsn64-softmmu.mak 2014-11-01 04:55:27.248299838 +0000 @@ -0,0 +1,36 @@ +# Default configuration for mipsn64-softmmu + +include pci.mak +include sound.mak +include usb.mak +CONFIG_ESP=y +CONFIG_VGA=y +CONFIG_VGA_PCI=y +CONFIG_VGA_ISA=y +CONFIG_VGA_ISA_MM=y +CONFIG_VGA_CIRRUS=y +CONFIG_VMWARE_VGA=y +CONFIG_SERIAL=y +CONFIG_PARALLEL=y +CONFIG_I8254=y +CONFIG_PCSPK=y +CONFIG_PCKBD=y +CONFIG_FDC=y +CONFIG_ACPI=y +CONFIG_APM=y +CONFIG_I8257=y +CONFIG_PIIX4=y +CONFIG_IDE_ISA=y +CONFIG_IDE_PIIX=y +CONFIG_NE2000_ISA=y +CONFIG_RC4030=y +CONFIG_DP8393X=y +CONFIG_DS1225Y=y +CONFIG_MIPSNET=y +CONFIG_PFLASH_CFI01=y +CONFIG_G364FB=y +CONFIG_I8259=y +CONFIG_JAZZ_LED=y +CONFIG_MC146818RTC=y +CONFIG_ISA_TESTDEV=y +CONFIG_EMPTY_SLOT=y Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ qemu-git-trunk/default-configs/mipsn64el-linux-user.mak 2014-10-30 14:24:05.878953747 +0000 @@ -0,0 +1 @@ +# Default configuration for mipsn64el-linux-user Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ qemu-git-trunk/default-configs/mipsn64el-softmmu.mak 2014-11-01 04:55:39.748239599 +0000 @@ -0,0 +1,39 @@ +# Default configuration for mipsn64el-softmmu + +include pci.mak +include sound.mak +include usb.mak +CONFIG_ESP=y +CONFIG_VGA=y +CONFIG_VGA_PCI=y +CONFIG_VGA_ISA=y +CONFIG_VGA_ISA_MM=y +CONFIG_VGA_CIRRUS=y +CONFIG_VMWARE_VGA=y +CONFIG_SERIAL=y +CONFIG_PARALLEL=y +CONFIG_I8254=y +CONFIG_PCSPK=y +CONFIG_PCKBD=y +CONFIG_FDC=y +CONFIG_ACPI=y +CONFIG_APM=y +CONFIG_I8257=y +CONFIG_PIIX4=y +CONFIG_IDE_ISA=y +CONFIG_IDE_PIIX=y +CONFIG_IDE_VIA=y +CONFIG_NE2000_ISA=y +CONFIG_RC4030=y +CONFIG_DP8393X=y +CONFIG_DS1225Y=y +CONFIG_MIPSNET=y +CONFIG_PFLASH_CFI01=y +CONFIG_FULONG=y +CONFIG_G364FB=y +CONFIG_I8259=y +CONFIG_JAZZ_LED=y +CONFIG_MC146818RTC=y +CONFIG_VT82C686=y +CONFIG_ISA_TESTDEV=y +CONFIG_EMPTY_SLOT=y
Mechanically add new n32/n64 configuration files copying the relevant preexisting ones, fixing the system emulation configuration build, that breaks due to the lack of the respective configuration files, for the `mipsn32' and `mipsn32el' targets on this occasion as well. Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com> --- To be applied first so as not to break the build and consequently bisection with the configuration changes posted next. Maciej qemu-mips-configs.diff