Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Oct 06 2021, David Hildenbrand <david@redhat.com> wrote:

> On 06.10.21 12:59, Cornelia Huck wrote:
>> On Fri, Sep 24 2021, David Hildenbrand <david@redhat.com> wrote:
>> 
>>> On 23.09.21 17:31, Cornelia Huck wrote:
>>>> On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:
>>>>
>>>>> Looking into supporting virtio-mem
>>>>> a) without a shared zeropage for the memory backing of the device --
>>>>>      not allowing the driver to read unplugged memory
>>>>> b) on architectures with memory properties for RAM (e.g., s390x with
>>>>>      storage keys and storage attributes)
>>>>> requires extension of the spec to handle both cases cleanly and describe
>>>>> the expected semantics.
>>>>>
>>>>> I'll open a github issue soon; in the meantime, I'll work on the actual
>>>>> implementation in QEMU and Linux.
>>>>
>>>> LGTM, but would like a second opinion.
>>> Thanks Conny! I'll wait for more feedback before I open a github issue /
>>> request a vote.
>> 
>> Anyone else interested in looking at this?
>> 
>> Otherwise, I'd say just open an issue and request a vote.
>> 
>
> Would it make sense to split it into two parts?
>
> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE: #1-#4
> Memory properties: #5
>
> Then I could resend via the split and request two votes.

From my POV, this can go in via one vote[*]. We can also split this up,
if you think that makes sense.

[*] Less votes == less work for me :)