From: Eduardo Habkost <ehabkost@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PULL 00/15] Machine queue, 2021-07-07
Date: Thu, 8 Jul 2021 11:32:37 -0400 [thread overview]
Message-ID: <CAOpTY_oTm=30KGMof+SSUebR_S7ndgCjR0zLVGoEFQ=ceg0Lgw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA_UybrCmOffY6HD7eiE=Ubks1LGhKYmXgQ_hYYsKMYfhQ@mail.gmail.com>
On Thu, Jul 8, 2021 at 5:53 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 7 Jul 2021 at 20:32, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > The following changes since commit 9aef0954195cc592e86846dbbe7f3c2c5603690a:
> >
> > Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging (2021-07-06 11:24:58 +0100)
> >
> > are available in the Git repository at:
> >
> > https://gitlab.com/ehabkost/qemu.git tags/machine-next-pull-request
> >
> > for you to fetch changes up to 4dc87143b9dbc0ae5719b67b4e533c824b239f00:
> >
> > vfio: Disable only uncoordinated discards for VFIO_TYPE1 iommus (2021-07-06 18:05:26 -0400)
> >
> > ----------------------------------------------------------------
> > Machine queue, 2021-07-07
> >
> > Deprecation:
> > * Deprecate pmem=on with non-DAX capable backend file
> > (Igor Mammedov)
> >
> > Feature:
> > * virtio-mem: vfio support (David Hildenbrand)
> >
> > Cleanup:
> > * vmbus: Don't make QOM property registration conditional
> > (Eduardo Habkost)
> >
>
> Hi; this generates warnings in the docs build:
>
> /home/pm/qemu/docs/../include/exec/memory.h:2286: warning: Function
> parameter or member 'rdm' not described in
> 'memory_region_set_ram_discard_manager'
> /home/pm/qemu/docs/../include/exec/memory.h:2286: warning: Excess
> function parameter 'urn' description in
> 'memory_region_set_ram_discard_manager'
>
> This seems to be because the function prototype for this
> function says it takes parameters 'mr' and 'rdm', but the
> doc comment documents 'mr' and 'urn'.
Sorry, I will apply David's fixup and resubmit.
It worries me that this is not being detected by our GitLab CI jobs.
Is anybody working to fix that?
--
Eduardo
prev parent reply other threads:[~2021-07-08 16:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 19:32 [PULL 00/15] Machine queue, 2021-07-07 Eduardo Habkost
2021-07-07 19:32 ` [PULL 01/15] vmbus: Don't make QOM property registration conditional Eduardo Habkost
2021-07-07 19:32 ` [PULL 02/15] Deprecate pmem=on with non-DAX capable backend file Eduardo Habkost
2021-07-07 19:32 ` [PULL 03/15] memory: Introduce RamDiscardManager for RAM memory regions Eduardo Habkost
2021-07-07 19:32 ` [PULL 04/15] memory: Helpers to copy/free a MemoryRegionSection Eduardo Habkost
2021-07-07 19:32 ` [PULL 05/15] virtio-mem: Factor out traversing unplugged ranges Eduardo Habkost
2021-07-07 19:32 ` [PULL 06/15] virtio-mem: Don't report errors when ram_block_discard_range() fails Eduardo Habkost
2021-07-07 19:32 ` [PULL 07/15] virtio-mem: Implement RamDiscardManager interface Eduardo Habkost
2021-07-07 19:32 ` [PULL 08/15] vfio: Support for RamDiscardManager in the !vIOMMU case Eduardo Habkost
2021-07-07 19:32 ` [PULL 09/15] vfio: Query and store the maximum number of possible DMA mappings Eduardo Habkost
2021-07-07 19:32 ` [PULL 10/15] vfio: Sanity check maximum number of DMA mappings with RamDiscardManager Eduardo Habkost
2021-07-07 19:32 ` [PULL 11/15] vfio: Support for RamDiscardManager in the vIOMMU case Eduardo Habkost
2021-07-07 19:32 ` [PULL 12/15] softmmu/physmem: Don't use atomic operations in ram_block_discard_(disable|require) Eduardo Habkost
2021-07-07 19:32 ` [PULL 13/15] softmmu/physmem: Extend ram_block_discard_(require|disable) by two discard types Eduardo Habkost
2021-07-07 19:32 ` [PULL 14/15] virtio-mem: Require only coordinated discards Eduardo Habkost
2021-07-07 19:32 ` [PULL 15/15] vfio: Disable only uncoordinated discards for VFIO_TYPE1 iommus Eduardo Habkost
2021-07-08 9:53 ` [PULL 00/15] Machine queue, 2021-07-07 Peter Maydell
2021-07-08 13:03 ` David Hildenbrand
2021-07-08 15:32 ` Eduardo Habkost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOpTY_oTm=30KGMof+SSUebR_S7ndgCjR0zLVGoEFQ=ceg0Lgw@mail.gmail.com' \
--to=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).