--- tme/TODO 2018/04/24 16:37:52 1.1.1.1 +++ tme/TODO 2018/04/24 16:42:32 1.1.1.4 @@ -1,4 +1,8 @@ -the m68k exception vector table lists the spaces used for the different vectors +the sun2 mainbus signal handler needs to OR together like signals from +the different buses; right now the state of a signal on the mainbus is +just the state of the signal on the last bus that happened to call it +out. this will cause interrupts to get lost (but because of cooperative +threading, this probably isn't manifesting now). clean up posix-serial callouts to be like 3c400 @@ -26,5 +30,223 @@ an instruction fetch, we still might fau mid-instruction-fetch. this optimization would however remove a test and goto in the fast FETCH macros. -probably the way ENA_NONBOOT works on the sun2 is that all FC_SP -references go to the PROM +/* version enforcement: */ +#if !defined(TME_BUS_DEVICE_VERSION) || TME_VERSION_CURRENT_X(TME_BUS_DEVICE_VERSION) != 0 +#error "check your sources; version is now 0" +#endif + +/* includes: */ +#include +#undef TME_BUS_VERSION +#define TME_BUS_VERSION TME_VERSION_X(0, 0, 0) +#include + +sun-sc's slow cycle implementation is broken; it should use the new +bus-device dma support + +if a tlb_fill function invalidates previous TLBs, make sure that it +invalidates before it fills (since it may be filling the same +structure it wants to invalidate.) + +m68k: lowering the interrupt priority mask below 7 when the external +priority is 7 causes another NMI to be recognized. + +TLBs filled for DVMA space for the VME bus shouldn't refer to the +obmem bus fault handler, right? + +file a PR against NetBSD/sun3 1.6.x: +sys/arch/sun3/dev/if_ie.c:ie_readframe(), when NBPFILTER == 0, calls +ieget() with NULL for its int *to_bpf argument. this ultimately +causes a NULL dereference in (the inline expansion of) check_eh() - +witness a "clrl 0" instruction in the compiler output for +ie_readframe(). proper fix is to remove the *to_bpf = 0 in check_eh(). + +file a PR against NetBSD/sun3: +XXX FIXME - this hack works around a bug in NetBSD/sun3, present +since revision 1.49 of src/sys/arch/sun3/conf/GENERIC (when the +sun3x port was merged into the sun3 port). in this revision, the +declaration for cgtwo0 changed: + +-cgtwo0 at vmes0 addr 0xff400000 level 4 vect 0xA8 ++cgtwo0 at vme2 addr 0x400000 ipl 4 vect 0xA8 + +because the cg2mmap() function in src/sys/arch/sun3/dev/cg2.c +doesn't add the 0xff000000 mask to the configured physical +address (needed because the cgtwo is an A24 device), when Xsun +mmap()s the cgtwo it gets a mapping of physical address 0x400000 +in VME space instead of the correct 0xff400000. the sparc cgtwo +driver gets this right. + +- bus: DRQ(x) and DACK(x), with an UNSPEC +- ncr5380: bug where a SCSI callout deferred because of a higher-priority callout isn't put into later_callouts + +in ncr5380.c:_tme_ncr5380_bus_tlb_fill(), the structure assignment +of *tlb from *ncr5380->tme_ncr5380_dma_tlb may copy fields partially +and/or out-of-order, such that the subsequent relevance test succeeds +when it should fail? we should probably test at least the important, +invalidating fields in *ncr5380->tme_ncr5380_dma_tlb instead of the +local *tlb? XXX actually, ncr5380.c needs to use the new TLB +valid/invalid tests, and be made more thread-safe. + +in ncr5380.c:_tme_ncr5380_scsi_cycle(), we test if tme_scsi_dma_in +points to the internal FIFO to determine if the transfer was a read; +however, if the transfer was a write this value may be garbage (under +NDEBUG, it isn't initialized in _tme_ncr5380_callout()) that happens +to match the internal FIFO anyways. + +the SCSI DMA structure needs to be expanded to support tme_shared +pointers and bus boundary values, and scsi-bus.c needs to use +tme_memory_bus_read_buffer(), tme_memory_bus_write_buffer() as +appropriate. + +need barriers in the m68k read/write/fetch, etc. functions + +remove the locks argument from the generic bus-device DMA functions, since +elements are only supposed to have a single mutex (and provide a pointer +to the mutex in the struct tme_bus_device, or maybe have the mutex in the +struct tme_bus_device). + +sun4: log when cache and memerr become visible/invisible +sun4: log when FPU compliance changes + +bus-device-auto.sh: keep bus router from device structure in a local, +in case it gets changed during a callout + +ncr53c9x: the SS2 esp is really an ESP100A, not an ESP100. + +sparc: for long-lived idle types, print address when first detected + +sparc: most unimplemented instructions cause NULL dereferences from opcode table + +gtk-keyboard.c: some X servers actually *don't* give locking behavior +to the Caps_Lock, Num_Lock, etc., keysyms, and this causes problems. +see the comments in _tme_gtk_keyboard_x11_new(). + +sun4: FAILURE: SEVAR (60000004) Power-Up, Exp = 00000000, Obs = ffed9000 + +add [] to all tr character classes, so they work for SysV + +sparc: convert tme_sparc_ls_tlb_map from a struct tme_bus_tlb to a new struct type, +since it uses various fields that will disappear in the bus cycle transition. + +sparc64 recode: don't assist membar instructions +sparc64 recode: don't redispatch return instructions; instead they +should return a value for the TME_SPARC_IREG_PC_NEXT register, and we +should set pc_advance and reg_guest_pc so PCs won't get updated by the +TME_SPARC_RECODE_INSN_UPDATE_PCS code. (but what about a return in a +branch delay slot? - just add it to +_tme_sparc_recode_insn_branch_delay_bad()) + +sparc64 recode: make the %rcc flags thunk only do 64-bit flags (the +32-bit flags shouldn't be needed) + +recode: we must document that tme_recode_insns_thunk() REQUIRES that +guest read/write instructions THAT ARE READS have +TME_RECODE_OPERAND_ZERO for tme_recode_insn_operand_src[1] (this frees +tme_recode_insns_thunk() from having to skip _src[1] on a read). +this should be an assert(). + +tme_bus_tlb_map() - check that addr_offset can be a tme_bus_addr_t, +no matter what tme_bus_addr_t's size. + +sparc64 recode: TME_SPARC_RECODE_SRC_HASH_SIZE_ELEMENT assumes +that sizeof(tme_sparc_recode_src_key_t) >= sizeof(tme_recode_thunk_off_t) + +sparc64 FPU: the new operations (especially FMOVcc) are always +present, no matter what the architecture. this exposes us to guests. + +x86 recode: stack alignment correct for a read/write assist call on an +x86_64 host? + +SUN-ULTRA-1: make the onboard esp0 revision 2, and the onboard +ncr53c9x a variant esp200 + +sparc64 recode: a redispatch should probably encourage thunk +generation (otherwise, after a wrpsr we'll interpret instructions +until the next branch), something similar to the encouragement +at the end of the sparc-execute.c recode thunk running. + +sparc execute: note that the V8 execute_trap ISP description notes +that if a trap is taken preinstruction when annul != 0, the PCs are +just advanced past the annulled instruction when they are saved for +the trap (i.e., in the trap case, the annulled instruction isn't +fetched). if we put the annulled bit into tme_sparc, we wouldn't have +to force _tme_sparc_instruction_burst_remaining to be at least one +after an annulling branch (if the burst was zero, we'll fetch the +annulled instruction at the beginning of the next burst) and we'll get +better emulation (because a real CPU doesn't fetch an annulled +instruction when the previous instruction traps - but how could this +happen, anyways? how can you annul an instruction but take a trap +before it's fetched? maybe that's only possible by a trap for an +interrupt?) + +sparc preemptive threading: an std must execute atomically; we must +do one store instead of two. + +stp103x: there may be a race on setting TICK.INT_DIS, where you +may still get a tick interrupt afterwards? + +make a version of tme_misc_cycles_spin_until() that doesn't +do too many gettimeofday() calls? + +sparc64 recode: do we need to address-mask PC in +_tme_sparc_recode_recode()? + +sparc64 recode: we should address-mask the PC_next_nexts made +in the assist functions. + +sparc32 external: remove the interrupt acknowledge cycle + +make tme_sjlj_sleep_yield() and tme_sjlj_cond_sleep_yield() return +immediately if the time to sleep is zero (because otherwise, +tme_sjlj_yield() will think the thread is blocked). + +sparc64 recode assist: it's only necessary to set PC_next_next if +the instruction handler might redispatch; are there any assist +types where we know that the handler will not redispatch? + +replace some gettimeofday() calls with tme_gettimeofday(), +also with tme_thread_long() as needed. + +sunfb bus transition: instead of initializing the completion error, +tme_sunfb_bus_cycle_transition() should poison it and make sure that +the cycle handler defines it *and* the fast cycle types. + +sparc execute: check for an external check at the beginning of +tme_sparc_thread():TME_SPARC_MODE_EXECUTION, and truncate the +execution burst if true? + +sparc optimization: in tme_sparc${arch}_ls(), push the poisoning of an +unusable TLB entry before the address_map call, into the address_map +functions (and only if they trap). + +sparc: in tme_sparc${arch}_ls(), should a TME_SPARC_LSINFO_OP_ATOMIC +start out as TME_BUS_CYCLE_READ? this would at least make a TLB miss +report the access as a read. the ultrasparc manual isn't clear if +atomics are always reported in SFSR as writes. + +threading: any threading implementation must call tme_thread_long() as +needed, including in its own tme_*_yield() functions as needed. + +NetBSD/sparc (>=5.x only?): on some hosts and some debugging setups, +keys will unexpectedly repeat in the guest when large updates are +happening on the text console: + 1. original keypress, starts key repeat callout + 2. user process writes a lot to the console kd device + 3. kd.c:kd_putfb() does splsoftclock() and calls prom_putstr() + 4. while prom_putstr() is running, the key release interrupt + happens. since we're at splsoftclock(), the zs soft interrupt + for the key release is held pending. (the key repeat callout is + only cancelled in the soft interrupt path.) + 5. while prom_putstr() is running, the key repeat callout expires. + since we're at splsoftclock(), the callout is held pending. it + is now too late to avoid the key repeating. + 6. prom_putstr() finally finishes. the key repeat callout is called + (either before or after the zs soft interrupt, it doesn't matter) + and repeats the key. +in a non-debugging setup (-DNDEBUG, -DTME_NO_LOG, etc.) the emulator +seems fast enough that prom_putstr() finishes before the key repeat +callout expires, which is why this problem probably won't get fixed. +(before recode, we may have avoided the problem because the emulator +was actually too slow - the key release interrupt could have happened +even before we got to the prom_putstr() point.)