[PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
eric.auger at redhat.com
Wed Apr 26 01:26:24 PDT 2017
On 25/04/2017 12:43, Peter Maydell wrote:
> On 14 April 2017 at 11:15, Eric Auger <eric.auger at redhat.com> wrote:
>> Add description for how to save GICV3 LPI pending bit into
>> guest RAM pending tables.
>> Signed-off-by: Eric Auger <eric.auger at redhat.com>
>> v5: creation
>> Documentation/virtual/kvm/devices/arm-vgic-v3.txt | 6 ++++++
>> 1 file changed, 6 insertions(+)
>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> index c1a2461..9293b45 100644
>> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> +++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> @@ -167,11 +167,17 @@ Groups:
>> request the initialization of the VGIC, no additional parameter in
>> + KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES
>> + save all LPI pending bits into guest RAM pending tables.
>> + The first kB of the pending table is not altered by this operation.
>> -ENXIO: VGIC not properly configured as required prior to calling
>> this attribute
>> -ENODEV: no online VCPU
>> -ENOMEM: memory shortage when allocating vgic internal data
>> + -EFAULT: Invalid guest ram access
>> + -EBUSY: One or more VCPUS are running
> When does the -EFAULT return happen? (if the guest points GITS_BASER<n>
> etc at invalid memory, presumably?)
Yes that's correct, when GICR_PENDBASER contains a bad GPA.
How does the QEMU migration code
> handle this case? Failing migration because the guest has done something
> silly doesn't seem too palatable, but trying to avoid that could be
> more effort than an obscure corner case really merits.
The kvm_device_access will cause an abort() as for other errors returned
> -- PMM
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
More information about the linux-arm-kernel