[PATCH v4 0/2] hw/vfio: Improve vfio_get_dirty_bitmap() tracepoint

Joao Martins posted 2 patches 10 months, 3 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20230530180556.24441-1-joao.m.martins@oracle.com
Maintainers: Alex Williamson <alex.williamson@redhat.com>, "Cédric Le Goater" <clg@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>, David Hildenbrand <david@redhat.com>, "Philippe Mathieu-Daudé" <philmd@linaro.org>
hw/vfio/common.c        |  7 ++++---
hw/vfio/trace-events    |  2 +-
include/exec/ram_addr.h | 28 ++++++++++++++++++++++------
3 files changed, 27 insertions(+), 10 deletions(-)
[PATCH v4 0/2] hw/vfio: Improve vfio_get_dirty_bitmap() tracepoint
Posted by Joao Martins 10 months, 3 weeks ago
Hey,

This tiny series changes the tracepoint to include the number of
dirty pages via the vfio_get_dirty_bitmap. I find it useful for
observability in general to understand the number of dirty pages in an
IOVA range. With dirty tracking supported by device or IOMMU it's specially
relevant data to include in the tracepoint.

First patch changes the return value to be the number of dirty pages in
the helper function setting dirty bits and the second patch expands the
VFIO tracepoint to include the dirty pages.

Thanks,
	Joao

Changes since v3[3]:
* s/nr/number in patches subject line (Avihai)
* s/cpu_physical_memory_set_lebitmap()/cpu_physical_memory_set_dirty_lebitmap() (Avihai)
* Add Reviewed-by's from Phillipe and Cedric

Changes since v2[2]:
* Add a comment explaining the difference of retval between
cpu_physical_memory_set_dirty_lebitmap() and
cpu_physical_memory_sync_dirty_bitmap() (Peter Xu)
* Add Peter's Reviewed-by;
* Rename dirty variable into dirty_pages (Philippe Mathieu-Daude)

Changes since v1[1]:
* Make the nr of dirty pages a retval similar to sync variant of helper in
  patch 1 (Cedric)
* Stash number of bits set in bitmap quad in a variable and reuse in
  GLOBAL_DIRTY_RATE in patch 1
* Drop init to 0 given that we always initialize the @dirty used in the
  tracepoint

[1] https://lore.kernel.org/qemu-devel/20230523151217.46427-1-joao.m.martins@oracle.com/
[2] https://lore.kernel.org/qemu-devel/20230525114321.71066-1-joao.m.martins@oracle.com/
[3] https://lore.kernel.org/qemu-devel/20230529121114.5038-1-joao.m.martins@oracle.com/

Joao Martins (2):
  exec/ram_addr: return number of dirty pages in
    cpu_physical_memory_set_dirty_lebitmap()
  hw/vfio: Add number of dirty pages to vfio_get_dirty_bitmap tracepoint

 hw/vfio/common.c        |  7 ++++---
 hw/vfio/trace-events    |  2 +-
 include/exec/ram_addr.h | 28 ++++++++++++++++++++++------
 3 files changed, 27 insertions(+), 10 deletions(-)

-- 
2.39.3
Re: [PATCH v4 0/2] hw/vfio: Improve vfio_get_dirty_bitmap() tracepoint
Posted by Philippe Mathieu-Daudé 10 months, 1 week ago
On 30/5/23 20:05, Joao Martins wrote:

> Joao Martins (2):
>    exec/ram_addr: return number of dirty pages in
>      cpu_physical_memory_set_dirty_lebitmap()
>    hw/vfio: Add number of dirty pages to vfio_get_dirty_bitmap tracepoint

Queued, thanks.
Re: [PATCH v4 0/2] hw/vfio: Improve vfio_get_dirty_bitmap() tracepoint
Posted by Cédric Le Goater 10 months, 1 week ago
On 6/13/23 11:34, Philippe Mathieu-Daudé wrote:
> On 30/5/23 20:05, Joao Martins wrote:
> 
>> Joao Martins (2):
>>    exec/ram_addr: return number of dirty pages in
>>      cpu_physical_memory_set_dirty_lebitmap()
>>    hw/vfio: Add number of dirty pages to vfio_get_dirty_bitmap tracepoint
> 
> Queued, thanks.
> 

I had taken it into my vfio-next branch. As you wish.

Thanks,

C.


Re: [PATCH v4 0/2] hw/vfio: Improve vfio_get_dirty_bitmap() tracepoint
Posted by Philippe Mathieu-Daudé 10 months, 1 week ago
On 13/6/23 11:37, Cédric Le Goater wrote:
> On 6/13/23 11:34, Philippe Mathieu-Daudé wrote:
>> On 30/5/23 20:05, Joao Martins wrote:
>>
>>> Joao Martins (2):
>>>    exec/ram_addr: return number of dirty pages in
>>>      cpu_physical_memory_set_dirty_lebitmap()
>>>    hw/vfio: Add number of dirty pages to vfio_get_dirty_bitmap 
>>> tracepoint
>>
>> Queued, thanks.
>>
> 
> I had taken it into my vfio-next branch. As you wish.

Oh I just sent my PR :/ I can drop them if the PR fails.
I didn't understood Alex ack'ing the series meant you'd
take the series (I try to look for exec/memory patches).