Re: [PATCH] s390x: Clear RAM on diag308 subcode 3 reset

["David Hildenbrand (Red Hat)" <david@kernel.org>]

>>>        /*
>>>         * Temporarily drop the record/replay mutex to let rr_cpu_thread_fn()
>>> @@ -479,6 +480,7 @@ static void s390_machine_reset(MachineState *machine,
>>> ResetType type)
>>>        switch (reset_type) {
>>>        case S390_RESET_EXTERNAL:
>>>        case S390_RESET_REIPL:
>>> +    case S390_RESET_REIPL_CLEAR:
>>>            /*
>>>             * Reset the subsystem which includes a AP reset. If a PV
>>>             * guest had APQNs attached the AP reset is a prerequisite to
>>> @@ -489,6 +491,10 @@ static void s390_machine_reset(MachineState *machine,
>>> ResetType type)
>>>                s390_machine_unprotect(ms);
>>>            }
>>> +        if (reset_type == S390_RESET_REIPL_CLEAR) {
>>> +            ram_block_discard_range(rb, 0 , qemu_ram_get_used_length(rb));
>>> +        }
>>> +

...

>>
>>
>>
>> Do I see that right that this patch never made it into qemu master? IIRC
>> Matt has clarified all concerns?
> 
> I was hoping to see a reply from David that he's fine with the patch now...
> David?

Staring at this again, one more point regarding userfaultfd: doing the 
discard on the destination while postcopy is active might be problematic.

I don't remember all details, but I think that if we have the following:

1) Migrate page X to dst
2) Discard page X on dst
3) Access page X on dst

that postcopy_request_page()->migrate_send_rp_req_pages() would assume 
that the page was already transferred (marked received in the receive 
bitmap during 1) ) and essentially never place a fresh zeropage during 
3) to be stuck forever.

-- 
Cheers

David