On Sat, Sep 14, 2013 at 10:46:37AM +0100, Peter Maydell wrote: > On 14 September 2013 02:52, Christoffer Dall > <christoffer.dall@xxxxxxxxxx> 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? I will rename to bpr and abpr. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
