[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [RFC 1/3] hw/intc/arm_gicv3_its: Don't abort on table sav
From: |
Auger Eric |
Subject: |
Re: [Qemu-arm] [RFC 1/3] hw/intc/arm_gicv3_its: Don't abort on table save/restore |
Date: |
Tue, 17 Oct 2017 14:54:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi Peter,
On 12/10/2017 13:54, Peter Maydell wrote:
> On 27 September 2017 at 15:56, Eric Auger <address@hidden> wrote:
>> The ITS is not properly reset at the moment. It is possible the
>> GITS_BASER<n>.valid is set and the in-kernel ITS caches are not
>> empty (list of devices, collections, LPIs) while data structures
>> in guest RAM are invalid/inconsistent.
>>
>> For instance, this happens after a guest shutdown -r now or a
>> system reset, if we save the state before the guest re-writes
>> the ITS registers or map devices, the table save ioctl may
>> produce a QEMU abort.
>>
>> Until there is a proper reset implemented, let's unplug the
>> consistency error checking.
>>
>> The reset issue will be fixed in subsequent patches.
>>
>> Signed-off-by: Eric Auger <address@hidden>
>> Reported-by: wanghaibin <address@hidden>
>
> When in particular does this cause an abort -- when we're
> trying to save the state in these edge cases, or when we're
> trying to restore it?
Both.
After a guest reset, device GITS_BASER<n> may point to an L1 device
table that is not valid anymore. In that case device table save IOTCL
returned -EINVAL and we aborted.
On restore we had a bug in case all data in the table is invalid. In
that case as well we currently abort.
What does the kernel do -- is it just
> rejecting the attempt, or might it actually have done bad
> things to guest memory ?
On Save, in case the GITS_BASER points to an invalid linear device tree
table but the page still corresponds to a visible gfn window, this
memory could be overwritten by the kernel.
Thanks
Eric
>
> thanks
> -- PMM
>