From: David Hildenbrand <david@redhat.com> To: linux-kernel@vger.kernel.org Cc: virtualization@lists.linux-foundation.org, linux-mm@kvack.org, David Hildenbrand <david@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Marek Kedzierski <mkedzier@redhat.com>, Hui Zhu <teawater@gmail.com>, Sebastien Boeuf <sebastien.boeuf@intel.com>, Pankaj Gupta <pankaj.gupta.linux@gmail.com>, Wei Yang <richard.weiyang@linux.alibaba.com> Subject: [PATCH v1 2/2] virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE Date: Mon, 15 Feb 2021 13:24:21 +0100 [thread overview] Message-ID: <20210215122421.27964-1-david@redhat.com> (raw) In-Reply-To: <20210215122143.27608-1-david@redhat.com> The spec currently states that while unplugged memory should not be read, the device has to allow for reading unplugged memory inside the usable region. The primary motivation for this default handling was that in some corner cases in Linux, unplugged memory inside added Linux memory blocks (and exposed via /proc/iomem as "System RAM (...)") might still be read. So to support SBM (Sub Block Mode) in Linux cleanly, the device has to support reading unplugged memory. One example is kdump(): when makedumpfile isn't used or when an older version is used, PG_offline is ignored and unplugged memory might still be read. Another corner-case example is /dev/mem: even with STRICT_DEVMEM, some unplugged memory might be read by tools automatically. For example, QEMU won't support reading unplugged memory with file-backed memory backends initially: there is no shared zero page, thus, special handling will be required in the future to allow for reading unplugged memory when using a file backing (tmpfs/shmem, hugetlbfs, ...). The device will indicate VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and fail device initialization if the driver does not indicate support. The result is that Linux won't be able to make use of any memory without this change. With this change, Linux will at least be able to (un)plug in Linux memory block granularity. Print an info so this handling can be identified. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Cc: Hui Zhu <teawater@gmail.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Signed-off-by: David Hildenbrand <david@redhat.com> --- drivers/virtio/virtio_mem.c | 12 ++++++++++++ include/uapi/linux/virtio_mem.h | 10 +++++++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c index 6d4e01c4e2fa..58d8df528728 100644 --- a/drivers/virtio/virtio_mem.c +++ b/drivers/virtio/virtio_mem.c @@ -2425,6 +2425,17 @@ static int virtio_mem_init(struct virtio_mem *vm) pageblock_nr_pages) * PAGE_SIZE; sb_size = max_t(uint64_t, vm->device_block_size, sb_size); + /* + * Unplugged memory might be read in corner cases, for example, via + * kdump. Fallback to adding/removing individual Linux memory blocks. + */ + if (sb_size < memory_block_size_bytes() && !force_bbm && + virtio_has_feature(vm->vdev, VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE)) { + sb_size = memory_block_size_bytes(); + dev_info(&vm->vdev->dev, + "The device does not support reading unplugged memory: using big block mode\n"); + } + if (sb_size < memory_block_size_bytes() && !force_bbm) { /* SBM: At least two subblocks per Linux memory block. */ vm->in_sbm = true; @@ -2711,6 +2722,7 @@ static unsigned int virtio_mem_features[] = { #if defined(CONFIG_NUMA) && defined(CONFIG_ACPI_NUMA) VIRTIO_MEM_F_ACPI_PXM, #endif + VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, }; static const struct virtio_device_id virtio_mem_id_table[] = { diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h index 70e01c687d5e..6ac77cfb8aca 100644 --- a/include/uapi/linux/virtio_mem.h +++ b/include/uapi/linux/virtio_mem.h @@ -68,9 +68,11 @@ * explicitly triggered (VIRTIO_MEM_REQ_UNPLUG). * * There are no guarantees what will happen if unplugged memory is - * read/written. Such memory should, in general, not be touched. E.g., - * even writing might succeed, but the values will simply be discarded at - * random points in time. + * read/written. Often, unplugged memory inside the usable region can + * be read, to simplify creation of memory dumps; however, some devices + * don't even support that. Unplugged memory should, in general, not be + * touched. E.g., even writing might succeed, but the values will simply be + * discarded at random points in time. * * It can happen that the device cannot process a request, because it is * busy. The device driver has to retry later. @@ -87,6 +89,8 @@ /* node_id is an ACPI PXM and is valid */ #define VIRTIO_MEM_F_ACPI_PXM 0 +/* any unplugged memory must never be accessed */ +#define VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE 1 /* --- virtio-mem: guest -> host requests --- */ -- 2.29.2
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com> To: linux-kernel@vger.kernel.org Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>, Wei Yang <richard.weiyang@linux.alibaba.com>, "Michael S. Tsirkin" <mst@redhat.com>, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Sebastien Boeuf <sebastien.boeuf@intel.com>, Marek Kedzierski <mkedzier@redhat.com>, Hui Zhu <teawater@gmail.com> Subject: [PATCH v1 2/2] virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE Date: Mon, 15 Feb 2021 13:24:21 +0100 [thread overview] Message-ID: <20210215122421.27964-1-david@redhat.com> (raw) In-Reply-To: <20210215122143.27608-1-david@redhat.com> The spec currently states that while unplugged memory should not be read, the device has to allow for reading unplugged memory inside the usable region. The primary motivation for this default handling was that in some corner cases in Linux, unplugged memory inside added Linux memory blocks (and exposed via /proc/iomem as "System RAM (...)") might still be read. So to support SBM (Sub Block Mode) in Linux cleanly, the device has to support reading unplugged memory. One example is kdump(): when makedumpfile isn't used or when an older version is used, PG_offline is ignored and unplugged memory might still be read. Another corner-case example is /dev/mem: even with STRICT_DEVMEM, some unplugged memory might be read by tools automatically. For example, QEMU won't support reading unplugged memory with file-backed memory backends initially: there is no shared zero page, thus, special handling will be required in the future to allow for reading unplugged memory when using a file backing (tmpfs/shmem, hugetlbfs, ...). The device will indicate VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and fail device initialization if the driver does not indicate support. The result is that Linux won't be able to make use of any memory without this change. With this change, Linux will at least be able to (un)plug in Linux memory block granularity. Print an info so this handling can be identified. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Cc: Hui Zhu <teawater@gmail.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Signed-off-by: David Hildenbrand <david@redhat.com> --- drivers/virtio/virtio_mem.c | 12 ++++++++++++ include/uapi/linux/virtio_mem.h | 10 +++++++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c index 6d4e01c4e2fa..58d8df528728 100644 --- a/drivers/virtio/virtio_mem.c +++ b/drivers/virtio/virtio_mem.c @@ -2425,6 +2425,17 @@ static int virtio_mem_init(struct virtio_mem *vm) pageblock_nr_pages) * PAGE_SIZE; sb_size = max_t(uint64_t, vm->device_block_size, sb_size); + /* + * Unplugged memory might be read in corner cases, for example, via + * kdump. Fallback to adding/removing individual Linux memory blocks. + */ + if (sb_size < memory_block_size_bytes() && !force_bbm && + virtio_has_feature(vm->vdev, VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE)) { + sb_size = memory_block_size_bytes(); + dev_info(&vm->vdev->dev, + "The device does not support reading unplugged memory: using big block mode\n"); + } + if (sb_size < memory_block_size_bytes() && !force_bbm) { /* SBM: At least two subblocks per Linux memory block. */ vm->in_sbm = true; @@ -2711,6 +2722,7 @@ static unsigned int virtio_mem_features[] = { #if defined(CONFIG_NUMA) && defined(CONFIG_ACPI_NUMA) VIRTIO_MEM_F_ACPI_PXM, #endif + VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, }; static const struct virtio_device_id virtio_mem_id_table[] = { diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h index 70e01c687d5e..6ac77cfb8aca 100644 --- a/include/uapi/linux/virtio_mem.h +++ b/include/uapi/linux/virtio_mem.h @@ -68,9 +68,11 @@ * explicitly triggered (VIRTIO_MEM_REQ_UNPLUG). * * There are no guarantees what will happen if unplugged memory is - * read/written. Such memory should, in general, not be touched. E.g., - * even writing might succeed, but the values will simply be discarded at - * random points in time. + * read/written. Often, unplugged memory inside the usable region can + * be read, to simplify creation of memory dumps; however, some devices + * don't even support that. Unplugged memory should, in general, not be + * touched. E.g., even writing might succeed, but the values will simply be + * discarded at random points in time. * * It can happen that the device cannot process a request, because it is * busy. The device driver has to retry later. @@ -87,6 +89,8 @@ /* node_id is an ACPI PXM and is valid */ #define VIRTIO_MEM_F_ACPI_PXM 0 +/* any unplugged memory must never be accessed */ +#define VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE 1 /* --- virtio-mem: guest -> host requests --- */ -- 2.29.2 _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-02-15 12:30 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-15 12:21 [PATCH v1 0/2] virito-mem: one fix and VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE David Hildenbrand 2021-02-15 12:21 ` David Hildenbrand 2021-02-15 12:21 ` [PATCH v1 1/2] virtio-mem: don't read big block size in SBM David Hildenbrand 2021-02-15 12:21 ` David Hildenbrand 2021-02-15 12:24 ` David Hildenbrand [this message] 2021-02-15 12:24 ` [PATCH v1 2/2] virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE David Hildenbrand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210215122421.27964-1-david@redhat.com \ --to=david@redhat.com \ --cc=jasowang@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mkedzier@redhat.com \ --cc=mst@redhat.com \ --cc=pankaj.gupta.linux@gmail.com \ --cc=richard.weiyang@linux.alibaba.com \ --cc=sebastien.boeuf@intel.com \ --cc=teawater@gmail.com \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.