Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-21 Thread Paolo Bonzini 


On 20/09/2016 20:29, Thorsten Kohfeldt wrote:
>>
>> -0009 (RW): pc.ram
>> 000a-000b (RW): vga-lowmem
>> 000c-000f (R-): pc.ram @ 000c
>> 0010-07ff (RW): pc.ram @ 0010
>> fd00-fdff (RW): vga.vram
>> febc-febd (RW): e1000-mmio
>> febf-febf0fff (RW): vga.mmio
>> febf0400-febf041f (RW): vga ioports remapped
>> febf0500-febf0515 (RW): bochs dispi interface
>> febf0600-febf0607 (RW): qemu extended regs
>> fec0-fec00fff (RW): ioapic
>> fed0-fed003ff (RW): hpet
>> fee0-feef (RW): apic-msi
>> fffc- (R-): pc.bios
> 
> How did you create this output ?

By hand. :)

Paolo

> I did not find any hint in monitor help or the qemu source tree.
> (either too many matches or no matches at all for my searches.)
> Is this what you envision to receive from this patch initiative ?

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-20 Thread Thorsten Kohfeldt 


Am 20.09.2016 um 20:46 schrieb Laszlo Ersek:

On 09/20/16 20:23, Thorsten Kohfeldt wrote:


Am 20.09.2016 um 02:51 schrieb Laszlo Ersek:



I think it would make sense to work from the pre-rendered FlatView,
if the information you can get out of it covers your needs.


I assume you know by now that I do _not_ feel that it covers my needs.


Okay. I guess you've made your point convincingly enough (although I'm
just an interested bystander in this thread). I think the patch has a
very low chance for regressions and it shouldn't draw in a big
maintenance burden, so it could be considered "pure improvement" as-is.

I'm not volunteering to do a full review. One thing I notice though is
that the constification of memory_region_size()'s sole parameter could
be / should be moved into a separate, "prep" patch.


I am really not having the attitude of unwillingness to listen to suggestions.
But this was my train of thoughts towards that split up (before I posted):
1) This (split up) moves the patch suite size from 1 file to 3 files.
2) It now requires an aditional cover letter, a trivial patch and the actual 
patch.
3) If the trivial patch was applied but not the actual patch,
   I'd have to maintain 2 variants of the actual patch to fit current and
   also older trees (with and without constant local mr pointer variable).
And this comes on top since 2b9e35760a8ff5548f6789d048c6e6e3c22c70ee
4) Well, that would be even more, as I have to maintain 2 variants already 
anyway:
   V2.6/V2.7 and master.

Having that stated, of course I am willing to follow your suggestion
anyway to get this through if it is insisted upon.


(I propose you wait for further feedback before reposting just with this
change.)


I'm gladly looking forward to decisive guidance.

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-20 Thread Laszlo Ersek 
On 09/20/16 20:23, Thorsten Kohfeldt wrote:
> 
> Am 20.09.2016 um 02:51 schrieb Laszlo Ersek:

>> I think it would make sense to work from the pre-rendered FlatView,
>> if the information you can get out of it covers your needs.
> 
> I assume you know by now that I do _not_ feel that it covers my needs.

Okay. I guess you've made your point convincingly enough (although I'm
just an interested bystander in this thread). I think the patch has a
very low chance for regressions and it shouldn't draw in a big
maintenance burden, so it could be considered "pure improvement" as-is.

I'm not volunteering to do a full review. One thing I notice though is
that the constification of memory_region_size()'s sole parameter could
be / should be moved into a separate, "prep" patch.

(I propose you wait for further feedback before reposting just with this
change.)

Thanks
Laszlo

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-20 Thread Thorsten Kohfeldt 


Am 20.09.2016 um 09:56 schrieb Paolo Bonzini:


... dumping the flat-view would give you something much simpler:

