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 4/5] virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE


On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> Until now, we allowed a driver to read unplugged memory within the
> usable device-managed region: this simplified bring-up of virtio-mem in
> Linux quite a bit, especially when it came to physical memory dumping.
>
> When the device is using a memory backend that supports a shared
> zeropage, such as virtio-mem in QEMU under Linux on anonymous memory, the
> old behavior could be realized easily.
>
> However, when using other memory backends (such as hugetlbfs or shmem)
> or architectures, such as s390x, where a shared zeropage either does not
> exist or cannot be used, letting the driver read unplugged memory can
> result in undesired memory consumption in the hypervisor. The device
> wants to make sure that the guest is aware and will not read unplugged
> memory, not even in corner cases.
>
> In the meantime, the Linux implementation matured such that it will no
> longer access unplugged memory, for example, during kdump, when reading
> /proc/kcore, or via (now removed) /dev/kmem.
>
> Similar to VIRTIO_F_ACCESS_PLATFORM, this change will be disruptive and
> require driver adaptions -- even if it's just accepting the new feature.
> Devices are expected to only set the bit when really required, to keep
> existing setups working.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>



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