Messages in this thread | | | Subject | Re: [PATCH v5 20/23] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor | From | Zenghui Yu <> | Date | Fri, 20 Mar 2020 11:53:10 +0800 |
| |
Hi Marc,
On 2020/3/19 20:10, Marc Zyngier wrote: >> But I wonder that should we use nassgireq to *only* keep track what >> the guest had written into the GICD_CTLR.nASSGIreq. If not, we may >> lose the guest-request bit after migration among hosts with different >> has_gicv4_1 settings. > > I'm unsure of what you're suggesting here. If userspace tries to set > GICD_CTLR.nASSGIreq on a non-4.1 host, this bit will not latch.
This is exactly what I *was* concerning about.
> Userspace can check that at restore time. Or we could fail the > userspace write, which is a bit odd (the bit is otherwise RES0). > > Could you clarify your proposal?
Let's assume two hosts below. 'has_gicv4_1' is true on host-A while it is false on host-B because of lack of HW support or the kernel parameter "kvm-arm.vgic_v4_enable=0".
If we migrate guest through A->B->A, we may end-up lose the initial guest-request "nASSGIreq=1" and don't use direct vSGI delivery for this guest when it's migrated back to host-A.
This can be "fixed" by keep track of what guest had written into nASSGIreq. And we need to evaluate the need for using direct vSGI for a specified guest by 'has_gicv4_1 && nassgireq'.
But if it's expected that "if userspace tries to set nASSGIreq on a non-4.1 host, this bit will not latch", then this shouldn't be a problem at all.
Anyway this is not a big deal to me and I won't complain about it in the future ;-) Either way, for this patch:
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Thanks
| |