qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/5] hw: arm_gic: Support setting/getting binary


From: Christoffer Dall
Subject: Re: [Qemu-devel] [PATCH 4/5] hw: arm_gic: Support setting/getting binary point reg
Date: Thu, 19 Sep 2013 21:03:41 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Sep 19, 2013 at 08:48:35PM +0100, Christoffer Dall wrote:
> On Sat, Sep 14, 2013 at 10:46:37AM +0100, Peter Maydell wrote:
> > On 14 September 2013 02:52, Christoffer Dall
> > <address@hidden> wrote:
> > > On Fri, Sep 06, 2013 at 03:41:04PM +0100, Peter Maydell wrote:
> > >> The TCG QEMU GIC model is currently adopting the
> > >> "GIC without Security Extensions" model, which implies
> > >> that we should be implementing GIC_ABPR too. What
> > >> model does KVM's in-kernel vGIC use? (ie what state
> > >> does it put into binary_point[0] and [1] on save/load)?
> > >>
> > > We put whatever the guest writes into the GICV_BPR and GICV_ABPR, but
> > > the in-kernel distributor does not care about priorities at all and
> > > considers all interrupts to be group 0 interrupts, which just happens to
> > > work for Linux.
> > >
> > > So yes, we should implement the GIC_ABPR, but there's no need for it
> > > yet.  But, if I don't add these fields the guest will (by reading the
> > > GICC_[A]BPR registers) be able to tell it was migrated, but it will not
> > > influence anything on the distributor level.  Therefore, by adding these
> > > fields we support the kernel's limited model fully without adding a
> > > bunch of code that we can't really test in real life anyhow, and it
> > > doesn't prevent us from adding full grouping support later on.
> > 
> > I agree we should have the fields for KVM's benefit. I think we
> > should also add simple reads-as-written code in the TCG
> > side so they're both accessible. State that the TCG implementation
> > can't access is a bit weird. We should probably also call
> > the fields bpr[NCPU] and abpr[NCPU] or something, so they're
> > a little more self-documenting about what they represent.
> > 
> I already added the accessors for the TCG side?

oh, accessor for ABPR, got it.

> 
> I will rename to bpr and abpr.
> 
> -Christoffer

-- 
Christoffer



reply via email to

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