-0009 (RW): pc.ram
000a-000b (RW): vga-lowmem
000c-000f (R-): pc.ram @ 000c
0010-07ff (RW): pc.ram @ 0010
fd00-fdff (RW): vga.vram
febc-febd (RW): e1000-mmio
febf-febf0fff (RW): vga.mmio
febf0400-febf041f (RW): vga ioports remapped
febf0500-febf0515 (RW): bochs dispi interface
febf0600-febf0607 (RW): qemu extended regs
fec0-fec00fff (RW): ioapic
fed0-fed003ff (RW): hpet
fee0-feef (RW): apic-msi
fffc- (R-): pc.bios


How did you create this output ?
I did not find any hint in monitor help or the qemu source tree.
(either too many matches or no matches at all for my searches.)
Is this what you envision to receive from this patch initiative ?


This is less information of course, but it may good idea depending on
_why_ you're doing that.

Paolo


I explained more of my motivation in a reply to Laszlo's mail, i.e. why
I am really keen on exactly the kind of output I suggest with the patch.

But as a compromise, I would be willing to add the flat view map as well.
Still though, I see that as an additional patch on top, coming later,
as this would need more discussion about how to exacly format the output.

I'd really like to have that mtree mapinfo discussion tool merged _soon_.

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-20 Thread Thorsten Kohfeldt 


Am 20.09.2016 um 02:51 schrieb Laszlo Ersek:

On 09/20/16 02:16, Thorsten Kohfeldt wrote:


Am 15.09.2016 um 11:52 schrieb Paolo Bonzini:


On 07/09/2016 02:48, Thorsten Kohfeldt wrote:

From: Thorsten Kohfeldt 
Date: Wed, 31 Aug 2016 22:43:14 +0200
Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for
mapinfo

Motivation
When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
directly grasp the implications of the priorisation algorithms in place
for the 'layered mapping' of memory regions.
Even though there are rules (documented in docs/memory.txt), once in a
while one might question the correctness of the actual implementation of
the rules.
Particularly, I believe I have uncovered a divergence of (sub-)region
priorisation/order/visibility in a corner case of importing a device
(which requires a 'quirk') with mmap enabled vs. mmap disabled.
This modification provides a means of visualising the ACTUAL
mapping/visibility/occlusion of subregions within regions, whereas the
current info mtree command only lists the tree of regions (all, visible
and invisible ones).
It is primarily intended to provide support for easy presentation of my
cause, but I strongly believe this modification also has general purpose
advantages.


It is a useful addition, but I think a simpler presentation is also
fine.  What about "info mtree -f" which would visit the FlatView instead
of the tree?  The patch would probably be much shorter.


For quite some time I had the patch in use as a direct modification of
'info mtree', but I felt that a general purpose use must provide an ad
hoc user selectable presentation width parameter for the map info.
I personally use a width of 65 or even 129 characters PREFIXING the
tree elements which the command currently responds.
My guess is though that most users would want a width of only 9 or 17.
So I believe that a numerical parameter is a must.
Visit the flat view -
I'm not sure I understand you. Do you suggest to traverse a completely
different data structure ?
The purpose of the suggested visualisation is to point out where
each of the tree's memory regions are "pinched" by other regions, so
their "native" contents is NOT visible any more throughout the full
region length, but (fractionally) rather another regions's content.
Thus, I personally require to traverse exactly that tree structure.

No offence, but I would rather not want to modify the patch towards
what I feel would be a completely different purpose.

I would appreciate if someone would review the patch in its current
functional form to get it queued for qemu 2.8.
My intention is to be able to rely on communication partners being
able to reproduce findings using the new command once I start to
attack the VFIO mmap flaw I talk about in the commit comment.


# PATCH (as published in mailing list) *CONVERSION* from
qemu-2.6/qemu-2.7 to qemu-master:
sed s/'[.]mhandler[.]cmd = '/'.cmd= '/ 
qemu-master.patch


# patch commit adapted that way for qemu-master and frequently rebased in 
branch:
https://github.com/Thorsten-Kohfeldt/qemu/commits/upstream-pullrequest-mapinfo-V1-rebased


