Re: [PATCH v4 0/6] Enhance documentation for new developers

2025-01-13 Thread Pierrick Bouvier

On 12/9/24 10:30, Pierrick Bouvier wrote:

This series extends our documentation with new pages to help developers
onboarding on QEMU. It focuses on providing a big picture of QEMU (to a
modest extend).

As such, it was written to be simple, short, easy to understand, and pointing to
more details. It provides another way to dive into details instead of simply
hitting the "search" box.

The first patches enhance the existing developer section. They provide
information about b4 and git-publish, two important tools that I learnt from my
coworkers, and were not presented anywhere, and were really missing IMHO.

Then, we introduce a new Codebase page, presenting (succintly) the various parts
of QEMU, and what every folder of the codebase contains.
We then add a glossary with the most recurrent acronyms we hear in our daily
conversations on the mailing list.
Finally, we add an "How-to" page which present how to build and test qemu, and
how to contribute a patch. It's definitely a repetition of existing information,
but the goal was to have a self contained page with all the commands I run
daily personally, and that someone would be interested to have.

When reviewing, please keep in mind this is targeting someone who discovers
QEMU, and not someone who contributed to the project for several years. What is
obvious for you will not be obvious for a random young developer.

That said, please free to point if something is "false", or "really incomplete".
It can be hard to summarize in one or two sentences complex parts, but that's
the intent here.

Your feedback on content or organization is very welcome!

Thanks,
Pierrick

v2:
- removed how-to section
- integrated all suggestions from Daniel and Peter (thanks for all your 
comments)
- Note: build environment keeps mentioning windows-arm64 because we solved the
   issue with gcc_struct attribute. The related series will be merged before 
this
   documentation.

v3:
- added a comment about git-publish asked by Daniel.

v4:
- add suggestion from Thomas for codebase and message-id.

Pierrick Bouvier (6):
   docs/devel: remove dead video link for sourcehut submit process
   docs/devel: add git-publish for patch submitting
   docs/devel: add b4 for patch retrieval
   docs/devel: add information on how to setup build environments
   docs: add a codebase section
   docs: add a glossary

  docs/about/build-platforms.rst |   4 +-
  docs/about/emulation.rst   |   2 +
  docs/devel/build-environment.rst   | 118 +++
  docs/devel/codebase.rst| 220 +++
  docs/devel/control-flow-integrity.rst  |   2 +
  docs/devel/decodetree.rst  |   2 +
  docs/devel/ebpf_rss.rst|   2 +
  docs/devel/index-build.rst |   1 +
  docs/devel/index-internals.rst |   2 +
  docs/devel/index.rst   |   1 +
  docs/devel/migration/main.rst  |   2 +
  docs/devel/multi-thread-tcg.rst|   2 +
  docs/devel/qapi-code-gen.rst   |   1 +
  docs/devel/submitting-a-patch.rst  |  44 +++-
  docs/devel/testing/main.rst|   9 +-
  docs/devel/testing/qtest.rst   |   2 +
  docs/glossary.rst  | 280 +
  docs/index.rst |   3 +
  docs/interop/qemu-ga.rst   |   2 +
  docs/system/arm/virt.rst   |   2 +
  docs/system/images.rst |   2 +
  docs/system/qemu-block-drivers.rst.inc |   2 +
  docs/tools/qemu-nbd.rst|   2 +
  docs/tools/qemu-storage-daemon.rst |   2 +
  docs/user/main.rst |   6 +
  25 files changed, 709 insertions(+), 6 deletions(-)
  create mode 100644 docs/devel/build-environment.rst
  create mode 100644 docs/devel/codebase.rst
  create mode 100644 docs/glossary.rst



Gentle ping on this series.

It was reviewed and it's currently waiting to be pulled by a maintainer.

Regards,
Pierrick



Re: [PATCH v2 0/2] block: Fix leak in send_qmp_error_event

2025-01-13 Thread Fabiano Rosas
Philippe Mathieu-Daudé  writes:

> Respin of Fabiano patch using g_autofree,
> and clarifying method docstrings.
>
> Fabiano Rosas (1):
>   block: Fix leak in send_qmp_error_event
>
> Philippe Mathieu-Daudé (1):
>   block: Improve blk_get_attached_dev_id() docstring
>
>  include/sysemu/block-backend-io.h |  7 +++
>  block/block-backend.c | 16 ++--
>  2 files changed, 17 insertions(+), 6 deletions(-)

Ping



Re: [PATCH v7 1/2] memory: Update inline documentation

