On 24.03.21 12:18, Oscar Salvador wrote:
On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote:
It used to be true that we can have busy system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on
lower levels.
Let me ask some rookie questions:
What does "busy" term stand for here?
IORESOURCE_BUSY - here: actually added, not just some reserved range / container.
Why resources coming from virtio-mem are added at a lower levels?
Some information can be had from ebf71552bb0e690cad523ad175e8c4c89a33c333
commit ebf71552bb0e690cad523ad175e8c4c89a33c333
Author: David Hildenbrand <david@xxxxxxxxxx>
Date: Thu May 7 16:01:35 2020 +0200
virtio-mem: Add parent resource for all added "System RAM"
Let's add a parent resource, named after the virtio device (inspired by
drivers/dax/kmem.c). This allows user space to identify which memory
belongs to which virtio-mem device.
With this change and two virtio-mem devices:
:/# cat /proc/iomem
00000000-00000fff : Reserved
00001000-0009fbff : System RAM
[...]
140000000-333ffffff : virtio0
140000000-147ffffff : System RAM
148000000-14fffffff : System RAM
150000000-157ffffff : System RAM
[...]
334000000-3033ffffff : virtio1
338000000-33fffffff : System RAM
340000000-347ffffff : System RAM
348000000-34fffffff : System RAM
[...]
For dax/kmem it comes naturally due to the "Persistent Memory" and
device parent resources like:
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
150000000-33fffffff : dax0.0
150000000-33fffffff : System RAM (kmem)
3280000000-32ffffffff : PCI Bus 0000:00
Thanks
--
Thanks,
David / dhildenb
