On 20.07.20 16:43, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 07:51:27PM +0200, David Hildenbrand wrote:
>>> Regarding documentation (some linked in the cover letter), so far I have
>>> (generic/x86-64)
>>>
>>> 1. https://virtio-mem.gitlab.io/
>>> 2. virtio spec proposal [1]
>>> 3. QEMU 910b25766b33 ("virtio-mem: Paravirtualized memory hot(un)plug")
>>> 4. Linux 5f1f79bbc9 ("virtio-mem: Paravirtualized memory hotplug")
>>> 5. Linux cover letter [2]
>>> 6. KVM forum talk [3] [4]
>>>
>>> As your questions go quite into technical detail, and I don't feel like
>>> rewriting the doc here :) , I suggest looking at [2], 1, and 5.
>>
>> Sorry, I suggest looking at [3] (not [2]) first. Includes pictures and a
>> comparison to memory ballooning (and DIMM-based memory hotplug).
>
> Ok, thanks for the pointers!
Thanks for having a look. Once the s390x part is in good shape, I'll add
proper documentation (+spec updates regarding exact system reset
handling on s390x).
>
> So I would go for what you suggested with option 2: provide a new
> diagnose which tells the kernel where the memory device area is
> (probably just start + size?), and leave all other interfaces alone.
Ha, that's precisely what I hacked previously today :) Have a new
diag500 ("KVM hypercall") subcode (4) to give start+size of the area
reserved for memory devices. Will send a new RFC this week to showcase
how it would look like.
>
> This looks to me like the by far "cleanest" solution which does not
> add semantics to existing interfaces, where it is questionable if this
> wouldn't cause problems in the future.
Yes, same thoughts over here!
--
Thanks,
David / dhildenb
