search for: config_virtio_mem

...git a/drivers/virtio/Makefile b/drivers/virtio/Makefile > index 8e98d24917cc..c7341f078a34 100644 > --- a/drivers/virtio/Makefile > +++ b/drivers/virtio/Makefile > @@ -12,3 +12,4 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o > obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o > obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o > obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o > +obj-$(CONFIG_VIRTIO_VCPU_WATCHDOG) += virtio_vcpu_stall_detector.o > diff --git a/drivers/virtio/virtio_vcpu_stall_detector.c b/drivers/virtio/virtio_vcpu_stall_detector.c > new file mode 100644 > index...

...git a/drivers/virtio/Makefile b/drivers/virtio/Makefile > index 8e98d24917cc..c7341f078a34 100644 > --- a/drivers/virtio/Makefile > +++ b/drivers/virtio/Makefile > @@ -12,3 +12,4 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o > obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o > obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o > obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o > +obj-$(CONFIG_VIRTIO_VCPU_WATCHDOG) += virtio_vcpu_stall_detector.o > diff --git a/drivers/virtio/virtio_vcpu_stall_detector.c b/drivers/virtio/virtio_vcpu_stall_detector.c > new file mode 100644 > index...

...an inspiration what this could look like. You can find the latest hack at: QEMU: https://github.com/davidhildenbrand/qemu/tree/virtio-mem Kernel: https://github.com/davidhildenbrand/linux/tree/virtio-mem Use the kernel in the guest and make sure to compile the virtio-mem driver into the kernel (CONFIG_VIRTIO_MEM=y). A host kernel patch is contained to allow atomic resize of KVM memory regions, however it is pretty much untested. 1. Starting a guest with virtio-mem memory: We will create a guest with 2 NUMA nodes and 4GB of "boot + DMA" memory. This memory is visible also to guests without...

...an inspiration what this could look like. You can find the latest hack at: QEMU: https://github.com/davidhildenbrand/qemu/tree/virtio-mem Kernel: https://github.com/davidhildenbrand/linux/tree/virtio-mem Use the kernel in the guest and make sure to compile the virtio-mem driver into the kernel (CONFIG_VIRTIO_MEM=y). A host kernel patch is contained to allow atomic resize of KVM memory regions, however it is pretty much untested. 1. Starting a guest with virtio-mem memory: We will create a guest with 2 NUMA nodes and 4GB of "boot + DMA" memory. This memory is visible also to guests without...

...k like. You can find the latest hack at: > > QEMU: https://github.com/davidhildenbrand/qemu/tree/virtio-mem > > Kernel: https://github.com/davidhildenbrand/linux/tree/virtio-mem > > Use the kernel in the guest and make sure to compile the virtio-mem > driver into the kernel (CONFIG_VIRTIO_MEM=y). A host kernel patch is > contained to allow atomic resize of KVM memory regions, however it is > pretty much untested. > > > 1. Starting a guest with virtio-mem memory: > We will create a guest with 2 NUMA nodes and 4GB of "boot + DMA" > memory. This memor...

...4 --- a/drivers/virtio/Makefile +++ b/drivers/virtio/Makefile @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o +obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c new file mode 100644 index 000000000000..d8da656c9145 --- /dev/null +++ b/drivers/virtio/virtio_mem.c @@ -0,0 +1,1559 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Virtio-mem device driver. + * + * Co...

This series is based on v5.7-rc4. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v4 This is basically a resend of v3 [1], now based on v5.7-rc4 and restested. One patch was reshuffled and two ACKs I missed to add were added. The rebase did not require any modifications to patches. Details about virtio-mem can be found in the cover letter of v2 [2]. A

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v2 I now have acks for all !virtio-mem changes. I'll be happy to get review feedback, testing reports, etc. for the virtio-mem changes. If there are no further comments, I guess this is good to go as a v1 soon. The basic idea of virtio-mem is to provide a

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. This

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. This

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v3 Patch #1 - #10 where contained in v2 and only contain minor modifications (mostly smaller fixes). The remaining patches are new and contain smaller optimizations. Details about virtio-mem can be found in the cover letter of v2 [1]. A basic QEMU implementation was

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v3 Patch #1 - #10 where contained in v2 and only contain minor modifications (mostly smaller fixes). The remaining patches are new and contain smaller optimizations. Details about virtio-mem can be found in the cover letter of v2 [1]. A basic QEMU implementation was

Long time no RFC! I finally had time to get the next version of the Linux driver side of virtio-mem into shape, incorporating ideas and feedback from previous discussions. This RFC is based on the series currently on the mm list: - [PATCH 0/3] Remove __online_page_set_limits() - [PATCH v1 0/3] mm/memory_hotplug: Export generic_online_page() - [PATCH v4 0/8] mm/memory_hotplug: Shrink zones before

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v1 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. It's

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v1 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. It's

This patch series aims to move the logical block size checking to the block code. This was inspired by missing check for valid logical block size in virtio-blk which causes the kernel to crash in a weird way later on when it is invalid. I added blk_is_valid_logical_block_size which returns true iff the block size is one of supported sizes. I added this check to virtio-blk, and also converted

This patch series aims to move the logical block size checking to the block code. This was inspired by missing check for valid logical block size in virtio-blk which causes the kernel to crash in a weird way later on when it is invalid. I added blk_is_valid_logical_block_size which returns true iff the block size is one of supported sizes. I added this check to virtio-blk, and also converted