# sample output info mtree 9
https://gist.github.com/Thorsten-Kohfeldt/254b5a21fef497054959f58af53a44c9

# sample output info mtree 65
https://gist.github.com/Thorsten-Kohfeldt/39cf5c8521c1999518b3438315e439f4


I think your current output explains, for each part (that is, each "sample"

> of user-selected size) of each MemoryRegion, whether that sample is actually
> visible in the finally rendered, flat view of the address space(s).
> (And, if not, why not.)

If not why not: Right. That _is_ my goal.


Whereas I think Paolo's idea is to map the flat view to begin with,

> and visually associate each interval of the guest visible physical address
> space with the one region that is ultimately accessed in that interval.
> This too would explain what the guest sees where, and why. It wouldn't give
> much information about ranges that the guest can *not* access (due to
> occlusion by other regions or otherwise),
> but maybe the "why not" is not so important after all?

To the contrary IMHO. See my whole line of statements above.
The "why not" explanation is all what drove me to attempt to make this patch
an official part of qemu - as a tool for 'bugfix' discussions.
Otherwise I'd have to state "apply this patch then you see what I mean".
For me that "why not" is an important part of information from point of view
of a "memory region subtree/stack maintainer".
Please note that while hunting down that VFIO/mmap problem around last Xmas
I _was_ experimenting with flat view dumps.
But only the final mtree mapinfo was the real eye opener for me.


Regarding the FlatView thing -- QEMU already maintains a flat rendering of

> the memory region tree, so that guest accesses to the various regions can
> be quickly dispatched to the accessors that can serve these accesses.
> Memory regions are massaged

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-20 Thread Paolo Bonzini 


On 20/09/2016 02:51, Laszlo Ersek wrote:
> Here's an example, from one of your sample outputs: you currently have
> 
> ~
> 000c-000c3fff (prio 1, RW): alias pam-ram @pc.ram 
> 000c-000c3fff [disabled]
> ~
> 000c-000c3fff (prio 1, RW): alias pam-pci @pc.ram 
> 000c-000c3fff [disabled]
> @
> 000c-000c3fff (prio 1, R-): alias pam-rom @pc.ram 
> 000c-000c3fff
> o
> 000c-000c3fff (prio 1, RW): alias pam-pci @pci 
> 000c-000c3fff [disabled]
> 
> with
> 
> @: alias region mapped at sample
> ~: alias region mappable but disabled at sample
> o: region occluded by some other region at sample
> 
> If you have an address in the c-c3fff range, you have to consult all four 
> lines to see which region will match.
> 
> Working off of the FlatView, first I think you would find the right 
> resolution for the output "for free" (you wouldn't need a user sample size -- 
> the interval c-c3fff would neither need further subdivision nor be 
> blurred by over-coarse resolution). You could represent the c-c3fff 
> interval (and every other interval too) with a single letter, such as P, 
> where P would stand for "alias pam-rom @pc.ram 
> 000c-000c3fff".
> 
> Second, given an address in c-c3fff, there would be only one range to 
> consult (same as QEMU itself does with FlatView), and you'd find the 
> MemoryRegion visible in that range at once.
> 
> ... I hope Paolo will correct me if I misunderstood his suggestion.

Yes, this would work.  Alternatively, dumping the flat-view would give
you something much simpler:

-0009 (RW): pc.ram
000a-000b (RW): vga-lowmem
000c-000f (R-): pc.ram @ 000c
0010-07ff (RW): pc.ram @ 0010
fd00-fdff (RW): vga.vram
febc-febd (RW): e1000-mmio
febf-febf0fff (RW): vga.mmio
febf0400-febf041f (RW): vga ioports remapped
febf0500-febf0515 (RW): bochs dispi interface
febf0600-febf0607 (RW): qemu extended regs
fec0-fec00fff (RW): ioapic
fed0-fed003ff (RW): hpet
fee0-feef (RW): apic-msi
fffc- (R-): pc.bios

This is less information of course, but it may good idea depending on
_why_ you're doing that.

