[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC 2/5] s390x: implement diag260

From: David Hildenbrand
Subject: Re: [PATCH RFC 2/5] s390x: implement diag260
Date: Mon, 20 Jul 2020 17:43:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

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!


David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]