[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v3 4/6] xen/arm: Add save/restore support for guest core registers
On Thu, 2014-05-08 at 16:18 -0500, Wei Huang wrote: > This patch implements a save/resore support for ARM guest core > registers. > > Signed-off-by: Evgeny Fedotov <e.fedotov@xxxxxxxxxxx> > Signed-off-by: Wei Huang <w1.huang@xxxxxxxxxxx> > --- > xen/arch/arm/hvm.c | 263 > +++++++++++++++++++++++++++++++- > xen/include/public/arch-arm/hvm/save.h | 121 ++++++++++++++- > 2 files changed, 382 insertions(+), 2 deletions(-) > > diff --git a/xen/include/public/arch-arm/hvm/save.h > b/xen/include/public/arch-arm/hvm/save.h > index 8679bfd..18e5899 100644 > --- a/xen/include/public/arch-arm/hvm/save.h > +++ b/xen/include/public/arch-arm/hvm/save.h [...] > + /* return address (EL1 ==> EL0) */ > + uint64_t elr_el1; /* elr_el1, NA */ > + /* return address (EL2 ==> EL1) */ > + uint64_t pc64; /* elr_el2, elr_el2 */ The guest name of this register would be pc or r15, not elr_el2 which is the hyp mode exception return address. (I think the _el2 suffix should never appear in these structs) > + /* spsr registers */ > + uint32_t spsr_el1; /* spsr_el1, spsr_svc */ > + uint32_t spsr_fiq; /* NA, spsr_fiq */ > + uint32_t spsr_irq; /* NA, spsr_irq */ > + uint32_t spsr_und; /* NA, spsr_und */ > + uint32_t spsr_abt; /* NA, spsr_abt */ I think in general you can replace /* NA, .* */ with "32-bit only" and /* .*, NA */ with "64-bit only". and omit the comment in cases where everything matches. e.g. uint64_t vbar /* vbar, vbar */ > + > + /* stack pointers */ > + uint64_t sp_el0; /* sp_el0, NA */ > + uint64_t sp_el1; /* sp_el1, NA */ > + > + /* guest mode */ > + uint32_t cpsr; /* spsr_el2, spsr_el2 */ The guest register is just cpsr I think, spsr_el2 is a hypervisor mode ism. > + /* ======= Guest System Registers ======= > + * - multiplexed for AArch32 and AArch64 guests > + * - 64-bit preferred if needed (for 64-bit guests) > + * - architecture specific registers are noted specifically > + */ > + /* exception */ > + uint64_t vbar; /* vbar, vbar */ There's a bit of a mixture of v7 and v8 naming here. Can we try to consistently use the v8 naming (foo_el1/el0) for anything which is v8 only or common and only use v7 naming for 32-bit only registers. Or maybe we should be trying to use the "General names" as defined in section J or the ARMv8 ARM? Whatever we do it should be consistent. (I know Xen internally is a bit confused about this, but please lets try not to leak that into the public API). > + /* mmu related */ > + uint64_t ttbcr; /* ttbcr, ttbcr */ > + uint64_t ttbr0; /* ttbr0, ttbr0 */ > + uint64_t ttbr1; /* ttbr1, ttbr1 */ > + uint32_t dacr; /* NA, dacr32 */ > + > + uint64_t par; /* par, par */ > + uint64_t mair0; /* mair, mair0 */ > + uint64_t mair1; /* NA, mair1 */ mair0 and mair1 are only 32-bit. But actually I think the mapping is MAIR0==MAIR_EL1[31:0] and MAIR1==MAIR_EL1[63:32], so you should use that. > + /* fault status */ > + uint32_t ifar; /* ifar, ifar */ > + uint32_t ifsr; /* ifsr, ifsr */ > + uint32_t dfar; /* dfar, dfar */ > + uint32_t dfsr; /* dfsr, dfsr */ > + > + uint64_t far; /* far, far */ > + uint64_t esr; /* esr, esr */ I don't think there is a 32-bit ESR, since 32-bit has all the banked register CPSR.MODE stuff instead. I think the 32-bit ifar/dfar ifsr/dfsr have a mapping onto the 64-bit far etc. Table D1-81 in the ARMv8 ARM spells all that out. > + > + uint32_t afsr0; /* afsr0, afsr0 */ > + uint32_t afsr1; /* afsr1, afsr1 */ > + > + /* thumbee and jazelle */ > + uint32_t teecr; /* NA, teecr */ > + uint32_t teehbr; /* NA, teehbr */ > + > + uint32_t joscr; /* NA, joscr */ > + uint32_t jmcr; /* NA, jmcr */ > + > + /* control registers */ > + uint32_t sctlr; /* sctlr, sctlr */ > + uint32_t actlr; /* actlr, actlr */ > + uint32_t cpacr; /* cpacr, cpacr */ > + > + uint32_t csselr; /* csselr, csselr */ > + > + /* software management related */ > + uint32_t contextidr; /* contextidr, contextidr */ > + uint64_t tpidr_el0; /* tpidr_el0, tpidr_el0 */ > + uint64_t tpidr_el1; /* tpidr_el1, tpidr_el1 */ > + uint64_t tpidrro_el0; /* tpidrro_el0, tdidrro_el0 */ > +}; > +DECLARE_HVM_SAVE_TYPE(VCPU, 5, struct hvm_arm_cpu); > + > /* > * Largest type-code in use > */ > -#define HVM_SAVE_CODE_MAX 4 > +#define HVM_SAVE_CODE_MAX 5 > > #endif > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |