qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH qemu] spapr: Force 32bit when resetting a core


From: Peter Maydell
Subject: Re: [PATCH qemu] spapr: Force 32bit when resetting a core
Date: Wed, 19 Jan 2022 10:16:35 +0000

On Wed, 19 Jan 2022 at 04:03, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
>
>
> On 1/17/22 03:45, Peter Maydell wrote:
> > On Fri, 7 Jan 2022 at 07:29, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >>
> >> "PowerPC Processor binding to IEEE 1275" says in
> >> "8.2.1. Initial Register Values" that the initial state is defined as
> >> 32bit so do it for both SLOF and VOF.
> >>
> >> This should not cause behavioral change as SLOF switches to 64bit very
> >> early anyway. As nothing enforces LE anywhere, this drops it for VOF.
> >>
> >> The goal is to make VOF work with TCG as otherwise it barfs with
> >> qemu: fatal: TCG hflags mismatch (current:0x6c000004 rebuilt:0x6c000000)
> >
> > If you get this assert it means that something is changing
> > the CPU state and not calling the function to recalculate
> > the hflags (which are basically caching part of the CPU state).
> > So I don't know whether this patch is correct or not in updating
> > MSR bits, but in any case I think it is only masking the
> > missing-hflags-update that is causing the assertion...
>
>
> If we emulate a bare metal machine, then most likely we want MSR_SF
> (==64bit) set. But this particular case is paravirtual pseries/spapr and
> it requires special handling so spapr_reset_vcpu() seems to be the right
> place.

That may be so, but my point remains: if you are getting hflags
mismatch asserts then something is failing to recalculate the
hflags after updating CPU state.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]