Re: [PATCH v2 00/14] s390x: virtio-mem support

[Christian Borntraeger <borntraeger@linux.ibm.com>]

Am 16.12.24 um 22:18 schrieb David Hildenbrand:
> Thanks, queued to
> 
> https://github.com/davidhildenbrand/qemu.git mem-next
> On 13.12.24 15:26, David Hildenbrand wrote:
>> On 13.12.24 13:35, Thomas Huth wrote:
>>> On 12/12/2024 22.52, David Hildenbrand wrote:
>>>> On 13.11.24 15:46, David Hildenbrand wrote:
>>>>> On 08.10.24 12:54, David Hildenbrand wrote:
>>>>>> Based on current master.
>>>>>>
>>>>>> There is really not much left to do on s390x, because virtio-mem already
>>>>>> implements most things we need today (e.g., early-migration,
>>>>>> unplugged-inaccessible). The biggest part of this series is just doing what
>>>>>> we do with virtio-pci, wiring it up in the machine hotplug handler and ...
>>>>>> well, messing with the physical memory layout where we can now exceed
>>>>>> initial RAM size and have sparsity (memory holes).
>>>>>>
>>>>>> I tested a lot of things, including:
>>>>>>      * Memory hotplug/unplug
>>>>>>      * Device hotplug/unplug
>>>>>>      * System resets / reboots
>>>>>>      * Migrate to/from file (including storage attributes under KVM)
>>>>>>      * Basic live migration
>>>>>>      * Basic postcopy live migration
>>>>>>
>>>>>> More details on how to use it on s390x -- which is pretty much how
>>>>>> we use it on other architectures, except
>>>>>> s/virtio-mem-pci/virtio-mem-ccw/ --- is in the last patch.
>>>>>>
>>>>>> This series introduces a new diag(500) "STORAGE LIMIT" subcode that will
>>>>>> be documented in the kernel and at [2] once this+kernel part go upstream.
>>>>>>
>>>>>> There are not many s390x-specific virtio-mem future work items, except:
>>>>>> * Storage attribute migration might be improved
>>>>>> * We might want to reset storage attributes of unplugged memory
>>>>>>       (might or might not be required for upcoming page table reclaim in
>>>>>>        Linux; TBD)
>>>>>>
>>>>>> The Linux driver is available at [3].
>>>>>>
>>>>>> [1] https://lkml.kernel.org/r/20240906101658.514470-1-pbonzini@redhat.com
>>>>>> [2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
>>>>>> [3] https://lkml.kernel.org/r/20240910191541.2179655-6-david@redhat.com
>>>>>
>>>>> Gentle ping (and thanks to Thomas for the review!).
>>>>>
>>>>> I assume the kernel portion will go upstream in the next merge window.
>>>>> I'd like get the QEMU parts merged soon after that.
>>>>>
>>>>> 9.2 is going to get released in roughly one month, so there is still time.
>>>>
>>>> In the meantime, 9.2 was released. I don't have any changes planned. Series
>>>> still applies to current master, I'll do a quick test tomorrow.
>>>>
>>>>>
>>>>> @Thomas, this is mostly s390x stuff, so I guess it should go through the
>>>>> s390x tree? But I could also take this through my "memory devices" tree.
>>>>
>>>> @Thomas, any thoughts?
>>>
>>> I'm fine either way - feel free to put it into your tree, otherwise I'll
>>> pick it up likely sometime next week.
>>
>> Okay, let me let this sit here for a couple days longer and retest it
>> next week. I can queue it then, as another required patch ("virtio-mem:
>> unplug memory only during system resets, not device resets") still sits
>> in my tree all-lonely. :)
> 
> Testing revealed no surprised.
> 
> Queued to
> 
> https://github.com/davidhildenbrand/qemu.git mem-next

Thank you for doing it. Awesome work.