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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 4/5] hw: arm_gic: Support setting/getting binary point reg
Date: Sat, 14 Sep 2013 10:46:37 +0100

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.

-- PMM



reply via email to

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