similar to: [PATCH RFC v4 00/13] virtio-mem: paravirtualized memory

On 05.06.20 10:55, Alex Shi wrote: > > > ? 2020/1/9 ??9:48, David Hildenbrand ??: >> Ping, >> >> I'd love to get some feedback on >> >> a) The remaining MM bits from MM folks (especially, patch #6 and #8). >> b) The general virtio infrastructure (esp. uapi in patch #2) from virtio >> folks. >> >> I'm planning to send a proper

On 05.06.20 11:08, David Hildenbrand wrote: > On 05.06.20 10:55, Alex Shi wrote: >> >> >> ? 2020/1/9 ??9:48, David Hildenbrand ??: >>> Ping, >>> >>> I'd love to get some feedback on >>> >>> a) The remaining MM bits from MM folks (especially, patch #6 and #8). >>> b) The general virtio infrastructure (esp. uapi in patch

On 05.06.20 11:08, David Hildenbrand wrote: > On 05.06.20 10:55, Alex Shi wrote: >> >> >> ? 2020/1/9 ??9:48, David Hildenbrand ??: >>> Ping, >>> >>> I'd love to get some feedback on >>> >>> a) The remaining MM bits from MM folks (especially, patch #6 and #8). >>> b) The general virtio infrastructure (esp. uapi in patch

On 14.05.20 12:02, teawater wrote: > > >> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >> >> On 14.05.20 08:44, teawater wrote: >>> Hi David, >>> >>> I got a kernel warning with v2 and v3. >> >> Hi Hui, >> >> thanks for playing with the latest versions. Surprisingly, I can >> reproduce even by

On 14.05.20 12:02, teawater wrote: > > >> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >> >> On 14.05.20 08:44, teawater wrote: >>> Hi David, >>> >>> I got a kernel warning with v2 and v3. >> >> Hi Hui, >> >> thanks for playing with the latest versions. Surprisingly, I can >> reproduce even by

On 14.05.20 13:10, David Hildenbrand wrote: > On 14.05.20 12:12, David Hildenbrand wrote: >> On 14.05.20 12:02, teawater wrote: >>> >>> >>>> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >>>> >>>> On 14.05.20 08:44, teawater wrote: >>>>> Hi David, >>>>> >>>>> I got a

On 14.05.20 08:44, teawater wrote: > Hi David, > > I got a kernel warning with v2 and v3. Hi Hui, thanks for playing with the latest versions. Surprisingly, I can reproduce even by hotplugging a DIMM instead as well - that's good, so it's not related to virtio-mem, lol. Seems to be some QEMU setup issue with older machine types. Can you switch to a newer qemu machine version,

On 23.05.2018 20:24, David Hildenbrand wrote: > This is the Linux driver side of virtio-mem. Compared to the QEMU side, > it is in a pretty complete and clean state. > > virtio-mem is a paravirtualized mechanism of adding/removing memory to/from > a VM. We can do this on a 4MB granularity right now. In Linux, all > memory is added to the ZONE_NORMAL, so unplugging cannot be

? 2020/6/5 ??6:05, David Hildenbrand ??: >> I guess I know what's happening here. In case we only have DMA memory >> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >> map such PFNs (total 0 (slots), used 0 (slots)). >> >> Can you try with

? 2020/6/5 ??6:05, David Hildenbrand ??: >> I guess I know what's happening here. In case we only have DMA memory >> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >> map such PFNs (total 0 (slots), used 0 (slots)). >> >> Can you try with

On 02.03.20 14:49, David Hildenbrand wrote: > 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

Hi, this is an idea that is based on Andrea Arcangeli's original idea to host enforce guest access to memory given up using virtio-balloon using userfaultfd in the hypervisor. While looking into the details, I realized that host-enforcing virtio-balloon would result in way too many problems (mainly backwards compatibility) and would also have some conceptual restrictions that I want to avoid.

Hi, this is an idea that is based on Andrea Arcangeli's original idea to host enforce guest access to memory given up using virtio-balloon using userfaultfd in the hypervisor. While looking into the details, I realized that host-enforcing virtio-balloon would result in way too many problems (mainly backwards compatibility) and would also have some conceptual restrictions that I want to avoid.

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

On 14.05.20 12:12, David Hildenbrand wrote: > On 14.05.20 12:02, teawater wrote: >> >> >>> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >>> >>> On 14.05.20 08:44, teawater wrote: >>>> Hi David, >>>> >>>> I got a kernel warning with v2 and v3. >>> >>> Hi Hui, >>>

Hi! As dom0 I''m running Ubuntu Hardy withe xen 3.3 from backports. Reason to using xen 3.3 is that I could get Intrepid stock kernel to work as domu with xen 3.2. Now the problem I have is that I can''t passthrough PCI-devices to my domu. If I run lspci in the domu nothing is returned. I''ve tried to use the kernel from Hardy (2.6.24-21-xen) and stock kernel from

Package: xen-hypervisor-3.4-amd64 and linux-image-2.6.32-5-xen-amd64 Version: 3.4.3-1 and 2.6.32-15 Hello all, GRUB-PC does not automatically populate Xen related parameters in /boot/grub/grub.cfg so I added them manually (see below). All the packages involved on my Dell PowerEdge R710 running Debian GNU/Linux Squeeze AMD64 are from the Squeeze repository. There are four (4) 1TB SATA HDD

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where