On 2019/12/24 12:45, Auger Eric wrote:
Hi Zenghui,
On 12/24/19 3:52 AM, Zenghui Yu wrote:
Hi Marc, Eric,
On 2019/12/23 22:07, Marc Zyngier wrote:
Hi Zenghui,
On 2019-12-23 13:43, Zenghui Yu wrote:
I noticed there is no userspace access callbacks for GICR_PENDBASER,
so this patch will make the PTZ field also 'Read As Zero' by userspace.
Should we consider adding a uaccess_read callback for GICR_PENDBASER
which just returns the unchanged vgic_cpu->pendbaser to userspace?
(Though this is really not a big deal. We now always emulate the PTZ
field to guest as RAZ. And 'vgic_cpu->pendbaser & GICR_PENDBASER_PTZ'
only indicates whether KVM will optimize the LPI enabling process,
where Read As Zero indicates never optimize..)
I don't think adding a userspace accessor would help much. All this
bit tells userspace is that the guest has programmed a zero filled
table. On restore, we'd avoid a rescan of the table if there was
no LPI mapped.
Yes, I agree.
And thinking of it, this fixes a bug for non-Linux guests: If you write
PTZ=1, we never clear it. Which means that if userspace saves and
restores
PENDBASER with PTZ set, we'll never restore the pending bits, which is
pretty bad (see vgic_enable_lpis()).
But I'm afraid I can't follow this point. After reading the code (with
Qemu) a bit further, the Redistributors are restored before the ITS.
This is also part of the kernel documentation:
Documentation/virt/kvm/devices/arm-vgic-its.txt (ITS restore sequence)
Yeah, I see. Thanks for the pointer, Eric!
Zenghui
So
there should be _no_ LPI has been mapped when we're restoring GICR_CTLR
and enabling LPI, which says we will not scan the whole pending table
and restore pending by vgic_enable_lpis()/its_sync_lpi_pending_table(),
regardless of what the PTZ is.
Instead, vgic_its_restore_ite()/vgic_v3_lpi_sync_pending_status() is
where we actually read the guest RAM and restore the LPI pending state.
yes the pending state is restored from
vgic_its_restore_ite/vgic_add_lpi/vgic_v3_lpi_sync_pending_status and
this path ignores the PTZ.
Thanks
Eric
Which means we will still do the right thing even for non-Linux guests.
Not sure if I've got things correctly here.
In the end, let's keep the patch as it is.
This patch on its own fixes more than one bug!
If so, just by luck ;-)
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