Paolo



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-19 Thread Laszlo Ersek 
On 09/20/16 02:16, Thorsten Kohfeldt wrote:
> 
> Am 15.09.2016 um 11:52 schrieb Paolo Bonzini:
>>
>> On 07/09/2016 02:48, Thorsten Kohfeldt wrote:
>>> From: Thorsten Kohfeldt 
>>> Date: Wed, 31 Aug 2016 22:43:14 +0200
>>> Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for
>>> mapinfo
>>>
>>> Motivation
>>> When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
>>> directly grasp the implications of the priorisation algorithms in place
>>> for the 'layered mapping' of memory regions.
>>> Even though there are rules (documented in docs/memory.txt), once in a
>>> while one might question the correctness of the actual implementation of
>>> the rules.
>>> Particularly, I believe I have uncovered a divergence of (sub-)region
>>> priorisation/order/visibility in a corner case of importing a device
>>> (which requires a 'quirk') with mmap enabled vs. mmap disabled.
>>> This modification provides a means of visualising the ACTUAL
>>> mapping/visibility/occlusion of subregions within regions, whereas the
>>> current info mtree command only lists the tree of regions (all, visible
>>> and invisible ones).
>>> It is primarily intended to provide support for easy presentation of my
>>> cause, but I strongly believe this modification also has general purpose
>>> advantages.
>>
>> It is a useful addition, but I think a simpler presentation is also
>> fine.  What about "info mtree -f" which would visit the FlatView instead
>> of the tree?  The patch would probably be much shorter.
>>
>> Thanks,
>>
>> Paolo
> 
> Paolo,
> 
> For quite some time I had the patch in use as a direct modification of
> 'info mtree', but I felt that a general purpose use must provide an ad
> hoc user selectable presentation width parameter for the map info.
> I personally use a width of 65 or even 129 characters PREFIXING the
> tree elements which the command currently responds.
> My guess is though that most users would want a width of only 9 or 17.
> So I believe that a numerical parameter is a must.
> Visit the flat view -
> I'm not sure I understand you. Do you suggest to traverse a completely
> different data structure ?
> The purpose of the suggested visualisation is to point out where
> each of the tree's memory regions are "pinched" by other regions, so
> their "native" contents is NOT visible any more throughout the full
> region length, but (fractionally) rather another regions's content.
> Thus, I personally require to traverse exactly that tree structure.
> 
> No offence, but I would rather not want to modify the patch towards
> what I feel would be a completely different purpose.
> 
> I would appreciate if someone would review the patch in its current
> functional form to get it queued for qemu 2.8.
> My intention is to be able to rely on communication partners being
> able to reproduce findings using the new command once I start to
> attack the VFIO mmap flaw I talk about in the commit comment.
> 
> 
> @ALL
> I have provided 2 patch branches in github,
> one for qemu-2.7.0 and
> one for qemu-current-master (this needed a tiny sed-conversion, see below).
> I also placed some example info mtree mapinfo output on gist.github:
> 
> 
> # patch commit for qemu-2.7 (same patch also works for qemu-2.6):
> https://github.com/Thorsten-Kohfeldt/qemu/commit/5633a3cdbf6fd7cccd098fb83f591fbb15e8d383
> 
> # in branch:
> https://github.com/Thorsten-Kohfeldt/qemu/commits/monitor_--hmp_info_mtree_mapinfo-width
> 
> 
> # PATCH (as published in mailing list) *CONVERSION* from
> qemu-2.6/qemu-2.7 to qemu-master:
> sed s/'[.]mhandler[.]cmd = '/'.cmd= '/ >qemu-master.patch
> 
> # patch commit adapted that way for qemu-master:
> https://github.com/Thorsten-Kohfeldt/qemu/commit/60b8c1be1a0119df1f1859b0d484e06e709c2ea2
> 
> # in branch:
> https://github.com/Thorsten-Kohfeldt/qemu/commits/upstream-pullrequest-mapinfo-V1
> 
> 
> 
> # sample output info mtree 9
> https://gist.github.com/Thorsten-Kohfeldt/254b5a21fef497054959f58af53a44c9
> 
> # sample output info mtree 65
> https://gist.github.com/Thorsten-Kohfeldt/39cf5c8521c1999518b3438315e439f4

