On 31/03/2020 18:08, Greg Kurz wrote:
> On Tue, 31 Mar 2020 13:59:01 +1100
> Alexey Kardashevskiy wrote:
>
>>
>>
>> On 31/03/2020 11:44, David Gibson wrote:
>>> On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
>>
On Tue, 31 Mar 2020 13:59:01 +1100
Alexey Kardashevskiy wrote:
>
>
> On 31/03/2020 11:44, David Gibson wrote:
> > On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
> >> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
> >> to be presented a new boot-time device tree a
On 31/03/2020 11:44, David Gibson wrote:
> On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
>> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
>> to be presented a new boot-time device tree after CAS negotiation.
>> CAS-generated resets rely on qemu_system_reset_requ
On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
> to be presented a new boot-time device tree after CAS negotiation.
> CAS-generated resets rely on qemu_system_reset_request() which has
> the particularity of dropping t
The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
to be presented a new boot-time device tree after CAS negotiation.
CAS-generated resets rely on qemu_system_reset_request() which has
the particularity of dropping the main loop lock at some point. This
opens a window where migratio
