OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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?
> 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 :)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]