I think your current output explains, for each part (that is, each "sample" of 
user-selected size) of each MemoryRegion, whether that sample is actually 
visible in the finally rendered, flat view of the address space(s). (And, if 
not, why not.)

Whereas I think Paolo's idea is to map the flat view to begin with, and 
visually associate each interval of the guest visible physical address space 
with the one region that is ultimately accessed in that interval. This too 
would explain what the guest sees where, and why. It wouldn't give much 
information about ranges that the guest can *not* access (due to occlusion by 
other regions or otherwise), but maybe the "why not" is not so important after 
all?

Regarding the FlatView thing -- QEMU already maintains a flat rendering of the 
memory region tree, so that guest accesses to the various regions can

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-19 Thread Thorsten Kohfeldt 


Am 15.09.2016 um 11:52 schrieb Paolo Bonzini:


On 07/09/2016 02:48, Thorsten Kohfeldt wrote:

From: Thorsten Kohfeldt 
Date: Wed, 31 Aug 2016 22:43:14 +0200
Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

Motivation
When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
directly grasp the implications of the priorisation algorithms in place
for the 'layered mapping' of memory regions.
Even though there are rules (documented in docs/memory.txt), once in a
while one might question the correctness of the actual implementation of
the rules.
Particularly, I believe I have uncovered a divergence of (sub-)region
priorisation/order/visibility in a corner case of importing a device
(which requires a 'quirk') with mmap enabled vs. mmap disabled.
This modification provides a means of visualising the ACTUAL
mapping/visibility/occlusion of subregions within regions, whereas the
current info mtree command only lists the tree of regions (all, visible
and invisible ones).
It is primarily intended to provide support for easy presentation of my
cause, but I strongly believe this modification also has general purpose
advantages.


It is a useful addition, but I think a simpler presentation is also
fine.  What about "info mtree -f" which would visit the FlatView instead
of the tree?  The patch would probably be much shorter.

Thanks,

Paolo


Paolo,

For quite some time I had the patch in use as a direct modification of
'info mtree', but I felt that a general purpose use must provide an ad
hoc user selectable presentation width parameter for the map info.
I personally use a width of 65 or even 129 characters PREFIXING the
tree elements which the command currently responds.
My guess is though that most users would want a width of only 9 or 17.
So I believe that a numerical parameter is a must.
Visit the flat view -
I'm not sure I understand you. Do you suggest to traverse a completely
different data structure ?
The purpose of the suggested visualisation is to point out where
each of the tree's memory regions are "pinched" by other regions, so
their "native" contents is NOT visible any more throughout the full
region length, but (fractionally) rather another regions's content.
Thus, I personally require to traverse exactly that tree structure.

No offence, but I would rather not want to modify the patch towards
what I feel would be a completely different purpose.

I would appreciate if someone would review the patch in its current
functional form to get it queued for qemu 2.8.
My intention is to be able to rely on communication partners being
able to reproduce findings using the new command once I start to
attack the VFIO mmap flaw I talk about in the commit comment.


@ALL
I have provided 2 patch branches in github,
one for qemu-2.7.0 and
one for qemu-current-master (this needed a tiny sed-conversion, see below).
I also placed some example info mtree mapinfo output on gist.github:


# patch commit for qemu-2.7 (same patch also works for qemu-2.6):
https://github.com/Thorsten-Kohfeldt/qemu/commit/5633a3cdbf6fd7cccd098fb83f591fbb15e8d383
# in branch:
https://github.com/Thorsten-Kohfeldt/qemu/commits/monitor_--hmp_info_mtree_mapinfo-width

# PATCH (as published in mailing list) *CONVERSION* from qemu-2.6/qemu-2.7 to 
qemu-master:
sed s/'[.]mhandler[.]cmd = '/'.cmd= '/ qemu-master.patch

