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 christoffer.dall@linaro.org 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