On Tue, 2016-09-27 at 11:30 +0200, Cédric Le Goater wrote:
> On 09/27/2016 11:10 AM, Cédric Le Goater wrote:
> >
> > >
> > > >
> > > > +#include <libfdt.h>
> > > > +
> > > > +static void xscom_complete(uint64_t hmer_bits)
> > > > +{
> > > > + CPUState *cs = current_cpu;
> > >
> > > Hmm.. is current_cpu a safe thing to use in the case of KVM or MTTCG?
> >
> > yes, as we are running under cpu_exec when doing this call.
>
> well, this is not true under the monitor.
>
> So we will have to come up with something to handle xscom read/writes
> from the monitor. Could we use first_cpu in that case ?
Well, we'll need to find the chip etc... I think the XSCOM bridge (or bus)
should have special methods for the monitor that don't update HMER but
print out the status instead.
Cheers,
Ben.
> Thanks,
>
> C.
>
> >
> > >
> > > >
> > > > + PowerPCCPU *cpu = POWERPC_CPU(cs);
> > > > + CPUPPCState *env = &cpu->env;
> > > > +
> > > > + cpu_synchronize_state(cs);
> > > > + env->spr[SPR_HMER] |= hmer_bits;
> > > > +
> > > > + /* XXX Need a CPU helper to set HMER, also handle gneeration
> > > > + * of HMIs
> > > > + */
> >
> > Ben,
> >
> > The CPU helper would be to replicate the value of the SPR_HMER in all
> > the threads of the core I guess ?
> >
> > Thanks,
> >
> > C.
> >
