[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 00/30] ppc-for-5.2 queue 20200904
From: |
David Gibson |
Subject: |
Re: [PULL 00/30] ppc-for-5.2 queue 20200904 |
Date: |
Tue, 8 Sep 2020 09:50:59 +1000 |
On Mon, Sep 07, 2020 at 09:46:28PM +0200, Philippe Mathieu-Daudé wrote:
> On 9/7/20 7:26 PM, Laurent Vivier wrote:
> > On 07/09/2020 18:29, Laurent Vivier wrote:
> >> On 07/09/2020 16:51, Cornelia Huck wrote:
> >>> On Mon, 7 Sep 2020 16:31:24 +0200
> >>> Laurent Vivier <lvivier@redhat.com> wrote:
> >>>
> >>>> 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:
> >>>
> >>>>>>>> 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?
> >>>
> >>> Possibly, we should not have any state handling for linux-user.
> >>>
> >>
> >> I did that, but now 390_cpu_has_work() is false because
> >> CPU_INTERRUPT_HARD is not set in cs->interrupt_request.
> >>
> >> I think we should not enter in cpu_loop() with halted set to 1.
> >>
> >> Before the patch of this series, s390_cpu_reset() is called twice, and
> >> on the second call, halted is already 0.
> >>
> >> With start_powered_off set to true in initfn, on the first reset
> >> "halted" is 0 and on the second it is 1 (because it has been copied from
> >> start_powered_off) and so cpu_loop() starts with halted set to 1 and fails.
> >
> > What is happening:
> >
> > [without start_powered_off]
> >
> > 1- halted is set to 1 in s390x_cpu_initfn()
> > 2- halted is set to 0 in s390x_cpu_reset() by parent_reset()
> > (cpu_common_reset()
> > 3- cpu_loop() is always entered with halted set to 0
> >
> > [with start_powered_off]
> >
> > 1- halted is set to start_powered_off (1) in s390x_cpu_reset() by
> > parent_reset() (cpu_common_reset()
> > 2- cpu_loop() is always entered with halted set to 1
> >
> > So in the first case, cpu_loop() is always started with halted set to 0
> > and in the second case with halted set to 1.
> >
> > And I think, with linux-user, it should never be started with halted set
> > to 1.
> >
> > We can't add a "#ifdef CONFIG_USER_ONLY" in hw/core/cpu.c to set halted
> > to 0 because it is in the common files, but we can do:
> >
> > diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
> > index 73d7d6007e8e..749cd548f0f3 100644
> > --- a/target/s390x/cpu.c
> > +++ b/target/s390x/cpu.c
> > @@ -291,9 +291,9 @@ static void s390_cpu_initfn(Object *obj)
> > S390CPU *cpu = S390_CPU(obj);
> >
> > cpu_set_cpustate_pointers(cpu);
> > - cs->start_powered_off = true;
> > cs->exception_index = EXCP_HLT;
> > #if !defined(CONFIG_USER_ONLY)
> > + cs->start_powered_off = true;
> > object_property_add(obj, "crash-information", "GuestPanicInformation",
> > s390_cpu_get_crash_info_qom, NULL, NULL, NULL);
> > cpu->env.tod_timer =
>
> This looks like the correct fix indeed :)
> (Maybe worth adding a comment around).
>
> Thanks for investigating!
Yes, thanks for figuring this out. I'll fix up my PR accordingly and
resend today.
--
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/~dgibson
signature.asc
Description: PGP signature
- [PULL 27/30] spapr: introduce SpaprMachineState::numa_assoc_array, (continued)
- [PULL 27/30] spapr: introduce SpaprMachineState::numa_assoc_array, David Gibson, 2020/09/03
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Peter Maydell, 2020/09/06
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, David Gibson, 2020/09/06
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Laurent Vivier, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Philippe Mathieu-Daudé, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Laurent Vivier, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Cornelia Huck, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Laurent Vivier, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Laurent Vivier, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Philippe Mathieu-Daudé, 2020/09/07
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904,
David Gibson <=
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Cornelia Huck, 2020/09/08
- Re: [PULL 00/30] ppc-for-5.2 queue 20200904, Thiago Jung Bauermann, 2020/09/08