# patch commit adapted that way for qemu-master:
https://github.com/Thorsten-Kohfeldt/qemu/commit/60b8c1be1a0119df1f1859b0d484e06e709c2ea2
# in branch:
https://github.com/Thorsten-Kohfeldt/qemu/commits/upstream-pullrequest-mapinfo-V1


# sample output info mtree 9
https://gist.github.com/Thorsten-Kohfeldt/254b5a21fef497054959f58af53a44c9

# sample output info mtree 65
https://gist.github.com/Thorsten-Kohfeldt/39cf5c8521c1999518b3438315e439f4


Regards,

Thorsten

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-16 Thread Laszlo Ersek 
On 09/15/16 11:52, Paolo Bonzini wrote:
> 
> 
> On 07/09/2016 02:48, Thorsten Kohfeldt wrote:
>> From: Thorsten Kohfeldt 
>> Date: Wed, 31 Aug 2016 22:43:14 +0200
>> Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo
>>
>> Motivation
>> When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
>> directly grasp the implications of the priorisation algorithms in place
>> for the 'layered mapping' of memory regions.
>> Even though there are rules (documented in docs/memory.txt), once in a
>> while one might question the correctness of the actual implementation of
>> the rules.
>> Particularly, I believe I have uncovered a divergence of (sub-)region
>> priorisation/order/visibility in a corner case of importing a device
>> (which requires a 'quirk') with mmap enabled vs. mmap disabled.
>> This modification provides a means of visualising the ACTUAL
>> mapping/visibility/occlusion of subregions within regions, whereas the
>> current info mtree command only lists the tree of regions (all, visible
>> and invisible ones).
>> It is primarily intended to provide support for easy presentation of my
>> cause, but I strongly believe this modification also has general purpose
>> advantages.
> 
> It is a useful addition, but I think a simpler presentation is also
> fine.  What about "info mtree -f" which would visit the FlatView instead
> of the tree?  The patch would probably be much shorter.

I'm very interested in this feature (as a mere user at this point).
Thorsten, can you please CC me on your next version, and also include an
example command response in either the Notes section of the patch, or in
a separate 0/1 blurb?

Thanks
Laszlo

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-15 Thread Paolo Bonzini 


On 07/09/2016 02:48, Thorsten Kohfeldt wrote:
> From: Thorsten Kohfeldt 
> Date: Wed, 31 Aug 2016 22:43:14 +0200
> Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo
> 
> Motivation
> When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
> directly grasp the implications of the priorisation algorithms in place
> for the 'layered mapping' of memory regions.
> Even though there are rules (documented in docs/memory.txt), once in a
> while one might question the correctness of the actual implementation of
> the rules.
> Particularly, I believe I have uncovered a divergence of (sub-)region
> priorisation/order/visibility in a corner case of importing a device
> (which requires a 'quirk') with mmap enabled vs. mmap disabled.
> This modification provides a means of visualising the ACTUAL
> mapping/visibility/occlusion of subregions within regions, whereas the
> current info mtree command only lists the tree of regions (all, visible
> and invisible ones).
> It is primarily intended to provide support for easy presentation of my
> cause, but I strongly believe this modification also has general purpose
> advantages.

It is a useful addition, but I think a simpler presentation is also
fine.  What about "info mtree -f" which would visit the FlatView instead
of the tree?  The patch would probably be much shorter.

Thanks,

Paolo

[Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

2016-09-06 Thread Thorsten Kohfeldt 

From: Thorsten Kohfeldt 
Date: Wed, 31 Aug 2016 22:43:14 +0200
Subject: [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo

Motivation
When 'tuning' 'quirks' for VFIO imported devices, it is not easy to
directly grasp the implications of the priorisation algorithms in place
for the 'layered mapping' of memory regions.
Even though there are rules (documented in docs/memory.txt), once in a
while one might question the correctness of the actual implementation of
the rules.
Particularly, I believe I have uncovered a divergence of (sub-)region
priorisation/order/visibility in a corner case of importing a device
(which requires a 'quirk') with mmap enabled vs. mmap disabled.
This modification provides a means of visualising the ACTUAL
mapping/visibility/occlusion of subregions within regions, whereas the
current info mtree command only lists the tree of regions (all, visible
and invisible ones).
It is primarily intended to provide support for easy presentation of my
cause, but I strongly believe this modification also has general purpose
advantages.

Functional implementation
A new OPTIONAL integer parameter, mapinfo-width, is added to the
monitor/hmp 'info mtree' command.
Effect:
When given and between 5 and 257, then each mtree output line is
prefixed with  columns of 'visibility samples', depicting
what qemu's memory region priorisation algorithms effectively make
visible/accessible at that sample address at the time of inquiry.
NOTE that
the sampling algorithm virtually cuts the memory region into (width - 1)
'slices' and computes (width) samples at the edges of those virtual
slices. Thus, it is probably a good idea to always request (2^n + 1)
samples.
ALSO NOTE that
the memory regions are NOT actually accessed at those 'samples', ONLY a
region PRIORISATION EVALUATION is performed for the sample addresses.
You can setup a default using environment variable
QEMU_INFO_MTREE_MAPINFO_WIDTH (must be in the Qemu instance's
environment; when unset, then the default is 0, i.e. off).
Giving negative values for sample-width results in using that default,
while values above 257 are reduced to 257, and values from 0 to 4 switch
the sampling off.

Technical implementation
3 functions are added to memory.c:
sane_mtree_info_sample_width() is used to sanitise the new parameter,
i.e. to provide a default and adjust it towards 'usability'. It is
called by existing function mtree_info().
mtree_print_mr_v_samples() is called for each mtree memory region (mr)
output line in order to print the 'mapinfo' prefix. The call is
performed by existing function mtree_print_mr() with parameter
'const MemoryRegion *mr', thus promising the object under investigation
is not modified.
mtree_mr_sample_reftype_marker() is used to traverse an mr subtree for a
given hardware address in order to basically find the first matching
enabled region and return its type. It is called by
mtree_print_mr_v_samples() for  'sample'
addresses. As an mr tree is traversed, limited recursion is involved.
Additionally, for existing functions memory_region_to_address_space(),
memory_region_size(), and memory_region_find_rcu() their parameter
'MemoryRegion *mr' had to be constrained to 'const MemoryRegion *mr' in
order to satisfy the compiler while attempting to emphasize the
'object is not modified' promise by insisting to pass *mr as const into
mtree_print_mr_v_samples(). This did not entail changes in the bodies of
mentioned functions.

Signed-off-by: Thorsten Kohfeldt 
---
 hmp-commands-info.hx  |   9 +-
 include/exec/memory.h |   7 +-
 memory.c  | 246 --
 monitor.c |   4 +-
 4 files changed, 250 insertions(+), 16 deletions(-)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index 74446c6..1593238 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -264,16 +264,17 @@ ETEXI

 {
 .name   = "mtree",
-.args_type  = "",
-.params = "",
-.help   = "show memory tree",
+.args_type  = "mapinfo-width:l?",
+.params = "[mapinfo-width]",
+.help   = "show memory tree "
+  "(mapinfo-width: depict memory subregion mappings with 
leading characters)",
 .mhandler.cmd = hmp_info_mtree,
 },

 STEXI
 @item info mtree
 @findex mtree
-Show memory tree.
+Show memory tree optionally depicting subregion mappings.
 ETEXI

 {
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 3e4d416..751483c 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -536,7 +536,7 @@ struct Object *memory_region_owner(MemoryRegion *mr);
  *
  * @mr: the memory region being queried.
  */
-uint64_t memory_region_size(MemoryRegion *mr);
+uint64_t memory_region_size(const MemoryRegion *mr);

 /**
  * memory_region_is_ram: check whether a memory region is random access
@@ -1202,7 +1202,10 @@ void