qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 6/7] monitor: "i": Add ARM specifics


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [PATCH 6/7] monitor: "i": Add ARM specifics
Date: Wed, 6 May 2015 15:32:46 +0100
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Wed, 6 May 2015, Paolo Bonzini wrote:
> On 06/05/2015 16:12, Richard Henderson wrote:
> >> Can
> >> > we rely on the env/CPUState always being up to date during
> >> > target_disas (which happens at translate time?) or will we need to go
> >> > field by field to make sure any env updates explicitly occur before
> >> > target_disas?
> > I *think* so, but it's a near thing.  The path goes
> > 
> >  tb_find_fast:
> >   cpu_get_tb_cpu_state, fill fill in flags for TB from current ENV state.
> >   tb_find_slow,
> >     tb_gen_code, using those same flags.
> > 
> > There's the edge case of re-translation, but I'm going to assert that cpu 
> > mode
> > changes ought not happen in that context.  Doing otherwise means that the
> > kernel has just switched modes, the translator has failed to end the TB, and
> > the new code has faulted immediately.
> > 
> > What I don't know is if we can, at the moment, canonicalize on TB flags.  If
> > the monitor were to use cpu_get_tb_cpu_state, I know it would work when 
> > using
> > TCG, but I don't know if we keep all the same data up-to-date in KVM or XEN 
> > modes.
> 
> We do for KVM.
> 
> As far as I know, Xen doesn't have CPU state at all, not even in
> fully-virtualized mode.  The CPU state is held (and serialized during
> migration) by the hypervisor.

Yes, that is correct, QEMU is only used as device emulator on Xen.



reply via email to

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