* [Qemu-devel] SPARC64 supported processors @ 2017-06-27 17:59 Pasha Tatashin 2017-06-29 6:57 ` Mark Cave-Ayland 2017-06-29 9:45 ` Artyom Tarasenko 0 siblings, 2 replies; 4+ messages in thread From: Pasha Tatashin @ 2017-06-27 17:59 UTC (permalink / raw) To: qemu-devel Hi, I am trying to evaluate the current qemu support for sparc64 processors. First, it seems -smp is not supported for any processor, is this correct? When I set -smp greater than 1, I am getting: qemu-system-sparc64: Number of SMP CPUs requested (2) exceeds max CPUs supported by machine 'sun4u' (1) I've done some testing for all available sparc64 cpus + latest linux kernel: Fujitsu Sparc64 Working Fujitsu Sparc64 III Exception 0x30 (DAE_side_effect_page) in OpenBios Fujitsu Sparc64 IV Working Fujitsu Sparc64 V Working TI UltraSparc I Working TI UltraSparc II Working TI UltraSparc IIi Working TI UltraSparc IIe Exception 0x28 (division_by_zero) in init_tick_ops Can make it to work if is_hummingbird() is changed to return 0. The IO stick, and OpenBios stick properties are absent, so we have to default to %tick for now. Sun UltraSparc III Illegal instruction in cheetah_boot(): wr %g0, %g1, %dcr It appears dispatch control register is not implemented. Sun UltraSparc IIIi Sun UltraSparc IV Sun UltraSparc IV+ Sun UltraSparc IIIi+ In these four CPUs, I am getting exception 0x32 in cheetah_generic_boot: stxa %g0, [ %g3 ] #ASI_DMMU Sun UltraSparc T1 Sun UltraSparc T2 Both of the above boot pretty far but fail in this function when tmpfs is mounted: direct_pcr_write(unsigned long reg_num, u64 val) __asm__ __volatile__("wr %0, 0x0, %%pcr" : : "r" (val)); Seems like performance counter registers are not supported. needed to add these to kernel parameters: keep_bootcon -> to see where we are panicking lpj=1000 -> jiffers could not calculate for some reason. NEC UltraSparc I Working Does this look right or may be I have missed something, and we can get some of the Sun UltraSparc to work for example? Thank you, Pasha ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] SPARC64 supported processors 2017-06-27 17:59 [Qemu-devel] SPARC64 supported processors Pasha Tatashin @ 2017-06-29 6:57 ` Mark Cave-Ayland 2017-06-29 9:56 ` Artyom Tarasenko 2017-06-29 9:45 ` Artyom Tarasenko 1 sibling, 1 reply; 4+ messages in thread From: Mark Cave-Ayland @ 2017-06-29 6:57 UTC (permalink / raw) To: Pasha Tatashin, qemu-devel, Artyom Tarasenko On 27/06/17 18:59, Pasha Tatashin wrote: Hi Pasha, > Hi, > > I am trying to evaluate the current qemu support for sparc64 processors. > First, it seems -smp is not supported for any processor, is this > correct? When I set -smp greater than 1, I am getting: > > qemu-system-sparc64: Number of SMP CPUs requested (2) exceeds max CPUs > supported by machine 'sun4u' (1) Yes, that is correct for the moment. Before the MTTCG patches were merged, TCG only ran one thread so -smp 2 would effectively split your single host CPU into 2 virtual CPUs which doesn't give much benefit. Now MTTCG has been included multi CPUs become much more useful and really for SPARC64 there are 2 main tasks (for sun4u): reviewing the atomic instructions and marking them with the appropriate barriers in TCG, and then updating OpenBIOS (and possibly fw_cfg) to handle multiple CPUs on startup. The other point to note here is that since the default sun4u CPU doesn't have the equivalent of a "sleep until interrupt" instruction then the guest processes will run at 100% CPU on the host since there is no way for the guest to indicate that it should yield. I would expect that this would be possible with other CPUs though. > I've done some testing for all available sparc64 cpus + latest linux > kernel: > > Fujitsu Sparc64 Working > Fujitsu Sparc64 III Exception 0x30 (DAE_side_effect_page) in OpenBios > Fujitsu Sparc64 IV Working > Fujitsu Sparc64 V Working > TI UltraSparc I Working > TI UltraSparc II Working > TI UltraSparc IIi Working > TI UltraSparc IIe Exception 0x28 (division_by_zero) in init_tick_ops > Can make it to work if is_hummingbird() is changed > to return 0. The IO stick, and OpenBios stick properties > are absent, so we have to default to %tick for now. > > Sun UltraSparc III Illegal instruction in cheetah_boot(): > wr %g0, %g1, %dcr > It appears dispatch control register is not implemented. > > Sun UltraSparc IIIi > Sun UltraSparc IV > Sun UltraSparc IV+ > Sun UltraSparc IIIi+ > In these four CPUs, I am getting exception 0x32 in > cheetah_generic_boot: stxa %g0, [ %g3 ] #ASI_DMMU > > Sun UltraSparc T1 > Sun UltraSparc T2 > > Both of the above boot pretty far but fail in this function when tmpfs > is mounted: > direct_pcr_write(unsigned long reg_num, u64 val) > __asm__ __volatile__("wr %0, 0x0, %%pcr" : : "r" (val)); > > Seems like performance counter registers are not supported. > > needed to add these to kernel parameters: > keep_bootcon -> to see where we are panicking > lpj=1000 -> jiffers could not calculate for some reason. > > NEC UltraSparc I Working > > Does this look right or may be I have missed something, and we can get > some of the Sun UltraSparc to work for example? That's certainly a very comprehensive set of tests :) I'd say that it's a fairly accurate reflection of where we are at the moment in that the basic SPARC64 core is working well and it's the CPU-specific parts which need more work. Currently myself and Artyom (CCd) are the SPARC maintainers and we tend to focus on different areas: my interest is with the sun4u machine as I have some legacy Solaris images I'm trying to run whilst Artyom has recently contributed niagara support to the 2.9 release. Note that I do try and keep the wiki page at http://wiki.qemu.org/Documentation/Platforms/SPARC up to date so that people can track current progress. Yes we can certainly look at trying to support more of the UltraSPARC CPUs if that is of interest. In reality the main reason that things haven't progressed further is due to lack of available time: whilst both myself and Artyom have done bits of work for particular clients, the majority of the work takes place in our own time outside of work and home which is, of course, limited. If there are particular features you would like added to QEMU's SPARC emulation then offers of help in terms of people/documentation/sponsorship are always welcome. Feel free to follow-up with both myself and Artyom off-list if this is something of interest to you. ATB, Mark. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] SPARC64 supported processors 2017-06-29 6:57 ` Mark Cave-Ayland @ 2017-06-29 9:56 ` Artyom Tarasenko 0 siblings, 0 replies; 4+ messages in thread From: Artyom Tarasenko @ 2017-06-29 9:56 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: Pasha Tatashin, qemu-devel Hi Mark, On Thu, Jun 29, 2017 at 8:57 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote: > On 27/06/17 18:59, Pasha Tatashin wrote: > > Hi Pasha, > >> Hi, >> >> I am trying to evaluate the current qemu support for sparc64 processors. >> First, it seems -smp is not supported for any processor, is this >> correct? When I set -smp greater than 1, I am getting: >> >> qemu-system-sparc64: Number of SMP CPUs requested (2) exceeds max CPUs >> supported by machine 'sun4u' (1) > > Yes, that is correct for the moment. Before the MTTCG patches were > merged, TCG only ran one thread so -smp 2 would effectively split your > single host CPU into 2 virtual CPUs which doesn't give much benefit. > > Now MTTCG has been included multi CPUs become much more useful and > really for SPARC64 there are 2 main tasks (for sun4u): reviewing the > atomic instructions and marking them with the appropriate barriers in > TCG, and then updating OpenBIOS (and possibly fw_cfg) to handle multiple > CPUs on startup. > > The other point to note here is that since the default sun4u CPU doesn't > have the equivalent of a "sleep until interrupt" instruction then the > guest processes will run at 100% CPU on the host since there is no way > for the guest to indicate that it should yield. Well, it should be possible to recognize the scheduler loops for the popular OSes at the translation time and halt or throttle down if nothing happens. But I'm not sure the hack is worth the effort. > I would expect that this > would be possible with other CPUs though. The IIIi has ways to reduce the frequency, but not halt completely. Not sure about IV(+). >> I've done some testing for all available sparc64 cpus + latest linux >> kernel: >> >> Fujitsu Sparc64 Working >> Fujitsu Sparc64 III Exception 0x30 (DAE_side_effect_page) in OpenBios >> Fujitsu Sparc64 IV Working >> Fujitsu Sparc64 V Working >> TI UltraSparc I Working >> TI UltraSparc II Working >> TI UltraSparc IIi Working >> TI UltraSparc IIe Exception 0x28 (division_by_zero) in init_tick_ops >> Can make it to work if is_hummingbird() is changed >> to return 0. The IO stick, and OpenBios stick properties >> are absent, so we have to default to %tick for now. >> >> Sun UltraSparc III Illegal instruction in cheetah_boot(): >> wr %g0, %g1, %dcr >> It appears dispatch control register is not implemented. >> >> Sun UltraSparc IIIi >> Sun UltraSparc IV >> Sun UltraSparc IV+ >> Sun UltraSparc IIIi+ >> In these four CPUs, I am getting exception 0x32 in >> cheetah_generic_boot: stxa %g0, [ %g3 ] #ASI_DMMU >> >> Sun UltraSparc T1 >> Sun UltraSparc T2 >> >> Both of the above boot pretty far but fail in this function when tmpfs >> is mounted: >> direct_pcr_write(unsigned long reg_num, u64 val) >> __asm__ __volatile__("wr %0, 0x0, %%pcr" : : "r" (val)); >> >> Seems like performance counter registers are not supported. >> >> needed to add these to kernel parameters: >> keep_bootcon -> to see where we are panicking >> lpj=1000 -> jiffers could not calculate for some reason. >> >> NEC UltraSparc I Working >> >> Does this look right or may be I have missed something, and we can get >> some of the Sun UltraSparc to work for example? > > That's certainly a very comprehensive set of tests :) I'd say that it's > a fairly accurate reflection of where we are at the moment in that the > basic SPARC64 core is working well and it's the CPU-specific parts which > need more work. > > Currently myself and Artyom (CCd) are the SPARC maintainers and we tend > to focus on different areas: my interest is with the sun4u machine as I > have some legacy Solaris images I'm trying to run whilst Artyom has > recently contributed niagara support to the 2.9 release. Note that I do > try and keep the wiki page at > http://wiki.qemu.org/Documentation/Platforms/SPARC up to date so that > people can track current progress. > > Yes we can certainly look at trying to support more of the UltraSPARC > CPUs if that is of interest. In reality the main reason that things > haven't progressed further is due to lack of available time: whilst both > myself and Artyom have done bits of work for particular clients, the > majority of the work takes place in our own time outside of work and > home which is, of course, limited. > > If there are particular features you would like added to QEMU's SPARC > emulation then offers of help in terms of > people/documentation/sponsorship are always welcome. Feel free to > follow-up with both myself and Artyom off-list if this is something of > interest to you. > > -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] SPARC64 supported processors 2017-06-27 17:59 [Qemu-devel] SPARC64 supported processors Pasha Tatashin 2017-06-29 6:57 ` Mark Cave-Ayland @ 2017-06-29 9:45 ` Artyom Tarasenko 1 sibling, 0 replies; 4+ messages in thread From: Artyom Tarasenko @ 2017-06-29 9:45 UTC (permalink / raw) To: Pasha Tatashin; +Cc: qemu-devel, Mark Cave-Ayland Hi Pasha, On Tue, Jun 27, 2017 at 7:59 PM, Pasha Tatashin <pasha.tatashin@oracle.com> wrote: > Hi, > > I am trying to evaluate the current qemu support for sparc64 processors. > First, it seems -smp is not supported for any processor, is this correct? > When I set -smp greater than 1, I am getting: > > qemu-system-sparc64: Number of SMP CPUs requested (2) exceeds max CPUs > supported by machine 'sun4u' (1) > > I've done some testing for all available sparc64 cpus + latest linux kernel: > > Fujitsu Sparc64 Working > Fujitsu Sparc64 III Exception 0x30 (DAE_side_effect_page) in OpenBios > Fujitsu Sparc64 IV Working > Fujitsu Sparc64 V Working > TI UltraSparc I Working > TI UltraSparc II Working > TI UltraSparc IIi Working > TI UltraSparc IIe Exception 0x28 (division_by_zero) in init_tick_ops > Can make it to work if is_hummingbird() is changed > to return 0. The IO stick, and OpenBios stick properties > are absent, so we have to default to %tick for now. > > Sun UltraSparc III Illegal instruction in cheetah_boot(): > wr %g0, %g1, %dcr > It appears dispatch control register is not implemented. > > Sun UltraSparc IIIi > Sun UltraSparc IV > Sun UltraSparc IV+ > Sun UltraSparc IIIi+ > In these four CPUs, I am getting exception 0x32 in > cheetah_generic_boot: stxa %g0, [ %g3 ] #ASI_DMMU The UltraSPARC III {,i,i+} and IV(+) MMUs are not implemented. IIi is the best for the sun4u target, I think. > Sun UltraSparc T1 > Sun UltraSparc T2 Same here. T2 is pretty much a stub currently. The emulation uses the same MMU as for T1. > Both of the above boot pretty far but fail in this function when tmpfs is > mounted: > direct_pcr_write(unsigned long reg_num, u64 val) > __asm__ __volatile__("wr %0, 0x0, %%pcr" : : "r" (val)); > > Seems like performance counter registers are not supported. Correct. As discussed off-list they are not. Btw, you can try to get through even without modifying qemu. Start qemu-system-sparc64 with -s -S options, connect to it with gdb, set a breakpoint before the instruction and skip it by modifying the %pc and %npc registers. > needed to add these to kernel parameters: > keep_bootcon -> to see where we are panicking > lpj=1000 -> jiffers could not calculate for some reason. > > NEC UltraSparc I Working > > Does this look right or may be I have missed something, and we can get some > of the Sun UltraSparc to work for example? > > Thank you, > Pasha > -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-06-29 9:57 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-27 17:59 [Qemu-devel] SPARC64 supported processors Pasha Tatashin 2017-06-29 6:57 ` Mark Cave-Ayland 2017-06-29 9:56 ` Artyom Tarasenko 2017-06-29 9:45 ` Artyom Tarasenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.