qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/7] ppc: Make kvm_arch_put_registers


From: David Gibson
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/7] ppc: Make kvm_arch_put_registers() put *all* the registers
Date: Sat, 18 Aug 2012 02:24:56 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Aug 17, 2012 at 03:58:08PM +0200, Alexander Graf wrote:
> On 08/15/2012 06:33 AM, David Gibson wrote:
> >At least when invoked with high enough 'level' arguments,
> >kvm_arch_put_registers() is supposed to copy essentially all the cpu state
> >as encoded in qemu's internal structures into the kvm state.  Currently
> >the ppc version does not do this - it never calls KVM_SET_SREGS, for
> >example, and therefore never sets the SDR1 and various other important
> >though rarely changed registers.
> >
> >Instead, the code paths which need to set these registers need to
> >explicitly make (conditional) kvm calls which transfer the changes to kvm.
> >This breaks the usual model of handling state updates in qemu, where code
> >just changes the internal model and has it flushed out to kvm automatically
> >at some later point.
> >
> >This patch fixes this for Book S ppc CPUs by adding a suitable call to
> >KVM_SET_SREGS and als to KVM_SET_ONE_REG to set the HIOR (the only register
> >that is set with that call so far).  This lets us remove the hacks to
> >explicitly set these registers from the kvmppc_set_papr() function.
> 
> HIOR is a read-only register from the guest's point of view when
> running in PAPR mode, so we don't need to sync it back again. The
> same goes for SDR1, though resetting that is valid for non-PAPR
> guests.

*When running in PAPR mode*, which we aren't always.  System resets
are so rare that there's really no point optimizing register sets out
of it, so we might as well set HIOR and SDR1 on every reset, then it's
correct both for PAPR and non-PAPR mode.

> Overall, does a normal system reset on PPC guarantee that the SRs
> and SLBs are reset? At least OpenBIOS boots up in real mode and
> overwrites all SR/SLB entries while still in real mode.

I don't know, but it's not really relevant here.  What this does is
make sure that KVM state is synced with qemu state on reset.  That
means that whatever reset handlers do to the qemu state - and that's
what they usually operate on - will get reflected in KVM state when
the guest executes again.

-- 
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



reply via email to

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