2025-01-13 Thread Peter Xu
On Sat, Jan 11, 2025 at 01:15:24PM +0900, Akihiko Odaki wrote:
> On 2025/01/11 0:18, Peter Xu wrote:
> > On Fri, Jan 10, 2025 at 05:43:15PM +0900, Akihiko Odaki wrote:
> > > On 2025/01/10 4:37, Peter Xu wrote:
> > > > On Thu, Jan 09, 2025 at 02:29:21PM -0500, Peter Xu wrote:
> > > > > On Thu, Jan 09, 2025 at 01:30:35PM +0100, BALATON Zoltan wrote:
> > > > > > On Thu, 9 Jan 2025, Akihiko Odaki wrote:
> > > > > > > Do not refer to "memory region's reference count"
> > > > > > > -
> > > > > > > 
> > > > > > > Now MemoryRegions do have their own reference counts, but they 
> > > > > > > will not
> > > > > > > be used when their owners are not themselves. However, the 
> > > > > > > documentation
> > > > > > > of memory_region_ref() says it adds "1 to a memory region's 
> > > > > > > reference
> > > > > > > count", which is confusing. Avoid referring to "memory region's
> > > > > > > reference count" and just say: "Add a reference to a memory 
> > > > > > > region".
> > > > > > > Make a similar change to memory_region_unref() too.
> > > > > > > 
> > > > > > > Refer to docs/devel/memory.rst for "owner"
> > > > > > > --
> > > > > > > 
> > > > > > > memory_region_ref() and memory_region_unref() used to have their 
> > > > > > > own
> > > > > > > descriptions of "owner", but they are somewhat out-of-date and
> > > > > > > misleading.
> > > > > > > 
> > > > > > > In particular, they say "whenever memory regions are accessed 
> > > > > > > outside
> > > > > > > the BQL, they need to be preserved against hot-unplug", but 
> > > > > > > protecting
> > > > > > > against hot-unplug is not mandatory if it is known that they will 
> > > > > > > never
> > > > > > > be hot-unplugged. They also say "MemoryRegions actually do not 
> > > > > > > have
> > > > > > > their own reference count", but they actually do. They just will 
> > > > > > > not be
> > > > > > > used unless their owners are not themselves.
> > > > > > > 
> > > > > > > Refer to docs/devel/memory.rst as the single source of truth 
> > > > > > > instead of
> > > > > > > maintaining duplicate descriptions of "owner".
> > > > > > > 
> > > > > > > Clarify that owner may be missing
> > > > > > > 
> > > > > > > -
> > > > > > > A memory region may not have an owner, and memory_region_ref() and
> > > > > > > memory_region_unref() do nothing for such.
> > > > > > > 
> > > > > > > memory: Clarify owner must not call memory_region_ref()
> > > > > > > 
> > > > > > > 
> > > > > > > The owner must not call this function as it results in a circular
> > > > > > > reference.
> > > > > > > 
> > > > > > > Signed-off-by: Akihiko Odaki 
> > > > > > > Reviewed-by: Peter Xu 
> > > > > > > ---
> > > > > > > include/exec/memory.h | 59 
> > > > > > > ---
> > > > > > > 1 file changed, 28 insertions(+), 31 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/include/exec/memory.h b/include/exec/memory.h
> > > > > > > index 9458e2801d50..ca247343f433 100644
> > > > > > > --- a/include/exec/memory.h
> > > > > > > +++ b/include/exec/memory.h
> > > > > > > @@ -1210,7 +1210,7 @@ void 
> > > > > > > memory_region_section_free_copy(MemoryRegionSection *s);
> > > > > > >* memory_region_add_subregion() to add subregions.
> > > > > > >*
> > > > > > >* @mr: the #MemoryRegion to be initialized
> > > > > > > - * @owner: the object that tracks the region's reference count
> > > > > > > + * @owner: the object that keeps the region alive
> > > > > > >* @name: used for debugging; not visible to the user or ABI
> > > > > > >* @size: size of the region; any subregions beyond this size 
> > > > > > > will be clipped
> > > > > > >*/
> > > > > > > @@ -1220,29 +1220,26 @@ void memory_region_init(MemoryRegion *mr,
> > > > > > >   uint64_t size);
> > > > > > > 
> > > > > > > /**
> > > > > > > - * memory_region_ref: Add 1 to a memory region's reference count
> > > > > > > + * memory_region_ref: Add a reference to the owner of a memory 
> > > > > > > region
> > > > > > >*
> > > > > > > - * Whenever memory regions are accessed outside the BQL, they 
> > > > > > > need to be
> > > > > > > - * preserved against hot-unplug.  MemoryRegions actually do not 
> > > > > > > have their
> > > > > > > - * own reference count; they piggyback on a QOM object, their 
> > > > > > > "owner".
> > > > > > > - * This function adds a reference to the owner.
> > > > > > > - *
> > > > > > > - * All MemoryRegions must have an owner if they can disappear, 
> > > > > > > even if the
> > > > > > > - * device they belong to operates exclusively under the BQL.  
> > > > > > > This is because
> > > > > > > - * the region could be returned at any time by 
> > > > > > > memory_region_find, and this
> > > > > > > - * is usually under guest control.
> > > > > > > + * This func

Re: [PATCH v17 00/11] New vmapple machine type and xhci fixes

2025-01-13 Thread Philippe Mathieu-Daudé

On 12/1/25 22:00, Phil Dennis-Jordan wrote:

This patch set introduces a new ARM and macOS HVF specific machine type
called "vmapple". There are also some patches for fixing XHCI spec
compliance issues and adding a workaround to a quirk in the macOS guest's
XHCI driver.




Phil Dennis-Jordan (3):
   hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec
   hw/usb/hcd-xhci-pci: Use event ring 0 if mapping unsupported


Patches 1 & 2 queued.