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@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? oh, accessor for ABPR, got it. > > I will rename to bpr and abpr. > > -Christoffer -- Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
