On 07/09/2020 16:05, Philippe Mathieu-Daudé wrote: > Hi Thiago, > > On 9/7/20 3:29 PM, Laurent Vivier wrote: >> On 07/09/2020 04:38, David Gibson wrote: >>> On Sun, Sep 06, 2020 at 04:20:10PM +0100, Peter Maydell wrote: >>>> On Fri, 4 Sep 2020 at 04:47, David Gibson <[email protected]> >>>> wrote: >>>>> >>>>> The following changes since commit >>>>> 67a7bfe560a1bba59efab085cb3430f45176d382: >>>>> >>>>> Merge remote-tracking branch >>>>> 'remotes/huth-gitlab/tags/pull-request-2020-09-03' into staging >>>>> (2020-09-03 16:58:25 +0100) >>>>> >>>>> are available in the Git repository at: >>>>> >>>>> git://github.com/dgibson/qemu.git tags/ppc-for-5.2-20200904 >>>>> >>>>> for you to fetch changes up to b172606ecf29a140073f7787251a9d70ecb53b6e: >>>>> >>>>> spapr_numa: move NVLink2 associativity handling to spapr_numa.c >>>>> (2020-09-04 13:40:09 +1000) >>>>> >>>>> ---------------------------------------------------------------- >>>>> ppc patch queue 2020-09-04 >>>>> >>>>> Next pull request for qemu-5.2. The biggest thing here is the >>>>> generalization of ARM's start-powered-off machine property to all >>>>> targets. This can fix a number of odd little edge cases where KVM >>>>> could run vcpus before they were properly initialized. This does >>>>> include changes to a number of files that aren't normally in my >>>>> purview. There are suitable Acked-by lines and Peter requested this >>>>> come in via my tree, since the most pressing requirement for it is in >>>>> pseries machines with the POWER secure virtual machine facility. >>>>> >>>>> In addition we have: >>>>> * The start of Daniel Barboza's rework and clean up of pseries >>>>> machine NUMA handling >>>>> * Correction to behaviour of the nvdimm= generic machine property on >>>>> pseries >>>>> * An optimization to the allocation of XIVE interrupts on KVM >>>>> * Some fixes for confused behaviour with kernel_irqchip when both >>>>> XICS and XIVE are in play >>>>> * Add HIOMAP comamnd to pnv flash >>>>> * Properly advertise the fact that spapr_vscsi doesn't handle >>>>> hotplugged disks >>>>> * Some assorted minor enhancements >>>> >>>> Hi -- this fails to build for Windows: >>>> >>>> ../../hw/ppc/spapr_numa.c: In function 'spapr_numa_fixup_cpu_dt': >>>> ../../hw/ppc/spapr_numa.c:77:5: error: unknown type name 'uint' >>>> uint vcpu_assoc_size = NUMA_ASSOC_SIZE + 1; >>>> ^ >>> >>> Huh, that's weird. My testing run was less thorough than I'd usually >>> do, because so many tests were broken on the master branch, but I was >>> pretty sure I did do successful mingw builds. >>> >>>> That should probably be using one of the standard C types. >>> >>> Done. >>> >>>> The 'check-tcg' tests for the linux-user static build also >>>> failed on an s390x test: >>>> >>>> CHECK debian-s390x-cross >>>> BUILD s390x-linux-user guest-tests with docker qemu/debian-s390x-cross >>>> RUN tests for s390x >>>> TEST threadcount on s390x >>>> Unhandled trap: 0x10003 >> >> This is EXCP_HALTED (include/exec/cpu-all.h) >> >> The message error comes from cpu_loop() in linux-user/s390x/cpu_loop.c. >> >> The trap can only come from accel/tcg/cpu-exec.c >> >> 679 int cpu_exec(CPUState *cpu) >> 680 { >> ... >> 688 if (cpu_handle_halt(cpu)) { >> 689 return EXCP_HALTED; >> 690 } >> >> and >> >> 428 static inline bool cpu_handle_halt(CPUState *cpu) >> 429 { >> 430 if (cpu->halted) { >> ... >> 441 if (!cpu_has_work(cpu)) { >> 442 return true; >> 443 } >> >> and >> >> 58 static bool s390_cpu_has_work(CPUState *cs) >> 59 { >> 60 S390CPU *cpu = S390_CPU(cs); >> 61 >> 62 /* STOPPED cpus can never wake up */ >> 63 if (s390_cpu_get_state(cpu) != S390_CPU_STATE_LOAD && >> 64 s390_cpu_get_state(cpu) != S390_CPU_STATE_OPERATING) { >> 65 return false; >> 66 } >> 67 >> 68 if (!(cs->interrupt_request & CPU_INTERRUPT_HARD)) { >> 69 return false; >> 70 } >> 71 >> 72 return s390_cpu_has_int(cpu); >> 73 } >> >> and in target/s390x/cpu.h: >> >> 772 #ifndef CONFIG_USER_ONLY >> 773 unsigned int s390_cpu_set_state(uint8_t cpu_state, S390CPU *cpu); >> 774 #else >> 775 static inline unsigned int s390_cpu_set_state(uint8_t cpu_state, >> S390CPU *cpu) >> 776 { >> 777 return 0; >> 778 } >> 779 #endif /* CONFIG_USER_ONLY */ >> 780 static inline uint8_t s390_cpu_get_state(S390CPU *cpu) >> 781 { >> 782 return cpu->env.cpu_state; >> 783 } >> >> As cpu_state is never set, perhaps in case of linux-user it should >> always return S390_CPU_STATE_OPERATING? >> >> Something like: >> >> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h >> index 035427521cec..8a8628fcdcc6 100644 >> --- a/target/s390x/cpu.h >> +++ b/target/s390x/cpu.h >> @@ -771,16 +771,20 @@ int s390_assign_subch_ioeventfd(EventNotifier >> *notifier, uint32_t sch_id, >> int vq, bool assign); >> #ifndef CONFIG_USER_ONLY >> unsigned int s390_cpu_set_state(uint8_t cpu_state, S390CPU *cpu); >> +static inline uint8_t s390_cpu_get_state(S390CPU *cpu) >> +{ >> + return cpu->env.cpu_state; >> +} >> #else >> static inline unsigned int s390_cpu_set_state(uint8_t cpu_state, >> S390CPU *cpu) >> { >> return 0; >> } >> -#endif /* CONFIG_USER_ONLY */ >> static inline uint8_t s390_cpu_get_state(S390CPU *cpu) >> { >> - return cpu->env.cpu_state; >> + return S390_CPU_STATE_OPERATING; >> } >> +#endif /* CONFIG_USER_ONLY */ > > Since this is the effect of your "target/s390x: Use start-powered-off > CPUState property" patch, can you have a look please? >
For information, the problem appears only with "--enable-debug-tcg" (I have also "--static --enable-linux-user --disable-system --disable-tools"). CC: David Hildenbrand (s390 TCG CPU maintainer) Thanks, Laurent
