search for: 347ffffff

Displaying 10 results from an estimated 10 matches for "347ffffff".

Did you mean: 147ffffff
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...as "System RAM (virtio_mem)" in /proc/iomem, so esp. kexec-tools can properly handle it. Example /proc/iomem before this change: [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM 334000000-533ffffff : virtio1 338000000-33fffffff : System RAM 340000000-347ffffff : System RAM 348000000-34fffffff : System RAM [...] Example /proc/iomem after this change: [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM (virtio_mem) 334000000-533ffffff : virtio1 338000000-33fffffff : System RAM (virtio_mem) 340000000-347ffffff : Sys...
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...as "System RAM (virtio_mem)" in /proc/iomem, so esp. kexec-tools can properly handle it. Example /proc/iomem before this change: [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM 334000000-533ffffff : virtio1 338000000-33fffffff : System RAM 340000000-347ffffff : System RAM 348000000-34fffffff : System RAM [...] Example /proc/iomem after this change: [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM (virtio_mem) 334000000-533ffffff : virtio1 338000000-33fffffff : System RAM (virtio_mem) 340000000-347ffffff : Sys...
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
2020 Jun 11
0
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...n /proc/iomem, so esp. kexec-tools can properly handle it. > > Example /proc/iomem before this change: > [...] > 140000000-333ffffff : virtio0 > 140000000-147ffffff : System RAM > 334000000-533ffffff : virtio1 > 338000000-33fffffff : System RAM > 340000000-347ffffff : System RAM > 348000000-34fffffff : System RAM > [...] > > Example /proc/iomem after this change: > [...] > 140000000-333ffffff : virtio0 > 140000000-147ffffff : System RAM (virtio_mem) > 334000000-533ffffff : virtio1 > 338000000-33fffffff : System R...
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
2020 Apr 30
1
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
...ke dax/kmem to avoid the rename: :/# cat /proc/iomem 00000000-00000fff : Reserved [...] 100000000-13fffffff : System RAM 140000000-33fffffff : virtio0 140000000-147ffffff : System RAM 148000000-14fffffff : System RAM 150000000-157ffffff : System RAM 340000000-303fffffff : virtio1 340000000-347ffffff : System RAM 3280000000-32ffffffff : PCI Bus 0000:00 -- Thanks, David / dhildenb
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
2020 Apr 30
2
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
2020 Apr 30
2
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only
[PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools
2020 Apr 29
4
[PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools
This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches
[PATCH v4 00/15] virtio-mem: paravirtualized memory
2020 May 07
17
[PATCH v4 00/15] virtio-mem: paravirtualized memory
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
[PATCH v3 00/15] virtio-mem: paravirtualized memory
2020 May 07
20
[PATCH v3 00/15] virtio-mem: paravirtualized memory
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
[PATCH v3 00/15] virtio-mem: paravirtualized memory
2020 May 07
20
[PATCH v3 00/15] virtio-mem: paravirtualized memory
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