On 22.12.2017 10:08, Christian Borntraeger wrote: > > > On 12/21/2017 01:00 PM, David Hildenbrand wrote: >> On 20.12.2017 13:23, Christian Borntraeger wrote: >>> FWIW, this patch set has survived some testing on my side (with storage >>> keys, with VSIE, with both), so I would say that after a respin with some >>> patch sqashing we give it some more days for the last reviews and then apply >>> the whole thing via a topic branch via Martins s390 tree. I will merge >>> this branch as well to solve the potential conflicts with >>> Davids patch ( s390x/mm: cleanup gmap_pte_op_walk() ) which is still >>> pending in my tree >>> >> >> "postcopy works every second try, seems to be QEMU or my setup". >> Shouldn't we first understand why? gmap is a very sensible topic and we >> should rather spend more time understanding everything. We don't want >> guest escalation bugs. > > > I somehow missed that in the cover letter. Yes we should make sure that this works ( > on the other hand I usually blame postcopy because userfault makes several assumptions > which are somewhat "brave". See the empty zero page issue, which could in theory also break > if a postcopy guest does some clever ballooning in and out). But anyway I will have a look > after christmas into postcopy. > > FWIW; Martin and I looked over the patches and they seem good enough (after we fixed postcopy). > I also did some testing on that and it seems to work fine so far (including classic migration). > Postcopy returns with this on the source and results in a paused VM which can be resumed without any problem: qemu-system-s390x: RP: Received invalid message 0x0000 length 0x0000 This doesn't tell me anything, but Peter Xu seems to have a Qemu series wich improves postcopy error handling. I'll try it later today. A second postcopy migration with the resumed VM succeeds. The VM and its VSIE guests survive a memtester run and don't log any errors. The destination does not log any errors... All in all I'm not really concerned about postcopy although it certainly needs fixing and I'll have a closer look this week. @David: The complicated parts are the new VSIE modes and the splitting. If you could have a look at that I'd really appreciate it.
Attachment:
signature.asc
Description: OpenPGP digital signature
