Re: of AVR target page size

[Michael Rolnik]

I guess we can add some bits TARGET_PAGE_BITS, this will make us to push
some portion of SRAM into the CPU.

Michael Rolnik

On Thu, Mar 18, 2021 at 12:33 AM Peter Maydell 
wrote:

> On Wed, 17 Mar 2021 at 20:17, Dr. David Alan Gilbert
>  wrote:
> >
> > Hi Michael,
> >   I noticed your AVR code defines:
> >
> >   #define TARGET_PAGE_BITS 8
> >
> > and has an explanation of why.
> >
> > Note however that's not going to work with the current live
> > migration/snapshotting code, since you're a couple of bits smaller
> > than the smallest page size we had so far, and for many years
> > the RAM migration code has stolen the bottom few bits of the address
> > as a flag field, and has already used 0x100 up; see migration/ram.c
> > RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> > you change it then it'll break migration compatibility with existing
> > qemu's.
>
> If you want to use low bits as flags for other stuff, you
> should have a compile time assert that you have the number
> of bits you expect, or otherwise force a compile error.
> Otherwise you'll end up with unpleasant surprises like this one...
>
> I think that for the cpu-all.h uses of low bits we would
> end up with a compile error for excessively small TARGET_PAGE_BITS
> because we define the bits like this:
> #define TLB_DISCARD_WRITE   (1 << (TARGET_PAGE_BITS_MIN - 6))
> and I expect the compiler will complain if the RHS of the '<<'
> is a negative constant. But I don't know if that's deliberate
> or a happy accident :-)
>
> thanks
> -- PMM
>


-- 
Best Regards,
Michael Rolnik

Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log

[Kunkun Jiang]

Hi Kevin,

On 2021/3/18 14:28, Tian, Kevin wrote:

From: Kunkun Jiang
Sent: Wednesday, March 10, 2021 5:41 PM

Hi all,

In the past, we clear dirty log immediately after sync dirty log to
userspace. This may cause redundant dirty handling if userspace
handles dirty log iteratively:

After vfio clears dirty log, new dirty log starts to generate. These
new dirty log will be reported to userspace even if they are generated
before userspace handles the same dirty page.

Since a new dirty log tracking method for vfio based on iommu hwdbm[1]
has been introduced in the kernel and added a new capability named
VFIO_DIRTY_LOG_MANUAL_CLEAR, we can eliminate some redundant dirty
handling by supporting it.

Is there any performance data showing the benefit of this new method?


Current dirty log tracking method for VFIO:
[1] All pages marked dirty if not all iommu_groups have pinned_scope
[2] pinned pages by various vendor drivers if all iommu_groups have 
pinned scope


Both methods are coarse-grained and can not determine which pages are
really dirty. Each round may mark the pages that are not really dirty as 
dirty

and send them to the destination. ( It might be better if the range of the
pinned_scope was smaller. ) This will result in a waste of resources.

HWDBM is short for Hardware Dirty Bit Management.
(e.g. smmuv3 HTTU, Hardware Translation Table Update)

About SMMU HTTU:
HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
state of the TTD (Translation Table Descriptor) by hardware.

With HTTU, stage1 TTD is classified into 3 types:
         DBM bit AP[2](readonly bit)
1. writable_clean  1    1
2. writable_dirty   1    0
3. readonly   0    1

If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
writable_clean to writable_dirty. Then software can scan TTD to sync dirty
state into dirty bitmap. With this feature, we can track the dirty log of
DMA continuously and precisely.

The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
the KVM side. We add this new log_clear() interface only to split the old
log_sync() into two separated procedures:

- use log_sync() to collect the collection only, and,
- use log_clear() to clear the dirty bitmap.

If you're interested in this new method, you can take a look at our set of
patches.
[1] 
https://lore.kernel.org/linux-iommu/20210310090614.26668-1-zhukeqi...@huawei.com/


Best regards,
Kunkun Jiang


This series include patches as below:
Patch 1:
- updated the linux-headers/linux/vfio.h from kernel side

Patch 2:
- introduced 'struct VFIODMARange' to describe a range of the given DMA
   mapping and with respect to a VFIO_IOMMU_MAP_DMA operation

Patch 3:
- implemented the operation to manual clear vfio dirty log, which can
   eliminate some redundant dirty handling

Thanks,
Kunkun Jiang

[1] https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
zhukeqi...@huawei.com/T/#mb168c9738ecd3d8794e2da14f970545d5820f
863

Zenghui Yu (3):
   linux-headers: update against 5.12-rc2 and "vfio log clear" series
   vfio: Maintain DMA mapping range for the container
   vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP

  hw/vfio/common.c  | 207 --
  include/hw/vfio/vfio-common.h |  10 ++
  linux-headers/linux/vfio.h|  55 -
  3 files changed, 264 insertions(+), 8 deletions(-)

--
2.23.0



.

Re: [PATCH v3 00/36] block: update graph permissions update

[Vladimir Sementsov-Ogievskiy]

17.03.2021 20:33, Eric Blake wrote:

On 3/17/21 10:38 AM, Vladimir Sementsov-Ogievskiy wrote:


6/36 Checking commit 5780b805277e (block: drop ctx argument from
bdrv_root_attach_child)
7/36 Checking commit 68189c099a3a (block: make bdrv_reopen_{prepare,
commit, abort} private)
ERROR: Author email address is mangled by the mailing list
#2:
Author: Vladimir Sementsov-Ogievskiy via 



Who know what is it? Commit message, subject and "From:" header are
clean in the email..


The list mangles mails for setups where DKIM/SCP setups are strict
enough that the mail would be rejected by various recipients otherwise.
But I have no idea why the mailing list rewrote the headers for that one
mail, but not the rest of your series - usually, DKIM setups are
persistent enough that it will be an all-or-none conversion to the
entire series.

At any rate, a maintainer can manually fix it for one patch, or you can
resend (if the mailing list keeps mangling headers, you can add a 'From:
' line in the body of your email that will override the mangled header;
but since the list doesn't usually mangle your headers, you may not need
to resort to that).



I'm looking at 7/36 in my mailbox, and don't see where is it mangled?

Looking at message source I see clean "From: Vladimir Sementsov-Ogievskiy 
", and "qemu-devel@nongnu.org" is only in Cc:.

And I've sent the series by git-email, so emails in thunderbird came from the 
mailing list in a clean way.

As well, message looks good in the archive: 
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06288.html

--
Best regards,
Vladimir

Re: [RFC v2 11/13] vhost: Shadow virtqueue buffers forwarding

[Eugenio Perez Martin]

On Thu, Mar 18, 2021 at 4:14 AM Jason Wang  wrote:
>
>
> 在 2021/3/17 下午10:38, Eugenio Perez Martin 写道:
> > On Wed, Mar 17, 2021 at 3:51 AM Jason Wang  wrote:
> >>
> >> 在 2021/3/17 上午12:05, Eugenio Perez Martin 写道:
> >>> On Tue, Mar 16, 2021 at 9:15 AM Jason Wang  wrote:
>  在 2021/3/16 上午3:48, Eugenio Pérez 写道:
> > Initial version of shadow virtqueue that actually forward buffers.
> >
> > It reuses the VirtQueue code for the device part. The driver part is
> > based on Linux's virtio_ring driver, but with stripped functionality
> > and optimizations so it's easier to review.
> >
> > These will be added in later commits.
> >
> > Signed-off-by: Eugenio Pérez 
> > ---
> > hw/virtio/vhost-shadow-virtqueue.c | 212 
> > +++--
> > hw/virtio/vhost.c  | 113 ++-
> > 2 files changed, 312 insertions(+), 13 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> > b/hw/virtio/vhost-shadow-virtqueue.c
> > index 1460d1d5d1..68ed0f2740 100644
> > --- a/hw/virtio/vhost-shadow-virtqueue.c
> > +++ b/hw/virtio/vhost-shadow-virtqueue.c
> > @@ -9,6 +9,7 @@
> >
> > #include "hw/virtio/vhost-shadow-virtqueue.h"
> > #include "hw/virtio/vhost.h"
> > +#include "hw/virtio/virtio-access.h"
> >
> > #include "standard-headers/linux/vhost_types.h"
> >
> > @@ -55,11 +56,96 @@ typedef struct VhostShadowVirtqueue {
> > /* Virtio device */
> > VirtIODevice *vdev;
> >
> > +/* Map for returning guest's descriptors */
> > +VirtQueueElement **ring_id_maps;
> > +
> > +/* Next head to expose to device */
> > +uint16_t avail_idx_shadow;
> > +
> > +/* Next free descriptor */
> > +uint16_t free_head;
> > +
> > +/* Last seen used idx */
> > +uint16_t shadow_used_idx;
> > +
> > +/* Next head to consume from device */
> > +uint16_t used_idx;
> > +
> > /* Descriptors copied from guest */
> > vring_desc_t descs[];
> > } VhostShadowVirtqueue;
> >
> > -/* Forward guest notifications */
> > +static void vhost_vring_write_descs(VhostShadowVirtqueue *svq,
> > +const struct iovec *iovec,
> > +size_t num, bool more_descs, bool 
> > write)
> > +{
> > +uint16_t i = svq->free_head, last = svq->free_head;
> > +unsigned n;
> > +uint16_t flags = write ? virtio_tswap16(svq->vdev, 
> > VRING_DESC_F_WRITE) : 0;
> > +vring_desc_t *descs = svq->vring.desc;
> > +
> > +if (num == 0) {
> > +return;
> > +}
> > +
> > +for (n = 0; n < num; n++) {
> > +if (more_descs || (n + 1 < num)) {
> > +descs[i].flags = flags | virtio_tswap16(svq->vdev,
> > +VRING_DESC_F_NEXT);
> > +} else {
> > +descs[i].flags = flags;
> > +}
> > +descs[i].addr = virtio_tswap64(svq->vdev, 
> > (hwaddr)iovec[n].iov_base);
>  So unsing virtio_tswap() is probably not correct since we're talking
>  with vhost backends which has its own endiness.
> 
> >>> I was trying to expose the buffer with the same endianness as the
> >>> driver originally offered, so if guest->qemu requires a bswap, I think
> >>> it will always require a bswap again to expose to the device again.
> >>
> >> So assumes vhost-vDPA always provide a non-transitional device[1].
> >>
> >> Then if Qemu present a transitional device, we need to do the endian
> >> conversion when necessary, if Qemu present a non-transitional device, we
> >> don't need to do that, guest driver will do that for us.
> >>
> >> But it looks to me the virtio_tswap() can't be used for this since it:
> >>
> >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
> >> {
> >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> >>   return virtio_is_big_endian(vdev);
> >> #elif defined(TARGET_WORDS_BIGENDIAN)
> >>   if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> >>   /* Devices conforming to VIRTIO 1.0 or later are always LE. */
> >>   return false;
> >>   }
> >>   return true;
> >> #else
> >>   return false;
> >> #endif
> >> }
> >>
> >> So if we present a legacy device on top of a non-transitiaonl vDPA
> >> device. The VIRITIO_F_VERSION_1 check is wrong.
> >>
> >>
>  For vhost-vDPA, we can assume that it's a 1.0 device.
> >>> Isn't it needed if the host is big endian?
> >>
> >> [1]
> >>
> >> So non-transitional device always assume little endian.
> >>
> >> For vhost-vDPA, we don't want to present transitional device which may
> >> end up with a lot of burdens.
> >>
> >> I suspect the legacy driver plust vhost vDPA already break, so I

Re: [PATCH] hw/arm/virt: Disable pl011 clock migration if needed

[Andrew Jones]

On Thu, Mar 18, 2021 at 10:38:01AM +0800, Gavin Shan wrote:
> A clock is added by commit aac63e0e6ea3 ("hw/char/pl011: add a clock
> input") since v5.2.0 which corresponds to virt-5.2 machine type. It
> causes backwards migration failure from upstream to downstream (v5.1.0)
> when the machine type is specified with virt-5.1.
> 
> This fixes the issue by following instructions from section "Connecting
> subsections to properties" in docs/devel/migration.rst. With this applied,
> the PL011 clock is migrated based on the machine type.
> 
>virt-5.2 or newer:  migration
>virt-5.1 or older:  non-migration
> 
> Cc: qemu-sta...@nongnu.org # v5.2.0+
> Fixes: aac63e0e6ea3 ("hw/char/pl011: add a clock input")
> Suggested-by: Andrew Jones 
> Signed-off-by: Gavin Shan 
> ---
>  hw/char/pl011.c | 9 +
>  hw/core/machine.c   | 1 +
>  include/hw/char/pl011.h | 1 +
>  3 files changed, 11 insertions(+)

Reviewed-by: Andrew Jones 

And I agree with applying to 5.2 stable.

Thanks,
drew

Re: [PATCH V3] file-posix: allow -EBUSY -EINVAL errors during write zeros on block

[Vladimir Sementsov-Ogievskiy via]

18.03.2021 02:23, John Snow wrote:

On 3/9/21 7:16 PM, ChangLimin wrote:

Since Linux 5.10, write zeros to a multipath device using
ioctl(fd, BLKZEROOUT, range) with cache none or directsync return -EBUSY
permanently.



When do we get -EINVAL? Both of the commits referenced below don't specifically 
mention it, so I am not sure in which circumstances that might arise.


Similar to handle_aiocb_write_zeroes_unmap, handle_aiocb_write_zeroes_block
allow -EBUSY and -EINVAL errors during ioctl(fd, BLKZEROOUT, range).

Reference commit in Linux 5.10:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=384d87ef2c954fc58e6c5fd8253e4a1984f5fe02
 


Although it will be fixed in 5.12, I think it's good to avoid similar problem 
in the future.
https://lore.kernel.org/linux-block/53689a67-7591-0ad8-3e7d-dca9a626c...@kernel.dk/ 




Wait, if they're fixing the function to actually apply a different fallback 
path, shouldn't we *not* allow EBUSY?


Signed-off-by: ChangLimin 
---
  block/file-posix.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 05079b40ca..4e132db929 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1629,8 +1629,13 @@ static ssize_t 
handle_aiocb_write_zeroes_block(RawPosixAIOData *aiocb)
          } while (errno == EINTR);

          ret = translate_err(-errno);
-        if (ret == -ENOTSUP) {
-            s->has_write_zeroes = false;
+        switch (ret) {
+        case -ENOTSUP:
+            s->has_write_zeroes = false; /* fall through */
+        case -EINVAL:
+        case -EBUSY:
+            return -ENOTSUP;
+            break;


oh, we're not "allowing" them, we're treating the failure *more seriously* so 
that we avoid attempting to call this function ever again for this FD.


No. s->has_write_zeroes is set to false only for ENOTSUP came from 
translate_err, this behavior is not changed.

The only thing the patch does is _returning_ ENOTSUP instead of EINVAL and 
EBUSY. And I don't understand why. I think that at least for EINVAL it's just 
wrong.



Can you please add a brief comment here, something like:

/* Linux 5.10/5.11 may return these for multipath devices */


          }
      }
  #endif
--
2.27.0







--
Best regards,
Vladimir

Re: [RFC v9 29/50] target/arm: cleanup cpu includes

[Claudio Fontana]

On 3/17/21 8:01 PM, Philippe Mathieu-Daudé wrote:
> On 3/17/21 7:29 PM, Claudio Fontana wrote:
>> cpu.c,
>> cpu32.c,
>> cpu64.c,
>> tcg/sysemu/tcg-cpu.c,
>>
>> all need a good cleanup when it comes to included header files.
>>
>> Signed-off-by: Claudio Fontana 
>> ---
>>  target/arm/cpu.c|  8 ++--
>>  target/arm/cpu32.c  | 14 --
>>  target/arm/cpu64.c  |  6 --
>>  target/arm/tcg/sysemu/tcg-cpu.c | 22 +-
>>  roms/SLOF   |  2 +-
>>  5 files changed, 4 insertions(+), 48 deletions(-)
> 
>> diff --git a/roms/SLOF b/roms/SLOF
>> index 33a7322de1..e18ddad851 16
>> --- a/roms/SLOF
>> +++ b/roms/SLOF
>> @@ -1 +1 @@
>> -Subproject commit 33a7322de13e9dca4b38851a345a58d37e7a441d
>> +Subproject commit e18ddad8516ff2cfe36ec130200318f7251aa78c
> 
> Besides this dubious change, the rest LGTM :)
> 

Oops thanks, no idea how that got in there.

Ciao,

C

Re: "make check" broken with everything but tools disabled

[Philippe Mathieu-Daudé]

On 3/17/21 11:35 PM, John Snow wrote:
> On 3/16/21 9:28 AM, Markus Armbruster wrote:
>> Watch this:
>>
>>  $ mkdir bld-tools
>>  $ cd bld-tools
>>  $ ../configure --disable-system --disable-user --enable-tools
>>  $ make check
>>  [...]
>>  make: *** No rule to make target
>> 'tests/qemu-iotests/socket_scm_helper', needed by 'check-block'.  Stop.
>>
>>
> 
> One more thing to add a CI job to check, I suppose.

We have the 'build-tools-and-docs-debian' job, but
lack the 'check-tools-and-docs-debian' one.

Re: [PATCH 0/2] *** This is based on pull request from Alex Bennée ***

[Markus Armbruster]

Please use the subject line for explaining the purpose of the series.
"Based on" information should go into the body.  Ideally also in
machine-readable form, like

Based-on: <20171220185924.32756-1-arm...@redhat.com>

where the thing in  is the pull request's Message-id.

Note: I used one of my pull requests, not Alex's, for this example.

Yonggang Luo  writes:

> *** BLURB HERE ***

Recommend to delete this placeholder next time :)

> The pull request
> https://patchew.org/QEMU/20210317072216.16316-1-alex.ben...@linaro.org/
>
> Yonggang Luo (2):
>   plugins: Update qemu-plugins.symbols to match qemu-plugins.h
>   plugins: Move all typedef and type declaration to the front of the
> qemu-plugin.h
>
>  include/qemu/qemu-plugin.h   | 187 +--
>  plugins/qemu-plugins.symbols |  25 +++--
>  2 files changed, 104 insertions(+), 108 deletions(-)

Re: Serious doubts about Gitlab CI

[Philippe Mathieu-Daudé]

On 3/18/21 2:28 AM, Bin Meng wrote:
> On Thu, Mar 18, 2021 at 4:32 AM Philippe Mathieu-Daudé  
> wrote:
>>
>> Hi,
>>
>> For some (unclear) reason I got my free tier Gitlab account renewed and
>> lost the privilege for users opening account before the quota limit.
>>
>> I pushed a single branch to my namespace repo to trigger a pipeline.
>> 1h later I was surprised to see the pipeline was stuck, having completed
>> 99 jobs of 119. Looking closer there is a red comment on top of the
>> pipeline:
>>
>>  philmd has exceeded its pipeline minutes quota. Unless you buy
>>  additional pipeline minutes, no new jobs or pipelines in its projects
>>  will run. [Buy more Pipelines minutes]
>>
>> So I exhausted my 400 monthly minutes credit.
>>
>> From this FAQ:
>> https://about.gitlab.com/pricing/faq-consumption-cicd/#managing-your-cicd-minutes-usage
>>
>> Q. What happens if I hit the CI/CD Minutes allotted limit and forget to
>> purchase additional CI/CD Minutes?
>>
>> A. You will not be able to run new jobs until you purchase additional
>> CI/CD Minutes, or until the next month when you receive your monthly
>> allotted CI/CD Minutes.
>>
>> Q. Will I be notified before I hit my limit on CI/CD Minutes?
>>
>> A. You will receive notification banners in-app when your group has less
>> than 30%, 5% or exceeded your total allotted CI/CD minutes.
>>
>> I indeed received 3 warnings in 7 minutes.
>>
>> Now I'm having serious doubts about Gitlab usefulness for the QEMU
>> community...
>>
>> Some screenshots FWIW:
>>
>> https://pasteboard.co/JT51wGR.png
>> https://pasteboard.co/JT51Rqq.png
> 
> This snapshot shows that 2278 / 400 minutes (569%) were used. Strange?

Checking the timestamps, the last job was created *before* the 400min
limit. Gitlab didn't killed the running jobs once the limit was reached,
so the counter kept incrementing. Now I wonder if I buy 400 new minutes
I'll have new credit or it will be used to pay my debt...

Anyhow we have more than 100 jobs, so that mean if we use Gitlab once
a month, each job can't take more than 4min...

>> https://pasteboard.co/JT52fNL.png
> 
> I checked my gitlab settings, and it shows 0 / 400 minutes. However I
> am pretty sure I have been using gitlab CI this month several times.

You likely created your account more than 6 months ago. See
previous discussions:

https://forum.gitlab.com/t/ci-cd-minutes-for-gitlab-saas-free-tier/40241/42
https://forum.gitlab.com/t/ci-cd-minutes-for-gitlab-saas-free-tier/40241/52
https://forum.gitlab.com/t/ci-cd-minutes-for-gitlab-saas-free-tier/40241/59
https://forum.gitlab.com/t/ci-cd-minutes-for-gitlab-saas-free-tier/40241/63

RE: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log

[Tian, Kevin]

> From: Kunkun Jiang 
> Sent: Thursday, March 18, 2021 3:59 PM
> 
> Hi Kevin,
> 
> On 2021/3/18 14:28, Tian, Kevin wrote:
> >> From: Kunkun Jiang
> >> Sent: Wednesday, March 10, 2021 5:41 PM
> >>
> >> Hi all,
> >>
> >> In the past, we clear dirty log immediately after sync dirty log to
> >> userspace. This may cause redundant dirty handling if userspace
> >> handles dirty log iteratively:
> >>
> >> After vfio clears dirty log, new dirty log starts to generate. These
> >> new dirty log will be reported to userspace even if they are generated
> >> before userspace handles the same dirty page.
> >>
> >> Since a new dirty log tracking method for vfio based on iommu hwdbm[1]
> >> has been introduced in the kernel and added a new capability named
> >> VFIO_DIRTY_LOG_MANUAL_CLEAR, we can eliminate some redundant
> dirty
> >> handling by supporting it.
> > Is there any performance data showing the benefit of this new method?
> >
> Current dirty log tracking method for VFIO:
> [1] All pages marked dirty if not all iommu_groups have pinned_scope
> [2] pinned pages by various vendor drivers if all iommu_groups have
> pinned scope
> 
> Both methods are coarse-grained and can not determine which pages are
> really dirty. Each round may mark the pages that are not really dirty as
> dirty
> and send them to the destination. ( It might be better if the range of the
> pinned_scope was smaller. ) This will result in a waste of resources.
> 
> HWDBM is short for Hardware Dirty Bit Management.
> (e.g. smmuv3 HTTU, Hardware Translation Table Update)
> 
> About SMMU HTTU:
> HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
> state of the TTD (Translation Table Descriptor) by hardware.
> 
> With HTTU, stage1 TTD is classified into 3 types:
>           DBM bit AP[2](readonly bit)
> 1. writable_clean  1    1
> 2. writable_dirty   1    0
> 3. readonly   0    1
> 
> If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
> writable_clean to writable_dirty. Then software can scan TTD to sync dirty
> state into dirty bitmap. With this feature, we can track the dirty log of
> DMA continuously and precisely.
> 
> The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
> the KVM side. We add this new log_clear() interface only to split the old
> log_sync() into two separated procedures:
> 
> - use log_sync() to collect the collection only, and,
> - use log_clear() to clear the dirty bitmap.
> 
> If you're interested in this new method, you can take a look at our set of
> patches.
> [1]
> https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
> zhukeqi...@huawei.com/
> 

I know what you are doing. Intel is also working on VT-d dirty bit support
based on above link. What I'm curious is the actual performance gain 
with this optimization. KVM doing that is one good reference, but IOMMU
has different characteristics (e.g. longer invalidation latency) compared to 
CPU MMU. It's always good to understand what a so-called optimization
can actually optimize in a context different from where it's originally proved.😊

Thanks
Kevin

Re: "make check" broken with everything but tools disabled

[Claudio Fontana]

On 3/16/21 2:28 PM, Markus Armbruster wrote:
> Watch this:
> 
> $ mkdir bld-tools
> $ cd bld-tools
> $ ../configure --disable-system --disable-user --enable-tools
> $ make check
> [...]
> make: *** No rule to make target 'tests/qemu-iotests/socket_scm_helper', 
> needed by 'check-block'.  Stop.
> 
> 

Hi Markus,

I can reproduce this error too.

When looking at the sequence of commands I was almost sure it was due to a 
missing "make" before the "make check",
as my experience with the new build system (meson-based), is that I have to do:

make

first, and then

make check

later, or bugs start happening, build can end up doing the wrong things.
I thought this was a known limitation and I am currently just dealing with it.

But then I tried to apply this to your specific case, and I get the same error 
nevertheless.

make: *** No rule to make target 'tests/qemu-iotests/socket_scm_helper', needed 
by 'check-block'.  Stop.

Ciao,

CLaudio

[PATCH v2 2/7] ui/vdagent: core infrastructure

[Gerd Hoffmann]

The vdagent protocol allows the guest agent (spice-vdagent) and the
spice client exchange messages to implement features which require
guest cooperation, for example clipboard support.

This is a qemu implementation of the spice client side.  This allows
the spice guest agent talk to qemu directly when not using the spice
protocol.

usage: qemu \
  -chardev vdagent,id=vdagent \
  -device virtserialport,chardev=vdagent,name=com.redhat.spice.0

This patch adds just the protocol basics: initial handshake and
capability negotiation.

Signed-off-by: Gerd Hoffmann 
---
 ui/vdagent.c| 279 
 qapi/char.json  |  13 +++
 ui/meson.build  |   1 +
 ui/trace-events |   8 ++
 4 files changed, 301 insertions(+)
 create mode 100644 ui/vdagent.c

diff --git a/ui/vdagent.c b/ui/vdagent.c
new file mode 100644
index ..146ddb8e31b4
--- /dev/null
+++ b/ui/vdagent.c
@@ -0,0 +1,279 @@
+#include "qemu/osdep.h"
+#include "include/qemu-common.h"
+#include "chardev/char.h"
+#include "trace.h"
+
+#include "qapi/qapi-types-char.h"
+
+#include "spice/vd_agent.h"
+
+struct VDAgentChardev {
+Chardev parent;
+
+/* guest vdagent */
+uint32_t caps;
+VDIChunkHeader chunk;
+uint32_t chunksize;
+uint8_t *msgbuf;
+uint32_t msgsize;
+};
+typedef struct VDAgentChardev VDAgentChardev;
+
+#define TYPE_CHARDEV_VDAGENT "chardev-vdagent"
+
+DECLARE_INSTANCE_CHECKER(VDAgentChardev, VDAGENT_CHARDEV,
+ TYPE_CHARDEV_VDAGENT);
+
+/* -- */
+/* names, for debug logging   */
+
+static const char *cap_name[] = {
+[VD_AGENT_CAP_MOUSE_STATE]= "mouse-state",
+[VD_AGENT_CAP_MONITORS_CONFIG]= "monitors-config",
+[VD_AGENT_CAP_REPLY]  = "reply",
+[VD_AGENT_CAP_CLIPBOARD]  = "clipboard",
+[VD_AGENT_CAP_DISPLAY_CONFIG] = "display-config",
+[VD_AGENT_CAP_CLIPBOARD_BY_DEMAND]= "clipboard-by-demand",
+[VD_AGENT_CAP_CLIPBOARD_SELECTION]= "clipboard-selection",
+[VD_AGENT_CAP_SPARSE_MONITORS_CONFIG] = "sparse-monitors-config",
+[VD_AGENT_CAP_GUEST_LINEEND_LF]   = "guest-lineend-lf",
+[VD_AGENT_CAP_GUEST_LINEEND_CRLF] = "guest-lineend-crlf",
+[VD_AGENT_CAP_MAX_CLIPBOARD]  = "max-clipboard",
+[VD_AGENT_CAP_AUDIO_VOLUME_SYNC]  = "audio-volume-sync",
+[VD_AGENT_CAP_MONITORS_CONFIG_POSITION]   = "monitors-config-position",
+[VD_AGENT_CAP_FILE_XFER_DISABLED] = "file-xfer-disabled",
+[VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS]  = 
"file-xfer-detailed-errors",
+#if 0
+[VD_AGENT_CAP_GRAPHICS_DEVICE_INFO]   = "graphics-device-info",
+[VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB] = 
"clipboard-no-release-on-regrab",
+[VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL]  = "clipboard-grab-serial",
+#endif
+};
+
+static const char *msg_name[] = {
+[VD_AGENT_MOUSE_STATE]   = "mouse-state",
+[VD_AGENT_MONITORS_CONFIG]   = "monitors-config",
+[VD_AGENT_REPLY] = "reply",
+[VD_AGENT_CLIPBOARD] = "clipboard",
+[VD_AGENT_DISPLAY_CONFIG]= "display-config",
+[VD_AGENT_ANNOUNCE_CAPABILITIES] = "announce-capabilities",
+[VD_AGENT_CLIPBOARD_GRAB]= "clipboard-grab",
+[VD_AGENT_CLIPBOARD_REQUEST] = "clipboard-request",
+[VD_AGENT_CLIPBOARD_RELEASE] = "clipboard-release",
+[VD_AGENT_FILE_XFER_START]   = "file-xfer-start",
+[VD_AGENT_FILE_XFER_STATUS]  = "file-xfer-status",
+[VD_AGENT_FILE_XFER_DATA]= "file-xfer-data",
+[VD_AGENT_CLIENT_DISCONNECTED]   = "client-disconnected",
+[VD_AGENT_MAX_CLIPBOARD] = "max-clipboard",
+[VD_AGENT_AUDIO_VOLUME_SYNC] = "audio-volume-sync",
+#if 0
+[VD_AGENT_GRAPHICS_DEVICE_INFO]  = "graphics-device-info",
+#endif
+};
+
+#define GET_NAME(_m, _v) \
+(((_v) < ARRAY_SIZE(_m) && (_m[_v])) ? (_m[_v]) : "???")
+
+/* -- */
+/* send messages  */
+
+static void vdagent_send_buf(VDAgentChardev *vd, void *ptr, uint32_t msgsize)
+{
+uint8_t *msgbuf = ptr;
+uint32_t len, pos = 0;
+
+while (pos < msgsize) {
+len = qemu_chr_be_can_write(CHARDEV(vd));
+if (len > msgsize - pos) {
+len = msgsize - pos;
+}
+qemu_chr_be_write(CHARDEV(vd), msgbuf + pos, len);
+pos += len;
+}
+}
+
+static void vdagent_send_msg(VDAgentChardev *vd, VDAgentMessage *msg)
+{
+uint8_t *msgbuf = (void *)msg;
+uint32_t msgsize = sizeof(VDAgentMessage) + msg->size;
+uint32_t msgoff = 0;
+VDIChunkHeader chunk;
+
+trace_vdagent_send(GET_NAME(msg_name, msg->type));
+
+msg->protocol

[PATCH v2 0/7] ui: add vdagent implementation and clipboard support.

[Gerd Hoffmann]

Fist sketch of cut+paste support for vnc.  On the guest side we are
going to reuse the spice vdagent, so things should work out-of-the-box
with guests in the wild.  So this patch set brings a qemu implemenation
of the vdagent protocol.

Beside that there is the clipboard infrastructure of course.  For now
only text support is there.  The design allows adding more data types,
so we can add image support and maybe more later on.  So far vdagent,
vnc server and gtk ui are hooked up.

Usage: qemu \
  -chardev vdagent,id=vdagent,clipboard=on \
  -device virtio-serial-pci \
  -device virtserialport,chardev=vdagent,name=com.redhat.spice.0

v2:
 - add a bunch of sanity checks.
 - add proper chunking.
 - use autofree.

Gerd Hoffmann (7):
  ui: add clipboard infrastructure
  ui/vdagent: core infrastructure
  ui/vdagent: add mouse support
  ui/vdagent: add clipboard support
  ui/vnc: clipboard support
  ui/gtk: move struct GtkDisplayState to ui/gtk.h
  ui/gtk: add clipboard support

 include/ui/clipboard.h |  68 +
 include/ui/gtk.h   |  67 
 ui/vnc.h   |  24 ++
 chardev/char.c |   6 +
 ui/clipboard.c |  92 ++
 ui/gtk-clipboard.c | 189 
 ui/gtk.c   |  56 +---
 ui/vdagent.c   | 679 +
 ui/vnc-clipboard.c | 323 
 ui/vnc.c   |  20 +-
 qapi/char.json |  17 ++
 ui/meson.build |   5 +-
 ui/trace-events|  10 +
 13 files changed, 1494 insertions(+), 62 deletions(-)
 create mode 100644 include/ui/clipboard.h
 create mode 100644 ui/clipboard.c
 create mode 100644 ui/gtk-clipboard.c
 create mode 100644 ui/vdagent.c
 create mode 100644 ui/vnc-clipboard.c

-- 
2.30.2

[PATCH v2 4/7] ui/vdagent: add clipboard support

[Gerd Hoffmann]

This patch adds support for clipboard messages to the qemu vdagent
implementation, which allows the guest exchange clipboard data with
qemu.  Clipboard support can be enabled/disabled using the new
'clipboard' parameter for the vdagent chardev.  Default is off.

Signed-off-by: Gerd Hoffmann 
---
 chardev/char.c  |   3 +
 ui/vdagent.c| 259 
 qapi/char.json  |   4 +-
 ui/trace-events |   2 +
 4 files changed, 267 insertions(+), 1 deletion(-)

diff --git a/chardev/char.c b/chardev/char.c
index fd4d86d0dd3f..353f3eb298d9 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -930,6 +930,9 @@ QemuOptsList qemu_chardev_opts = {
 },{
 .name = "mouse",
 .type = QEMU_OPT_BOOL,
+},{
+.name = "clipboard",
+.type = QEMU_OPT_BOOL,
 #ifdef CONFIG_LINUX
 },{
 .name = "tight",
diff --git a/ui/vdagent.c b/ui/vdagent.c
index 61c12b02b573..89485973c512 100644
--- a/ui/vdagent.c
+++ b/ui/vdagent.c
@@ -3,6 +3,7 @@
 #include "chardev/char.h"
 #include "hw/qdev-core.h"
 #include "qemu/option.h"
+#include "ui/clipboard.h"
 #include "ui/console.h"
 #include "ui/input.h"
 #include "trace.h"
@@ -13,12 +14,14 @@
 #include "spice/vd_agent.h"
 
 #define VDAGENT_MOUSE_DEFAULT true
+#define VDAGENT_CLIPBOARD_DEFAULT false
 
 struct VDAgentChardev {
 Chardev parent;
 
 /* config */
 bool mouse;
+bool clipboard;
 
 /* guest vdagent */
 uint32_t caps;
@@ -33,6 +36,11 @@ struct VDAgentChardev {
 uint32_t mouse_y;
 uint32_t mouse_btn;
 QemuInputHandlerState *mouse_hs;
+
+/* clipboard */
+QemuClipboardPeer cbpeer;
+QemuClipboardInfo *cbinfo[QEMU_CLIPBOARD_SELECTION__COUNT];
+uint32_t cbpending[QEMU_CLIPBOARD_SELECTION__COUNT];
 };
 typedef struct VDAgentChardev VDAgentChardev;
 
@@ -88,6 +96,24 @@ static const char *msg_name[] = {
 #endif
 };
 
+static const char *sel_name[] = {
+[VD_AGENT_CLIPBOARD_SELECTION_CLIPBOARD] = "clipboard",
+[VD_AGENT_CLIPBOARD_SELECTION_PRIMARY]   = "primary",
+[VD_AGENT_CLIPBOARD_SELECTION_SECONDARY] = "secondary",
+};
+
+static const char *type_name[] = {
+[VD_AGENT_CLIPBOARD_NONE]   = "none",
+[VD_AGENT_CLIPBOARD_UTF8_TEXT]  = "text",
+[VD_AGENT_CLIPBOARD_IMAGE_PNG]  = "png",
+[VD_AGENT_CLIPBOARD_IMAGE_BMP]  = "bmp",
+[VD_AGENT_CLIPBOARD_IMAGE_TIFF] = "tiff",
+[VD_AGENT_CLIPBOARD_IMAGE_JPG]  = "jpg",
+#if 0
+[VD_AGENT_CLIPBOARD_FILE_LIST]  = "files",
+#endif
+};
+
 #define GET_NAME(_m, _v) \
 (((_v) < ARRAY_SIZE(_m) && (_m[_v])) ? (_m[_v]) : "???")
 
@@ -144,6 +170,10 @@ static void vdagent_send_caps(VDAgentChardev *vd)
 if (vd->mouse) {
 caps->caps[0] |= (1 << VD_AGENT_CAP_MOUSE_STATE);
 }
+if (vd->clipboard) {
+caps->caps[0] |= (1 << VD_AGENT_CAP_CLIPBOARD_BY_DEMAND);
+caps->caps[0] |= (1 << VD_AGENT_CAP_CLIPBOARD_SELECTION);
+}
 
 vdagent_send_msg(vd, msg);
 }
@@ -236,6 +266,209 @@ static QemuInputHandler vdagent_mouse_handler = {
 .sync  = vdagent_pointer_sync,
 };
 
+/* -- */
+/* clipboard  */
+
+static uint32_t type_qemu_to_vdagent(enum QemuClipboardType type)
+{
+switch (type) {
+case QEMU_CLIPBOARD_TYPE_TEXT:
+return VD_AGENT_CLIPBOARD_UTF8_TEXT;
+default:
+return VD_AGENT_CLIPBOARD_NONE;
+}
+}
+
+static void vdagent_send_clipboard_grab(VDAgentChardev *vd,
+QemuClipboardInfo *info)
+{
+g_autofree VDAgentMessage *msg = g_malloc0(sizeof(VDAgentMessage) +
+   sizeof(uint32_t) * 
(QEMU_CLIPBOARD_TYPE__COUNT + 1));
+uint8_t *s = msg->data;
+uint32_t *data = (uint32_t *)(msg->data + 4);
+uint32_t q, v, type;
+
+for (q = 0, v = 0; q < QEMU_CLIPBOARD_TYPE__COUNT; q++) {
+type = type_qemu_to_vdagent(q);
+if (type != VD_AGENT_CLIPBOARD_NONE && info->types[q].available) {
+data[v++] = type;
+}
+}
+
+*s = info->selection;
+msg->type = VD_AGENT_CLIPBOARD_GRAB;
+msg->size = sizeof(uint32_t) * (v + 1);
+
+vdagent_send_msg(vd, msg);
+}
+
+static void vdagent_send_clipboard_data(VDAgentChardev *vd,
+QemuClipboardInfo *info,
+QemuClipboardType type)
+{
+g_autofree VDAgentMessage *msg = g_malloc0(sizeof(VDAgentMessage) +
+   sizeof(uint32_t) * 2 +
+   info->types[type].size);
+
+uint8_t *s = msg->data;
+uint32_t *t = (uint32_t *)(msg->data + 4);
+uint8_t *d = msg->data + 8;
+
+*s = info->selection;
+*t = type_qemu_to_vdagent(type);
+memcpy(d, info->types[type].data, info->types[type].size);
+
+msg->type = VD_AGENT_CLIPBOARD;
+msg->size = siz

[PATCH v2 1/7] ui: add clipboard infrastructure

[Gerd Hoffmann]

Add some infrastructure to manage the clipboard in qemu.

TODO: Add API docs.

Signed-off-by: Gerd Hoffmann 
---
 include/ui/clipboard.h | 68 +++
 ui/clipboard.c | 92 ++
 ui/meson.build |  1 +
 3 files changed, 161 insertions(+)
 create mode 100644 include/ui/clipboard.h
 create mode 100644 ui/clipboard.c

diff --git a/include/ui/clipboard.h b/include/ui/clipboard.h
new file mode 100644
index ..00ff559425ee
--- /dev/null
+++ b/include/ui/clipboard.h
@@ -0,0 +1,68 @@
+#ifndef QEMU_CLIPBOARD_H
+#define QEMU_CLIPBOARD_H
+
+#include "qemu/notify.h"
+
+typedef enum QemuClipboardType QemuClipboardType;
+typedef enum QemuClipboardSelection QemuClipboardSelection;
+typedef struct QemuClipboardPeer QemuClipboardPeer;
+typedef struct QemuClipboardInfo QemuClipboardInfo;
+
+enum QemuClipboardType {
+QEMU_CLIPBOARD_TYPE_TEXT,  /* text/plain; charset=utf-8 */
+QEMU_CLIPBOARD_TYPE__COUNT,
+};
+
+/* same as VD_AGENT_CLIPBOARD_SELECTION_* */
+enum QemuClipboardSelection {
+QEMU_CLIPBOARD_SELECTION_CLIPBOARD,
+QEMU_CLIPBOARD_SELECTION_PRIMARY,
+QEMU_CLIPBOARD_SELECTION_SECONDARY,
+QEMU_CLIPBOARD_SELECTION__COUNT,
+};
+
+struct QemuClipboardPeer {
+const char *name;
+Notifier update;
+void (*request)(QemuClipboardInfo *info,
+QemuClipboardType type);
+};
+
+struct QemuClipboardInfo {
+uint32_t refcount;
+QemuClipboardPeer *owner;
+QemuClipboardSelection selection;
+struct {
+bool available;
+bool requested;
+size_t size;
+void *data;
+} types[QEMU_CLIPBOARD_TYPE__COUNT];
+};
+
+struct QemuClipboardData {
+uint32_t refcount;
+QemuClipboardInfo *info;
+QemuClipboardType type;
+};
+
+void qemu_clipboard_peer_register(QemuClipboardPeer *peer);
+void qemu_clipboard_peer_unregister(QemuClipboardPeer *peer);
+
+QemuClipboardInfo *qemu_clipboard_info_new(QemuClipboardPeer *owner,
+   QemuClipboardSelection selection);
+QemuClipboardInfo *qemu_clipboard_info_get(QemuClipboardInfo *info);
+void qemu_clipboard_info_put(QemuClipboardInfo *info);
+
+void qemu_clipboard_update(QemuClipboardInfo *info);
+void qemu_clipboard_request(QemuClipboardInfo *info,
+QemuClipboardType type);
+
+void qemu_clipboard_set_data(QemuClipboardPeer *peer,
+ QemuClipboardInfo *info,
+ QemuClipboardType type,
+ uint32_t size,
+ void *data,
+ bool update);
+
+#endif /* QEMU_CLIPBOARD_H */
diff --git a/ui/clipboard.c b/ui/clipboard.c
new file mode 100644
index ..556531c578a1
--- /dev/null
+++ b/ui/clipboard.c
@@ -0,0 +1,92 @@
+#include "qemu/osdep.h"
+#include "ui/clipboard.h"
+
+static NotifierList clipboard_notifiers =
+NOTIFIER_LIST_INITIALIZER(clipboard_notifiers);
+
+void qemu_clipboard_peer_register(QemuClipboardPeer *peer)
+{
+notifier_list_add(&clipboard_notifiers, &peer->update);
+}
+
+void qemu_clipboard_peer_unregister(QemuClipboardPeer *peer)
+{
+notifier_remove(&peer->update);
+}
+
+void qemu_clipboard_update(QemuClipboardInfo *info)
+{
+notifier_list_notify(&clipboard_notifiers, info);
+}
+
+QemuClipboardInfo *qemu_clipboard_info_new(QemuClipboardPeer *owner,
+   QemuClipboardSelection selection)
+{
+QemuClipboardInfo *info = g_new0(QemuClipboardInfo, 1);
+
+info->owner = owner;
+info->selection = selection;
+info->refcount = 1;
+
+return info;
+}
+
+QemuClipboardInfo *qemu_clipboard_info_get(QemuClipboardInfo *info)
+{
+info->refcount++;
+return info;
+}
+
+void qemu_clipboard_info_put(QemuClipboardInfo *info)
+{
+uint32_t type;
+
+if (!info) {
+return;
+}
+
+info->refcount--;
+if (info->refcount > 0) {
+return;
+}
+
+for (type = 0; type < QEMU_CLIPBOARD_TYPE__COUNT; type++) {
+g_free(info->types[type].data);
+}
+g_free(info);
+}
+
+void qemu_clipboard_request(QemuClipboardInfo *info,
+QemuClipboardType type)
+{
+if (info->types[type].data ||
+info->types[type].requested ||
+!info->types[type].available ||
+!info->owner)
+return;
+
+info->types[type].requested = true;
+info->owner->request(info, type);
+}
+
+void qemu_clipboard_set_data(QemuClipboardPeer *peer,
+ QemuClipboardInfo *info,
+ QemuClipboardType type,
+ uint32_t size,
+ void *data,
+ bool update)
+{
+if (!info ||
+info->owner != peer) {
+return;
+}
+
+g_free(info->types[type].data);
+info->types[type].data = g_memdup(data, size);
+info->types[type].size = size;
+info-

Re: [RFC v2 11/13] vhost: Shadow virtqueue buffers forwarding

[Jason Wang]

在 2021/3/18 下午4:06, Eugenio Perez Martin 写道:

On Thu, Mar 18, 2021 at 4:14 AM Jason Wang  wrote:


在 2021/3/17 下午10:38, Eugenio Perez Martin 写道:

On Wed, Mar 17, 2021 at 3:51 AM Jason Wang  wrote:

在 2021/3/17 上午12:05, Eugenio Perez Martin 写道:

On Tue, Mar 16, 2021 at 9:15 AM Jason Wang  wrote:

在 2021/3/16 上午3:48, Eugenio Pérez 写道:

Initial version of shadow virtqueue that actually forward buffers.

It reuses the VirtQueue code for the device part. The driver part is
based on Linux's virtio_ring driver, but with stripped functionality
and optimizations so it's easier to review.

These will be added in later commits.

Signed-off-by: Eugenio Pérez 
---
 hw/virtio/vhost-shadow-virtqueue.c | 212 +++--
 hw/virtio/vhost.c  | 113 ++-
 2 files changed, 312 insertions(+), 13 deletions(-)

diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
b/hw/virtio/vhost-shadow-virtqueue.c
index 1460d1d5d1..68ed0f2740 100644
--- a/hw/virtio/vhost-shadow-virtqueue.c
+++ b/hw/virtio/vhost-shadow-virtqueue.c
@@ -9,6 +9,7 @@

 #include "hw/virtio/vhost-shadow-virtqueue.h"
 #include "hw/virtio/vhost.h"
+#include "hw/virtio/virtio-access.h"

 #include "standard-headers/linux/vhost_types.h"

@@ -55,11 +56,96 @@ typedef struct VhostShadowVirtqueue {
 /* Virtio device */
 VirtIODevice *vdev;

+/* Map for returning guest's descriptors */
+VirtQueueElement **ring_id_maps;
+
+/* Next head to expose to device */
+uint16_t avail_idx_shadow;
+
+/* Next free descriptor */
+uint16_t free_head;
+
+/* Last seen used idx */
+uint16_t shadow_used_idx;
+
+/* Next head to consume from device */
+uint16_t used_idx;
+
 /* Descriptors copied from guest */
 vring_desc_t descs[];
 } VhostShadowVirtqueue;

-/* Forward guest notifications */
+static void vhost_vring_write_descs(VhostShadowVirtqueue *svq,
+const struct iovec *iovec,
+size_t num, bool more_descs, bool write)
+{
+uint16_t i = svq->free_head, last = svq->free_head;
+unsigned n;
+uint16_t flags = write ? virtio_tswap16(svq->vdev, VRING_DESC_F_WRITE) : 0;
+vring_desc_t *descs = svq->vring.desc;
+
+if (num == 0) {
+return;
+}
+
+for (n = 0; n < num; n++) {
+if (more_descs || (n + 1 < num)) {
+descs[i].flags = flags | virtio_tswap16(svq->vdev,
+VRING_DESC_F_NEXT);
+} else {
+descs[i].flags = flags;
+}
+descs[i].addr = virtio_tswap64(svq->vdev, (hwaddr)iovec[n].iov_base);

So unsing virtio_tswap() is probably not correct since we're talking
with vhost backends which has its own endiness.


I was trying to expose the buffer with the same endianness as the
driver originally offered, so if guest->qemu requires a bswap, I think
it will always require a bswap again to expose to the device again.

So assumes vhost-vDPA always provide a non-transitional device[1].

Then if Qemu present a transitional device, we need to do the endian
conversion when necessary, if Qemu present a non-transitional device, we
don't need to do that, guest driver will do that for us.

But it looks to me the virtio_tswap() can't be used for this since it:

static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
{
#if defined(LEGACY_VIRTIO_IS_BIENDIAN)
   return virtio_is_big_endian(vdev);
#elif defined(TARGET_WORDS_BIGENDIAN)
   if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
   /* Devices conforming to VIRTIO 1.0 or later are always LE. */
   return false;
   }
   return true;
#else
   return false;
#endif
}

So if we present a legacy device on top of a non-transitiaonl vDPA
device. The VIRITIO_F_VERSION_1 check is wrong.



For vhost-vDPA, we can assume that it's a 1.0 device.

Isn't it needed if the host is big endian?

[1]

So non-transitional device always assume little endian.

For vhost-vDPA, we don't want to present transitional device which may
end up with a lot of burdens.

I suspect the legacy driver plust vhost vDPA already break, so I plan to
mandate VERSION_1 for all vDPA devices.


Right. I think it's the best then.

However, then we will need a similar method to always expose
address/length as little endian, isn't it?


Yes.



+descs[i].len = virtio_tswap32(svq->vdev, iovec[n].iov_len);
+
+last = i;
+i = virtio_tswap16(svq->vdev, descs[i].next);
+}
+
+svq->free_head = virtio_tswap16(svq->vdev, descs[last].next);
+}
+
+static unsigned vhost_shadow_vq_add_split(VhostShadowVirtqueue *svq,
+  VirtQueueElement *elem)
+{
+int head;
+unsigned avail_idx;
+vring_avail_t *avail = svq->vring.avail;
+
+head = svq->free_head;
+
+/* We need some descriptors here */
+assert(elem->out_num || elem->in_num);
+
+vhost_

[PATCH v2 5/7] ui/vnc: clipboard support

[Gerd Hoffmann]

This patch adds support for cut+paste to the qemu vnc server, which
allows the vnc client exchange clipbaord data with qemu and other peers
like the qemu vdagent implementation.

Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.h   |  24 
 ui/vnc-clipboard.c | 323 +
 ui/vnc.c   |  20 ++-
 ui/meson.build |   1 +
 4 files changed, 362 insertions(+), 6 deletions(-)
 create mode 100644 ui/vnc-clipboard.c

diff --git a/ui/vnc.h b/ui/vnc.h
index d4f3e1555809..a7149831f906 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -29,6 +29,7 @@
 
 #include "qemu/queue.h"
 #include "qemu/thread.h"
+#include "ui/clipboard.h"
 #include "ui/console.h"
 #include "audio/audio.h"
 #include "qemu/bitmap.h"
@@ -348,6 +349,10 @@ struct VncState
 
 Notifier mouse_mode_notifier;
 
+QemuClipboardPeer cbpeer;
+QemuClipboardInfo *cbinfo;
+uint32_t cbpending;
+
 QTAILQ_ENTRY(VncState) next;
 };
 
@@ -417,6 +422,7 @@ enum {
 #define VNC_ENCODING_XVP  0XFECB /* -309 */
 #define VNC_ENCODING_ALPHA_CURSOR 0XFEC6 /* -314 */
 #define VNC_ENCODING_WMVi 0x574D5669
+#define VNC_ENCODING_CLIPBOARD_EXT0xc0a1e5ce
 
 /*
  *
@@ -458,6 +464,7 @@ enum VncFeatures {
 VNC_FEATURE_ZYWRLE,
 VNC_FEATURE_LED_STATE,
 VNC_FEATURE_XVP,
+VNC_FEATURE_CLIPBOARD_EXT,
 };
 
 #define VNC_FEATURE_RESIZE_MASK  (1 << VNC_FEATURE_RESIZE)
@@ -474,6 +481,7 @@ enum VncFeatures {
 #define VNC_FEATURE_ZYWRLE_MASK  (1 << VNC_FEATURE_ZYWRLE)
 #define VNC_FEATURE_LED_STATE_MASK   (1 << VNC_FEATURE_LED_STATE)
 #define VNC_FEATURE_XVP_MASK (1 << VNC_FEATURE_XVP)
+#define VNC_FEATURE_CLIPBOARD_EXT_MASK   (1 <<  VNC_FEATURE_CLIPBOARD_EXT)
 
 
 /* Client -> Server message IDs */
@@ -535,6 +543,17 @@ enum VncFeatures {
 #define VNC_XVP_ACTION_REBOOT 3
 #define VNC_XVP_ACTION_RESET 4
 
+/* extended clipboard flags  */
+#define VNC_CLIPBOARD_TEXT (1 << 0)
+#define VNC_CLIPBOARD_RTF  (1 << 1)
+#define VNC_CLIPBOARD_HTML (1 << 2)
+#define VNC_CLIPBOARD_DIB  (1 << 3)
+#define VNC_CLIPBOARD_FILES(1 << 4)
+#define VNC_CLIPBOARD_CAPS (1 << 24)
+#define VNC_CLIPBOARD_REQUEST  (1 << 25)
+#define VNC_CLIPBOARD_PEEK (1 << 26)
+#define VNC_CLIPBOARD_NOTIFY   (1 << 27)
+#define VNC_CLIPBOARD_PROVIDE  (1 << 28)
 
 /*
  *
@@ -618,4 +637,9 @@ int vnc_zrle_send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h);
 int vnc_zywrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int 
h);
 void vnc_zrle_clear(VncState *vs);
 
+/* vnc-clipboard.c */
+void vnc_server_cut_text_caps(VncState *vs);
+void vnc_client_cut_text(VncState *vs, size_t len, uint8_t *text);
+void vnc_client_cut_text_ext(VncState *vs, int32_t len, uint32_t flags, 
uint8_t *data);
+
 #endif /* QEMU_VNC_H */
diff --git a/ui/vnc-clipboard.c b/ui/vnc-clipboard.c
new file mode 100644
index ..10ada8004f38
--- /dev/null
+++ b/ui/vnc-clipboard.c
@@ -0,0 +1,323 @@
+/*
+ * QEMU VNC display driver -- clipboard support
+ *
+ * Copyright (C) 2021 Gerd Hoffmann 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "vnc.h"
+#include "vnc-jobs.h"
+
+static uint8_t *inflate_buffer(uint8_t *in, uint32_t in_len, uint32_t *size)
+{
+z_stream stream = {
+.next_in  = in,
+.avail_in = in_len,
+.zalloc   = Z_NULL,
+.zfree= Z_NULL,
+};
+uint32_t out_len = 8;
+uint8_t *out = g_malloc(out_len);
+int ret;
+
+stream.next_out = out + stream.total_out;
+stream.avail_out = out_len - stream.total_out;
+
+ret = inflateInit(&stream);
+if (ret != Z_OK) {
+goto err;
+}
+
+while (stream.avail_in) {
+

Re: [RFC v2 05/13] vhost: Route guest->host notification through shadow virtqueue

[Eugenio Perez Martin]

On Thu, Mar 18, 2021 at 4:11 AM Jason Wang  wrote:
>
>
> 在 2021/3/18 上午12:47, Eugenio Perez Martin 写道:
> > On Wed, Mar 17, 2021 at 3:05 AM Jason Wang  wrote:
> >>
> >> 在 2021/3/16 下午6:31, Eugenio Perez Martin 写道:
> >>> On Tue, Mar 16, 2021 at 8:18 AM Jason Wang  wrote:
>  在 2021/3/16 上午3:48, Eugenio Pérez 写道:
> > Shadow virtqueue notifications forwarding is disabled when vhost_dev
> > stops, so code flow follows usual cleanup.
> >
> > Signed-off-by: Eugenio Pérez 
> > ---
> > hw/virtio/vhost-shadow-virtqueue.h |   7 ++
> > include/hw/virtio/vhost.h  |   4 +
> > hw/virtio/vhost-shadow-virtqueue.c | 113 ++-
> > hw/virtio/vhost.c  | 143 
> > -
> > 4 files changed, 265 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-shadow-virtqueue.h 
> > b/hw/virtio/vhost-shadow-virtqueue.h
> > index 6cc18d6acb..c891c6510d 100644
> > --- a/hw/virtio/vhost-shadow-virtqueue.h
> > +++ b/hw/virtio/vhost-shadow-virtqueue.h
> > @@ -17,6 +17,13 @@
> >
> > typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
> >
> > +bool vhost_shadow_vq_start(struct vhost_dev *dev,
> > +   unsigned idx,
> > +   VhostShadowVirtqueue *svq);
> > +void vhost_shadow_vq_stop(struct vhost_dev *dev,
> > +  unsigned idx,
> > +  VhostShadowVirtqueue *svq);
> > +
> > VhostShadowVirtqueue *vhost_shadow_vq_new(struct vhost_dev *dev, 
> > int idx);
> >
> > void vhost_shadow_vq_free(VhostShadowVirtqueue *vq);
> > diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
> > index ac963bf23d..7ffdf9aea0 100644
> > --- a/include/hw/virtio/vhost.h
> > +++ b/include/hw/virtio/vhost.h
> > @@ -55,6 +55,8 @@ struct vhost_iommu {
> > QLIST_ENTRY(vhost_iommu) iommu_next;
> > };
> >
> > +typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
> > +
> > typedef struct VhostDevConfigOps {
> > /* Vhost device config space changed callback
> >  */
> > @@ -83,7 +85,9 @@ struct vhost_dev {
> > uint64_t backend_cap;
> > bool started;
> > bool log_enabled;
> > +bool shadow_vqs_enabled;
> > uint64_t log_size;
> > +VhostShadowVirtqueue **shadow_vqs;
>  Any reason that you don't embed the shadow virtqueue into
>  vhost_virtqueue structure?
> 
> >>> Not really, it could be relatively big and I would prefer SVQ
> >>> members/methods to remain hidden from any other part that includes
> >>> vhost.h. But it could be changed, for sure.
> >>>
>  (Note that there's a masked_notifier in struct vhost_virtqueue).
> 
> >>> They are used differently: in SVQ the masked notifier is a pointer,
> >>> and if it's NULL the SVQ code knows that device is not masked. The
> >>> vhost_virtqueue is the real owner.
> >>
> >> Yes, but it's an example for embedding auxciliary data structures in the
> >> vhost_virtqueue.
> >>
> >>
> >>> It could be replaced by a boolean in SVQ or something like that, I
> >>> experimented with a tri-state too (UNMASKED, MASKED, MASKED_NOTIFIED)
> >>> and let vhost.c code to manage all the transitions. But I find clearer
> >>> the pointer use, since it's the more natural for the
> >>> vhost_virtqueue_mask, vhost_virtqueue_pending existing functions.
> >>>
> >>> This masking/unmasking is the part I dislike the most from this
> >>> series, so I'm very open to alternatives.
> >>
> >> See below. I think we don't even need to care about that.
> >>
> >>
> > Error *migration_blocker;
> > const VhostOps *vhost_ops;
> > void *opaque;
> > diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> > b/hw/virtio/vhost-shadow-virtqueue.c
> > index 4512e5b058..3e43399e9c 100644
> > --- a/hw/virtio/vhost-shadow-virtqueue.c
> > +++ b/hw/virtio/vhost-shadow-virtqueue.c
> > @@ -8,9 +8,12 @@
> >  */
> >
> > #include "hw/virtio/vhost-shadow-virtqueue.h"
> > +#include "hw/virtio/vhost.h"
> > +
> > +#include "standard-headers/linux/vhost_types.h"
> >
> > #include "qemu/error-report.h"
> > -#include "qemu/event_notifier.h"
> > +#include "qemu/main-loop.h"
> >
> > /* Shadow virtqueue to relay notifications */
> > typedef struct VhostShadowVirtqueue {
> > @@ -18,14 +21,121 @@ typedef struct VhostShadowVirtqueue {
> > EventNotifier kick_notifier;
> > /* Shadow call notifier, sent to vhost */
> > EventNotifier call_notifier;
> > +
> > +/*
> > + * Borrowed virtqueue's guest to host notifier.
> > + * To borrow it in this event notifier allows to register on the 
> > event
> > + * 

[PATCH v2 3/7] ui/vdagent: add mouse support

[Gerd Hoffmann]

This patch adds support for mouse messages to the vdagent
implementation.  This can be enabled/disabled using the new
'mouse' parameter for the vdagent chardev.  Default is on.

Signed-off-by: Gerd Hoffmann 
---
 chardev/char.c |   3 ++
 ui/vdagent.c   | 141 +
 qapi/char.json |   4 +-
 3 files changed, 147 insertions(+), 1 deletion(-)

diff --git a/chardev/char.c b/chardev/char.c
index 97cafd68494a..fd4d86d0dd3f 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -927,6 +927,9 @@ QemuOptsList qemu_chardev_opts = {
 },{
 .name = "logappend",
 .type = QEMU_OPT_BOOL,
+},{
+.name = "mouse",
+.type = QEMU_OPT_BOOL,
 #ifdef CONFIG_LINUX
 },{
 .name = "tight",
diff --git a/ui/vdagent.c b/ui/vdagent.c
index 146ddb8e31b4..61c12b02b573 100644
--- a/ui/vdagent.c
+++ b/ui/vdagent.c
@@ -1,21 +1,38 @@
 #include "qemu/osdep.h"
 #include "include/qemu-common.h"
 #include "chardev/char.h"
+#include "hw/qdev-core.h"
+#include "qemu/option.h"
+#include "ui/console.h"
+#include "ui/input.h"
 #include "trace.h"
 
 #include "qapi/qapi-types-char.h"
+#include "qapi/qapi-types-ui.h"
 
 #include "spice/vd_agent.h"
 
+#define VDAGENT_MOUSE_DEFAULT true
+
 struct VDAgentChardev {
 Chardev parent;
 
+/* config */
+bool mouse;
+
 /* guest vdagent */
 uint32_t caps;
 VDIChunkHeader chunk;
 uint32_t chunksize;
 uint8_t *msgbuf;
 uint32_t msgsize;
+
+/* mouse */
+DeviceState mouse_dev;
+uint32_t mouse_x;
+uint32_t mouse_y;
+uint32_t mouse_btn;
+QemuInputHandlerState *mouse_hs;
 };
 typedef struct VDAgentChardev VDAgentChardev;
 
@@ -120,13 +137,105 @@ static void vdagent_send_caps(VDAgentChardev *vd)
 g_autofree VDAgentMessage *msg = g_malloc0(sizeof(VDAgentMessage) +

sizeof(VDAgentAnnounceCapabilities) +
sizeof(uint32_t));
+VDAgentAnnounceCapabilities *caps = (void *)msg->data;
 
 msg->type = VD_AGENT_ANNOUNCE_CAPABILITIES;
 msg->size = sizeof(VDAgentAnnounceCapabilities) + sizeof(uint32_t);
+if (vd->mouse) {
+caps->caps[0] |= (1 << VD_AGENT_CAP_MOUSE_STATE);
+}
 
 vdagent_send_msg(vd, msg);
 }
 
+/* -- */
+/* mouse events   */
+
+static void vdagent_send_mouse(VDAgentChardev *vd)
+{
+g_autofree VDAgentMessage *msg = g_malloc0(sizeof(VDAgentMessage) +
+   sizeof(VDAgentMouseState));
+VDAgentMouseState *mouse = (void *)msg->data;
+
+msg->type = VD_AGENT_MOUSE_STATE;
+msg->size = sizeof(VDAgentMouseState);
+
+mouse->x   = vd->mouse_x;
+mouse->y   = vd->mouse_y;
+mouse->buttons = vd->mouse_btn;
+
+vdagent_send_msg(vd, msg);
+}
+
+static void vdagent_pointer_event(DeviceState *dev, QemuConsole *src,
+  InputEvent *evt)
+{
+static const int bmap[INPUT_BUTTON__MAX] = {
+[INPUT_BUTTON_LEFT]= VD_AGENT_LBUTTON_MASK,
+[INPUT_BUTTON_RIGHT]   = VD_AGENT_RBUTTON_MASK,
+[INPUT_BUTTON_MIDDLE]  = VD_AGENT_MBUTTON_MASK,
+[INPUT_BUTTON_WHEEL_UP]= VD_AGENT_UBUTTON_MASK,
+[INPUT_BUTTON_WHEEL_DOWN]  = VD_AGENT_DBUTTON_MASK,
+#if 0
+[INPUT_BUTTON_SIDE]= VD_AGENT_SBUTTON_MASK,
+[INPUT_BUTTON_EXTRA]   = VD_AGENT_EBUTTON_MASK,
+#endif
+};
+
+VDAgentChardev *vd = container_of(dev, struct VDAgentChardev, mouse_dev);
+InputMoveEvent *move;
+InputBtnEvent *btn;
+uint32_t xres, yres;
+
+switch (evt->type) {
+case INPUT_EVENT_KIND_ABS:
+move = evt->u.abs.data;
+xres = qemu_console_get_width(src, 1024);
+yres = qemu_console_get_height(src, 768);
+if (move->axis == INPUT_AXIS_X) {
+vd->mouse_x = qemu_input_scale_axis(move->value,
+INPUT_EVENT_ABS_MIN,
+INPUT_EVENT_ABS_MAX,
+0, xres);
+} else if (move->axis == INPUT_AXIS_Y) {
+vd->mouse_y = qemu_input_scale_axis(move->value,
+INPUT_EVENT_ABS_MIN,
+INPUT_EVENT_ABS_MAX,
+0, yres);
+}
+break;
+
+case INPUT_EVENT_KIND_BTN:
+btn = evt->u.btn.data;
+if (btn->down) {
+vd->mouse_btn |= bmap[btn->button];
+} else {
+vd->mouse_btn &= ~bmap[btn->button];
+}
+break;
+
+default:
+/* keep gcc happy */
+break;
+}
+}
+
+static void vdagent_pointer_sync(DeviceState *dev)
+{
+VDAgentChardev *vd = container_of(dev, stru

[PATCH v2 6/7] ui/gtk: move struct GtkDisplayState to ui/gtk.h

[Gerd Hoffmann]

Want place gtk clipboard code in a separate C file, which in turn
requires GtkDisplayState being in a header file.  So move it.  No
functional change.

Signed-off-by: Gerd Hoffmann 
---
 include/ui/gtk.h | 57 
 ui/gtk.c | 55 --
 2 files changed, 57 insertions(+), 55 deletions(-)

diff --git a/include/ui/gtk.h b/include/ui/gtk.h
index 5ae0ad60a600..6e751794043f 100644
--- a/include/ui/gtk.h
+++ b/include/ui/gtk.h
@@ -18,12 +18,15 @@
 #include 
 #endif
 
+#include "ui/console.h"
 #include "ui/kbd-state.h"
 #if defined(CONFIG_OPENGL)
 #include "ui/egl-helpers.h"
 #include "ui/egl-context.h"
 #endif
 
+#define MAX_VCS 10
+
 typedef struct GtkDisplayState GtkDisplayState;
 
 typedef struct VirtualGfxConsole {
@@ -83,6 +86,60 @@ typedef struct VirtualConsole {
 };
 } VirtualConsole;
 
+struct GtkDisplayState {
+GtkWidget *window;
+
+GtkWidget *menu_bar;
+
+GtkAccelGroup *accel_group;
+
+GtkWidget *machine_menu_item;
+GtkWidget *machine_menu;
+GtkWidget *pause_item;
+GtkWidget *reset_item;
+GtkWidget *powerdown_item;
+GtkWidget *quit_item;
+
+GtkWidget *view_menu_item;
+GtkWidget *view_menu;
+GtkWidget *full_screen_item;
+GtkWidget *copy_item;
+GtkWidget *zoom_in_item;
+GtkWidget *zoom_out_item;
+GtkWidget *zoom_fixed_item;
+GtkWidget *zoom_fit_item;
+GtkWidget *grab_item;
+GtkWidget *grab_on_hover_item;
+
+int nb_vcs;
+VirtualConsole vc[MAX_VCS];
+
+GtkWidget *show_tabs_item;
+GtkWidget *untabify_item;
+GtkWidget *show_menubar_item;
+
+GtkWidget *vbox;
+GtkWidget *notebook;
+int button_mask;
+gboolean last_set;
+int last_x;
+int last_y;
+int grab_x_root;
+int grab_y_root;
+VirtualConsole *kbd_owner;
+VirtualConsole *ptr_owner;
+
+gboolean full_screen;
+
+GdkCursor *null_cursor;
+Notifier mouse_mode_notifier;
+gboolean free_scale;
+
+bool external_pause_update;
+
+DisplayOptions *opts;
+};
+
 extern bool gtk_use_gl_area;
 
 /* ui/gtk.c */
diff --git a/ui/gtk.c b/ui/gtk.c
index 1ea12535284a..7da288a25156 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -60,7 +60,6 @@
 #include "chardev/char.h"
 #include "qom/object.h"
 
-#define MAX_VCS 10
 #define VC_WINDOW_X_MIN  320
 #define VC_WINDOW_Y_MIN  240
 #define VC_TERM_X_MIN 80
@@ -119,60 +118,6 @@
 static const guint16 *keycode_map;
 static size_t keycode_maplen;
 
-struct GtkDisplayState {
-GtkWidget *window;
-
-GtkWidget *menu_bar;
-
-GtkAccelGroup *accel_group;
-
-GtkWidget *machine_menu_item;
-GtkWidget *machine_menu;
-GtkWidget *pause_item;
-GtkWidget *reset_item;
-GtkWidget *powerdown_item;
-GtkWidget *quit_item;
-
-GtkWidget *view_menu_item;
-GtkWidget *view_menu;
-GtkWidget *full_screen_item;
-GtkWidget *copy_item;
-GtkWidget *zoom_in_item;
-GtkWidget *zoom_out_item;
-GtkWidget *zoom_fixed_item;
-GtkWidget *zoom_fit_item;
-GtkWidget *grab_item;
-GtkWidget *grab_on_hover_item;
-
-int nb_vcs;
-VirtualConsole vc[MAX_VCS];
-
-GtkWidget *show_tabs_item;
-GtkWidget *untabify_item;
-GtkWidget *show_menubar_item;
-
-GtkWidget *vbox;
-GtkWidget *notebook;
-int button_mask;
-gboolean last_set;
-int last_x;
-int last_y;
-int grab_x_root;
-int grab_y_root;
-VirtualConsole *kbd_owner;
-VirtualConsole *ptr_owner;
-
-gboolean full_screen;
-
-GdkCursor *null_cursor;
-Notifier mouse_mode_notifier;
-gboolean free_scale;
-
-bool external_pause_update;
-
-DisplayOptions *opts;
-};
-
 struct VCChardev {
 Chardev parent;
 VirtualConsole *console;
-- 
2.30.2

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Philippe Mathieu-Daudé]

Hi Laurent,

+Paolo / Thomas

On 3/15/21 9:42 PM, Laurent Vivier wrote:
> The machine is based on Goldfish interfaces defined by Google
> for Android simulator. It uses Goldfish-rtc (timer and RTC),
> Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).
> 
> The machine is created with 128 virtio-mmio bus, and they can
> be used to use serial console, GPU, disk, NIC, HID, ...
> 
> Signed-off-by: Laurent Vivier 
> Reviewed-by: Richard Henderson 
> Tested-by: Philippe Mathieu-Daudé 
> Message-Id: <20210312214145.2936082-6-laur...@vivier.eu>
> ---
>  default-configs/devices/m68k-softmmu.mak  |   1 +
>  .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
>  hw/m68k/virt.c| 313 ++
>  MAINTAINERS   |  13 +
>  hw/m68k/Kconfig   |   9 +
>  hw/m68k/meson.build   |   1 +
>  6 files changed, 355 insertions(+)
>  create mode 100644 include/standard-headers/asm-m68k/bootinfo-virt.h
>  create mode 100644 hw/m68k/virt.c

> diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
> index 60d7bcfb8f2b..f839f8a03064 100644
> --- a/hw/m68k/Kconfig
> +++ b/hw/m68k/Kconfig
> @@ -23,3 +23,12 @@ config Q800
>  select ESP
>  select DP8393X
>  select OR_IRQ
> +
> +config M68K_VIRT
> +bool
> +select M68K_IRQC
> +select VIRT_CTRL
> +select GOLDFISH_PIC
> +select GOLDFISH_TTY
> +select GOLDFISH_RTC
> +select VIRTIO_MMIO

I had this error on gitlab:

(qemu) QEMU_PROG: -drive driver=IMGFMT,file=TEST_DIR/t.IMGFMT,if=virtio:
'virtio-blk-pci' is not a valid device model name
job: check-system-fedora
https://gitlab.com/philmd/qemu/-/jobs/1106469724

I bisected locally to this commit.

check-system-fedora uses build-system-fedora:

build-system-fedora:
CONFIGURE_ARGS: --disable-gcrypt --enable-nettle --enable-docs
 --enable-fdt=system --enable-slirp=system
 --enable-capstone=system

I'm confused because the machine provides a VIRTIO bus
via MMIO:

config VIRTIO_MMIO
bool
select VIRTIO

I remember I tested your machine with virtio-blk-device.

config VIRTIO_BLK
bool
default y
depends on VIRTIO

Ah, this is virtio-blk-pci, which has:

virtio_pci_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true:
files('virtio-blk-pci.c'))
virtio_ss.add_all(when: 'CONFIG_VIRTIO_PCI', if_true: virtio_pci_ss)

And VIRTIO_PCI isn't selected...

Are the tests incorrect then?

libqos isn't restricted to PCI:

tests/qtest/libqos/virtio-blk.c:24:#include "virtio-blk.h"
tests/qtest/libqos/virtio-blk.c:29:/* virtio-blk-device */
tests/qtest/libqos/virtio-blk.c:33:if (!g_strcmp0(interface,
"virtio-blk")) {
tests/qtest/libqos/virtio-blk.c:40:fprintf(stderr, "%s not present
in virtio-blk-device\n", interface);
tests/qtest/libqos/virtio-blk.c:109:/* virtio-blk-device */
tests/qtest/libqos/virtio-blk.c:111:
qos_node_create_driver("virtio-blk-device", virtio_blk_device_create);
tests/qtest/libqos/virtio-blk.c:112:
qos_node_consumes("virtio-blk-device", "virtio-bus", &opts);
tests/qtest/libqos/virtio-blk.c:113:
qos_node_produces("virtio-blk-device", "virtio-blk");

But qemu-iotests / qtests do use virtio-blk-pci. Maybe they should
use a generic virtio-blk-device instead, hoping it get plugged correctly
to the virtio bus...

[PATCH v2 7/7] ui/gtk: add clipboard support

[Gerd Hoffmann]

This patch adds clipboard support to the qemu gtk ui.

Signed-off-by: Gerd Hoffmann 
---
 include/ui/gtk.h   |  10 +++
 ui/gtk-clipboard.c | 189 +
 ui/gtk.c   |   1 +
 ui/meson.build |   2 +-
 4 files changed, 201 insertions(+), 1 deletion(-)
 create mode 100644 ui/gtk-clipboard.c

diff --git a/include/ui/gtk.h b/include/ui/gtk.h
index 6e751794043f..9516670ebc87 100644
--- a/include/ui/gtk.h
+++ b/include/ui/gtk.h
@@ -18,6 +18,7 @@
 #include 
 #endif
 
+#include "ui/clipboard.h"
 #include "ui/console.h"
 #include "ui/kbd-state.h"
 #if defined(CONFIG_OPENGL)
@@ -137,6 +138,12 @@ struct GtkDisplayState {
 
 bool external_pause_update;
 
+QemuClipboardPeer cbpeer;
+QemuClipboardInfo *cbinfo[QEMU_CLIPBOARD_SELECTION__COUNT];
+uint32_t cbpending[QEMU_CLIPBOARD_SELECTION__COUNT];
+GtkClipboard *gtkcb[QEMU_CLIPBOARD_SELECTION__COUNT];
+bool cbowner[QEMU_CLIPBOARD_SELECTION__COUNT];
+
 DisplayOptions *opts;
 };
 
@@ -207,4 +214,7 @@ void gtk_gl_area_init(void);
 int gd_gl_area_make_current(DisplayChangeListener *dcl,
 QEMUGLContext ctx);
 
+/* gtk-clipboard.c */
+void gd_clipboard_init(GtkDisplayState *gd);
+
 #endif /* UI_GTK_H */
diff --git a/ui/gtk-clipboard.c b/ui/gtk-clipboard.c
new file mode 100644
index ..3585e27cab78
--- /dev/null
+++ b/ui/gtk-clipboard.c
@@ -0,0 +1,189 @@
+/*
+ * GTK UI -- clipboard support
+ *
+ * Copyright (C) 2021 Gerd Hoffmann 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/main-loop.h"
+
+#include "ui/gtk.h"
+
+static QemuClipboardSelection gd_find_selection(GtkDisplayState *gd,
+GtkClipboard *clipboard)
+{
+QemuClipboardSelection s;
+
+for (s = 0; s < QEMU_CLIPBOARD_SELECTION__COUNT; s++) {
+if (gd->gtkcb[s] == clipboard) {
+return s;
+}
+}
+return QEMU_CLIPBOARD_SELECTION_CLIPBOARD;
+}
+
+static void gd_clipboard_get_data(GtkClipboard *clipboard,
+  GtkSelectionData *selection_data,
+  guint selection_info,
+  gpointer  data)
+{
+GtkDisplayState *gd = data;
+QemuClipboardSelection s = gd_find_selection(gd, clipboard);
+QemuClipboardType type = QEMU_CLIPBOARD_TYPE_TEXT;
+QemuClipboardInfo *info = qemu_clipboard_info_get(gd->cbinfo[s]);
+
+qemu_clipboard_request(info, type);
+while (info == gd->cbinfo[s] &&
+   info->types[type].available &&
+   info->types[type].data == NULL) {
+main_loop_wait(false);
+}
+
+if (info == gd->cbinfo[s] && gd->cbowner[s]) {
+gtk_selection_data_set_text(selection_data,
+info->types[type].data,
+info->types[type].size);
+} else {
+/* clipboard owner changed while waiting for the data */
+}
+
+qemu_clipboard_info_put(info);
+}
+
+static void gd_clipboard_clear(GtkClipboard *clipboard,
+   gpointer data)
+{
+GtkDisplayState *gd = data;
+QemuClipboardSelection s = gd_find_selection(gd, clipboard);
+
+gd->cbowner[s] = false;
+}
+
+static void gd_clipboard_notify(Notifier *notifier, void *data)
+{
+GtkDisplayState *gd = container_of(notifier, GtkDisplayState, 
cbpeer.update);
+QemuClipboardInfo *info = data;
+QemuClipboardSelection s = info->selection;
+bool self_update = info->owner == &gd->cbpeer;
+
+if (info != gd->cbinfo[s]) {
+qemu_clipboard_info_put(gd->cbinfo[s]);
+gd->cbinfo[s] = qemu_clipboard_info_get(info);
+gd->cbpending[s] = 0;
+if (!self_update) {
+GtkTargetList *list;
+GtkTargetEntry *targets;
+gint n_targets;
+
+list = gtk_target_list_new(NULL, 0);
+if (info->types[QEMU_CLIPBOARD_TYPE_TEXT].available) {
+gtk_target_list_add_text_targets(list, 0);
+}
+targets = gtk_target_table_new_from_list(list, &n_targets);
+
+gtk_clipboard_clear(gd->gtkcb[s]);
+gd->cbowner[s] = true;
+gtk_clipboard_set_with_data(gd->gtkcb[s],
+targets

[PULL 01/13] ui, monitor: remove deprecated VNC ACL option and HMP commands

[Daniel P . Berrangé]

The VNC ACL concept has been replaced by the pluggable "authz" framework
which does not use monitor commands.

Reviewed-by: Thomas Huth 
Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrangé 
---
 docs/system/deprecated.rst   |  16 ---
 docs/system/removed-features.rst |  12 ++
 hmp-commands.hx  |  76 -
 monitor/misc.c   | 187 ---
 ui/vnc.c |  38 ---
 5 files changed, 12 insertions(+), 317 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 1db30f8f27..0e1fdf5c14 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -28,12 +28,6 @@ The 'file' driver for drives is no longer appropriate for 
character or host
 devices and will only accept regular files (S_IFREG). The correct driver
 for these file types is 'host_cdrom' or 'host_device' as appropriate.
 
-``-vnc acl`` (since 4.0.0)
-''
-
-The ``acl`` option to the ``-vnc`` argument has been replaced
-by the ``tls-authz`` and ``sasl-authz`` options.
-
 ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
 '
 
@@ -281,16 +275,6 @@ Use the more generic commands ``block-export-add`` and 
``block-export-del``
 instead.  As part of this deprecation, where ``nbd-server-add`` used a
 single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.
 
-Human Monitor Protocol (HMP) commands
--
-
-``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, ``acl_remove`` 
(since 4.0.0)
-''
-
-The ``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, and
-``acl_remove`` commands are deprecated with no replacement. Authorization
-for VNC should be performed using the pluggable QAuthZ objects.
-
 System emulator CPUS
 
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 82e7fcc517..aa612c2846 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -45,6 +45,11 @@ This option lacked the possibility to specify an audio 
backend device.
 Use ``-device usb-audio`` now instead (and specify a corresponding USB
 host controller or ``-usb`` if necessary).
 
+``-vnc acl`` (removed in 6.0)
+'
+
+The ``acl`` option to the ``-vnc`` argument has been replaced
+by the ``tls-authz`` and ``sasl-authz`` options.
 
 QEMU Machine Protocol (QMP) commands
 
@@ -87,6 +92,13 @@ documentation of ``query-hotpluggable-cpus`` for additional 
details.
 No replacement.  The ``change vnc password`` and ``change DEVICE MEDIUM``
 commands are not affected.
 
+``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, ``acl_remove`` 
(removed in 6.0)
+'
+
+The ``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, and
+``acl_remove`` commands were removed with no replacement. Authorization
+for VNC should be performed using the pluggable QAuthZ objects.
+
 Guest Emulator ISAs
 ---
 
diff --git a/hmp-commands.hx b/hmp-commands.hx
index d4001f9c5d..b500b8526d 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1433,82 +1433,6 @@ SRST
   Change watchdog action.
 ERST
 
-{
-.name   = "acl_show",
-.args_type  = "aclname:s",
-.params = "aclname",
-.help   = "list rules in the access control list",
-.cmd= hmp_acl_show,
-},
-
-SRST
-``acl_show`` *aclname*
-  List all the matching rules in the access control list, and the default
-  policy. There are currently two named access control lists,
-  *vnc.x509dname* and *vnc.username* matching on the x509 client
-  certificate distinguished name, and SASL username respectively.
-ERST
-
-{
-.name   = "acl_policy",
-.args_type  = "aclname:s,policy:s",
-.params = "aclname allow|deny",
-.help   = "set default access control list policy",
-.cmd= hmp_acl_policy,
-},
-
-SRST
-``acl_policy`` *aclname* ``allow|deny``
-  Set the default access control list policy, used in the event that
-  none of the explicit rules match. The default policy at startup is
-  always ``deny``.
-ERST
-
-{
-.name   = "acl_add",
-.args_type  = "aclname:s,match:s,policy:s,index:i?",
-.params = "aclname match allow|deny [index]",
-.help   = "add a match rule to the access control list",
-.cmd= hmp_acl_add,
-},
-
-SRST
-``acl_add`` *aclname* *match* ``allow|deny`` [*index*]
-  Add a match rule to the access control list, allowing or denying access.
-  The match will normally be an exact username or x509 distinguished name,
-  but can 

[PULL v2 00/13] misc patches removing deprecated features

[Daniel P . Berrangé]

The following changes since commit 571d413b5da6bc6f1c2aaca8484717642255ddb0:

  Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-20210316' 
into staging (2021-03-17 21:02:37 +)

are available in the Git repository at:

  https://gitlab.com/berrange/qemu tags/dep-many-pull-request

for you to fetch changes up to 8d17adf34f501ded65a106572740760f0a75577c:

  block: remove support for using "file" driver with block/char devices 
(2021-03-18 09:22:55 +)


Remove many old deprecated features

The following features have been deprecated for well over the 2
release cycle we promise

  ``-drive file=json:{...{'driver':'file'}}`` (since 3.0)
  ``-vnc acl`` (since 4.0.0)
  ``-mon ...,control=readline,pretty=on|off`` (since 4.1)
  ``migrate_set_downtime`` and ``migrate_set_speed`` (since 2.8.0)
  ``query-named-block-nodes`` result ``encryption_key_missing`` (since 2.10.0)
  ``query-block`` result ``inserted.encryption_key_missing`` (since 2.10.0)
  ``migrate-set-cache-size`` and ``query-migrate-cache-size`` (since 2.11.0)
  ``query-named-block-nodes`` and ``query-block`` result 
dirty-bitmaps[i].status (since 4.0)
  ``query-cpus`` (since 2.12.0)
  ``query-cpus-fast`` ``arch`` output member (since 3.0.0)
  ``query-events`` (since 4.0)
  chardev client socket with ``wait`` option (since 4.0)
  ``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, ``acl_remove`` 
(since 4.0.0)
  ``ide-drive`` (since 4.2)
  ``scsi-disk`` (since 4.2)



Daniel P. Berrangé (13):
  ui, monitor: remove deprecated VNC ACL option and HMP commands
  monitor: raise error when 'pretty' option is used with HMP
  monitor: remove 'query-events' QMP command
  migrate: remove QMP/HMP commands for speed, downtime and cache size
  machine: remove 'query-cpus' QMP command
  machine: remove 'arch' field from 'query-cpus-fast' QMP command
  chardev: reject use of 'wait' flag for socket client chardevs
  hw/ide: remove 'ide-drive' device
  hw/scsi: remove 'scsi-disk' device
  block: remove 'encryption_key_missing' flag from QAPI
  block: remove dirty bitmaps 'status' field
  block: remove 'dirty-bitmaps' field from 'BlockInfo' struct
  block: remove support for using "file" driver with block/char devices

 block/dirty-bitmap.c  |  38 --
 block/file-posix.c|  17 +-
 block/qapi.c  |   6 -
 chardev/char-socket.c |  12 +-
 docs/devel/migration.rst  |   2 +-
 docs/qdev-device-use.txt  |   2 +-
 docs/rdma.txt |   2 +-
 docs/system/deprecated.rst| 108 -
 docs/system/removed-features.rst  | 108 +
 docs/xbzrle.txt   |   5 -
 hmp-commands-info.hx  |  13 -
 hmp-commands.hx   | 121 --
 hw/core/machine-hmp-cmds.c|   8 +-
 hw/core/machine-qmp-cmds.c| 120 --
 hw/i386/pc.c  |   2 -
 hw/ide/qdev.c |  38 --
 hw/ppc/mac_newworld.c |  13 -
 hw/ppc/mac_oldworld.c |  13 -
 hw/scsi/scsi-disk.c   |  62 ---
 hw/sparc64/sun4u.c|  15 -
 include/block/dirty-bitmap.h  |   1 -
 include/monitor/hmp.h |   4 -
 migration/migration.c |  45 ---
 migration/ram.c   |   2 +-
 monitor/hmp-cmds.c|  34 --
 monitor/misc.c| 187 -
 monitor/monitor.c |   4 +-
 monitor/qmp-cmds-control.c|  24 --
 qapi/block-core.json  |  64 +--
 qapi/control.json |  45 ---
 qapi/machine.json | 181 +
 qapi/migration.json   |  98 -
 qemu-options.hx   |   5 +-
 scripts/device-crash-test |   2 -
 softmmu/vl.c  |   1 -
 tests/acceptance/pc_cpu_hotplug_props.py  |   2 +-
 tests/acceptance/x86_cpu_model_versions.py|   2 +-
 tests/migration/guestperf/engine.py   |  18 +-
 tests/qemu-iotests/051|   4 -
 tests/qemu-iotests/051.pc.out |  20 -
 tests/qemu-iotests/124|   4 -
 tests/qemu-iotests/181|   2 +-
 tests/qemu-iotests/184.out|   6 +-
 tests/qemu-iotests/191.out|  48 +--
 tests/qemu-iotests/194|   4 +-
 tests/qemu-iotests/194.out|   4 +-
 tests/qemu-iotests/226.out|  10

[PULL 03/13] monitor: remove 'query-events' QMP command

[Daniel P . Berrangé]

The code comment suggests removing QAPIEvent_(str|lookup) symbols too,
however, these are both auto-generated as standard for any enum in
QAPI. As such it they'll exist whether we use them or not.

Reviewed-by: Eric Blake 
Reviewed-by: Thomas Huth 
Signed-off-by: Daniel P. Berrangé 
---
 docs/system/deprecated.rst   |  6 -
 docs/system/removed-features.rst |  6 +
 monitor/qmp-cmds-control.c   | 24 -
 qapi/control.json| 45 
 4 files changed, 6 insertions(+), 75 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 8f4d756e35..bffc7e4d59 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -249,12 +249,6 @@ The ``query-cpus`` command is replaced by the 
``query-cpus-fast`` command.
 The ``arch`` output member of the ``query-cpus-fast`` command is
 replaced by the ``target`` output member.
 
-``query-events`` (since 4.0)
-
-
-The ``query-events`` command has been superseded by the more powerful
-and accurate ``query-qmp-schema`` command.
-
 chardev client socket with ``wait`` option (since 4.0)
 ''
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 372aadceae..e932d023a2 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -77,6 +77,12 @@ documentation of ``query-hotpluggable-cpus`` for additional 
details.
 
 Use ``blockdev-change-medium`` or ``change-vnc-password`` instead.
 
+``query-events`` (removed in 6.0)
+'
+
+The ``query-events`` command has been superseded by the more powerful
+and accurate ``query-qmp-schema`` command.
+
 Human Monitor Protocol (HMP) commands
 -
 
diff --git a/monitor/qmp-cmds-control.c b/monitor/qmp-cmds-control.c
index 509ae870bd..513b547233 100644
--- a/monitor/qmp-cmds-control.c
+++ b/monitor/qmp-cmds-control.c
@@ -130,30 +130,6 @@ CommandInfoList *qmp_query_commands(Error **errp)
 return list;
 }
 
-EventInfoList *qmp_query_events(Error **errp)
-{
-/*
- * TODO This deprecated command is the only user of
- * QAPIEvent_str() and QAPIEvent_lookup[].  When the command goes,
- * they should go, too.
- */
-EventInfoList *ev_list = NULL;
-QAPIEvent e;
-
-for (e = 0 ; e < QAPI_EVENT__MAX ; e++) {
-const char *event_name = QAPIEvent_str(e);
-EventInfo *info;
-
-assert(event_name != NULL);
-info = g_malloc0(sizeof(*info));
-info->name = g_strdup(event_name);
-
-QAPI_LIST_PREPEND(ev_list, info);
-}
-
-return ev_list;
-}
-
 /*
  * Minor hack: generated marshalling suppressed for this command
  * ('gen': false in the schema) so we can parse the JSON string
diff --git a/qapi/control.json b/qapi/control.json
index 2615d5170b..71a838d49e 100644
--- a/qapi/control.json
+++ b/qapi/control.json
@@ -159,51 +159,6 @@
 { 'command': 'query-commands', 'returns': ['CommandInfo'],
   'allow-preconfig': true }
 
-##
-# @EventInfo:
-#
-# Information about a QMP event
-#
-# @name: The event name
-#
-# Since: 1.2
-##
-{ 'struct': 'EventInfo', 'data': {'name': 'str'} }
-
-##
-# @query-events:
-#
-# Return information on QMP events.
-#
-# Features:
-# @deprecated: This command is deprecated, because its output doesn't
-#  reflect compile-time configuration.  Use 'query-qmp-schema'
-#  instead.
-#
-# Returns: A list of @EventInfo.
-#
-# Since: 1.2
-#
-# Example:
-#
-# -> { "execute": "query-events" }
-# <- {
-#  "return": [
-#  {
-# "name":"SHUTDOWN"
-#  },
-#  {
-# "name":"RESET"
-#  }
-#   ]
-#}
-#
-# Note: This example has been shortened as the real response is too long.
-#
-##
-{ 'command': 'query-events', 'returns': ['EventInfo'],
-  'features': [ 'deprecated' ] }
-
 ##
 # @quit:
 #
-- 
2.30.2

[PULL 04/13] migrate: remove QMP/HMP commands for speed, downtime and cache size

[Daniel P . Berrangé]

The generic 'migrate_set_parameters' command handle all types of param.

Only the QMP commands were documented in the deprecations page, but the
rationale for deprecating applies equally to HMP, and the replacements
exist. Furthermore the HMP commands are just shims to the QMP commands,
so removing the latter breaks the former unless they get re-implemented.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrangé 
---
 docs/devel/migration.rst|  2 +-
 docs/rdma.txt   |  2 +-
 docs/system/deprecated.rst  | 10 ---
 docs/system/removed-features.rst| 20 ++
 docs/xbzrle.txt |  5 --
 hmp-commands-info.hx| 13 
 hmp-commands.hx | 45 -
 include/monitor/hmp.h   |  4 --
 migration/migration.c   | 45 -
 migration/ram.c |  2 +-
 monitor/hmp-cmds.c  | 34 --
 qapi/migration.json | 98 -
 tests/migration/guestperf/engine.py | 16 ++---
 tests/qemu-iotests/181  |  2 +-
 tests/qtest/migration-test.c| 48 --
 tests/qtest/test-hmp.c  |  6 +-
 tests/qtest/vhost-user-test.c   |  8 +--
 17 files changed, 40 insertions(+), 320 deletions(-)

diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
index ad381b89b2..19c3d4f3ea 100644
--- a/docs/devel/migration.rst
+++ b/docs/devel/migration.rst
@@ -641,7 +641,7 @@ time per vCPU.
 
 .. note::
   During the postcopy phase, the bandwidth limits set using
-  ``migrate_set_speed`` is ignored (to avoid delaying requested pages that
+  ``migrate_set_parameter`` is ignored (to avoid delaying requested pages that
   the destination is waiting for).
 
 Postcopy device transfer
diff --git a/docs/rdma.txt b/docs/rdma.txt
index 49dc9f8bca..2b4cdea1d8 100644
--- a/docs/rdma.txt
+++ b/docs/rdma.txt
@@ -89,7 +89,7 @@ RUNNING:
 First, set the migration speed to match your hardware's capabilities:
 
 QEMU Monitor Command:
-$ migrate_set_speed 40g # or whatever is the MAX of your RDMA device
+$ migrate_set_parameter max_bandwidth 40g # or whatever is the MAX of your 
RDMA device
 
 Next, on the destination machine, add the following to the QEMU command line:
 
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index bffc7e4d59..c92387180c 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -183,11 +183,6 @@ Use argument ``id`` instead.
 
 Use argument ``id`` instead.
 
-``migrate_set_downtime`` and ``migrate_set_speed`` (since 2.8.0)
-
-
-Use ``migrate-set-parameters`` instead.
-
 ``query-named-block-nodes`` result ``encryption_key_missing`` (since 2.10.0)
 
 
@@ -203,11 +198,6 @@ Always false.
 
 Use argument value ``null`` instead.
 
-``migrate-set-cache-size`` and ``query-migrate-cache-size`` (since 2.11.0)
-''
-
-Use ``migrate-set-parameters`` and ``query-migrate-parameters`` instead.
-
 ``block-commit`` arguments ``base`` and ``top`` (since 3.1.0)
 '
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index e932d023a2..d7f46a6ebc 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -83,6 +83,16 @@ Use ``blockdev-change-medium`` or ``change-vnc-password`` 
instead.
 The ``query-events`` command has been superseded by the more powerful
 and accurate ``query-qmp-schema`` command.
 
+``migrate_set_cache_size`` and ``query-migrate-cache-size`` (removed in 6.0)
+
+
+Use ``migrate_set_parameter`` and ``info migrate_parameters`` instead.
+
+``migrate_set_downtime`` and ``migrate_set_speed`` (removed in 6.0)
+'''
+
+Use ``migrate_set_parameter`` instead.
+
 Human Monitor Protocol (HMP) commands
 -
 
@@ -111,6 +121,16 @@ The ``acl_show``, ``acl_reset``, ``acl_policy``, 
``acl_add``, and
 ``acl_remove`` commands were removed with no replacement. Authorization
 for VNC should be performed using the pluggable QAuthZ objects.
 
+``migrate-set-cache-size`` and ``info migrate-cache-size`` (removed in 6.0)
+'''
+
+Use ``migrate-set-parameters`` and ``info migrate-parameters`` instead.
+
+``migrate_set_downtime`` and ``migrate_set_speed`` (removed in 6.0)
+'''
+
+Use ``migrate-set-parameters`` instead.
+
 Guest Emulator ISAs
 ---
 
diff --git a/docs/xbzrle.txt b/docs/xbzrle.txt
index 6bd1828f34..bcb3f0c901 10064

[PULL 10/13] block: remove 'encryption_key_missing' flag from QAPI

[Daniel P . Berrangé]

This has been hardcoded to "false" since 2.10.0, since secrets required
to unlock block devices are now always provided up front instead of using
interactive prompts.

Reviewed-by: Eric Blake 
Reviewed-by: Thomas Huth 
Signed-off-by: Daniel P. Berrangé 
---
 block/qapi.c |  1 -
 docs/system/deprecated.rst   | 10 ---
 docs/system/removed-features.rst | 10 +++
 qapi/block-core.json |  8 --
 tests/qemu-iotests/184.out   |  6 ++--
 tests/qemu-iotests/191.out   | 48 +++-
 tests/qemu-iotests/273.out   | 15 --
 7 files changed, 33 insertions(+), 65 deletions(-)

diff --git a/block/qapi.c b/block/qapi.c
index 84a0aadc09..3acc118c44 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -62,7 +62,6 @@ BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
 info->ro = bs->read_only;
 info->drv= g_strdup(bs->drv->format_name);
 info->encrypted  = bs->encrypted;
-info->encryption_key_missing = false;
 
 info->cache = g_new(BlockdevCacheInfo, 1);
 *info->cache = (BlockdevCacheInfo) {
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index ced6adf752..d6051ef6b4 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -183,16 +183,6 @@ Use argument ``id`` instead.
 
 Use argument ``id`` instead.
 
-``query-named-block-nodes`` result ``encryption_key_missing`` (since 2.10.0)
-
-
-Always false.
-
-``query-block`` result ``inserted.encryption_key_missing`` (since 2.10.0)
-'
-
-Always false.
-
 ``blockdev-add`` empty string argument ``backing`` (since 2.10.0)
 '
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 2d6ff6aaf6..eeff82b5ec 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -110,6 +110,16 @@ chardev client socket with ``wait`` option (removed in 6.0)
 Character devices creating sockets in client mode should not specify
 the 'wait' field, which is only applicable to sockets in server mode
 
+``query-named-block-nodes`` result ``encryption_key_missing`` (removed in 6.0)
+''
+
+Removed with no replacement.
+
+``query-block`` result ``inserted.encryption_key_missing`` (removed in 6.0)
+'''
+
+Removed with no replacement.
+
 Human Monitor Protocol (HMP) commands
 -
 
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 9f555d5c1d..d256b7b776 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -319,8 +319,6 @@
 #
 # @encrypted: true if the backing device is encrypted
 #
-# @encryption_key_missing: always false
-#
 # @detect_zeroes: detect and optimize zero writes (Since 2.1)
 #
 # @bps: total throughput limit in bytes per second is specified
@@ -385,10 +383,6 @@
 # @dirty-bitmaps: dirty bitmaps information (only present if node
 # has one or more dirty bitmaps) (Since 4.2)
 #
-# Features:
-# @deprecated: Member @encryption_key_missing is deprecated.  It is
-#  always false.
-#
 # Since: 0.14
 #
 ##
@@ -396,8 +390,6 @@
   'data': { 'file': 'str', '*node-name': 'str', 'ro': 'bool', 'drv': 'str',
 '*backing_file': 'str', 'backing_file_depth': 'int',
 'encrypted': 'bool',
-'encryption_key_missing': { 'type': 'bool',
-'features': [ 'deprecated' ] },
 'detect_zeroes': 'BlockdevDetectZeroesOptions',
 'bps': 'int', 'bps_rd': 'int', 'bps_wr': 'int',
 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int',
diff --git a/tests/qemu-iotests/184.out b/tests/qemu-iotests/184.out
index 87c73070e3..77e5489d65 100644
--- a/tests/qemu-iotests/184.out
+++ b/tests/qemu-iotests/184.out
@@ -54,8 +54,7 @@ Testing:
 "direct": false,
 "writeback": true
 },
-"file": "json:{\"throttle-group\": \"group0\", \"driver\": 
\"throttle\", \"file\": {\"driver\": \"null-co\"}}",
-"encryption_key_missing": false
+"file": "json:{\"throttle-group\": \"group0\", \"driver\": 
\"throttle\", \"file\": {\"driver\": \"null-co\"}}"
 },
 {
 "iops_rd": 0,
@@ -82,8 +81,7 @@ Testing:
 "direct": false,
 "writeback": true
 },
-"file": "null-co://",
-"encryption_key_missing": false
+"file": "null-co://"
 }
 ]
 }
diff --git a/tests/qemu-iotests/191.out b/tests/qemu-iotests/191.out
index 022021efab..ea88777374 100644
--- a/tests/qemu-iotests/191.out
+++ b/tes

[PULL 02/13] monitor: raise error when 'pretty' option is used with HMP

[Daniel P . Berrangé]

This is only semantically useful for QMP.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrangé 
---
 docs/system/deprecated.rst   | 7 ---
 docs/system/removed-features.rst | 6 ++
 monitor/monitor.c| 4 ++--
 qemu-options.hx  | 5 +++--
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 0e1fdf5c14..8f4d756e35 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -53,13 +53,6 @@ needs two devices (``-device intel-hda -device hda-duplex``) 
and
 ``pcspk`` which can be activated using ``-machine
 pcspk-audiodev=``.
 
-``-mon ...,control=readline,pretty=on|off`` (since 4.1)
-'''
-
-The ``pretty=on|off`` switch has no effect for HMP monitors, but is
-silently ignored. Using the switch with HMP monitors will become an
-error in the future.
-
 RISC-V ``-bios`` (since 5.1)
 
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index aa612c2846..372aadceae 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -51,6 +51,12 @@ host controller or ``-usb`` if necessary).
 The ``acl`` option to the ``-vnc`` argument has been replaced
 by the ``tls-authz`` and ``sasl-authz`` options.
 
+``-mon ...,control=readline,pretty=on|off`` (removed in 6.0)
+
+
+The ``pretty=on|off`` switch has no effect for HMP monitors and
+its use is rejected.
+
 QEMU Machine Protocol (QMP) commands
 
 
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 640496e562..636bcc81c5 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -716,8 +716,8 @@ int monitor_init(MonitorOptions *opts, bool allow_hmp, 
Error **errp)
 return -1;
 }
 if (opts->pretty) {
-warn_report("'pretty' is deprecated for HMP monitors, it has no "
-"effect and will be removed in future versions");
+error_setg(errp, "'pretty' is not compatible with HMP monitors");
+return -1;
 }
 monitor_init_hmp(chr, true, &local_err);
 break;
diff --git a/qemu-options.hx b/qemu-options.hx
index 9128dec510..671b310ab8 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3740,8 +3740,9 @@ DEF("mon", HAS_ARG, QEMU_OPTION_mon, \
 "-mon [chardev=]name[,mode=readline|control][,pretty[=on|off]]\n", 
QEMU_ARCH_ALL)
 SRST
 ``-mon [chardev=]name[,mode=readline|control][,pretty[=on|off]]``
-Setup monitor on chardev name. ``pretty`` turns on JSON pretty
-printing easing human reading and debugging.
+Setup monitor on chardev name. ``pretty`` is only valid when
+``mode=control``, turning on JSON pretty printing to ease
+human reading and debugging.
 ERST
 
 DEF("debugcon", HAS_ARG, QEMU_OPTION_debugcon, \
-- 
2.30.2

[PULL 06/13] machine: remove 'arch' field from 'query-cpus-fast' QMP command

[Daniel P . Berrangé]

Reviewed-by: Thomas Huth 
Signed-off-by: Daniel P. Berrangé 
---
 docs/system/deprecated.rst   |  6 -
 docs/system/removed-features.rst |  6 +
 hw/core/machine-qmp-cmds.c   | 41 
 qapi/machine.json| 22 -
 4 files changed, 6 insertions(+), 69 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 9a62afa6de..30c5969e22 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -228,12 +228,6 @@ Since the ``dirty-bitmaps`` field is optionally present in 
both the old and
 new locations, clients must use introspection to learn where to anticipate
 the field if/when it does appear in command output.
 
-``query-cpus-fast`` ``arch`` output member (since 3.0.0)
-
-
-The ``arch`` output member of the ``query-cpus-fast`` command is
-replaced by the ``target`` output member.
-
 chardev client socket with ``wait`` option (since 4.0)
 ''
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index d7d86b3143..ce1087c6a7 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -98,6 +98,12 @@ Use ``migrate_set_parameter`` instead.
 
 The ``query-cpus`` command is replaced by the ``query-cpus-fast`` command.
 
+``query-cpus-fast`` ``arch`` output member (removed in 6.0)
+'''
+
+The ``arch`` output member of the ``query-cpus-fast`` command is
+replaced by the ``target`` output member.
+
 Human Monitor Protocol (HMP) commands
 -
 
diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index af60cd969d..68a942595a 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -24,46 +24,6 @@
 #include "sysemu/runstate.h"
 #include "sysemu/sysemu.h"
 
-static CpuInfoArch sysemu_target_to_cpuinfo_arch(SysEmuTarget target)
-{
-/*
- * The @SysEmuTarget -> @CpuInfoArch mapping below is based on the
- * TARGET_ARCH -> TARGET_BASE_ARCH mapping in the "configure" script.
- */
-switch (target) {
-case SYS_EMU_TARGET_I386:
-case SYS_EMU_TARGET_X86_64:
-return CPU_INFO_ARCH_X86;
-
-case SYS_EMU_TARGET_PPC:
-case SYS_EMU_TARGET_PPC64:
-return CPU_INFO_ARCH_PPC;
-
-case SYS_EMU_TARGET_SPARC:
-case SYS_EMU_TARGET_SPARC64:
-return CPU_INFO_ARCH_SPARC;
-
-case SYS_EMU_TARGET_MIPS:
-case SYS_EMU_TARGET_MIPSEL:
-case SYS_EMU_TARGET_MIPS64:
-case SYS_EMU_TARGET_MIPS64EL:
-return CPU_INFO_ARCH_MIPS;
-
-case SYS_EMU_TARGET_TRICORE:
-return CPU_INFO_ARCH_TRICORE;
-
-case SYS_EMU_TARGET_S390X:
-return CPU_INFO_ARCH_S390;
-
-case SYS_EMU_TARGET_RISCV32:
-case SYS_EMU_TARGET_RISCV64:
-return CPU_INFO_ARCH_RISCV;
-
-default:
-return CPU_INFO_ARCH_OTHER;
-}
-}
-
 static void cpustate_to_cpuinfo_s390(CpuInfoS390 *info, const CPUState *cpu)
 {
 #ifdef TARGET_S390X
@@ -104,7 +64,6 @@ CpuInfoFastList *qmp_query_cpus_fast(Error **errp)
 value->props = props;
 }
 
-value->arch = sysemu_target_to_cpuinfo_arch(target);
 value->target = target;
 if (target == SYS_EMU_TARGET_S390X) {
 cpustate_to_cpuinfo_s390(&value->u.s390x, cpu);
diff --git a/qapi/machine.json b/qapi/machine.json
index 9811927504..c0c52aef10 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -34,21 +34,6 @@
  'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
  'x86_64', 'xtensa', 'xtensaeb' ] }
 
-##
-# @CpuInfoArch:
-#
-# An enumeration of cpu types that enable additional information during
-# @query-cpus-fast.
-#
-# @s390: since 2.12
-#
-# @riscv: since 2.12
-#
-# Since: 2.6
-##
-{ 'enum': 'CpuInfoArch',
-  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'riscv', 'other' 
] }
-
 ##
 # @CpuS390State:
 #
@@ -86,14 +71,9 @@
 # @props: properties describing to which node/socket/core/thread
 # virtual CPU belongs to, provided if supported by board
 #
-# @arch: base architecture of the cpu
-#
 # @target: the QEMU system emulation target, which determines which
 #  additional fields will be listed (since 3.0)
 #
-# Features:
-# @deprecated: Member @arch is deprecated.  Use @target instead.
-#
 # Since: 2.12
 #
 ##
@@ -102,8 +82,6 @@
   'qom-path' : 'str',
   'thread-id': 'int',
   '*props'   : 'CpuInstanceProperties',
-  'arch' : { 'type': 'CpuInfoArch',
- 'features': [ 'deprecated' ] },
   'target'   : 'SysEmuTarget' },
   'discriminator' : 'target',
   'data'  : { 's390x': 'CpuInfoS390' } }
-- 
2.30.2

[PULL 05/13] machine: remove 'query-cpus' QMP command

[Daniel P . Berrangé]

The newer 'query-cpus-fast' command avoids side effects on the guest
execution. Note that some of the field names are different in the
'query-cpus-fast' command.

Reviewed-by: Wainer dos Santos Moschetta 
Tested-by: Wainer dos Santos Moschetta 
Signed-off-by: Daniel P. Berrangé 
---
 docs/system/deprecated.rst |   5 -
 docs/system/removed-features.rst   |   5 +
 hw/core/machine-hmp-cmds.c |   8 +-
 hw/core/machine-qmp-cmds.c |  79 --
 qapi/machine.json  | 161 +
 tests/acceptance/pc_cpu_hotplug_props.py   |   2 +-
 tests/acceptance/x86_cpu_model_versions.py |   2 +-
 tests/migration/guestperf/engine.py|   2 +-
 tests/qtest/numa-test.c|   6 +-
 tests/qtest/qmp-test.c |   6 +-
 tests/qtest/test-x86-cpuid-compat.c|   4 +-
 11 files changed, 22 insertions(+), 258 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index c92387180c..9a62afa6de 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -228,11 +228,6 @@ Since the ``dirty-bitmaps`` field is optionally present in 
both the old and
 new locations, clients must use introspection to learn where to anticipate
 the field if/when it does appear in command output.
 
-``query-cpus`` (since 2.12.0)
-'
-
-The ``query-cpus`` command is replaced by the ``query-cpus-fast`` command.
-
 ``query-cpus-fast`` ``arch`` output member (since 3.0.0)
 
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index d7f46a6ebc..d7d86b3143 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -93,6 +93,11 @@ Use ``migrate_set_parameter`` and ``info 
migrate_parameters`` instead.
 
 Use ``migrate_set_parameter`` instead.
 
+``query-cpus`` (removed in 6.0)
+'''
+
+The ``query-cpus`` command is replaced by the ``query-cpus-fast`` command.
+
 Human Monitor Protocol (HMP) commands
 -
 
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 6357be9c6b..58248cffa3 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -130,7 +130,7 @@ void hmp_info_numa(Monitor *mon, const QDict *qdict)
 {
 int i, nb_numa_nodes;
 NumaNodeMem *node_mem;
-CpuInfoList *cpu_list, *cpu;
+CpuInfoFastList *cpu_list, *cpu;
 MachineState *ms = MACHINE(qdev_get_machine());
 
 nb_numa_nodes = ms->numa_state ? ms->numa_state->num_nodes : 0;
@@ -139,7 +139,7 @@ void hmp_info_numa(Monitor *mon, const QDict *qdict)
 return;
 }
 
-cpu_list = qmp_query_cpus(&error_abort);
+cpu_list = qmp_query_cpus_fast(&error_abort);
 node_mem = g_new0(NumaNodeMem, nb_numa_nodes);
 
 query_numa_node_mem(node_mem, ms);
@@ -148,7 +148,7 @@ void hmp_info_numa(Monitor *mon, const QDict *qdict)
 for (cpu = cpu_list; cpu; cpu = cpu->next) {
 if (cpu->value->has_props && cpu->value->props->has_node_id &&
 cpu->value->props->node_id == i) {
-monitor_printf(mon, " %" PRIi64, cpu->value->CPU);
+monitor_printf(mon, " %" PRIi64, cpu->value->cpu_index);
 }
 }
 monitor_printf(mon, "\n");
@@ -157,6 +157,6 @@ void hmp_info_numa(Monitor *mon, const QDict *qdict)
 monitor_printf(mon, "node %d plugged: %" PRId64 " MB\n", i,
node_mem[i].node_plugged_mem >> 20);
 }
-qapi_free_CpuInfoList(cpu_list);
+qapi_free_CpuInfoFastList(cpu_list);
 g_free(node_mem);
 }
diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 44e979e503..af60cd969d 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -24,85 +24,6 @@
 #include "sysemu/runstate.h"
 #include "sysemu/sysemu.h"
 
-CpuInfoList *qmp_query_cpus(Error **errp)
-{
-MachineState *ms = MACHINE(qdev_get_machine());
-MachineClass *mc = MACHINE_GET_CLASS(ms);
-CpuInfoList *head = NULL, **tail = &head;
-CPUState *cpu;
-
-CPU_FOREACH(cpu) {
-CpuInfo *value;
-#if defined(TARGET_I386)
-X86CPU *x86_cpu = X86_CPU(cpu);
-CPUX86State *env = &x86_cpu->env;
-#elif defined(TARGET_PPC)
-PowerPCCPU *ppc_cpu = POWERPC_CPU(cpu);
-CPUPPCState *env = &ppc_cpu->env;
-#elif defined(TARGET_SPARC)
-SPARCCPU *sparc_cpu = SPARC_CPU(cpu);
-CPUSPARCState *env = &sparc_cpu->env;
-#elif defined(TARGET_RISCV)
-RISCVCPU *riscv_cpu = RISCV_CPU(cpu);
-CPURISCVState *env = &riscv_cpu->env;
-#elif defined(TARGET_MIPS)
-MIPSCPU *mips_cpu = MIPS_CPU(cpu);
-CPUMIPSState *env = &mips_cpu->env;
-#elif defined(TARGET_TRICORE)
-TriCoreCPU *tricore_cpu = TRICORE_CPU(cpu);
-CPUTriCoreState *env = &tricore_cpu->env;
-#elif defined(TARGET_S390X)
-  

Re: [PATCH v2 0/7] ui: add vdagent implementation and clipboard support.

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20210318091647.3233178-1-kra...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20210318091647.3233178-1-kra...@redhat.com
Subject: [PATCH v2 0/7] ui: add vdagent implementation and clipboard support.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20210317143325.2165821-1-ebl...@redhat.com -> 
patchew/20210317143325.2165821-1-ebl...@redhat.com
 - [tag update]  patchew/20210317194849.2262346-1-waine...@redhat.com -> 
patchew/20210317194849.2262346-1-waine...@redhat.com
 - [tag update]  patchew/20210318023801.18287-1-gs...@redhat.com -> 
patchew/20210318023801.18287-1-gs...@redhat.com
 * [new tag] patchew/20210318091647.3233178-1-kra...@redhat.com -> 
patchew/20210318091647.3233178-1-kra...@redhat.com
Switched to a new branch 'test'
509f0ec ui/gtk: add clipboard support
6413531 ui/gtk: move struct GtkDisplayState to ui/gtk.h
be4f996 ui/vnc: clipboard support
15ab2b9 ui/vdagent: add clipboard support
c920715 ui/vdagent: add mouse support
d23759f ui/vdagent: core infrastructure
f59e025 ui: add clipboard infrastructure

=== OUTPUT BEGIN ===
1/7 Checking commit f59e025bdd71 (ui: add clipboard infrastructure)
Use of uninitialized value $acpi_testexpected in string eq at 
./scripts/checkpatch.pl line 1529.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100644

total: 0 errors, 1 warnings, 167 lines checked

Patch 1/7 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/7 Checking commit d23759fc5d14 (ui/vdagent: core infrastructure)
Use of uninitialized value $acpi_testexpected in string eq at 
./scripts/checkpatch.pl line 1529.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#91: 
new file mode 100644

ERROR: if this code is redundant consider removing it
#141: FILE: ui/vdagent.c:46:
+#if 0

WARNING: line over 80 characters
#143: FILE: ui/vdagent.c:48:
+[VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB] = 
"clipboard-no-release-on-regrab",

ERROR: if this code is redundant consider removing it
#164: FILE: ui/vdagent.c:69:
+#if 0

WARNING: line over 80 characters
#216: FILE: ui/vdagent.c:121:
+   
sizeof(VDAgentAnnounceCapabilities) +

total: 2 errors, 3 warnings, 322 lines checked

Patch 2/7 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

3/7 Checking commit c9207151ac3c (ui/vdagent: add mouse support)
ERROR: if this code is redundant consider removing it
#137: FILE: ui/vdagent.c:179:
+#if 0

total: 1 errors, 0 warnings, 228 lines checked

Patch 3/7 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/7 Checking commit 15ab2b94f99a (ui/vdagent: add clipboard support)
ERROR: if this code is redundant consider removing it
#120: FILE: ui/vdagent.c:112:
+#if 0

ERROR: line over 90 characters
#159: FILE: ui/vdagent.c:286:
+   sizeof(uint32_t) * 
(QEMU_CLIPBOARD_TYPE__COUNT + 1));

WARNING: line over 80 characters
#406: FILE: ui/vdagent.c:652:
+cfg->clipboard = qemu_opt_get_bool(opts, "clipboard", 
VDAGENT_CLIPBOARD_DEFAULT);

total: 2 errors, 1 warnings, 359 lines checked

Patch 4/7 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

5/7 Checking commit be4f996a546c (ui/vnc: clipboard support)
Use of uninitialized value $acpi_testexpected in string eq at 
./scripts/checkpatch.pl line 1529.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#33: 
new file mode 100644

WARNING: line over 80 characters
#280: FILE: ui/vnc-clipboard.c:243:
+void vnc_client_cut_text_ext(VncState *vs, int32_t len, uint32_t flags, 
uint8_t *data)

WARNING: line over 80 characters
#289: FILE: ui/vnc-clipboard.c:252:
+qemu_clipboard_info_new(&vs->cbpeer, 
QEMU_CLIPBOARD_SELECTION_CLIPBOARD);

WARNING: line over 80 characters
#333: FILE: ui/vnc-clipboard.c:296:
+qemu_clipboard_info_new(&vs->cbpeer, 
QEMU_CLIPBOARD_SELECTION_CLIPBOARD);

ERROR: line over 90 characters
#420: FILE: ui/vnc.c:2430:
+vnc_client_cut_text_ext(vs, abs(read_s32(data, 4)), read_u32(data, 
8), data + 12);

WARNING: line over 80 characters
#499: FILE: ui/vnc.h:643:
+void vnc_client_cut_text_ext(VncState *vs, int32_t len, u

[PULL 07/13] chardev: reject use of 'wait' flag for socket client chardevs

[Daniel P . Berrangé]

This only makes sense conceptually when used with listener chardevs.

Reviewed-by: Marc-André Lureau 
Signed-off-by: Daniel P. Berrangé 
---
 chardev/char-socket.c| 12 
 docs/system/deprecated.rst   |  6 --
 docs/system/removed-features.rst |  6 ++
 3 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index c8bced76b7..f618bdec28 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -1339,14 +1339,10 @@ static bool qmp_chardev_validate_socket(ChardevSocket 
*sock,
 return false;
 }
 if (sock->has_wait) {
-warn_report("'wait' option is deprecated with "
-"socket in client connect mode");
-if (sock->wait) {
-error_setg(errp, "%s",
-   "'wait' option is incompatible with "
-   "socket in client connect mode");
-return false;
-}
+error_setg(errp, "%s",
+   "'wait' option is incompatible with "
+   "socket in client connect mode");
+return false;
 }
 }
 
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 30c5969e22..eed35fd004 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -228,12 +228,6 @@ Since the ``dirty-bitmaps`` field is optionally present in 
both the old and
 new locations, clients must use introspection to learn where to anticipate
 the field if/when it does appear in command output.
 
-chardev client socket with ``wait`` option (since 4.0)
-''
-
-Character devices creating sockets in client mode should not specify
-the 'wait' field, which is only applicable to sockets in server mode
-
 ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
 
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index ce1087c6a7..33b8c08f9b 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -104,6 +104,12 @@ The ``query-cpus`` command is replaced by the 
``query-cpus-fast`` command.
 The ``arch`` output member of the ``query-cpus-fast`` command is
 replaced by the ``target`` output member.
 
+chardev client socket with ``wait`` option (removed in 6.0)
+'''
+
+Character devices creating sockets in client mode should not specify
+the 'wait' field, which is only applicable to sockets in server mode
+
 Human Monitor Protocol (HMP) commands
 -
 
-- 
2.30.2

Re: [RFC v2 05/13] vhost: Route guest->host notification through shadow virtqueue

[Jason Wang]

在 2021/3/18 下午5:18, Eugenio Perez Martin 写道:

On Thu, Mar 18, 2021 at 4:11 AM Jason Wang  wrote:


在 2021/3/18 上午12:47, Eugenio Perez Martin 写道:

On Wed, Mar 17, 2021 at 3:05 AM Jason Wang  wrote:

在 2021/3/16 下午6:31, Eugenio Perez Martin 写道:

On Tue, Mar 16, 2021 at 8:18 AM Jason Wang  wrote:

在 2021/3/16 上午3:48, Eugenio Pérez 写道:

Shadow virtqueue notifications forwarding is disabled when vhost_dev
stops, so code flow follows usual cleanup.

Signed-off-by: Eugenio Pérez 
---
 hw/virtio/vhost-shadow-virtqueue.h |   7 ++
 include/hw/virtio/vhost.h  |   4 +
 hw/virtio/vhost-shadow-virtqueue.c | 113 ++-
 hw/virtio/vhost.c  | 143 -
 4 files changed, 265 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost-shadow-virtqueue.h 
b/hw/virtio/vhost-shadow-virtqueue.h
index 6cc18d6acb..c891c6510d 100644
--- a/hw/virtio/vhost-shadow-virtqueue.h
+++ b/hw/virtio/vhost-shadow-virtqueue.h
@@ -17,6 +17,13 @@

 typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;

+bool vhost_shadow_vq_start(struct vhost_dev *dev,
+   unsigned idx,
+   VhostShadowVirtqueue *svq);
+void vhost_shadow_vq_stop(struct vhost_dev *dev,
+  unsigned idx,
+  VhostShadowVirtqueue *svq);
+
 VhostShadowVirtqueue *vhost_shadow_vq_new(struct vhost_dev *dev, int idx);

 void vhost_shadow_vq_free(VhostShadowVirtqueue *vq);
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index ac963bf23d..7ffdf9aea0 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -55,6 +55,8 @@ struct vhost_iommu {
 QLIST_ENTRY(vhost_iommu) iommu_next;
 };

+typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
+
 typedef struct VhostDevConfigOps {
 /* Vhost device config space changed callback
  */
@@ -83,7 +85,9 @@ struct vhost_dev {
 uint64_t backend_cap;
 bool started;
 bool log_enabled;
+bool shadow_vqs_enabled;
 uint64_t log_size;
+VhostShadowVirtqueue **shadow_vqs;

Any reason that you don't embed the shadow virtqueue into
vhost_virtqueue structure?


Not really, it could be relatively big and I would prefer SVQ
members/methods to remain hidden from any other part that includes
vhost.h. But it could be changed, for sure.


(Note that there's a masked_notifier in struct vhost_virtqueue).


They are used differently: in SVQ the masked notifier is a pointer,
and if it's NULL the SVQ code knows that device is not masked. The
vhost_virtqueue is the real owner.

Yes, but it's an example for embedding auxciliary data structures in the
vhost_virtqueue.



It could be replaced by a boolean in SVQ or something like that, I
experimented with a tri-state too (UNMASKED, MASKED, MASKED_NOTIFIED)
and let vhost.c code to manage all the transitions. But I find clearer
the pointer use, since it's the more natural for the
vhost_virtqueue_mask, vhost_virtqueue_pending existing functions.

This masking/unmasking is the part I dislike the most from this
series, so I'm very open to alternatives.

See below. I think we don't even need to care about that.



 Error *migration_blocker;
 const VhostOps *vhost_ops;
 void *opaque;
diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
b/hw/virtio/vhost-shadow-virtqueue.c
index 4512e5b058..3e43399e9c 100644
--- a/hw/virtio/vhost-shadow-virtqueue.c
+++ b/hw/virtio/vhost-shadow-virtqueue.c
@@ -8,9 +8,12 @@
  */

 #include "hw/virtio/vhost-shadow-virtqueue.h"
+#include "hw/virtio/vhost.h"
+
+#include "standard-headers/linux/vhost_types.h"

 #include "qemu/error-report.h"
-#include "qemu/event_notifier.h"
+#include "qemu/main-loop.h"

 /* Shadow virtqueue to relay notifications */
 typedef struct VhostShadowVirtqueue {
@@ -18,14 +21,121 @@ typedef struct VhostShadowVirtqueue {
 EventNotifier kick_notifier;
 /* Shadow call notifier, sent to vhost */
 EventNotifier call_notifier;
+
+/*
+ * Borrowed virtqueue's guest to host notifier.
+ * To borrow it in this event notifier allows to register on the event
+ * loop and access the associated shadow virtqueue easily. If we use the
+ * VirtQueue, we don't have an easy way to retrieve it.

So this is something that worries me. It looks like a layer violation
that makes the codes harder to work correctly.


I don't follow you here.

The vhost code already depends on virtqueue in the same sense:
virtio_queue_get_host_notifier is called on vhost_virtqueue_start. So
if this behavior ever changes it is unlikely for vhost to keep working
without changes. vhost_virtqueue has a kick/call int where I think it
should be stored actually, but they are never used as far as I see.

Previous RFC did rely on vhost_dev_disable_notifiers. From its documentation:
/* Stop processing guest IO notifications in vhost.
* Start process

[PULL 12/13] block: remove 'dirty-bitmaps' field from 'BlockInfo' struct

[Daniel P . Berrangé]

The same data is available in the 'BlockDeviceInfo' struct.

Reviewed-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Daniel P. Berrangé 
---
 block/qapi.c|  5 -
 docs/system/deprecated.rst  | 13 -
 docs/system/removed-features.rst|  9 +
 qapi/block-core.json| 11 +--
 tests/qemu-iotests/194  |  4 ++--
 tests/qemu-iotests/236  |  2 +-
 tests/qemu-iotests/246  |  3 ++-
 tests/qemu-iotests/254  |  2 +-
 tests/qemu-iotests/260  |  5 +++--
 .../tests/migrate-bitmaps-postcopy-test |  6 --
 10 files changed, 23 insertions(+), 37 deletions(-)

diff --git a/block/qapi.c b/block/qapi.c
index 3acc118c44..943e7b15ad 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -383,11 +383,6 @@ static void bdrv_query_info(BlockBackend *blk, BlockInfo 
**p_info,
 info->io_status = blk_iostatus(blk);
 }
 
-if (bs && !QLIST_EMPTY(&bs->dirty_bitmaps)) {
-info->has_dirty_bitmaps = true;
-info->dirty_bitmaps = bdrv_query_dirty_bitmaps(bs);
-}
-
 if (bs && bs->drv) {
 info->has_inserted = true;
 info->inserted = bdrv_block_device_info(blk, bs, false, errp);
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index eadba0f288..c7e80fa731 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -198,19 +198,6 @@ Use arguments ``base-node`` and ``top-node`` instead.
 
 Specify the properties for the object as top-level arguments instead.
 
-``query-block`` result field ``dirty-bitmaps`` (Since 4.2)
-''
-
-The ``dirty-bitmaps`` field of the ``BlockInfo`` structure, returned by
-the query-block command is itself now deprecated. The ``dirty-bitmaps``
-field of the ``BlockDeviceInfo`` struct should be used instead, which is the
-type of the ``inserted`` field in query-block replies, as well as the
-type of array items in query-named-block-nodes.
-
-Since the ``dirty-bitmaps`` field is optionally present in both the old and
-new locations, clients must use introspection to learn where to anticipate
-the field if/when it does appear in command output.
-
 ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
 
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 47fdfe6f72..d164d3f290 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -127,6 +127,15 @@ The ``status`` field of the ``BlockDirtyInfo`` structure, 
returned by
 these commands is removed. Two new boolean fields, ``recording`` and
 ``busy`` effectively replace it.
 
+``query-block`` result field ``dirty-bitmaps`` (removed in 6.0)
+'''
+
+The ``dirty-bitmaps`` field of the ``BlockInfo`` structure, returned by
+the query-block command is itself now removed. The ``dirty-bitmaps``
+field of the ``BlockDeviceInfo`` struct should be used instead, which is the
+type of the ``inserted`` field in query-block replies, as well as the
+type of array items in query-named-block-nodes.
+
 Human Monitor Protocol (HMP) commands
 -
 
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 2a0c345c2c..0399449e13 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -539,9 +539,6 @@
 # @tray_open: True if the device's tray is open
 # (only present if it has a tray)
 #
-# @dirty-bitmaps: dirty bitmaps information (only present if the
-# driver has one or more dirty bitmaps) (Since 2.0)
-#
 # @io-status: @BlockDeviceIoStatus. Only present if the device
 # supports it and the VM is configured to stop on errors
 # (supported device models: virtio-blk, IDE, SCSI except
@@ -550,18 +547,12 @@
 # @inserted: @BlockDeviceInfo describing the device if media is
 #present
 #
-# Features:
-# @deprecated: Member @dirty-bitmaps is deprecated.  Use @inserted
-#  member @dirty-bitmaps instead.
-#
 # Since:  0.14
 ##
 { 'struct': 'BlockInfo',
   'data': {'device': 'str', '*qdev': 'str', 'type': 'str', 'removable': 'bool',
'locked': 'bool', '*inserted': 'BlockDeviceInfo',
-   '*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatus',
-   '*dirty-bitmaps': { 'type': ['BlockDirtyInfo'],
-   'features': [ 'deprecated' ] } } }
+   '*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatus' } }
 
 ##
 # @BlockMeasureInfo:
diff --git a/tests/qemu-iotests/194 b/tests/qemu-iotests/194
index 3889266afa..e44b8df728 100755
--- a/tests/qemu-iotests/194
+++ b/tests/qemu-iotests/194
@@ -95,7 +95,7 @@ with iotests.FilePath

[PULL 13/13] block: remove support for using "file" driver with block/char devices

[Daniel P . Berrangé]

The 'host_device' and 'host_cdrom' drivers must be used instead.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrangé 
---
 block/file-posix.c   | 17 ++---
 docs/system/deprecated.rst   |  7 ---
 docs/system/removed-features.rst |  7 +++
 tests/qemu-iotests/226.out   | 10 +-
 4 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 05079b40ca..20e14f8e96 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -719,15 +719,9 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 }
 
 if (!device) {
-if (S_ISBLK(st.st_mode)) {
-warn_report("Opening a block device as a file using the '%s' "
-"driver is deprecated", bs->drv->format_name);
-} else if (S_ISCHR(st.st_mode)) {
-warn_report("Opening a character device as a file using the '%s' "
-"driver is deprecated", bs->drv->format_name);
-} else if (!S_ISREG(st.st_mode)) {
-error_setg(errp, "A regular file was expected by the '%s' driver, "
-   "but something else was given", bs->drv->format_name);
+if (!S_ISREG(st.st_mode)) {
+error_setg(errp, "'%s' driver requires '%s' to be a regular file",
+   bs->drv->format_name, bs->filename);
 ret = -EINVAL;
 goto fail;
 } else {
@@ -736,8 +730,9 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 }
 } else {
 if (!(S_ISCHR(st.st_mode) || S_ISBLK(st.st_mode))) {
-error_setg(errp, "'%s' driver expects either "
-   "a character or block device", bs->drv->format_name);
+error_setg(errp, "'%s' driver requires '%s' to be either "
+   "a character or block device",
+   bs->drv->format_name, bs->filename);
 ret = -EINVAL;
 goto fail;
 }
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index c7e80fa731..d5e80d66eb 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -21,13 +21,6 @@ deprecated.
 System emulator command line arguments
 --
 
-``-drive file=json:{...{'driver':'file'}}`` (since 3.0)
-'''
-
-The 'file' driver for drives is no longer appropriate for character or host
-devices and will only accept regular files (S_IFREG). The correct driver
-for these file types is 'host_cdrom' or 'host_device' as appropriate.
-
 ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
 '
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index d164d3f290..bff16b7b05 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -57,6 +57,13 @@ by the ``tls-authz`` and ``sasl-authz`` options.
 The ``pretty=on|off`` switch has no effect for HMP monitors and
 its use is rejected.
 
+``-drive file=json:{...{'driver':'file'}}`` (removed 6.0)
+'
+
+The 'file' driver for drives is no longer appropriate for character or host
+devices and will only accept regular files (S_IFREG). The correct driver
+for these file types is 'host_cdrom' or 'host_device' as appropriate.
+
 QEMU Machine Protocol (QMP) commands
 
 
diff --git a/tests/qemu-iotests/226.out b/tests/qemu-iotests/226.out
index 42be973ff2..55504d29c4 100644
--- a/tests/qemu-iotests/226.out
+++ b/tests/qemu-iotests/226.out
@@ -3,23 +3,23 @@ QA output created by 226
 === Testing with driver:file ===
 
 == Testing RO ==
-qemu-io: can't open: A regular file was expected by the 'file' driver, but 
something else was given
-qemu-io: warning: Opening a character device as a file using the 'file' driver 
is deprecated
+qemu-io: can't open: 'file' driver requires 'TEST_DIR/t.IMGFMT' to be a 
regular file
+qemu-io: can't open: 'file' driver requires '/dev/null' to be a regular file
 == Testing RW ==
 qemu-io: can't open: Could not open 'TEST_DIR/t.IMGFMT': Is a directory
-qemu-io: warning: Opening a character device as a file using the 'file' driver 
is deprecated
+qemu-io: can't open: 'file' driver requires '/dev/null' to be a regular file
 
 === Testing with driver:host_device ===
 
 == Testing RO ==
-qemu-io: can't open: 'host_device' driver expects either a character or block 
device
+qemu-io: can't open: 'host_device' driver requires 'TEST_DIR/t.IMGFMT' to be 
either a character or block device
 == Testing RW ==
 qemu-io: can't open: Could not open 'TEST_DIR/t.IMGFMT': Is a directory
 
 === Testing with driver:host_cdrom ===
 
 == Testing RO ==
-qemu-io: can't open: 'host_cdrom' driver expects either a character or block 
device
+qemu-io: can't open: 'host_

[PULL 08/13] hw/ide: remove 'ide-drive' device

[Daniel P . Berrangé]

The 'ide-hd' and 'ide-cd' devices provide suitable alternatives.

Reviewed-by: Thomas Huth 
Signed-off-by: Daniel P. Berrangé 
---
 docs/qdev-device-use.txt |  2 +-
 docs/system/deprecated.rst   |  6 -
 docs/system/removed-features.rst |  8 +++
 hw/i386/pc.c |  1 -
 hw/ide/qdev.c| 38 
 hw/ppc/mac_newworld.c| 13 ---
 hw/ppc/mac_oldworld.c| 13 ---
 hw/sparc64/sun4u.c   | 15 -
 scripts/device-crash-test|  1 -
 softmmu/vl.c |  1 -
 tests/qemu-iotests/051   |  2 --
 tests/qemu-iotests/051.pc.out| 10 -
 12 files changed, 9 insertions(+), 101 deletions(-)

diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
index 245cdf29c7..2408889334 100644
--- a/docs/qdev-device-use.txt
+++ b/docs/qdev-device-use.txt
@@ -388,7 +388,7 @@ type.
 some DEVNAMEs:
 
 default device  suppressing DEVNAMEs
-CD-ROM  ide-cd, ide-drive, ide-hd, scsi-cd, scsi-hd
+CD-ROM  ide-cd, ide-hd, scsi-cd, scsi-hd
 floppy  floppy, isa-fdc
 parallelisa-parallel
 serial  isa-serial
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index eed35fd004..f512e05734 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -278,12 +278,6 @@ this CPU is also deprecated.
 System emulator devices
 ---
 
-``ide-drive`` (since 4.2)
-'
-
-The 'ide-drive' device is deprecated. Users should use 'ide-hd' or
-'ide-cd' as appropriate to get an IDE hard disk or CD-ROM as needed.
-
 ``scsi-disk`` (since 4.2)
 '
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 33b8c08f9b..794fc3f367 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -224,6 +224,14 @@ the upstream Linux kernel in 2018, and it has also been 
dropped from glibc, so
 there is no new Linux development taking place with this architecture. For
 running the old binaries, you can use older versions of QEMU.
 
+System emulator devices
+---
+
+``ide-drive`` (removed in 6.0)
+''
+
+The 'ide-drive' device has been removed. Users should use 'ide-hd' or
+'ide-cd' as appropriate to get an IDE hard disk or CD-ROM as needed.
 
 Related binaries
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 410db9ef96..804913bb7e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -341,7 +341,6 @@ GlobalProperty pc_compat_1_4[] = {
 { "scsi-disk", "discard_granularity", "0" },
 { "ide-hd", "discard_granularity", "0" },
 { "ide-cd", "discard_granularity", "0" },
-{ "ide-drive", "discard_granularity", "0" },
 { "virtio-blk-pci", "discard_granularity", "0" },
 /* DEV_NVECTORS_UNSPECIFIED as a uint32_t string: */
 { "virtio-serial-pci", "vectors", "0x" },
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 8cd19fa5e9..e70ebc83a0 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -283,20 +283,6 @@ static void ide_cd_realize(IDEDevice *dev, Error **errp)
 ide_dev_initfn(dev, IDE_CD, errp);
 }
 
-static void ide_drive_realize(IDEDevice *dev, Error **errp)
-{
-DriveInfo *dinfo = NULL;
-
-warn_report("'ide-drive' is deprecated, "
-"please use 'ide-hd' or 'ide-cd' instead");
-
-if (dev->conf.blk) {
-dinfo = blk_legacy_dinfo(dev->conf.blk);
-}
-
-ide_dev_initfn(dev, dinfo && dinfo->media_cd ? IDE_CD : IDE_HD, errp);
-}
-
 #define DEFINE_IDE_DEV_PROPERTIES() \
 DEFINE_BLOCK_PROPERTIES(IDEDrive, dev.conf),\
 DEFINE_BLOCK_ERROR_PROPERTIES(IDEDrive, dev.conf),  \
@@ -355,29 +341,6 @@ static const TypeInfo ide_cd_info = {
 .class_init= ide_cd_class_init,
 };
 
-static Property ide_drive_properties[] = {
-DEFINE_IDE_DEV_PROPERTIES(),
-DEFINE_PROP_END_OF_LIST(),
-};
-
-static void ide_drive_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-IDEDeviceClass *k = IDE_DEVICE_CLASS(klass);
-
-k->realize  = ide_drive_realize;
-dc->fw_name = "drive";
-dc->desc= "virtual IDE disk or CD-ROM (legacy)";
-device_class_set_props(dc, ide_drive_properties);
-}
-
-static const TypeInfo ide_drive_info = {
-.name  = "ide-drive",
-.parent= TYPE_IDE_DEVICE,
-.instance_size = sizeof(IDEDrive),
-.class_init= ide_drive_class_init,
-};
-
 static void ide_device_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *k = DEVICE_CLASS(klass);
@@ -402,7 +365,6 @@ static void ide_register_types(void)
 type_register_static(&ide_bus_info);
 type_register_static(&ide_hd_info);
 type_register_static(&ide_cd_info);
-type_register_static(&ide_drive_info);
 type_register_static(&ide_device_type_info

[PULL 09/13] hw/scsi: remove 'scsi-disk' device

[Daniel P . Berrangé]

The 'scsi-hd' and 'scsi-cd' devices provide suitable alternatives.

Reviewed-by: Thomas Huth 
Signed-off-by: Daniel P. Berrangé 
---
 docs/system/deprecated.rst   |  9 -
 docs/system/removed-features.rst |  6 
 hw/i386/pc.c |  1 -
 hw/scsi/scsi-disk.c  | 62 
 scripts/device-crash-test|  1 -
 tests/qemu-iotests/051   |  2 --
 tests/qemu-iotests/051.pc.out| 10 --
 7 files changed, 6 insertions(+), 85 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index f512e05734..ced6adf752 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -275,15 +275,6 @@ The ``I7200`` guest CPU relies on the nanoMIPS ISA, which 
is deprecated
 (the ISA has never been upstreamed to a compiler toolchain). Therefore
 this CPU is also deprecated.
 
-System emulator devices

-
-``scsi-disk`` (since 4.2)
-'
-
-The 'scsi-disk' device is deprecated. Users should use 'scsi-hd' or
-'scsi-cd' as appropriate to get a SCSI hard disk or CD-ROM as needed.
-
 System emulator machines
 
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 794fc3f367..2d6ff6aaf6 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -233,6 +233,12 @@ System emulator devices
 The 'ide-drive' device has been removed. Users should use 'ide-hd' or
 'ide-cd' as appropriate to get an IDE hard disk or CD-ROM as needed.
 
+``scsi-disk`` (removed in 6.0)
+''
+
+The 'scsi-disk' device has been removed. Users should use 'scsi-hd' or
+'scsi-cd' as appropriate to get a SCSI hard disk or CD-ROM as needed.
+
 Related binaries
 
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 804913bb7e..35e1770950 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -338,7 +338,6 @@ GlobalProperty pc_compat_1_4[] = {
 PC_CPU_MODEL_IDS("1.4.0")
 { "scsi-hd", "discard_granularity", "0" },
 { "scsi-cd", "discard_granularity", "0" },
-{ "scsi-disk", "discard_granularity", "0" },
 { "ide-hd", "discard_granularity", "0" },
 { "ide-cd", "discard_granularity", "0" },
 { "virtio-blk-pci", "discard_granularity", "0" },
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 2eaea7e637..3580e7ee61 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2476,28 +2476,6 @@ static void scsi_cd_realize(SCSIDevice *dev, Error 
**errp)
 aio_context_release(ctx);
 }
 
-static void scsi_disk_realize(SCSIDevice *dev, Error **errp)
-{
-DriveInfo *dinfo;
-Error *local_err = NULL;
-
-warn_report("'scsi-disk' is deprecated, "
-"please use 'scsi-hd' or 'scsi-cd' instead");
-
-if (!dev->conf.blk) {
-scsi_realize(dev, &local_err);
-assert(local_err);
-error_propagate(errp, local_err);
-return;
-}
-
-dinfo = blk_legacy_dinfo(dev->conf.blk);
-if (dinfo && dinfo->media_cd) {
-scsi_cd_realize(dev, errp);
-} else {
-scsi_hd_realize(dev, errp);
-}
-}
 
 static const SCSIReqOps scsi_disk_emulate_reqops = {
 .size = sizeof(SCSIDiskReq),
@@ -3161,45 +3139,6 @@ static const TypeInfo scsi_block_info = {
 };
 #endif
 
-static Property scsi_disk_properties[] = {
-DEFINE_SCSI_DISK_PROPERTIES(),
-DEFINE_PROP_BIT("removable", SCSIDiskState, features,
-SCSI_DISK_F_REMOVABLE, false),
-DEFINE_PROP_BIT("dpofua", SCSIDiskState, features,
-SCSI_DISK_F_DPOFUA, false),
-DEFINE_PROP_UINT64("wwn", SCSIDiskState, qdev.wwn, 0),
-DEFINE_PROP_UINT64("port_wwn", SCSIDiskState, qdev.port_wwn, 0),
-DEFINE_PROP_UINT16("port_index", SCSIDiskState, port_index, 0),
-DEFINE_PROP_UINT64("max_unmap_size", SCSIDiskState, max_unmap_size,
-   DEFAULT_MAX_UNMAP_SIZE),
-DEFINE_PROP_UINT64("max_io_size", SCSIDiskState, max_io_size,
-   DEFAULT_MAX_IO_SIZE),
-DEFINE_PROP_INT32("scsi_version", SCSIDiskState, qdev.default_scsi_version,
-  5),
-DEFINE_PROP_END_OF_LIST(),
-};
-
-static void scsi_disk_class_initfn(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass);
-
-sc->realize  = scsi_disk_realize;
-sc->alloc_req= scsi_new_request;
-sc->unit_attention_reported = scsi_disk_unit_attention_reported;
-dc->fw_name = "disk";
-dc->desc = "virtual SCSI disk or CD-ROM (legacy)";
-dc->reset = scsi_disk_reset;
-device_class_set_props(dc, scsi_disk_properties);
-dc->vmsd  = &vmstate_scsi_disk_state;
-}
-
-static const TypeInfo scsi_disk_info = {
-.name  = "scsi-disk",
-.parent= TYPE_SCSI_DISK_BASE,
-.class_init= scsi_disk_class_initfn,
-};
-
 static void scsi_disk_register_types(void)
 {
 type_register_static(

The windows guest can't bootup

[Yang Zhong]

Hello,

I synced today qemu code, and found the qemu can't bootup the windows guest.
This issue was caused by commit id 39205528 and revert this patch, the windows
guest can bootup.

qemu-system-x86_64: ../accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: 
Assertion `(((start | size) % (psize)) == 0)' failed.

I also enabled the vga device in the Linux guest, and same issue was found.

Regards,

Yang

Re: Serious doubts about Gitlab CI

[Daniel P . Berrangé]

On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> For some (unclear) reason I got my free tier Gitlab account renewed and
> lost the privilege for users opening account before the quota limit.
> 
> I pushed a single branch to my namespace repo to trigger a pipeline.
> 1h later I was surprised to see the pipeline was stuck, having completed
> 99 jobs of 119. Looking closer there is a red comment on top of the
> pipeline:
> 
>  philmd has exceeded its pipeline minutes quota. Unless you buy
>  additional pipeline minutes, no new jobs or pipelines in its projects
>  will run. [Buy more Pipelines minutes]
> 
> So I exhausted my 400 monthly minutes credit.
> 
> From this FAQ:
> https://about.gitlab.com/pricing/faq-consumption-cicd/#managing-your-cicd-minutes-usage
> 
> Q. What happens if I hit the CI/CD Minutes allotted limit and forget to
> purchase additional CI/CD Minutes?
> 
> A. You will not be able to run new jobs until you purchase additional
> CI/CD Minutes, or until the next month when you receive your monthly
> allotted CI/CD Minutes.
> 
> Q. Will I be notified before I hit my limit on CI/CD Minutes?
> 
> A. You will receive notification banners in-app when your group has less
> than 30%, 5% or exceeded your total allotted CI/CD minutes.
> 
> I indeed received 3 warnings in 7 minutes.
> 
> Now I'm having serious doubts about Gitlab usefulness for the QEMU
> community...

Per the discussions in the related Forum postings about CI limites, the
400 minute limit is still only intended to apply to projects that are
marked as private.  Public projects are not even being tracked for
accounting, let alone have a limit enforced. They also said they want
to make sure they don't impact ability of users to contribute to OSS
projects hosted on GitLab that require use of CI.

It feels like what you hit here is fallout from your account accidentally
getting blocked, rather than something which is hitting every contributor
to QEMU. Did they restore projects as private perhaps ?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

[PULL 11/13] block: remove dirty bitmaps 'status' field

[Daniel P . Berrangé]

The same information is available via the 'recording' and 'busy' fields.

Reviewed-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Daniel P. Berrangé 
---
 block/dirty-bitmap.c |  38 
 docs/system/deprecated.rst   |   7 -
 docs/system/removed-features.rst |   7 +
 include/block/dirty-bitmap.h |   1 -
 qapi/block-core.json |  45 
 tests/qemu-iotests/124   |   4 -
 tests/qemu-iotests/194.out   |   4 +-
 tests/qemu-iotests/236.out   |  42 ++--
 tests/qemu-iotests/246.out   |  66 ++
 tests/qemu-iotests/254.out   |   9 +-
 tests/qemu-iotests/257.out   | 378 +++
 11 files changed, 174 insertions(+), 427 deletions(-)

diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index a0eaa28785..68d295d6e3 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -166,43 +166,6 @@ bool bdrv_dirty_bitmap_enabled(BdrvDirtyBitmap *bitmap)
 return !bitmap->disabled;
 }
 
-/**
- * bdrv_dirty_bitmap_status: This API is now deprecated.
- * Called with BQL taken.
- *
- * A BdrvDirtyBitmap can be in four possible user-visible states:
- * (1) Active:   successor is NULL, and disabled is false: full r/w mode
- * (2) Disabled: successor is NULL, and disabled is true: qualified r/w mode,
- *   guest writes are dropped, but monitor writes are possible,
- *   through commands like merge and clear.
- * (3) Frozen:   successor is not NULL.
- *   A frozen bitmap cannot be renamed, deleted, cleared, set,
- *   enabled, merged to, etc. A frozen bitmap can only abdicate()
- *   or reclaim().
- *   In this state, the anonymous successor bitmap may be either
- *   Active and recording writes from the guest (e.g. backup jobs),
- *   or it can be Disabled and not recording writes.
- * (4) Locked:   Whether Active or Disabled, the user cannot modify this bitmap
- *   in any way from the monitor.
- * (5) Inconsistent: This is a persistent bitmap whose "in use" bit is set, and
- *   is unusable by QEMU. It can be deleted to remove it from
- *   the qcow2.
- */
-DirtyBitmapStatus bdrv_dirty_bitmap_status(BdrvDirtyBitmap *bitmap)
-{
-if (bdrv_dirty_bitmap_inconsistent(bitmap)) {
-return DIRTY_BITMAP_STATUS_INCONSISTENT;
-} else if (bdrv_dirty_bitmap_has_successor(bitmap)) {
-return DIRTY_BITMAP_STATUS_FROZEN;
-} else if (bdrv_dirty_bitmap_busy(bitmap)) {
-return DIRTY_BITMAP_STATUS_LOCKED;
-} else if (!bdrv_dirty_bitmap_enabled(bitmap)) {
-return DIRTY_BITMAP_STATUS_DISABLED;
-} else {
-return DIRTY_BITMAP_STATUS_ACTIVE;
-}
-}
-
 /* Called with BQL taken.  */
 static bool bdrv_dirty_bitmap_recording(BdrvDirtyBitmap *bitmap)
 {
@@ -582,7 +545,6 @@ BlockDirtyInfoList 
*bdrv_query_dirty_bitmaps(BlockDriverState *bs)
 info->granularity = bdrv_dirty_bitmap_granularity(bm);
 info->has_name = !!bm->name;
 info->name = g_strdup(bm->name);
-info->status = bdrv_dirty_bitmap_status(bm);
 info->recording = bdrv_dirty_bitmap_recording(bm);
 info->busy = bdrv_dirty_bitmap_busy(bm);
 info->persistent = bm->persistent;
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index d6051ef6b4..eadba0f288 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -198,13 +198,6 @@ Use arguments ``base-node`` and ``top-node`` instead.
 
 Specify the properties for the object as top-level arguments instead.
 
-``query-named-block-nodes`` and ``query-block`` result dirty-bitmaps[i].status 
(since 4.0)
-''
-
-The ``status`` field of the ``BlockDirtyInfo`` structure, returned by
-these commands is deprecated. Two new boolean fields, ``recording`` and
-``busy`` effectively replace it.
-
 ``query-block`` result field ``dirty-bitmaps`` (Since 4.2)
 ''
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index eeff82b5ec..47fdfe6f72 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -120,6 +120,13 @@ Removed with no replacement.
 
 Removed with no replacement.
 
+``query-named-block-nodes`` and ``query-block`` result dirty-bitmaps[i].status 
(removed in 6.0)
+'''
+
+The ``status`` field of the ``BlockDirtyInfo`` structure, returned by
+these commands is removed. Two new boolean fields, ``recording`` and
+``busy`` effectively replace it.
+
 Human Monitor Protocol (HMP) commands
 -
 
diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
index f581cf9fd7..40950ae3d5 100644
--- a/include/block/dirty-bitmap.h
+++ b/include/block/dirty

[Bug 1880518] Re: issue while installing docker inside s390x container

[Nayana]

Yes we have observed the issue with multiarch/qemu-user-static image
v5.2.0-1 and 5.2.0-2

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880518

Title:
  issue while installing docker inside s390x container

Status in QEMU:
  Incomplete

Bug description:
  This is in reference to 
https://github.com/multiarch/qemu-user-static/issues/108.
  I am facing issue while installing docker inside s390x container under qemu 
on Ubuntu 18.04 host running on amd64.
  Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel 
host after running 
  docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
  enabled
  interpreter /usr/bin/qemu-s390x-static
  flags: F
  offset 0
  magic 7f454c46020201020016
  mask ff00fffe
  I could get docker service up with the following trick. 
  printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > 
/etc/docker/daemon.json
  But even though docker service comes up, images are not getting pulled, 
docker pull fails with the following error.
  failed to register layer: Error processing tar file(exit status 1):

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1880518/+subscriptions

Re: [PATCH 0/2] *** This is based on pull request from Alex Bennée ***

[Yonggang Luo]

On Thu, Mar 18, 2021 at 8:50 AM Markus Armbruster  wrote:
>
> Please use the subject line for explaining the purpose of the series.
> "Based on" information should go into the body.  Ideally also in
> machine-readable form, like
>
> Based-on: <20171220185924.32756-1-arm...@redhat.com>
>
> where the thing in  is the pull request's Message-id.
>
> Note: I used one of my pull requests, not Alex's, for this example.
>
> Yonggang Luo  writes:
>
> > *** BLURB HERE ***
>
> Recommend to delete this placeholder next time :)
Thanks, i'll do it next time
>
> > The pull request
> > https://patchew.org/QEMU/20210317072216.16316-1-alex.ben...@linaro.org/
> >
> > Yonggang Luo (2):
> >   plugins: Update qemu-plugins.symbols to match qemu-plugins.h
> >   plugins: Move all typedef and type declaration to the front of the
> > qemu-plugin.h
> >
> >  include/qemu/qemu-plugin.h   | 187 +--
> >  plugins/qemu-plugins.symbols |  25 +++--
> >  2 files changed, 104 insertions(+), 108 deletions(-)
>


--
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Re: [PULL v3 00/42] Block layer patches and object-add QAPIfication

[Kevin Wolf]

Am 17.03.2021 um 22:01 hat Peter Maydell geschrieben:
> On Tue, 16 Mar 2021 at 18:12, Kevin Wolf  wrote:
> >
> > The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
> >
> >   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' 
> > into staging (2021-03-16 10:53:47 +)
> >
> > are available in the Git repository at:
> >
> >   git://repo.or.cz/qemu/kevin.git tags/for-upstream
> >
> > for you to fetch changes up to f5dda4c2186975ed75ec07b58bc6031e4867bb45:
> >
> >   vl: allow passing JSON to -object (2021-03-16 18:52:10 +0100)
> >
> > 
> > Block layer patches and object-add QAPIfication
> >
> > - QAPIfy object-add and --object
> > - stream: Fail gracefully if permission is denied
> > - storage-daemon: Fix crash on quit when job is still running
> > - curl: Fix use after free
> > - char: Deprecate backend aliases, fix QMP query-chardev-backends
> > - Fix image creation option defaults that exist in both the format and
> >   the protocol layer (e.g. 'cluster_size' in qcow2 and rbd; the qcow2
> >   default was incorrectly applied to the rbd layer)
> >
> > 
> 
> CONFLICT (content): Merge conflict in docs/system/deprecated.rst
> 
> Please fix up and resend.

Aaarrgh... I mean, the conflict resolution is trivial (we obviously want
both addititons), but I guess that means that the new pull request will
be last in the queue *again*.

Kevin

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Philippe Mathieu-Daudé]

Hi Peter,

On 3/11/21 11:43 AM, Claudio Fontana wrote:
> On 2/21/21 11:26 PM, Philippe Mathieu-Daudé wrote:
>> KVM requires the target cpu to be at least ARMv8 architecture
>> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
>> "target/arm: Remove KVM support for 32-bit Arm hosts").
>>
>> A KVM-only build won't be able to run TCG cpus, move the
>> v7A CPU definitions to cpu_tcg.c.
>>
>> Reported-by: Peter Maydell 
>> Reviewed-by: Peter Maydell 
>> Signed-off-by: Philippe Mathieu-Daudé 
> 
> 
> Here I think it's better to keep the "a15" cpu around,
> until we fix the board configuration situation.
> 
> I added a patch that does that into my KVM-only build series, to avoid the 
> resulting breakages.

Actually I got a downstream report that this break migration from QEMU
5.2 to QEMU 6.0.

I first thought it was on an old kernel (with 32-bit KVM enabled),
but not, it is for Aarch64 VMs on recent KVM (without 32-bit support)
but the 'virt' machines were started with default Cortex-A15 CPU...

mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");

I'm not sure upstream should care about this case, but I though
maybe you could give me hints about the best way to keep old VMs
working, as this likely affects any distribution. Obviously not
upgrading QEMU is not a solution :)

The simplest seems to revert 82bf7ae84ce and this patch, but I
doubt this will be enough.

Maybe there is some clever thing to do before reverting 82bf7ae84ce,
that could also benefit upstream, by doing something with versioned
machines? I have no idea (yet) how that work and if it could work.

Thanks,

Phil.

[PULL v4 00/42] Block layer patches and object-add QAPIfication

[Kevin Wolf]

The following changes since commit 571d413b5da6bc6f1c2aaca8484717642255ddb0:

  Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-20210316' 
into staging (2021-03-17 21:02:37 +)

are available in the Git repository at:

  git://repo.or.cz/qemu/kevin.git tags/for-upstream

for you to fetch changes up to ef11a2d8972147994492c36cd3d26677e831e4d7:

  vl: allow passing JSON to -object (2021-03-18 10:45:01 +0100)


Block layer patches and object-add QAPIfication

- QAPIfy object-add and --object
- stream: Fail gracefully if permission is denied
- storage-daemon: Fix crash on quit when job is still running
- curl: Fix use after free
- char: Deprecate backend aliases, fix QMP query-chardev-backends
- Fix image creation option defaults that exist in both the format and
  the protocol layer (e.g. 'cluster_size' in qcow2 and rbd; the qcow2
  default was incorrectly applied to the rbd layer)


Kevin Wolf (35):
  storage-daemon: Call job_cancel_sync_all() on shutdown
  stream: Don't crash when node permission is denied
  tests: Drop 'props' from object-add calls
  qapi/qom: Drop deprecated 'props' from object-add
  qapi/qom: Add ObjectOptions for iothread
  qapi/qom: Add ObjectOptions for authz-*
  qapi/qom: Add ObjectOptions for cryptodev-*
  qapi/qom: Add ObjectOptions for dbus-vmstate
  qapi/qom: Add ObjectOptions for memory-backend-*
  qapi/qom: Add ObjectOptions for rng-*, deprecate 'opened'
  qapi/qom: Add ObjectOptions for throttle-group
  qapi/qom: Add ObjectOptions for secret*, deprecate 'loaded'
  qapi/qom: Add ObjectOptions for tls-*, deprecate 'loaded'
  qapi/qom: Add ObjectOptions for can-*
  qapi/qom: Add ObjectOptions for colo-compare
  qapi/qom: Add ObjectOptions for filter-*
  qapi/qom: Add ObjectOptions for pr-manager-helper
  qapi/qom: Add ObjectOptions for confidential-guest-support
  qapi/qom: Add ObjectOptions for input-*
  qapi/qom: Add ObjectOptions for x-remote-object
  qapi/qom: QAPIfy object-add
  qom: Make "object" QemuOptsList optional
  qemu-storage-daemon: Implement --object with qmp_object_add()
  qom: Remove user_creatable_add_dict()
  qom: Factor out user_creatable_process_cmdline()
  qemu-io: Use user_creatable_process_cmdline() for --object
  qemu-nbd: Use user_creatable_process_cmdline() for --object
  qom: Add user_creatable_add_from_str()
  qemu-img: Use user_creatable_process_cmdline() for --object
  hmp: QAPIfy object_add
  qom: Add user_creatable_parse_str()
  char: Skip CLI aliases in query-chardev-backends
  char: Deprecate backend aliases 'tty' and 'parport'
  char: Simplify chardev_name_foreach()
  qom: Support JSON in HMP object_add and tools --object

Max Reitz (2):
  curl: Store BDRVCURLState pointer in CURLSocket
  curl: Disconnect sockets from CURLState

Paolo Bonzini (3):
  tests: convert check-qom-proplist to keyval
  qom: move user_creatable_add_opts logic to vl.c and QAPIfy it
  vl: allow passing JSON to -object

Stefan Hajnoczi (1):
  block/export: disable VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD for now

Stefano Garzarella (1):
  block: remove format defaults from QemuOpts in bdrv_create_file()

 qapi/authz.json   |  61 +++-
 qapi/block-core.json  |  27 ++
 qapi/common.json  |  52 +++
 qapi/crypto.json  | 159 +
 qapi/machine.json |  22 +-
 qapi/net.json |  20 --
 qapi/qom.json | 646 +-
 qapi/ui.json  |  13 +-
 docs/system/deprecated.rst|  31 +-
 docs/system/removed-features.rst  |   5 +
 docs/tools/qemu-img.rst   |   2 +-
 include/qom/object_interfaces.h   |  98 ++
 block.c   |  36 +-
 block/curl.c  |  50 +--
 block/export/vhost-user-blk-server.c  |   3 +-
 block/stream.c|  15 +-
 chardev/char.c|  19 +-
 hw/block/xen-block.c  |  16 +-
 monitor/hmp-cmds.c|  17 +-
 monitor/misc.c|   2 -
 qemu-img.c| 251 +++--
 qemu-io.c |  33 +-
 qemu-nbd.c|  34 +-
 qom/object_interfaces.c   | 172 -
 qom/qom-qmp-cmds.c|  28 +-
 softmmu/vl.c  |  84 -
 storage-daemon/qemu-storage-daemon.c  |  28 +-
 tests/qtest/qmp-cmd-test.c|  16 +-
 tests/qtest/test-netfilter.c  |  54 ++-
 tests/unit/check-qom-proplist.c   |  77 ++--
 tests/unit/test-char.c|   6 -
 hmp-commands.hx

RE: The windows guest can't bootup

[zhukeqian]

Hi,

Yep. It is known issue. Paolo will revert it.

Thanks.








Hello,

I synced today qemu code, and found the qemu can't bootup the windows guest.
This issue was caused by commit id 39205528 and revert this patch, the windows
guest can bootup.

qemu-system-x86_64: ../accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: 
Assertion `(((start | size) % (psize)) == 0)' failed.

I also enabled the vga device in the Linux guest, and same issue was found.

Regards,

Yang

Re: Serious doubts about Gitlab CI

[Philippe Mathieu-Daudé]

On 3/18/21 10:33 AM, Daniel P. Berrangé wrote:
> On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> For some (unclear) reason I got my free tier Gitlab account renewed and
>> lost the privilege for users opening account before the quota limit.
>>
>> I pushed a single branch to my namespace repo to trigger a pipeline.
>> 1h later I was surprised to see the pipeline was stuck, having completed
>> 99 jobs of 119. Looking closer there is a red comment on top of the
>> pipeline:
>>
>>  philmd has exceeded its pipeline minutes quota. Unless you buy
>>  additional pipeline minutes, no new jobs or pipelines in its projects
>>  will run. [Buy more Pipelines minutes]
>>
>> So I exhausted my 400 monthly minutes credit.
>>
>> From this FAQ:
>> https://about.gitlab.com/pricing/faq-consumption-cicd/#managing-your-cicd-minutes-usage
>>
>> Q. What happens if I hit the CI/CD Minutes allotted limit and forget to
>> purchase additional CI/CD Minutes?
>>
>> A. You will not be able to run new jobs until you purchase additional
>> CI/CD Minutes, or until the next month when you receive your monthly
>> allotted CI/CD Minutes.
>>
>> Q. Will I be notified before I hit my limit on CI/CD Minutes?
>>
>> A. You will receive notification banners in-app when your group has less
>> than 30%, 5% or exceeded your total allotted CI/CD minutes.
>>
>> I indeed received 3 warnings in 7 minutes.
>>
>> Now I'm having serious doubts about Gitlab usefulness for the QEMU
>> community...
> 
> Per the discussions in the related Forum postings about CI limites, the
> 400 minute limit is still only intended to apply to projects that are
> marked as private.  Public projects are not even being tracked for
> accounting, let alone have a limit enforced. They also said they want
> to make sure they don't impact ability of users to contribute to OSS
> projects hosted on GitLab that require use of CI.
> 
> It feels like what you hit here is fallout from your account accidentally
> getting blocked, rather than something which is hitting every contributor
> to QEMU. Did they restore projects as private perhaps ?

Yes my repository was restored as private and I had to switch it to
public. I'll try to blew everything (after backing it up) and recreate
it as public from start, and see if I get the unlimited minutes back.

Thanks,

Phil.

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Laurent Vivier]

Le 18/03/2021 à 10:19, Philippe Mathieu-Daudé a écrit :
> Hi Laurent,
> 
> +Paolo / Thomas
> 
> On 3/15/21 9:42 PM, Laurent Vivier wrote:
>> The machine is based on Goldfish interfaces defined by Google
>> for Android simulator. It uses Goldfish-rtc (timer and RTC),
>> Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).
>>
>> The machine is created with 128 virtio-mmio bus, and they can
>> be used to use serial console, GPU, disk, NIC, HID, ...
>>
>> Signed-off-by: Laurent Vivier 
>> Reviewed-by: Richard Henderson 
>> Tested-by: Philippe Mathieu-Daudé 
>> Message-Id: <20210312214145.2936082-6-laur...@vivier.eu>
>> ---
>>  default-configs/devices/m68k-softmmu.mak  |   1 +
>>  .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
>>  hw/m68k/virt.c| 313 ++
>>  MAINTAINERS   |  13 +
>>  hw/m68k/Kconfig   |   9 +
>>  hw/m68k/meson.build   |   1 +
>>  6 files changed, 355 insertions(+)
>>  create mode 100644 include/standard-headers/asm-m68k/bootinfo-virt.h
>>  create mode 100644 hw/m68k/virt.c
> 
>> diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
>> index 60d7bcfb8f2b..f839f8a03064 100644
>> --- a/hw/m68k/Kconfig
>> +++ b/hw/m68k/Kconfig
>> @@ -23,3 +23,12 @@ config Q800
>>  select ESP
>>  select DP8393X
>>  select OR_IRQ
>> +
>> +config M68K_VIRT
>> +bool
>> +select M68K_IRQC
>> +select VIRT_CTRL
>> +select GOLDFISH_PIC
>> +select GOLDFISH_TTY
>> +select GOLDFISH_RTC
>> +select VIRTIO_MMIO
> 
> I had this error on gitlab:
> 
> (qemu) QEMU_PROG: -drive driver=IMGFMT,file=TEST_DIR/t.IMGFMT,if=virtio:
> 'virtio-blk-pci' is not a valid device model name
> job: check-system-fedora
> https://gitlab.com/philmd/qemu/-/jobs/1106469724
> 
> I bisected locally to this commit.
> 
> check-system-fedora uses build-system-fedora:
> 
> build-system-fedora:
> CONFIGURE_ARGS: --disable-gcrypt --enable-nettle --enable-docs
>  --enable-fdt=system --enable-slirp=system
>  --enable-capstone=system
> 
> I'm confused because the machine provides a VIRTIO bus
> via MMIO:
> 
> config VIRTIO_MMIO
> bool
> select VIRTIO
> 
> I remember I tested your machine with virtio-blk-device.
> 
> config VIRTIO_BLK
> bool
> default y
> depends on VIRTIO
> 
> Ah, this is virtio-blk-pci, which has:
> 
> virtio_pci_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true:
> files('virtio-blk-pci.c'))
> virtio_ss.add_all(when: 'CONFIG_VIRTIO_PCI', if_true: virtio_pci_ss)
> 
> And VIRTIO_PCI isn't selected...

This machine doesn't have virtio-pci, but only virtio-mmio buses.

> Are the tests incorrect then?
> 
> libqos isn't restricted to PCI:
> 
> tests/qtest/libqos/virtio-blk.c:24:#include "virtio-blk.h"
> tests/qtest/libqos/virtio-blk.c:29:/* virtio-blk-device */
> tests/qtest/libqos/virtio-blk.c:33:if (!g_strcmp0(interface,
> "virtio-blk")) {
> tests/qtest/libqos/virtio-blk.c:40:fprintf(stderr, "%s not present
> in virtio-blk-device\n", interface);
> tests/qtest/libqos/virtio-blk.c:109:/* virtio-blk-device */
> tests/qtest/libqos/virtio-blk.c:111:
> qos_node_create_driver("virtio-blk-device", virtio_blk_device_create);
> tests/qtest/libqos/virtio-blk.c:112:
> qos_node_consumes("virtio-blk-device", "virtio-bus", &opts);
> tests/qtest/libqos/virtio-blk.c:113:
> qos_node_produces("virtio-blk-device", "virtio-blk");
> 
> But qemu-iotests / qtests do use virtio-blk-pci. Maybe they should
> use a generic virtio-blk-device instead, hoping it get plugged correctly
> to the virtio bus...

Yes, it's how the machine work: it has 128 virtio-mmio buses and virtio-devices 
are plugged directly
in the first free ones.

I think the fix would be to disable the virtio-blk-pci test for the machines 
without PCI bus.

Why is it executed for now?

Thanks,
Laurent

Re: of AVR target page size

[Dr. David Alan Gilbert]

* Michael Rolnik (mrol...@gmail.com) wrote:
> Hi Dave.
> 
> What is the smallest supported page size?

Currently 512 I think; in migration/ram.c we have:

#define RAM_SAVE_FLAG_FULL 0x01 /* Obsolete, not used anymore */
#define RAM_SAVE_FLAG_ZERO 0x02
#define RAM_SAVE_FLAG_MEM_SIZE 0x04
#define RAM_SAVE_FLAG_PAGE 0x08
#define RAM_SAVE_FLAG_EOS  0x10
#define RAM_SAVE_FLAG_CONTINUE 0x20
#define RAM_SAVE_FLAG_XBZRLE   0x40
/* 0x80 is reserved in migration.h start with 0x100 next */
#define RAM_SAVE_FLAG_COMPRESS_PAGE0x100

so we're already using the 0x100 (256) flag.

I spotted this yesterday because a patch tried to use the 0x200 flag.

Dave
> 
> On Wed, Mar 17, 2021 at 10:14 PM Dr. David Alan Gilbert 
> wrote:
> 
> > Hi Michael,
> >   I noticed your AVR code defines:
> >
> >   #define TARGET_PAGE_BITS 8
> >
> > and has an explanation of why.
> >
> > Note however that's not going to work with the current live
> > migration/snapshotting code, since you're a couple of bits smaller
> > than the smallest page size we had so far, and for many years
> > the RAM migration code has stolen the bottom few bits of the address
> > as a flag field, and has already used 0x100 up; see migration/ram.c
> > RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> > you change it then it'll break migration compatibility with existing
> > qemu's.
> >
> > Hmm.
> >
> > Dave
> >
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> >
> >
> 
> -- 
> Best Regards,
> Michael Rolnik
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [RFC v2 11/13] vhost: Shadow virtqueue buffers forwarding

[Eugenio Perez Martin]

On Thu, Mar 18, 2021 at 10:22 AM Jason Wang  wrote:
>
>
> 在 2021/3/18 下午4:06, Eugenio Perez Martin 写道:
> > On Thu, Mar 18, 2021 at 4:14 AM Jason Wang  wrote:
> >>
> >> 在 2021/3/17 下午10:38, Eugenio Perez Martin 写道:
> >>> On Wed, Mar 17, 2021 at 3:51 AM Jason Wang  wrote:
>  在 2021/3/17 上午12:05, Eugenio Perez Martin 写道:
> > On Tue, Mar 16, 2021 at 9:15 AM Jason Wang  wrote:
> >> 在 2021/3/16 上午3:48, Eugenio Pérez 写道:
> >>> Initial version of shadow virtqueue that actually forward buffers.
> >>>
> >>> It reuses the VirtQueue code for the device part. The driver part is
> >>> based on Linux's virtio_ring driver, but with stripped functionality
> >>> and optimizations so it's easier to review.
> >>>
> >>> These will be added in later commits.
> >>>
> >>> Signed-off-by: Eugenio Pérez 
> >>> ---
> >>>  hw/virtio/vhost-shadow-virtqueue.c | 212 
> >>> +++--
> >>>  hw/virtio/vhost.c  | 113 ++-
> >>>  2 files changed, 312 insertions(+), 13 deletions(-)
> >>>
> >>> diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> >>> b/hw/virtio/vhost-shadow-virtqueue.c
> >>> index 1460d1d5d1..68ed0f2740 100644
> >>> --- a/hw/virtio/vhost-shadow-virtqueue.c
> >>> +++ b/hw/virtio/vhost-shadow-virtqueue.c
> >>> @@ -9,6 +9,7 @@
> >>>
> >>>  #include "hw/virtio/vhost-shadow-virtqueue.h"
> >>>  #include "hw/virtio/vhost.h"
> >>> +#include "hw/virtio/virtio-access.h"
> >>>
> >>>  #include "standard-headers/linux/vhost_types.h"
> >>>
> >>> @@ -55,11 +56,96 @@ typedef struct VhostShadowVirtqueue {
> >>>  /* Virtio device */
> >>>  VirtIODevice *vdev;
> >>>
> >>> +/* Map for returning guest's descriptors */
> >>> +VirtQueueElement **ring_id_maps;
> >>> +
> >>> +/* Next head to expose to device */
> >>> +uint16_t avail_idx_shadow;
> >>> +
> >>> +/* Next free descriptor */
> >>> +uint16_t free_head;
> >>> +
> >>> +/* Last seen used idx */
> >>> +uint16_t shadow_used_idx;
> >>> +
> >>> +/* Next head to consume from device */
> >>> +uint16_t used_idx;
> >>> +
> >>>  /* Descriptors copied from guest */
> >>>  vring_desc_t descs[];
> >>>  } VhostShadowVirtqueue;
> >>>
> >>> -/* Forward guest notifications */
> >>> +static void vhost_vring_write_descs(VhostShadowVirtqueue *svq,
> >>> +const struct iovec *iovec,
> >>> +size_t num, bool more_descs, 
> >>> bool write)
> >>> +{
> >>> +uint16_t i = svq->free_head, last = svq->free_head;
> >>> +unsigned n;
> >>> +uint16_t flags = write ? virtio_tswap16(svq->vdev, 
> >>> VRING_DESC_F_WRITE) : 0;
> >>> +vring_desc_t *descs = svq->vring.desc;
> >>> +
> >>> +if (num == 0) {
> >>> +return;
> >>> +}
> >>> +
> >>> +for (n = 0; n < num; n++) {
> >>> +if (more_descs || (n + 1 < num)) {
> >>> +descs[i].flags = flags | virtio_tswap16(svq->vdev,
> >>> +
> >>> VRING_DESC_F_NEXT);
> >>> +} else {
> >>> +descs[i].flags = flags;
> >>> +}
> >>> +descs[i].addr = virtio_tswap64(svq->vdev, 
> >>> (hwaddr)iovec[n].iov_base);
> >> So unsing virtio_tswap() is probably not correct since we're talking
> >> with vhost backends which has its own endiness.
> >>
> > I was trying to expose the buffer with the same endianness as the
> > driver originally offered, so if guest->qemu requires a bswap, I think
> > it will always require a bswap again to expose to the device again.
>  So assumes vhost-vDPA always provide a non-transitional device[1].
> 
>  Then if Qemu present a transitional device, we need to do the endian
>  conversion when necessary, if Qemu present a non-transitional device, we
>  don't need to do that, guest driver will do that for us.
> 
>  But it looks to me the virtio_tswap() can't be used for this since it:
> 
>  static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
>  {
>  #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> return virtio_is_big_endian(vdev);
>  #elif defined(TARGET_WORDS_BIGENDIAN)
> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> /* Devices conforming to VIRTIO 1.0 or later are always LE. */
> return false;
> }
> return true;
>  #else
> return false;
>  #endif
>  }
> 
>  So if we present a legacy device on top of a non-transitiaonl vDPA
>  device. The VIRITIO_F_VERSION_1 check is wrong.
> 
> 
> >> For vhost-vDPA,

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Claudio Fontana]

On 3/18/21 10:47 AM, Philippe Mathieu-Daudé wrote:
> Hi Peter,
> 
> On 3/11/21 11:43 AM, Claudio Fontana wrote:
>> On 2/21/21 11:26 PM, Philippe Mathieu-Daudé wrote:
>>> KVM requires the target cpu to be at least ARMv8 architecture
>>> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
>>> "target/arm: Remove KVM support for 32-bit Arm hosts").
>>>
>>> A KVM-only build won't be able to run TCG cpus, move the
>>> v7A CPU definitions to cpu_tcg.c.
>>>
>>> Reported-by: Peter Maydell 
>>> Reviewed-by: Peter Maydell 
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>
>>
>> Here I think it's better to keep the "a15" cpu around,
>> until we fix the board configuration situation.
>>
>> I added a patch that does that into my KVM-only build series, to avoid the 
>> resulting breakages.
> 
> Actually I got a downstream report that this break migration from QEMU
> 5.2 to QEMU 6.0.
> 
> I first thought it was on an old kernel (with 32-bit KVM enabled),
> but not, it is for Aarch64 VMs on recent KVM (without 32-bit support)
> but the 'virt' machines were started with default Cortex-A15 CPU...
> 
> mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
> 
> I'm not sure upstream should care about this case, but I though
> maybe you could give me hints about the best way to keep old VMs
> working, as this likely affects any distribution. Obviously not
> upgrading QEMU is not a solution :)
> 
> The simplest seems to revert 82bf7ae84ce and this patch, but I
> doubt this will be enough.
> 
> Maybe there is some clever thing to do before reverting 82bf7ae84ce,
> that could also benefit upstream, by doing something with versioned
> machines? I have no idea (yet) how that work and if it could work.

Does just applying my series fix it?

https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06463.html

Ie, I have resurrected specifically the a15 to keep things working for "virt".

Patch 22/50. Maybe I am missing something though?

https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06494.html

Ciao,

Claudio

Re: [PATCH 2/2] qemu-img: align next status sector on destination alignment.

[Maxim Levitsky]

On Thu, 2020-11-12 at 17:04 +0200, Maxim Levitsky wrote:
> On Thu, 2020-11-12 at 07:45 -0600, Eric Blake wrote:
> > On 11/12/20 6:40 AM, Peter Lieven wrote:
> > 
> > > >  /*
> > > > - * Avoid that s->sector_next_status becomes unaligned to the 
> > > > source
> > > > - * request alignment and/or cluster size to avoid unnecessary 
> > > > read
> > > > - * cycles.
> > > > + * Avoid that s->sector_next_status becomes unaligned to the
> > > > + * source/destination request alignment and/or cluster size to 
> > > > avoid
> > > > + * unnecessary read/write cycles.
> > > >   */
> > > > -tail = (sector_num - src_cur_offset + n) % 
> > > > s->src_alignment[src_cur];
> > > > +alignment = MAX(s->src_alignment[src_cur], s->alignment);
> > > > +assert(is_power_of_2(alignment));
> > > > +
> > > > +tail = (sector_num - src_cur_offset + n) % alignment;
> > > >  if (n > tail) {
> > > >  n -= tail;
> > > >  }
> > > 
> > > I was also considering including the s->alignment when adding this 
> > > chance. However, you need the least common multiple of both alignments, 
> > > not the maximum, otherwise
> > > 
> > > you might get misaligned to either source or destination.
> > > 
> > > 
> > > Why exactly do you need the power of two requirement?
> > 
> > The power of two requirement ensures that you h ave the least common
> > multiple of both alignments ;)
> -
> Yes, and in addition to that both alignments are already power of two because 
> we align them
> to it. The assert I added is just in case.
> 
> This is how we calculate the destination alignment:
>  
> s.alignment = MAX(pow2floor(s.min_sparse),
>   DIV_ROUND_UP(out_bs->bl.request_alignment,
>BDRV_SECTOR_SIZE));
>  
>  
> This is how we calculate the source alignments (it is possible to have 
> several source files)
>  
> s.src_alignment[bs_i] = DIV_ROUND_UP(src_bs->bl.request_alignment,
>  BDRV_SECTOR_SIZE);
> if (!bdrv_get_info(src_bs, &bdi)) {
> s.src_alignment[bs_i] = MAX(s.src_alignment[bs_i], bdi.cluster_size / 
> BDRV_SECTOR_SIZE);
> }
> 
> 
> The bl.request_alignment comment mentions that it must be power of 2,
> and cluster sizes are also very likely to be power of 2 in all drivers
> we support. An assert for s.src_alignment won't hurt though.
> 
>  
> Note though that we don't really read the discard alignment.
> We have max_pdiscard, and pdiscard_alignment, but max_pdiscard
> is only used to split 'too large' discard requests, and pdiscard_alignment
> is advisory and used only in a couple of places.
> Neither are set by file-posix.
>  
> We do have request_alignment, which file-posix tries to align to the logical 
> block
> size which is still often 512 for backward compatibility on many devices 
> (even nvme)
>  
> Now both source and destination alignments in qemu-img convert are based on 
> request_aligment
> and on min_sparse (which is by default 4K, controlled by qemu-img -S parameter
> (which otherwise controls the minimum number of blocks to be zero, to consider
> discarding them in convert)
>  
> 
> This means that there is no guarantee to have 4K alignment, and besides,
> with sufficiently fragmented source file, the bdrv_block_status_above
> can return arbitrary short and unaligned extents which can't be aligned, 
> thus as I said this patch alone can't guarantee that we won't have 
> write and discard sharing the same page.
>  
> Another thing that can be discussed is why is_allocated_sectors was patched
> to convert short discards to writes. Probably because underlying hardware
> ignores them or something? In theory we should detect this and fail
> back to regular zeroing in this case.
> Again though, while in case of converting an empty file, this is the only
> source of writes, and eliminating it, also 'fixes' this case, with 
> sufficiently
> fragmented source file we can even without this code get a write and discard
> sharing a page.
> 
> 
> Best regards,
>   Maxim Levitsky
> 
> > However, there ARE devices in practice that have advertised a
> > non-power-of-2 discard granularity, such as 15MiB (see commits 430b26a8,
> > 63188c24).  Which means you probably don't want to assert power-of-2,
> > and in turn need to worry about least common multiple.
> > 

Any update on this patch?

Best regards,
Maxim Levitsky

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Philippe Mathieu-Daudé]

On 3/18/21 10:52 AM, Laurent Vivier wrote:
> Le 18/03/2021 à 10:19, Philippe Mathieu-Daudé a écrit :
>> Hi Laurent,
>>
>> +Paolo / Thomas
>>
>> On 3/15/21 9:42 PM, Laurent Vivier wrote:
>>> The machine is based on Goldfish interfaces defined by Google
>>> for Android simulator. It uses Goldfish-rtc (timer and RTC),
>>> Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).
>>>
>>> The machine is created with 128 virtio-mmio bus, and they can
>>> be used to use serial console, GPU, disk, NIC, HID, ...
>>>
>>> Signed-off-by: Laurent Vivier 
>>> Reviewed-by: Richard Henderson 
>>> Tested-by: Philippe Mathieu-Daudé 
>>> Message-Id: <20210312214145.2936082-6-laur...@vivier.eu>
>>> ---
>>>  default-configs/devices/m68k-softmmu.mak  |   1 +
>>>  .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
>>>  hw/m68k/virt.c| 313 ++
>>>  MAINTAINERS   |  13 +
>>>  hw/m68k/Kconfig   |   9 +
>>>  hw/m68k/meson.build   |   1 +
>>>  6 files changed, 355 insertions(+)
>>>  create mode 100644 include/standard-headers/asm-m68k/bootinfo-virt.h
>>>  create mode 100644 hw/m68k/virt.c
>>
>>> diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
>>> index 60d7bcfb8f2b..f839f8a03064 100644
>>> --- a/hw/m68k/Kconfig
>>> +++ b/hw/m68k/Kconfig
>>> @@ -23,3 +23,12 @@ config Q800
>>>  select ESP
>>>  select DP8393X
>>>  select OR_IRQ
>>> +
>>> +config M68K_VIRT
>>> +bool
>>> +select M68K_IRQC
>>> +select VIRT_CTRL
>>> +select GOLDFISH_PIC
>>> +select GOLDFISH_TTY
>>> +select GOLDFISH_RTC
>>> +select VIRTIO_MMIO
>>
>> I had this error on gitlab:
>>
>> (qemu) QEMU_PROG: -drive driver=IMGFMT,file=TEST_DIR/t.IMGFMT,if=virtio:
>> 'virtio-blk-pci' is not a valid device model name
>> job: check-system-fedora
>> https://gitlab.com/philmd/qemu/-/jobs/1106469724
>>
>> I bisected locally to this commit.
>>
>> check-system-fedora uses build-system-fedora:
>>
>> build-system-fedora:
>> CONFIGURE_ARGS: --disable-gcrypt --enable-nettle --enable-docs
>>  --enable-fdt=system --enable-slirp=system
>>  --enable-capstone=system
>>
>> I'm confused because the machine provides a VIRTIO bus
>> via MMIO:
>>
>> config VIRTIO_MMIO
>> bool
>> select VIRTIO
>>
>> I remember I tested your machine with virtio-blk-device.
>>
>> config VIRTIO_BLK
>> bool
>> default y
>> depends on VIRTIO
>>
>> Ah, this is virtio-blk-pci, which has:
>>
>> virtio_pci_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true:
>> files('virtio-blk-pci.c'))
>> virtio_ss.add_all(when: 'CONFIG_VIRTIO_PCI', if_true: virtio_pci_ss)
>>
>> And VIRTIO_PCI isn't selected...
> 
> This machine doesn't have virtio-pci, but only virtio-mmio buses.

Yes. I meant "VIRTIO_PCI isn't selected, which is the correct config
for this machine". So the problem isn't the m68k-virt machine addition,
but it shows another problem elsewhere.

>> Are the tests incorrect then?
>>
>> libqos isn't restricted to PCI:
>>
>> tests/qtest/libqos/virtio-blk.c:24:#include "virtio-blk.h"
>> tests/qtest/libqos/virtio-blk.c:29:/* virtio-blk-device */
>> tests/qtest/libqos/virtio-blk.c:33:if (!g_strcmp0(interface,
>> "virtio-blk")) {
>> tests/qtest/libqos/virtio-blk.c:40:fprintf(stderr, "%s not present
>> in virtio-blk-device\n", interface);
>> tests/qtest/libqos/virtio-blk.c:109:/* virtio-blk-device */
>> tests/qtest/libqos/virtio-blk.c:111:
>> qos_node_create_driver("virtio-blk-device", virtio_blk_device_create);
>> tests/qtest/libqos/virtio-blk.c:112:
>> qos_node_consumes("virtio-blk-device", "virtio-bus", &opts);
>> tests/qtest/libqos/virtio-blk.c:113:
>> qos_node_produces("virtio-blk-device", "virtio-blk");
>>
>> But qemu-iotests / qtests do use virtio-blk-pci. Maybe they should
>> use a generic virtio-blk-device instead, hoping it get plugged correctly
>> to the virtio bus...
> 
> Yes, it's how the machine work: it has 128 virtio-mmio buses and 
> virtio-devices are plugged directly
> in the first free ones.
> 
> I think the fix would be to disable the virtio-blk-pci test for the machines 
> without PCI bus.
> 
> Why is it executed for now?

This is probably the problem root cause.

Possible fix:

-->8 --
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 66ee9fbf450..d7f3fad51c1 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -217,13 +217,17 @@
   'emc141x-test.c',
   'usb-hcd-ohci-test.c',
   'virtio-test.c',
-  'virtio-blk-test.c',
-  'virtio-net-test.c',
-  'virtio-rng-test.c',
-  'virtio-scsi-test.c',
   'virtio-serial-test.c',
   'vmxnet3-test.c',
 )
+if config_all_devices.has_key('CONFIG_VIRTIO_PCI')
+  qos_test_ss.add(
+'virtio-blk-test.c',
+'virtio-net-test.c',
+'virtio-rng-test.c',
+'virtio-scsi-test.c',
+  )
+endif
 if have_virtfs
   qos_test_ss.add(files('virtio-9p-test.c'))
 endif
---

I'll test that locally but not on Gitlab.

Thanks,

Re: "make check" broken with everything but tools disabled

[Paolo Bonzini]

On 18/03/21 10:16, Claudio Fontana wrote:

my experience with the new build system (meson-based), is that I have to do:

make

first, and then

make check

later, or bugs start happening


This shouldn't be needed.

Paolo

Re: [PULL 00/16] Fuzzing + bugfix patches for QEMU 6.0 soft freeze

[Peter Maydell]

On Tue, 16 Mar 2021 at 21:18, Paolo Bonzini  wrote:
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 8b858f9998a9d59a9a7188f2c5c6ffb99eff6115:
>
>   qemu-timer: allow freeing a NULL timer (2021-03-16 14:30:30 -0400)
>
> 
> * add --enable/--disable-libgio to configure (Denis)
> * small fixes (Pavel, myself)
> * fuzzing update (Alexander)
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Laurent Vivier]

Le 18/03/2021 à 11:02, Philippe Mathieu-Daudé a écrit :
> On 3/18/21 10:52 AM, Laurent Vivier wrote:
>> Le 18/03/2021 à 10:19, Philippe Mathieu-Daudé a écrit :
>>> Hi Laurent,
>>>
>>> +Paolo / Thomas
>>>
>>> On 3/15/21 9:42 PM, Laurent Vivier wrote:
 The machine is based on Goldfish interfaces defined by Google
 for Android simulator. It uses Goldfish-rtc (timer and RTC),
 Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).

 The machine is created with 128 virtio-mmio bus, and they can
 be used to use serial console, GPU, disk, NIC, HID, ...

 Signed-off-by: Laurent Vivier 
 Reviewed-by: Richard Henderson 
 Tested-by: Philippe Mathieu-Daudé 
 Message-Id: <20210312214145.2936082-6-laur...@vivier.eu>
 ---
  default-configs/devices/m68k-softmmu.mak  |   1 +
  .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
  hw/m68k/virt.c| 313 ++
  MAINTAINERS   |  13 +
  hw/m68k/Kconfig   |   9 +
  hw/m68k/meson.build   |   1 +
  6 files changed, 355 insertions(+)
  create mode 100644 include/standard-headers/asm-m68k/bootinfo-virt.h
  create mode 100644 hw/m68k/virt.c
>>>
 diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
 index 60d7bcfb8f2b..f839f8a03064 100644
 --- a/hw/m68k/Kconfig
 +++ b/hw/m68k/Kconfig
 @@ -23,3 +23,12 @@ config Q800
  select ESP
  select DP8393X
  select OR_IRQ
 +
 +config M68K_VIRT
 +bool
 +select M68K_IRQC
 +select VIRT_CTRL
 +select GOLDFISH_PIC
 +select GOLDFISH_TTY
 +select GOLDFISH_RTC
 +select VIRTIO_MMIO
>>>
>>> I had this error on gitlab:
>>>
>>> (qemu) QEMU_PROG: -drive driver=IMGFMT,file=TEST_DIR/t.IMGFMT,if=virtio:
>>> 'virtio-blk-pci' is not a valid device model name
>>> job: check-system-fedora
>>> https://gitlab.com/philmd/qemu/-/jobs/1106469724
>>>
>>> I bisected locally to this commit.
>>>
>>> check-system-fedora uses build-system-fedora:
>>>
>>> build-system-fedora:
>>> CONFIGURE_ARGS: --disable-gcrypt --enable-nettle --enable-docs
>>>  --enable-fdt=system --enable-slirp=system
>>>  --enable-capstone=system
>>>
>>> I'm confused because the machine provides a VIRTIO bus
>>> via MMIO:
>>>
>>> config VIRTIO_MMIO
>>> bool
>>> select VIRTIO
>>>
>>> I remember I tested your machine with virtio-blk-device.
>>>
>>> config VIRTIO_BLK
>>> bool
>>> default y
>>> depends on VIRTIO
>>>
>>> Ah, this is virtio-blk-pci, which has:
>>>
>>> virtio_pci_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true:
>>> files('virtio-blk-pci.c'))
>>> virtio_ss.add_all(when: 'CONFIG_VIRTIO_PCI', if_true: virtio_pci_ss)
>>>
>>> And VIRTIO_PCI isn't selected...
>>
>> This machine doesn't have virtio-pci, but only virtio-mmio buses.
> 
> Yes. I meant "VIRTIO_PCI isn't selected, which is the correct config
> for this machine". So the problem isn't the m68k-virt machine addition,
> but it shows another problem elsewhere.
> 
>>> Are the tests incorrect then?
>>>
>>> libqos isn't restricted to PCI:
>>>
>>> tests/qtest/libqos/virtio-blk.c:24:#include "virtio-blk.h"
>>> tests/qtest/libqos/virtio-blk.c:29:/* virtio-blk-device */
>>> tests/qtest/libqos/virtio-blk.c:33:if (!g_strcmp0(interface,
>>> "virtio-blk")) {
>>> tests/qtest/libqos/virtio-blk.c:40:fprintf(stderr, "%s not present
>>> in virtio-blk-device\n", interface);
>>> tests/qtest/libqos/virtio-blk.c:109:/* virtio-blk-device */
>>> tests/qtest/libqos/virtio-blk.c:111:
>>> qos_node_create_driver("virtio-blk-device", virtio_blk_device_create);
>>> tests/qtest/libqos/virtio-blk.c:112:
>>> qos_node_consumes("virtio-blk-device", "virtio-bus", &opts);
>>> tests/qtest/libqos/virtio-blk.c:113:
>>> qos_node_produces("virtio-blk-device", "virtio-blk");
>>>
>>> But qemu-iotests / qtests do use virtio-blk-pci. Maybe they should
>>> use a generic virtio-blk-device instead, hoping it get plugged correctly
>>> to the virtio bus...
>>
>> Yes, it's how the machine work: it has 128 virtio-mmio buses and 
>> virtio-devices are plugged directly
>> in the first free ones.
>>
>> I think the fix would be to disable the virtio-blk-pci test for the machines 
>> without PCI bus.
>>
>> Why is it executed for now?
> 
> This is probably the problem root cause.
> 
> Possible fix:
> 
> -->8 --
> diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
> index 66ee9fbf450..d7f3fad51c1 100644
> --- a/tests/qtest/meson.build
> +++ b/tests/qtest/meson.build
> @@ -217,13 +217,17 @@
>'emc141x-test.c',
>'usb-hcd-ohci-test.c',
>'virtio-test.c',
> -  'virtio-blk-test.c',
> -  'virtio-net-test.c',
> -  'virtio-rng-test.c',
> -  'virtio-scsi-test.c',
>'virtio-serial-test.c',
>'vmxnet3-test.c',
>  )
> +if config_all_devices.has_key('CONFIG_VIRTIO_PCI')
> +  qos_test_ss.add(
> +'virtio-bl

Re: iotests failing on gitlab CI check-system-fedora job

[Peter Maydell]

On Wed, 17 Mar 2021 at 23:26, Paolo Bonzini  wrote:
>
> On 17/03/21 23:23, Peter Maydell wrote:
> > The check-system-fedora job in the gitlab CI seems to have
> > started reliably failing on iotests 040 041 127 256 267:
> >   https://gitlab.com/qemu-project/qemu/-/jobs/1106977551
> >
> > Could somebody have a look at what's happening, please?
> > (This is probably a regression that's got into master because
> > I stopped using "did gitlab CI pass" as a gate because gitlab
> > was running massively too slowly to be usable for that.)
>
> It's caused by adding virtio devices to the m68k target.  Probably it
> can be fixed by moving i386-softmmu to Fedora and m68k-softmmu to Debian.

Why are the iotests not specifying what machine type they run
on if they care about the machine type ?

thanks
-- PMM

[PATCH] tools/virtiofsd: include --socket-group in help

[Alex Bennée]

I confused myself wandering if this had been merged by looking at the
help output. It seems fuse_opt doesn't automagically add to help
output so lets do it now.

Updates: f6698f2b03 ("tools/virtiofsd: add support for --socket-group")
Signed-off-by: Alex Bennée 
---
 tools/virtiofsd/fuse_lowlevel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/virtiofsd/fuse_lowlevel.c b/tools/virtiofsd/fuse_lowlevel.c
index 1aa26c6333..58e32fc963 100644
--- a/tools/virtiofsd/fuse_lowlevel.c
+++ b/tools/virtiofsd/fuse_lowlevel.c
@@ -2450,6 +2450,7 @@ void fuse_lowlevel_help(void)
 printf(
 "-o allow_root  allow access by root\n"
 "--socket-path=PATH path for the vhost-user socket\n"
+"--socket-group=GRNAME  name of group for the vhost-user 
socket\n"
 "--fd=FDNUM fd number of vhost-user socket\n"
 "--thread-pool-size=NUM thread pool size limit (default %d)\n",
 THREAD_POOL_SIZE);
-- 
2.20.1

[Bug 1879531] Re: Stack-overflow in _eth_get_rss_ex_dst_addr

[Paolo Bonzini]

Updated version: https://www.mail-archive.com/qemu-
de...@nongnu.org/msg789998.html

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879531

Title:
  Stack-overflow in _eth_get_rss_ex_dst_addr

Status in QEMU:
  New

Bug description:
  Hello,
  While fuzzing, I found a 1-byte stack-overflow (read) through the
  e1000e. 

  ==10318==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ffdb76c16c2 at pc 0x55594f1a69e1 bp 0x7ffdb76c15a0 sp 0x7ffdb76c1598
  READ of size 1 at 0x7ffdb76c16c2 thread T0
  #0 0x55594f1a69e0 in _eth_get_rss_ex_dst_addr 
/home/alxndr/Development/qemu/net/eth.c:410:17
  #1 0x55594f1a39da in eth_parse_ipv6_hdr 
/home/alxndr/Development/qemu/net/eth.c:532:17
  #2 0x55594ebc34f2 in net_tx_pkt_parse_headers 
/home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:228:14
  #3 0x55594ebc2149 in net_tx_pkt_parse 
/home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:273:9
  #4 0x55594ec1ba76 in e1000e_process_tx_desc 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:737:29
  #5 0x55594ec1aea4 in e1000e_start_xmit 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
  #6 0x55594ec0e70e in e1000e_set_tdt 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
  #7 0x55594ebec435 in e1000e_core_write 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9
  #8 0x55594ebdf11b in e1000e_mmio_write 
/home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
  #9 0x55594dfd98b1 in memory_region_write_accessor 
/home/alxndr/Development/qemu/memory.c:483:5
  #10 0x55594dfd9211 in access_with_adjusted_size 
/home/alxndr/Development/qemu/memory.c:544:18
  #11 0x55594dfd7c30 in memory_region_dispatch_write 
/home/alxndr/Development/qemu/memory.c:1476:16
  #12 0x55594dde24b8 in flatview_write_continue 
/home/alxndr/Development/qemu/exec.c:3137:23
  #13 0x55594ddd12dc in flatview_write 
/home/alxndr/Development/qemu/exec.c:3177:14
  #14 0x55594ddd0dec in address_space_write 
/home/alxndr/Development/qemu/exec.c:3268:18
  #15 0x55594dfcdbdc in qtest_process_command 
/home/alxndr/Development/qemu/qtest.c:567:9
  #16 0x55594dfc3700 in qtest_process_inbuf 
/home/alxndr/Development/qemu/qtest.c:710:9
  #17 0x55594dfc2cc8 in qtest_read 
/home/alxndr/Development/qemu/qtest.c:722:5
  #18 0x55594f74b259 in qemu_chr_be_write_impl 
/home/alxndr/Development/qemu/chardev/char.c:183:9
  #19 0x55594f74b3ee in qemu_chr_be_write 
/home/alxndr/Development/qemu/chardev/char.c:195:9
  #20 0x55594f7556fc in fd_chr_read 
/home/alxndr/Development/qemu/chardev/char-fd.c:68:9
  #21 0x55594f7ea488 in qio_channel_fd_source_dispatch 
/home/alxndr/Development/qemu/io/channel-watch.c:84:12
  #22 0x7f43f6c1d897 in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
  #23 0x55594f9dea5d in glib_pollfds_poll 
/home/alxndr/Development/qemu/util/main-loop.c:219:9
  #24 0x55594f9dd1d7 in os_host_main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:242:5
  #25 0x55594f9dcd6e in main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:518:11
  #26 0x55594e44cd01 in qemu_main_loop 
/home/alxndr/Development/qemu/softmmu/vl.c:1664:9
  #27 0x55594f803c21 in main 
/home/alxndr/Development/qemu/softmmu/main.c:49:5
  #28 0x7f43f57b4e0a in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #29 0x55594dd03889 in _start 
(/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xdbd889)

  Address 0x7ffdb76c16c2 is located in stack of thread T0 at offset 34 in frame
  #0 0x55594f1a303f in eth_parse_ipv6_hdr 
/home/alxndr/Development/qemu/net/eth.c:486

This frame has 1 object(s):
  [32, 34) 'ext_hdr' (line 487) <== Memory access at offset 34 overflows 
this variable
  HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
  SUMMARY: AddressSanitizer: stack-buffer-overflow 
/home/alxndr/Development/qemu/net/eth.c:410:17 in _eth_get_rss_ex_dst_addr
  Shadow bytes around the buggy address:
0x100036ed0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  =>0x100036ed02d0: 00 00 00 00 f1 f1 f1 f1[02]f3 f3 f3 00 00 00 00
0x100036ed02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100036ed0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Shadow b

Re: of AVR target page size

[Michael Rolnik]

ok. I will try to fix it.

Regards,
Michael Rolnik

On Thu, Mar 18, 2021 at 11:55 AM Dr. David Alan Gilbert 
wrote:

> * Michael Rolnik (mrol...@gmail.com) wrote:
> > Hi Dave.
> >
> > What is the smallest supported page size?
>
> Currently 512 I think; in migration/ram.c we have:
>
> #define RAM_SAVE_FLAG_FULL 0x01 /* Obsolete, not used anymore */
> #define RAM_SAVE_FLAG_ZERO 0x02
> #define RAM_SAVE_FLAG_MEM_SIZE 0x04
> #define RAM_SAVE_FLAG_PAGE 0x08
> #define RAM_SAVE_FLAG_EOS  0x10
> #define RAM_SAVE_FLAG_CONTINUE 0x20
> #define RAM_SAVE_FLAG_XBZRLE   0x40
> /* 0x80 is reserved in migration.h start with 0x100 next */
> #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
>
> so we're already using the 0x100 (256) flag.
>
> I spotted this yesterday because a patch tried to use the 0x200 flag.
>
> Dave
> >
> > On Wed, Mar 17, 2021 at 10:14 PM Dr. David Alan Gilbert <
> dgilb...@redhat.com>
> > wrote:
> >
> > > Hi Michael,
> > >   I noticed your AVR code defines:
> > >
> > >   #define TARGET_PAGE_BITS 8
> > >
> > > and has an explanation of why.
> > >
> > > Note however that's not going to work with the current live
> > > migration/snapshotting code, since you're a couple of bits smaller
> > > than the smallest page size we had so far, and for many years
> > > the RAM migration code has stolen the bottom few bits of the address
> > > as a flag field, and has already used 0x100 up; see migration/ram.c
> > > RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> > > you change it then it'll break migration compatibility with existing
> > > qemu's.
> > >
> > > Hmm.
> > >
> > > Dave
> > >
> > > --
> > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > >
> > >
> >
> > --
> > Best Regards,
> > Michael Rolnik
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
>

-- 
Best Regards,
Michael Rolnik

Re: of AVR target page size

[Dr. David Alan Gilbert]

* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 17 Mar 2021 at 20:17, Dr. David Alan Gilbert
>  wrote:
> >
> > Hi Michael,
> >   I noticed your AVR code defines:
> >
> >   #define TARGET_PAGE_BITS 8
> >
> > and has an explanation of why.
> >
> > Note however that's not going to work with the current live
> > migration/snapshotting code, since you're a couple of bits smaller
> > than the smallest page size we had so far, and for many years
> > the RAM migration code has stolen the bottom few bits of the address
> > as a flag field, and has already used 0x100 up; see migration/ram.c
> > RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> > you change it then it'll break migration compatibility with existing
> > qemu's.
> 
> If you want to use low bits as flags for other stuff, you
> should have a compile time assert that you have the number
> of bits you expect, or otherwise force a compile error.
> Otherwise you'll end up with unpleasant surprises like this one...

Yes, I think that's been around for a long time.

> I think that for the cpu-all.h uses of low bits we would
> end up with a compile error for excessively small TARGET_PAGE_BITS
> because we define the bits like this:
> #define TLB_DISCARD_WRITE   (1 << (TARGET_PAGE_BITS_MIN - 6))
> and I expect the compiler will complain if the RHS of the '<<'
> is a negative constant. But I don't know if that's deliberate
> or a happy accident :-)


Something like this, does fail for AVR:

>From 8a617836955ebba1a4932d238fce600be51b9182 Mon Sep 17 00:00:00 2001
From: "Dr. David Alan Gilbert" 
Date: Thu, 18 Mar 2021 10:17:27 +
Subject: [PATCH] migration: Check TARGET_PAGE_SIZE vs RAM flags

migration/ram.c steals the bottom few bits of address for flags;
check that we don't run into TARGET_PAGE_SIZE

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/ram.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/migration/ram.c b/migration/ram.c
index 1ee7ff9c6d..f053d45f3c 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -81,6 +81,8 @@
 /* 0x80 is reserved in migration.h start with 0x100 next */
 #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
 
+#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
+
 static inline bool is_zero_range(uint8_t *p, uint64_t size)
 {
 return buffer_is_zero(p, size);
@@ -4101,5 +4103,10 @@ static SaveVMHandlers savevm_ram_handlers = {
 void ram_mig_init(void)
 {
 qemu_mutex_init(&XBZRLE.lock);
+#ifndef TARGET_PAGE_BITS_VARY
+QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= TARGET_PAGE_SIZE);
+#else
+QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 << TARGET_PAGE_BITS_MIN));
+#endif
 register_savevm_live("ram", 0, 4, &savevm_ram_handlers, &ram_state);
 }
-- 
2.30.2

> thanks
> -- PMM
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: of AVR target page size

[Dr. David Alan Gilbert]

* Michael Rolnik (mrol...@gmail.com) wrote:
> ok. I will try to fix it.

Thanks, if you can that would be great.

Dave

> Regards,
> Michael Rolnik
> 
> On Thu, Mar 18, 2021 at 11:55 AM Dr. David Alan Gilbert 
> wrote:
> 
> > * Michael Rolnik (mrol...@gmail.com) wrote:
> > > Hi Dave.
> > >
> > > What is the smallest supported page size?
> >
> > Currently 512 I think; in migration/ram.c we have:
> >
> > #define RAM_SAVE_FLAG_FULL 0x01 /* Obsolete, not used anymore */
> > #define RAM_SAVE_FLAG_ZERO 0x02
> > #define RAM_SAVE_FLAG_MEM_SIZE 0x04
> > #define RAM_SAVE_FLAG_PAGE 0x08
> > #define RAM_SAVE_FLAG_EOS  0x10
> > #define RAM_SAVE_FLAG_CONTINUE 0x20
> > #define RAM_SAVE_FLAG_XBZRLE   0x40
> > /* 0x80 is reserved in migration.h start with 0x100 next */
> > #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> >
> > so we're already using the 0x100 (256) flag.
> >
> > I spotted this yesterday because a patch tried to use the 0x200 flag.
> >
> > Dave
> > >
> > > On Wed, Mar 17, 2021 at 10:14 PM Dr. David Alan Gilbert <
> > dgilb...@redhat.com>
> > > wrote:
> > >
> > > > Hi Michael,
> > > >   I noticed your AVR code defines:
> > > >
> > > >   #define TARGET_PAGE_BITS 8
> > > >
> > > > and has an explanation of why.
> > > >
> > > > Note however that's not going to work with the current live
> > > > migration/snapshotting code, since you're a couple of bits smaller
> > > > than the smallest page size we had so far, and for many years
> > > > the RAM migration code has stolen the bottom few bits of the address
> > > > as a flag field, and has already used 0x100 up; see migration/ram.c
> > > > RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> > > > you change it then it'll break migration compatibility with existing
> > > > qemu's.
> > > >
> > > > Hmm.
> > > >
> > > > Dave
> > > >
> > > > --
> > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > > >
> > > >
> > >
> > > --
> > > Best Regards,
> > > Michael Rolnik
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> >
> >
> 
> -- 
> Best Regards,
> Michael Rolnik
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: of AVR target page size

[Peter Maydell]

On Thu, 18 Mar 2021 at 10:18, Dr. David Alan Gilbert
 wrote:
> diff --git a/migration/ram.c b/migration/ram.c
> index 1ee7ff9c6d..f053d45f3c 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -81,6 +81,8 @@
>  /* 0x80 is reserved in migration.h start with 0x100 next */
>  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
>
> +#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
> +
>  static inline bool is_zero_range(uint8_t *p, uint64_t size)
>  {
>  return buffer_is_zero(p, size);
> @@ -4101,5 +4103,10 @@ static SaveVMHandlers savevm_ram_handlers = {
>  void ram_mig_init(void)
>  {
>  qemu_mutex_init(&XBZRLE.lock);
> +#ifndef TARGET_PAGE_BITS_VARY
> +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= TARGET_PAGE_SIZE);
> +#else
> +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 << TARGET_PAGE_BITS_MIN));
> +#endif

You should just be able to check against TARGET_PAGE_BITS_MIN;
we set that for both the TARGET_PAGE_BITS_VARY and the don't-vary
case.

thanks
-- PMM

Re: [PATCH v2 3/7] ui/vdagent: add mouse support

[Marc-André Lureau]

Hi

On Thu, Mar 18, 2021 at 1:22 PM Gerd Hoffmann  wrote:

> This patch adds support for mouse messages to the vdagent
> implementation.  This can be enabled/disabled using the new
> 'mouse' parameter for the vdagent chardev.  Default is on.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  chardev/char.c |   3 ++
>  ui/vdagent.c   | 141 +
>  qapi/char.json |   4 +-
>  3 files changed, 147 insertions(+), 1 deletion(-)
>
> diff --git a/chardev/char.c b/chardev/char.c
> index 97cafd68494a..fd4d86d0dd3f 100644
> --- a/chardev/char.c
> +++ b/chardev/char.c
> @@ -927,6 +927,9 @@ QemuOptsList qemu_chardev_opts = {
>  },{
>  .name = "logappend",
>  .type = QEMU_OPT_BOOL,
> +},{
> +.name = "mouse",
> +.type = QEMU_OPT_BOOL,
>  #ifdef CONFIG_LINUX
>  },{
>  .name = "tight",
> diff --git a/ui/vdagent.c b/ui/vdagent.c
> index 146ddb8e31b4..61c12b02b573 100644
> --- a/ui/vdagent.c
> +++ b/ui/vdagent.c
> @@ -1,21 +1,38 @@
>  #include "qemu/osdep.h"
>  #include "include/qemu-common.h"
>  #include "chardev/char.h"
> +#include "hw/qdev-core.h"
> +#include "qemu/option.h"
> +#include "ui/console.h"
> +#include "ui/input.h"
>  #include "trace.h"
>
>  #include "qapi/qapi-types-char.h"
> +#include "qapi/qapi-types-ui.h"
>
>  #include "spice/vd_agent.h"
>
> +#define VDAGENT_MOUSE_DEFAULT true
> +
>  struct VDAgentChardev {
>  Chardev parent;
>
> +/* config */
> +bool mouse;
> +
>  /* guest vdagent */
>  uint32_t caps;
>  VDIChunkHeader chunk;
>  uint32_t chunksize;
>  uint8_t *msgbuf;
>  uint32_t msgsize;
> +
> +/* mouse */
> +DeviceState mouse_dev;
> +uint32_t mouse_x;
> +uint32_t mouse_y;
> +uint32_t mouse_btn;
> +QemuInputHandlerState *mouse_hs;
>  };
>  typedef struct VDAgentChardev VDAgentChardev;
>
> @@ -120,13 +137,105 @@ static void vdagent_send_caps(VDAgentChardev *vd)
>  g_autofree VDAgentMessage *msg = g_malloc0(sizeof(VDAgentMessage) +
>
> sizeof(VDAgentAnnounceCapabilities) +
> sizeof(uint32_t));
> +VDAgentAnnounceCapabilities *caps = (void *)msg->data;
>
>  msg->type = VD_AGENT_ANNOUNCE_CAPABILITIES;
>  msg->size = sizeof(VDAgentAnnounceCapabilities) + sizeof(uint32_t);
> +if (vd->mouse) {
> +caps->caps[0] |= (1 << VD_AGENT_CAP_MOUSE_STATE);
> +}
>
>  vdagent_send_msg(vd, msg);
>  }
>
> +/* -- */
> +/* mouse events   */
> +
> +static void vdagent_send_mouse(VDAgentChardev *vd)
> +{
> +g_autofree VDAgentMessage *msg = g_malloc0(sizeof(VDAgentMessage) +
> +   sizeof(VDAgentMouseState));
> +VDAgentMouseState *mouse = (void *)msg->data;
> +
> +msg->type = VD_AGENT_MOUSE_STATE;
> +msg->size = sizeof(VDAgentMouseState);
> +
> +mouse->x   = vd->mouse_x;
> +mouse->y   = vd->mouse_y;
> +mouse->buttons = vd->mouse_btn;
> +
>

Should there be a TODO for device_id support ? If not, it could use a
comment.


> +vdagent_send_msg(vd, msg);
> +}
> +
> +static void vdagent_pointer_event(DeviceState *dev, QemuConsole *src,
> +  InputEvent *evt)
> +{
> +static const int bmap[INPUT_BUTTON__MAX] = {
> +[INPUT_BUTTON_LEFT]= VD_AGENT_LBUTTON_MASK,
> +[INPUT_BUTTON_RIGHT]   = VD_AGENT_RBUTTON_MASK,
> +[INPUT_BUTTON_MIDDLE]  = VD_AGENT_MBUTTON_MASK,
> +[INPUT_BUTTON_WHEEL_UP]= VD_AGENT_UBUTTON_MASK,
> +[INPUT_BUTTON_WHEEL_DOWN]  = VD_AGENT_DBUTTON_MASK,
> +#if 0
> +[INPUT_BUTTON_SIDE]= VD_AGENT_SBUTTON_MASK,
> +[INPUT_BUTTON_EXTRA]   = VD_AGENT_EBUTTON_MASK,
> +#endif
> +};
> +
> +VDAgentChardev *vd = container_of(dev, struct VDAgentChardev,
> mouse_dev);
> +InputMoveEvent *move;
> +InputBtnEvent *btn;
> +uint32_t xres, yres;
> +
> +switch (evt->type) {
> +case INPUT_EVENT_KIND_ABS:
> +move = evt->u.abs.data;
> +xres = qemu_console_get_width(src, 1024);
> +yres = qemu_console_get_height(src, 768);
> +if (move->axis == INPUT_AXIS_X) {
> +vd->mouse_x = qemu_input_scale_axis(move->value,
> +INPUT_EVENT_ABS_MIN,
> +INPUT_EVENT_ABS_MAX,
> +0, xres);
> +} else if (move->axis == INPUT_AXIS_Y) {
> +vd->mouse_y = qemu_input_scale_axis(move->value,
> +INPUT_EVENT_ABS_MIN,
> +INPUT_EVENT_ABS_MAX,
> +0, yres);
> +}
> +break;
> +
> +case INPUT_EVENT_KIND_BTN:
> +btn = 

Re: of AVR target page size

[Dr. David Alan Gilbert]

* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Thu, 18 Mar 2021 at 10:18, Dr. David Alan Gilbert
>  wrote:
> > diff --git a/migration/ram.c b/migration/ram.c
> > index 1ee7ff9c6d..f053d45f3c 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -81,6 +81,8 @@
> >  /* 0x80 is reserved in migration.h start with 0x100 next */
> >  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> >
> > +#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
> > +
> >  static inline bool is_zero_range(uint8_t *p, uint64_t size)
> >  {
> >  return buffer_is_zero(p, size);
> > @@ -4101,5 +4103,10 @@ static SaveVMHandlers savevm_ram_handlers = {
> >  void ram_mig_init(void)
> >  {
> >  qemu_mutex_init(&XBZRLE.lock);
> > +#ifndef TARGET_PAGE_BITS_VARY
> > +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= TARGET_PAGE_SIZE);
> > +#else
> > +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 << TARGET_PAGE_BITS_MIN));
> > +#endif
> 
> You should just be able to check against TARGET_PAGE_BITS_MIN;
> we set that for both the TARGET_PAGE_BITS_VARY and the don't-vary
> case.

Oh yes, just:

diff --git a/migration/ram.c b/migration/ram.c
index 52537f14ac..a7269955b5 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -81,6 +81,8 @@
 /* 0x80 is reserved in migration.h start with 0x100 next */
 #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
 
+#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
+
 static inline bool is_zero_range(uint8_t *p, uint64_t size)
 {
 return buffer_is_zero(p, size);
@@ -4090,5 +4092,6 @@ static SaveVMHandlers savevm_ram_handlers = {
 void ram_mig_init(void)
 {
 qemu_mutex_init(&XBZRLE.lock);
+QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 << TARGET_PAGE_BITS_MIN));
 register_savevm_live("ram", 0, 4, &savevm_ram_handlers, &ram_state);
 }


works; lets keep that in mind somewhere after Michael fixes AVR.

Dave

> thanks
> -- PMM
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: Serious doubts about Gitlab CI

[Philippe Mathieu-Daudé]

On 3/18/21 10:50 AM, Philippe Mathieu-Daudé wrote:
> On 3/18/21 10:33 AM, Daniel P. Berrangé wrote:
>> On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
>>> Hi,
>>>
>>> For some (unclear) reason I got my free tier Gitlab account renewed and
>>> lost the privilege for users opening account before the quota limit.
>>>
>>> I pushed a single branch to my namespace repo to trigger a pipeline.
>>> 1h later I was surprised to see the pipeline was stuck, having completed
>>> 99 jobs of 119. Looking closer there is a red comment on top of the
>>> pipeline:
>>>
>>>  philmd has exceeded its pipeline minutes quota. Unless you buy
>>>  additional pipeline minutes, no new jobs or pipelines in its projects
>>>  will run. [Buy more Pipelines minutes]
>>>
>>> So I exhausted my 400 monthly minutes credit.
>>>
>>> From this FAQ:
>>> https://about.gitlab.com/pricing/faq-consumption-cicd/#managing-your-cicd-minutes-usage
>>>
>>> Q. What happens if I hit the CI/CD Minutes allotted limit and forget to
>>> purchase additional CI/CD Minutes?
>>>
>>> A. You will not be able to run new jobs until you purchase additional
>>> CI/CD Minutes, or until the next month when you receive your monthly
>>> allotted CI/CD Minutes.
>>>
>>> Q. Will I be notified before I hit my limit on CI/CD Minutes?
>>>
>>> A. You will receive notification banners in-app when your group has less
>>> than 30%, 5% or exceeded your total allotted CI/CD minutes.
>>>
>>> I indeed received 3 warnings in 7 minutes.
>>>
>>> Now I'm having serious doubts about Gitlab usefulness for the QEMU
>>> community...
>>
>> Per the discussions in the related Forum postings about CI limites, the
>> 400 minute limit is still only intended to apply to projects that are
>> marked as private.  Public projects are not even being tracked for
>> accounting, let alone have a limit enforced. They also said they want
>> to make sure they don't impact ability of users to contribute to OSS
>> projects hosted on GitLab that require use of CI.
>>
>> It feels like what you hit here is fallout from your account accidentally
>> getting blocked, rather than something which is hitting every contributor
>> to QEMU. Did they restore projects as private perhaps ?
> 
> Yes my repository was restored as private and I had to switch it to
> public. I'll try to blew everything (after backing it up) and recreate
> it as public from start, and see if I get the unlimited minutes back.

You were right, I forked the project again as public and can run CI
pipelines. I note this is different that my previous account, I am
restricted at 15 jobs at a time, so this is slower.

A also added '##.gl-alert-danger.gl-alert' rule to uBlock Origin plugin
to remove the annoying big red panel saying I'm out of minutes and have
to buy more.

💔

Re: [PATCH v2 2/7] ui/vdagent: core infrastructure

[Marc-André Lureau]

On Thu, Mar 18, 2021 at 1:17 PM Gerd Hoffmann  wrote:

> The vdagent protocol allows the guest agent (spice-vdagent) and the
> spice client exchange messages to implement features which require
> guest cooperation, for example clipboard support.
>
> This is a qemu implementation of the spice client side.  This allows
> the spice guest agent talk to qemu directly when not using the spice
> protocol.
>
> usage: qemu \
>   -chardev vdagent,id=vdagent \
>   -device virtserialport,chardev=vdagent,name=com.redhat.spice.0
>
> This patch adds just the protocol basics: initial handshake and
> capability negotiation.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  ui/vdagent.c| 279 
>  qapi/char.json  |  13 +++
>  ui/meson.build  |   1 +
>  ui/trace-events |   8 ++
>  4 files changed, 301 insertions(+)
>  create mode 100644 ui/vdagent.c
>
> diff --git a/ui/vdagent.c b/ui/vdagent.c
> new file mode 100644
> index ..146ddb8e31b4
> --- /dev/null
> +++ b/ui/vdagent.c
> @@ -0,0 +1,279 @@
> +#include "qemu/osdep.h"
> +#include "include/qemu-common.h"
> +#include "chardev/char.h"
> +#include "trace.h"
> +
> +#include "qapi/qapi-types-char.h"
> +
> +#include "spice/vd_agent.h"
> +
> +struct VDAgentChardev {
> +Chardev parent;
> +
> +/* guest vdagent */
> +uint32_t caps;
> +VDIChunkHeader chunk;
> +uint32_t chunksize;
> +uint8_t *msgbuf;
> +uint32_t msgsize;
> +};
> +typedef struct VDAgentChardev VDAgentChardev;
> +
> +#define TYPE_CHARDEV_VDAGENT "chardev-vdagent"
> +
> +DECLARE_INSTANCE_CHECKER(VDAgentChardev, VDAGENT_CHARDEV,
> + TYPE_CHARDEV_VDAGENT);
> +
> +/* -- */
> +/* names, for debug logging   */
> +
> +static const char *cap_name[] = {
> +[VD_AGENT_CAP_MOUSE_STATE]= "mouse-state",
> +[VD_AGENT_CAP_MONITORS_CONFIG]= "monitors-config",
> +[VD_AGENT_CAP_REPLY]  = "reply",
> +[VD_AGENT_CAP_CLIPBOARD]  = "clipboard",
> +[VD_AGENT_CAP_DISPLAY_CONFIG] = "display-config",
> +[VD_AGENT_CAP_CLIPBOARD_BY_DEMAND]= "clipboard-by-demand",
> +[VD_AGENT_CAP_CLIPBOARD_SELECTION]= "clipboard-selection",
> +[VD_AGENT_CAP_SPARSE_MONITORS_CONFIG] =
> "sparse-monitors-config",
> +[VD_AGENT_CAP_GUEST_LINEEND_LF]   = "guest-lineend-lf",
> +[VD_AGENT_CAP_GUEST_LINEEND_CRLF] = "guest-lineend-crlf",
> +[VD_AGENT_CAP_MAX_CLIPBOARD]  = "max-clipboard",
> +[VD_AGENT_CAP_AUDIO_VOLUME_SYNC]  = "audio-volume-sync",
> +[VD_AGENT_CAP_MONITORS_CONFIG_POSITION]   =
> "monitors-config-position",
> +[VD_AGENT_CAP_FILE_XFER_DISABLED] = "file-xfer-disabled",
> +[VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS]  =
> "file-xfer-detailed-errors",
> +#if 0
> +[VD_AGENT_CAP_GRAPHICS_DEVICE_INFO]   =
> "graphics-device-info",
> +[VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB] =
> "clipboard-no-release-on-regrab",
> +[VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL]  =
> "clipboard-grab-serial",
> +#endif
> +};
> +
> +static const char *msg_name[] = {
> +[VD_AGENT_MOUSE_STATE]   = "mouse-state",
> +[VD_AGENT_MONITORS_CONFIG]   = "monitors-config",
> +[VD_AGENT_REPLY] = "reply",
> +[VD_AGENT_CLIPBOARD] = "clipboard",
> +[VD_AGENT_DISPLAY_CONFIG]= "display-config",
> +[VD_AGENT_ANNOUNCE_CAPABILITIES] = "announce-capabilities",
> +[VD_AGENT_CLIPBOARD_GRAB]= "clipboard-grab",
> +[VD_AGENT_CLIPBOARD_REQUEST] = "clipboard-request",
> +[VD_AGENT_CLIPBOARD_RELEASE] = "clipboard-release",
> +[VD_AGENT_FILE_XFER_START]   = "file-xfer-start",
> +[VD_AGENT_FILE_XFER_STATUS]  = "file-xfer-status",
> +[VD_AGENT_FILE_XFER_DATA]= "file-xfer-data",
> +[VD_AGENT_CLIENT_DISCONNECTED]   = "client-disconnected",
> +[VD_AGENT_MAX_CLIPBOARD] = "max-clipboard",
> +[VD_AGENT_AUDIO_VOLUME_SYNC] = "audio-volume-sync",
> +#if 0
> +[VD_AGENT_GRAPHICS_DEVICE_INFO]  = "graphics-device-info",
> +#endif
> +};
> +
> +#define GET_NAME(_m, _v) \
> +(((_v) < ARRAY_SIZE(_m) && (_m[_v])) ? (_m[_v]) : "???")
> +
> +/* -- */
> +/* send messages  */
> +
> +static void vdagent_send_buf(VDAgentChardev *vd, void *ptr, uint32_t
> msgsize)
> +{
> +uint8_t *msgbuf = ptr;
> +uint32_t len, pos = 0;
> +
> +while (pos < msgsize) {
> +len = qemu_chr_be_can_write(CHARDEV(vd));
> +if (len > msgsize - pos) {
> +len = msgsize - pos;
> +}
> +qemu_chr_be_write(CHARDEV(vd), msgbuf + pos, len);
> +pos += len;
> +}

Re: of AVR target page size

[Peter Maydell]

On Thu, 18 Mar 2021 at 10:25, Dr. David Alan Gilbert
 wrote:
> Oh yes, just:
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 52537f14ac..a7269955b5 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -81,6 +81,8 @@
>  /* 0x80 is reserved in migration.h start with 0x100 next */
>  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
>
> +#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
> +
>  static inline bool is_zero_range(uint8_t *p, uint64_t size)
>  {
>  return buffer_is_zero(p, size);
> @@ -4090,5 +4092,6 @@ static SaveVMHandlers savevm_ram_handlers = {
>  void ram_mig_init(void)
>  {
>  qemu_mutex_init(&XBZRLE.lock);
> +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 << TARGET_PAGE_BITS_MIN));
>  register_savevm_live("ram", 0, 4, &savevm_ram_handlers, &ram_state);
>  }
>
>
> works; lets keep that in mind somewhere after Michael fixes AVR.

You don't have a great deal of headroom even after getting AVR
to change, by the way -- TARGET_PAGE_BITS_MIN for Arm is 10.
So you might want to think about ways to eg reclaim usage of
that "obsolete, not used" RAM_SAVE_FLAG_FULL bit.

Also, what does the
 /* 0x80 is reserved in migration.h start with 0x100 next */
comment refer to? migration.h has no instances of "RAM_SAVE"
or 0x80 or 1 << 7...

thanks
-- PMM

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Paolo Bonzini]

On 18/03/21 11:06, Laurent Vivier wrote:

This also removes the virtio-devices test, I think we should keep the
files, but in the files to disable the PCI part when it is not
available.


I think we should just shuffle the targets in the gitlab YAML to bypass 
the issue.


Paolo

Re: iotests failing on gitlab CI check-system-fedora job

[Paolo Bonzini]

On 18/03/21 11:07, Peter Maydell wrote:

On Wed, 17 Mar 2021 at 23:26, Paolo Bonzini  wrote:


On 17/03/21 23:23, Peter Maydell wrote:

The check-system-fedora job in the gitlab CI seems to have
started reliably failing on iotests 040 041 127 256 267:
   https://gitlab.com/qemu-project/qemu/-/jobs/1106977551

Could somebody have a look at what's happening, please?
(This is probably a regression that's got into master because
I stopped using "did gitlab CI pass" as a gate because gitlab
was running massively too slowly to be usable for that.)


It's caused by adding virtio devices to the m68k target.  Probably it
can be fixed by moving i386-softmmu to Fedora and m68k-softmmu to Debian.


Why are the iotests not specifying what machine type they run
on if they care about the machine type ?


Because the intersection of people building only "uncommon" targets and 
people running "check-block" is usually empty.  Adjusting 
tests/qemu-iotests/testenv.py should be quite easy though.


Paolo

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Peter Maydell]

On Thu, 18 Mar 2021 at 10:37, Paolo Bonzini  wrote:
>
> On 18/03/21 11:06, Laurent Vivier wrote:
> > This also removes the virtio-devices test, I think we should keep the
> > files, but in the files to disable the PCI part when it is not
> > available.
>
> I think we should just shuffle the targets in the gitlab YAML to bypass
> the issue.

Then we'll hit it again later. I'm pretty sure this isn't the
first time we've run into "some test makes dubious assumptions"...

-- PMM

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Paolo Bonzini]

On 18/03/21 11:40, Peter Maydell wrote:

On Thu, 18 Mar 2021 at 10:37, Paolo Bonzini  wrote:


On 18/03/21 11:06, Laurent Vivier wrote:

This also removes the virtio-devices test, I think we should keep the
files, but in the files to disable the PCI part when it is not
available.


I think we should just shuffle the targets in the gitlab YAML to bypass
the issue.


Then we'll hit it again later. I'm pretty sure this isn't the
first time we've run into "some test makes dubious assumptions"...


We can both fix qemu-iotests and CI configuration, but m68k is certainly 
not the culprit here.  And we are going to make more assumptions over 
time, not fewer, in order to keep the CI time at bay.


Paolo

Re: [RFC v9 38/50] target/arm: move kvm cpu properties setting to kvm-cpu

[Claudio Fontana]

On 3/17/21 7:30 PM, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu.c | 4 
>  target/arm/kvm/kvm-cpu.c | 1 +
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 3d6501c2c5..ac01fa0bae 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -786,10 +786,6 @@ void arm_cpu_post_init(Object *obj)
>  qdev_property_add_static(DEVICE(cpu), &arm_cpu_gt_cntfrq_property);
>  }
>  
> -if (kvm_enabled()) {
> -kvm_arm_add_vcpu_properties(obj);
> -}
> -
>  #ifndef CONFIG_USER_ONLY
>  if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64) &&
>  cpu_isar_feature(aa64_mte, cpu)) {
> diff --git a/target/arm/kvm/kvm-cpu.c b/target/arm/kvm/kvm-cpu.c
> index b3e97080cc..3b8a8de30f 100644
> --- a/target/arm/kvm/kvm-cpu.c
> +++ b/target/arm/kvm/kvm-cpu.c
> @@ -89,6 +89,7 @@ static void host_cpu_instance_init(Object *obj)
>  if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
>  aarch64_add_sve_properties(obj);
>  }
> +kvm_arm_add_vcpu_properties(obj);
>  arm_cpu_post_init(obj);
>  }
>  
> 

This is wrong, the arm_cpu_post_init stuff confused me. Dropped.

Re: of AVR target page size

[Dr. David Alan Gilbert]

* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Thu, 18 Mar 2021 at 10:25, Dr. David Alan Gilbert
>  wrote:
> > Oh yes, just:
> >
> > diff --git a/migration/ram.c b/migration/ram.c
> > index 52537f14ac..a7269955b5 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -81,6 +81,8 @@
> >  /* 0x80 is reserved in migration.h start with 0x100 next */
> >  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> >
> > +#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
> > +
> >  static inline bool is_zero_range(uint8_t *p, uint64_t size)
> >  {
> >  return buffer_is_zero(p, size);
> > @@ -4090,5 +4092,6 @@ static SaveVMHandlers savevm_ram_handlers = {
> >  void ram_mig_init(void)
> >  {
> >  qemu_mutex_init(&XBZRLE.lock);
> > +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 << TARGET_PAGE_BITS_MIN));
> >  register_savevm_live("ram", 0, 4, &savevm_ram_handlers, &ram_state);
> >  }
> >
> >
> > works; lets keep that in mind somewhere after Michael fixes AVR.
> 
> You don't have a great deal of headroom even after getting AVR
> to change, by the way -- TARGET_PAGE_BITS_MIN for Arm is 10.
> So you might want to think about ways to eg reclaim usage of
> that "obsolete, not used" RAM_SAVE_FLAG_FULL bit.

Yep, I've been warning anyone who adds one for ages

> Also, what does the
>  /* 0x80 is reserved in migration.h start with 0x100 next */
> comment refer to? migration.h has no instances of "RAM_SAVE"
> or 0x80 or 1 << 7...

It looks like it got moved to qemu-file.h a few years ago
as RAM_SAVE_FLAG_HOOK.

Dave

> thanks
> -- PMM
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Philippe Mathieu-Daudé]

On 3/18/21 10:56 AM, Claudio Fontana wrote:
> On 3/18/21 10:47 AM, Philippe Mathieu-Daudé wrote:
>> Hi Peter,
>>
>> On 3/11/21 11:43 AM, Claudio Fontana wrote:
>>> On 2/21/21 11:26 PM, Philippe Mathieu-Daudé wrote:
 KVM requires the target cpu to be at least ARMv8 architecture
 (support on ARMv7 has been dropped in commit 82bf7ae84ce:
 "target/arm: Remove KVM support for 32-bit Arm hosts").

 A KVM-only build won't be able to run TCG cpus, move the
 v7A CPU definitions to cpu_tcg.c.

 Reported-by: Peter Maydell 
 Reviewed-by: Peter Maydell 
 Signed-off-by: Philippe Mathieu-Daudé 
>>>
>>>
>>> Here I think it's better to keep the "a15" cpu around,
>>> until we fix the board configuration situation.
>>>
>>> I added a patch that does that into my KVM-only build series, to avoid the 
>>> resulting breakages.
>>
>> Actually I got a downstream report that this break migration from QEMU
>> 5.2 to QEMU 6.0.
>>
>> I first thought it was on an old kernel (with 32-bit KVM enabled),
>> but not, it is for Aarch64 VMs on recent KVM (without 32-bit support)
>> but the 'virt' machines were started with default Cortex-A15 CPU...
>>
>> mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
>>
>> I'm not sure upstream should care about this case, but I though
>> maybe you could give me hints about the best way to keep old VMs
>> working, as this likely affects any distribution. Obviously not
>> upgrading QEMU is not a solution :)
>>
>> The simplest seems to revert 82bf7ae84ce and this patch, but I
>> doubt this will be enough.
>>
>> Maybe there is some clever thing to do before reverting 82bf7ae84ce,
>> that could also benefit upstream, by doing something with versioned
>> machines? I have no idea (yet) how that work and if it could work.
> 
> Does just applying my series fix it?

But we are past soft-freeze so I'm looking for a surgical fix.

I'll send a partial revert for now.

Re: Can not use hmp block_resize command with -blockdev option

[Kevin Wolf]

Am 17.03.2021 um 23:49 hat John Snow geschrieben:
> On 3/16/21 11:43 PM, zhao xiaojun wrote:
> > Hi,
> > I use -blockdev option to specify a drive when qemu boot and i want to
> > resize it with hmp block_resize command. The hmp block_resize comand's
> > arguments: block_resize device new_size.
> > So I query the device by qmp query_block command, but the device filed
> > of the result output is NULL string.
> > 
> > result output:
> > {
> >    "return": [
> >      {
> >        "io-status": "ok",
> >        "device": "",
> >          ...
> > }
> > 
> > I noticed that the qmp block_resize command supports device or node-name
> > as argument.
> > 
> > If i can continue use the the hmp block_resize command with the device
> > argument?
> > 
> > Regards.
> 
> I'm not sure what you're asking: hmp's block_resize doesn't accept node-name
> arguments as you've found. Are you not able to use QMP's block_resize?

We should probably fix HMP block_resize to accept node names.

Kevin

Re: [RFC v2 05/13] vhost: Route guest->host notification through shadow virtqueue

[Eugenio Perez Martin]

On Thu, Mar 18, 2021 at 10:29 AM Jason Wang  wrote:
>
>
> 在 2021/3/18 下午5:18, Eugenio Perez Martin 写道:
> > On Thu, Mar 18, 2021 at 4:11 AM Jason Wang  wrote:
> >>
> >> 在 2021/3/18 上午12:47, Eugenio Perez Martin 写道:
> >>> On Wed, Mar 17, 2021 at 3:05 AM Jason Wang  wrote:
>  在 2021/3/16 下午6:31, Eugenio Perez Martin 写道:
> > On Tue, Mar 16, 2021 at 8:18 AM Jason Wang  wrote:
> >> 在 2021/3/16 上午3:48, Eugenio Pérez 写道:
> >>> Shadow virtqueue notifications forwarding is disabled when vhost_dev
> >>> stops, so code flow follows usual cleanup.
> >>>
> >>> Signed-off-by: Eugenio Pérez 
> >>> ---
> >>>  hw/virtio/vhost-shadow-virtqueue.h |   7 ++
> >>>  include/hw/virtio/vhost.h  |   4 +
> >>>  hw/virtio/vhost-shadow-virtqueue.c | 113 ++-
> >>>  hw/virtio/vhost.c  | 143 
> >>> -
> >>>  4 files changed, 265 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/hw/virtio/vhost-shadow-virtqueue.h 
> >>> b/hw/virtio/vhost-shadow-virtqueue.h
> >>> index 6cc18d6acb..c891c6510d 100644
> >>> --- a/hw/virtio/vhost-shadow-virtqueue.h
> >>> +++ b/hw/virtio/vhost-shadow-virtqueue.h
> >>> @@ -17,6 +17,13 @@
> >>>
> >>>  typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
> >>>
> >>> +bool vhost_shadow_vq_start(struct vhost_dev *dev,
> >>> +   unsigned idx,
> >>> +   VhostShadowVirtqueue *svq);
> >>> +void vhost_shadow_vq_stop(struct vhost_dev *dev,
> >>> +  unsigned idx,
> >>> +  VhostShadowVirtqueue *svq);
> >>> +
> >>>  VhostShadowVirtqueue *vhost_shadow_vq_new(struct vhost_dev *dev, 
> >>> int idx);
> >>>
> >>>  void vhost_shadow_vq_free(VhostShadowVirtqueue *vq);
> >>> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
> >>> index ac963bf23d..7ffdf9aea0 100644
> >>> --- a/include/hw/virtio/vhost.h
> >>> +++ b/include/hw/virtio/vhost.h
> >>> @@ -55,6 +55,8 @@ struct vhost_iommu {
> >>>  QLIST_ENTRY(vhost_iommu) iommu_next;
> >>>  };
> >>>
> >>> +typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
> >>> +
> >>>  typedef struct VhostDevConfigOps {
> >>>  /* Vhost device config space changed callback
> >>>   */
> >>> @@ -83,7 +85,9 @@ struct vhost_dev {
> >>>  uint64_t backend_cap;
> >>>  bool started;
> >>>  bool log_enabled;
> >>> +bool shadow_vqs_enabled;
> >>>  uint64_t log_size;
> >>> +VhostShadowVirtqueue **shadow_vqs;
> >> Any reason that you don't embed the shadow virtqueue into
> >> vhost_virtqueue structure?
> >>
> > Not really, it could be relatively big and I would prefer SVQ
> > members/methods to remain hidden from any other part that includes
> > vhost.h. But it could be changed, for sure.
> >
> >> (Note that there's a masked_notifier in struct vhost_virtqueue).
> >>
> > They are used differently: in SVQ the masked notifier is a pointer,
> > and if it's NULL the SVQ code knows that device is not masked. The
> > vhost_virtqueue is the real owner.
>  Yes, but it's an example for embedding auxciliary data structures in the
>  vhost_virtqueue.
> 
> 
> > It could be replaced by a boolean in SVQ or something like that, I
> > experimented with a tri-state too (UNMASKED, MASKED, MASKED_NOTIFIED)
> > and let vhost.c code to manage all the transitions. But I find clearer
> > the pointer use, since it's the more natural for the
> > vhost_virtqueue_mask, vhost_virtqueue_pending existing functions.
> >
> > This masking/unmasking is the part I dislike the most from this
> > series, so I'm very open to alternatives.
>  See below. I think we don't even need to care about that.
> 
> 
> >>>  Error *migration_blocker;
> >>>  const VhostOps *vhost_ops;
> >>>  void *opaque;
> >>> diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> >>> b/hw/virtio/vhost-shadow-virtqueue.c
> >>> index 4512e5b058..3e43399e9c 100644
> >>> --- a/hw/virtio/vhost-shadow-virtqueue.c
> >>> +++ b/hw/virtio/vhost-shadow-virtqueue.c
> >>> @@ -8,9 +8,12 @@
> >>>   */
> >>>
> >>>  #include "hw/virtio/vhost-shadow-virtqueue.h"
> >>> +#include "hw/virtio/vhost.h"
> >>> +
> >>> +#include "standard-headers/linux/vhost_types.h"
> >>>
> >>>  #include "qemu/error-report.h"
> >>> -#include "qemu/event_notifier.h"
> >>> +#include "qemu/main-loop.h"
> >>>
> >>>  /* Shadow virtqueue to relay notifications */
> >>>  typedef struct VhostShadowVirtqueue {
> >>> @@ -18,14 +21,121 @@ typedef struct VhostShadowVirtqueue {
> >>>  

Re: [PATCH v2 7/7] ui/gtk: add clipboard support

[Marc-André Lureau]

Hi

On Thu, Mar 18, 2021 at 1:25 PM Gerd Hoffmann  wrote:

> This patch adds clipboard support to the qemu gtk ui.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/ui/gtk.h   |  10 +++
>  ui/gtk-clipboard.c | 189 +
>  ui/gtk.c   |   1 +
>  ui/meson.build |   2 +-
>  4 files changed, 201 insertions(+), 1 deletion(-)
>  create mode 100644 ui/gtk-clipboard.c
>
> diff --git a/include/ui/gtk.h b/include/ui/gtk.h
> index 6e751794043f..9516670ebc87 100644
> --- a/include/ui/gtk.h
> +++ b/include/ui/gtk.h
> @@ -18,6 +18,7 @@
>  #include 
>  #endif
>
> +#include "ui/clipboard.h"
>  #include "ui/console.h"
>  #include "ui/kbd-state.h"
>  #if defined(CONFIG_OPENGL)
> @@ -137,6 +138,12 @@ struct GtkDisplayState {
>
>  bool external_pause_update;
>
> +QemuClipboardPeer cbpeer;
> +QemuClipboardInfo *cbinfo[QEMU_CLIPBOARD_SELECTION__COUNT];
> +uint32_t cbpending[QEMU_CLIPBOARD_SELECTION__COUNT];
> +GtkClipboard *gtkcb[QEMU_CLIPBOARD_SELECTION__COUNT];
> +bool cbowner[QEMU_CLIPBOARD_SELECTION__COUNT];
> +
>  DisplayOptions *opts;
>  };
>
> @@ -207,4 +214,7 @@ void gtk_gl_area_init(void);
>  int gd_gl_area_make_current(DisplayChangeListener *dcl,
>  QEMUGLContext ctx);
>
> +/* gtk-clipboard.c */
> +void gd_clipboard_init(GtkDisplayState *gd);
> +
>  #endif /* UI_GTK_H */
> diff --git a/ui/gtk-clipboard.c b/ui/gtk-clipboard.c
> new file mode 100644
> index ..3585e27cab78
> --- /dev/null
> +++ b/ui/gtk-clipboard.c
> @@ -0,0 +1,189 @@
> +/*
> + * GTK UI -- clipboard support
> + *
> + * Copyright (C) 2021 Gerd Hoffmann 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "qemu/main-loop.h"
> +
> +#include "ui/gtk.h"
> +
> +static QemuClipboardSelection gd_find_selection(GtkDisplayState *gd,
> +GtkClipboard *clipboard)
> +{
> +QemuClipboardSelection s;
> +
> +for (s = 0; s < QEMU_CLIPBOARD_SELECTION__COUNT; s++) {
> +if (gd->gtkcb[s] == clipboard) {
> +return s;
> +}
> +}
> +return QEMU_CLIPBOARD_SELECTION_CLIPBOARD;
> +}
> +
> +static void gd_clipboard_get_data(GtkClipboard *clipboard,
> +  GtkSelectionData *selection_data,
> +  guint selection_info,
> +  gpointer  data)
> +{
> +GtkDisplayState *gd = data;
> +QemuClipboardSelection s = gd_find_selection(gd, clipboard);
> +QemuClipboardType type = QEMU_CLIPBOARD_TYPE_TEXT;
> +QemuClipboardInfo *info = qemu_clipboard_info_get(gd->cbinfo[s]);
> +
> +qemu_clipboard_request(info, type);
> +while (info == gd->cbinfo[s] &&
> +   info->types[type].available &&
> +   info->types[type].data == NULL) {
> +main_loop_wait(false);
>

Added to the list of reasons not to want running the clipboard  (or shall I
say any UI code) inside qemu.

(gtk4 is supposed to have improved that, fwiw)

+}
> +
> +if (info == gd->cbinfo[s] && gd->cbowner[s]) {
> +gtk_selection_data_set_text(selection_data,
> +info->types[type].data,
> +info->types[type].size);
> +} else {
> +/* clipboard owner changed while waiting for the data */
> +}
> +
> +qemu_clipboard_info_put(info);
> +}
> +
> +static void gd_clipboard_clear(GtkClipboard *clipboard,
> +   gpointer data)
> +{
> +GtkDisplayState *gd = data;
> +QemuClipboardSelection s = gd_find_selection(gd, clipboard);
> +
> +gd->cbowner[s] = false;
> +}
> +
> +static void gd_clipboard_notify(Notifier *notifier, void *data)
> +{
> +GtkDisplayState *gd = container_of(notifier, GtkDisplayState,
> cbpeer.update);
> +QemuClipboardInfo *info = data;
> +QemuClipboardSelection s = info->selection;
> +bool self_update = info->owner == &gd->cbpeer;
> +
> +if (info != gd->cbinfo[s]) {
> +qemu_clipboard_info_put(gd->cbinfo[s]);
> +gd->cbinfo[s] = qemu_clipboard_info_get(info);
> +gd->cbpending[s] = 0;
> +if (!self_update) {
> +GtkTargetList *list;
> +GtkTargetEntry *targets;
> 

Re: of AVR target page size

[Michael Rolnik]

how do I test my fix? Is there a procedure?

Thanks,
Michael Rolnik

On Thu, Mar 18, 2021 at 12:45 PM Dr. David Alan Gilbert 
wrote:

> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > On Thu, 18 Mar 2021 at 10:25, Dr. David Alan Gilbert
> >  wrote:
> > > Oh yes, just:
> > >
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index 52537f14ac..a7269955b5 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -81,6 +81,8 @@
> > >  /* 0x80 is reserved in migration.h start with 0x100 next */
> > >  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> > >
> > > +#define RAM_SAVE_FLAG__MAX RAM_SAVE_FLAG_COMPRESS_PAGE
> > > +
> > >  static inline bool is_zero_range(uint8_t *p, uint64_t size)
> > >  {
> > >  return buffer_is_zero(p, size);
> > > @@ -4090,5 +4092,6 @@ static SaveVMHandlers savevm_ram_handlers = {
> > >  void ram_mig_init(void)
> > >  {
> > >  qemu_mutex_init(&XBZRLE.lock);
> > > +QEMU_BUILD_BUG_ON(RAM_SAVE_FLAG__MAX >= (1 <<
> TARGET_PAGE_BITS_MIN));
> > >  register_savevm_live("ram", 0, 4, &savevm_ram_handlers,
> &ram_state);
> > >  }
> > >
> > >
> > > works; lets keep that in mind somewhere after Michael fixes AVR.
> >
> > You don't have a great deal of headroom even after getting AVR
> > to change, by the way -- TARGET_PAGE_BITS_MIN for Arm is 10.
> > So you might want to think about ways to eg reclaim usage of
> > that "obsolete, not used" RAM_SAVE_FLAG_FULL bit.
>
> Yep, I've been warning anyone who adds one for ages
>
> > Also, what does the
> >  /* 0x80 is reserved in migration.h start with 0x100 next */
> > comment refer to? migration.h has no instances of "RAM_SAVE"
> > or 0x80 or 1 << 7...
>
> It looks like it got moved to qemu-file.h a few years ago
> as RAM_SAVE_FLAG_HOOK.
>
> Dave
>
> > thanks
> > -- PMM
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
>

-- 
Best Regards,
Michael Rolnik

arm_cpu_post_init (Was: Re: arm: "max" CPU class hierarchy changes possible?)

[Claudio Fontana]

On 3/11/21 8:10 PM, Andrew Jones wrote:
> On Thu, Mar 11, 2021 at 06:33:15PM +, Peter Maydell wrote:
>> On Thu, 11 Mar 2021 at 17:16, Claudio Fontana  wrote:
>>> Maybe Peter you could clarify similarly what the intended meaning of "max" 
>>> is on ARM?
>>
>> "max" is "best we can do, whatever that is". (On KVM this is "same as
>> the host".)
>> "host" is "whatever the host is (KVM only)".
>>
>>> KVM: (aarch64-only): aarch64_max_initfn():
>>>
>>> The following comment in the code seems wrong to me:
>>>
>>> /* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
>>> host); */
>>>
>>> This is not exactly true:
>>>
>>> "-cpu max" calls kvm_arm_set_cpu_features_from_host(), (which checks 
>>> "dtb_compatible", and if not set gets the features from the host, if set 
>>> ...?)
>>> After that, calls aarch64_add_sve_properties() and then adds also 
>>> "svw-max-vq". This code is common with TCG.


As part of this research I noticed that arm_cpu_post_init() is quite confusing, 
seems really inconsistent to me.

Apparently the intention was to call it from the leaf classes:

commit 51e5ef459eca045d7e8afe880ee60190f0b75b26
Author: Marc-André Lureau 
Date:   Tue Nov 27 12:55:59 2018 +0400

arm: replace instance_post_init()

Replace arm_cpu_post_init() instance callback by calling it from leaf
classes, to avoid potential ordering issue with other post_init callbacks.

Signed-off-by: Marc-André Lureau 
Suggested-by: Igor Mammedov 
Reviewed-by: Igor Mammedov 
Acked-by: Eduardo Habkost 


but then we end up calling it multiple times in the class hierarch, which is a 
recipe for bugs, and makes it difficult to understand what arm_cpu_post_init()
even means, what calling this function is supposed to do.

For a "max" or "host" cpu on AArch64, this function is called:

for the ARM CPU base class, TYPE_ARM_CPU, in

cpu.c::arm_cpu_instance_init,

then later again for the TYPE_AARCH64_CPU class, child of TYPE_ARM_CPU, in

cpu64.c::aarch64_cpu_instance_init,

then later again for the TYPE_ARM_HOST_CPU class, child of TYPE_AARCH64_CPU, in

cpu.c::arm_host_initfn.

Same for "max".

When looking at 32bit CPUs instead, only the ARM CPU base class ends up calling 
arm_cpu_post_init.
"Leaf" classes do not do it (see cpu_tcg.c).

What is then arm_cpu_post_init even supposed to mean?

Thanks,

Claudio


>>>
>>> In the case of cpu host instead,
>>>
>>> "-cpu host" calls kvm_arm_set_cpu_features_from_host(), same as max, then 
>>> calls aarch64_add_sve_properties() but does NOT add "svw-max-vq".
>>>
>>> Is this a bug?
> 
> It was left out intentionally. More below.
> 
>>
>> Maybe; that's a question for Richard or Drew...
>>
>>> Are "max" and "host" for KVM supposed to be the same like with x86?
> 
> Yes, but my understanding of "max" == "host" for KVM is that that only
> applies to the perspective of the guest. What CPU and what CPU features
> the guest can see should be exactly the same with either "max" or "host",
> depending on the enabling/disabling of any optional CPU properties.
> 
> The question here seems to be that, if one has a CPU property, does that
> imply the other should have the same? Which would effectively allow the
> two to be aliases (when KVM is enabled). I don't know, does x86 ensure
> 100% property compatibility?
> 
> I opted not to support sve-max-vq for "host" because I consider it a
> legacy CPU property, one I didn't want to propagate. Indeed it may
> make more sense to depreciate sve-max-vq than to "fix" this issue
> by adding it to "host". Note, we can already create equivalent SVE
> CPUs. The following are the same from the perspective of the guest
> 
>  -accel kvm -cpu host,sve512=on
>  -accel kvm -cpu max,sve512=on
> 
> And, for TCG, these are the same from the perspective of the guest
>  
>  -accel tcg -cpu max,sve512=on
>  -accel tcg -cpu max,sve-max-vq=4
> 
> So we already don't need sve-max-vq.
> 
> Thanks,
> drew
> 

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Philippe Mathieu-Daudé]

On 3/18/21 11:47 AM, Philippe Mathieu-Daudé wrote:
> On 3/18/21 10:56 AM, Claudio Fontana wrote:
>> On 3/18/21 10:47 AM, Philippe Mathieu-Daudé wrote:
>>> Hi Peter,
>>>
>>> On 3/11/21 11:43 AM, Claudio Fontana wrote:
 On 2/21/21 11:26 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
>
> A KVM-only build won't be able to run TCG cpus, move the
> v7A CPU definitions to cpu_tcg.c.
>
> Reported-by: Peter Maydell 
> Reviewed-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 


 Here I think it's better to keep the "a15" cpu around,
 until we fix the board configuration situation.

 I added a patch that does that into my KVM-only build series, to avoid the 
 resulting breakages.
>>>
>>> Actually I got a downstream report that this break migration from QEMU
>>> 5.2 to QEMU 6.0.
>>>
>>> I first thought it was on an old kernel (with 32-bit KVM enabled),
>>> but not, it is for Aarch64 VMs on recent KVM (without 32-bit support)
>>> but the 'virt' machines were started with default Cortex-A15 CPU...
>>>
>>> mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
>>>
>>> I'm not sure upstream should care about this case, but I though
>>> maybe you could give me hints about the best way to keep old VMs
>>> working, as this likely affects any distribution. Obviously not
>>> upgrading QEMU is not a solution :)
>>>
>>> The simplest seems to revert 82bf7ae84ce and this patch, but I
>>> doubt this will be enough.
>>>
>>> Maybe there is some clever thing to do before reverting 82bf7ae84ce,
>>> that could also benefit upstream, by doing something with versioned
>>> machines? I have no idea (yet) how that work and if it could work.
>>
>> Does just applying my series fix it?
> 
> But we are past soft-freeze so I'm looking for a surgical fix.
> 
> I'll send a partial revert for now.

Still, I'm not sure it makes sense. If you want to migrate a such
machine, KVM can not virtualize it, so you'll be forced to use TCG
right? In that case cpu_tcg is built in and you have the A15.

IOW the problem is not this patch, it is that since 82bf7ae84ce we
can not migrate A15.

So we need both 1/ revert 82bf7ae84ce and 2/ be sure the kernel
support 32-bit host... Am I missing something?

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Peter Maydell]

On Thu, 18 Mar 2021 at 10:45, Paolo Bonzini  wrote:
>
> On 18/03/21 11:40, Peter Maydell wrote:
> > On Thu, 18 Mar 2021 at 10:37, Paolo Bonzini  wrote:
> >>
> >> On 18/03/21 11:06, Laurent Vivier wrote:
> >>> This also removes the virtio-devices test, I think we should keep the
> >>> files, but in the files to disable the PCI part when it is not
> >>> available.
> >>
> >> I think we should just shuffle the targets in the gitlab YAML to bypass
> >> the issue.
> >
> > Then we'll hit it again later. I'm pretty sure this isn't the
> > first time we've run into "some test makes dubious assumptions"...
>
> We can both fix qemu-iotests and CI configuration, but m68k is certainly
> not the culprit here.  And we are going to make more assumptions over
> time, not fewer, in order to keep the CI time at bay.

I don't see why CI time is relevant to whether the test says
"I require X,Y,Z, so don't run me on configs without those"
or whether it just randomly assumes X,Y,Z are always present
or that if it says "I require W" than W must imply X,Y,Z...

thanks
-- PMM

[Bug 1880518] Re: issue while installing docker inside s390x container

[Nayana]

docker not starting inside s390x container. Log shows:

Error starting daemon: Error initializing network controller: error obtaining 
controller instance: failed to create NAT chain DOCKER: iptables failed: 
iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table 
`nat': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
 (exit status 3)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880518

Title:
  issue while installing docker inside s390x container

Status in QEMU:
  Incomplete

Bug description:
  This is in reference to 
https://github.com/multiarch/qemu-user-static/issues/108.
  I am facing issue while installing docker inside s390x container under qemu 
on Ubuntu 18.04 host running on amd64.
  Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel 
host after running 
  docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
  enabled
  interpreter /usr/bin/qemu-s390x-static
  flags: F
  offset 0
  magic 7f454c46020201020016
  mask ff00fffe
  I could get docker service up with the following trick. 
  printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > 
/etc/docker/daemon.json
  But even though docker service comes up, images are not getting pulled, 
docker pull fails with the following error.
  failed to register layer: Error processing tar file(exit status 1):

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1880518/+subscriptions

Re: of AVR target page size

[Peter Maydell]

On Thu, 18 Mar 2021 at 10:45, Dr. David Alan Gilbert
 wrote:
>
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > Also, what does the
> >  /* 0x80 is reserved in migration.h start with 0x100 next */
> > comment refer to? migration.h has no instances of "RAM_SAVE"
> > or 0x80 or 1 << 7...
>
> It looks like it got moved to qemu-file.h a few years ago
> as RAM_SAVE_FLAG_HOOK.

Could we put the define of RAM_SAVE_FLAG_HOOK in migration.h
with all the other RAM_SAVE_FLAG defines ? It looks like the two
places that use it already include migration.h...

thanks
-- PMM

Re: [PULL 0/7] Q800 for 6.0 patches

[Peter Maydell]

On Tue, 16 Mar 2021 at 21:27, Laurent Vivier  wrote:
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into =
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu-m68k.git tags/q800-for-6.0-pull-request
>
> for you to fetch changes up to 30ca7eddc486646fa19c9619fcf233ceaa65e28c:
>
>   mac_via: remove VIA1 timer optimisations (2021-03-16 21:41:37 +0100)
>
> 
> q800 pull request 20210316
>
> Several fixes for mac_via needed for future support of MacOS ROM


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM

Re: [PULL 5/5] m68k: add Virtual M68k Machine

[Philippe Mathieu-Daudé]

On 3/18/21 12:10 PM, Peter Maydell wrote:
> On Thu, 18 Mar 2021 at 10:45, Paolo Bonzini  wrote:
>>
>> On 18/03/21 11:40, Peter Maydell wrote:
>>> On Thu, 18 Mar 2021 at 10:37, Paolo Bonzini  wrote:

 On 18/03/21 11:06, Laurent Vivier wrote:
> This also removes the virtio-devices test, I think we should keep the
> files, but in the files to disable the PCI part when it is not
> available.

 I think we should just shuffle the targets in the gitlab YAML to bypass
 the issue.
>>>
>>> Then we'll hit it again later. I'm pretty sure this isn't the
>>> first time we've run into "some test makes dubious assumptions"...
>>
>> We can both fix qemu-iotests and CI configuration, but m68k is certainly
>> not the culprit here.  And we are going to make more assumptions over
>> time, not fewer, in order to keep the CI time at bay.
> 
> I don't see why CI time is relevant to whether the test says
> "I require X,Y,Z, so don't run me on configs without those"
> or whether it just randomly assumes X,Y,Z are always present
> or that if it says "I require W" than W must imply X,Y,Z...

Recently we changed a bit our view and are trying to have smarter
tests. In particular building target/device agnostic tests, and
have the test queries the QEMU binary what features/devices are
available before running. This will take some time before we get
there, unlikely for the 6.0 release. For short term, Paolo's
"shuffle gitlab YAML" suggestion is simpler.

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Peter Maydell]

On Thu, 18 Mar 2021 at 11:09, Philippe Mathieu-Daudé  wrote:
> Still, I'm not sure it makes sense. If you want to migrate a such
> machine, KVM can not virtualize it, so you'll be forced to use TCG
> right? In that case cpu_tcg is built in and you have the A15.
>
> IOW the problem is not this patch, it is that since 82bf7ae84ce we
> can not migrate A15.

Do you mean "we can't migrate a TCG A15" ? That would be a problem.
Or do you mean "we can't migrate a KVM A15" ? That's entirely
expected when we drop support for KVM A15 :-)
Or do you mean "migration from KVM to TCG doesn't work?" That's
a pre-existing thing I don't expect to work (we don't put anything
in to stop it working, but I'm pretty sure there will be a bunch
of things that mean it doesn't in practice work.)

> So we need both 1/ revert 82bf7ae84ce and 2/ be sure the kernel
> support 32-bit host... Am I missing something?

We're definitely not reverting 82bf7ae84ce if we can avoid it...

thanks
-- PMM

Re: [PULL 00/11] emulated nvme updates and fixes

[Peter Maydell]

On Tue, 16 Mar 2021 at 21:47, Klaus Jensen  wrote:
>
> From: Klaus Jensen 
>
> Hi Peter,
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   git://git.infradead.org/qemu-nvme.git tags/nvme-next-pull-request
>
> for you to fetch changes up to e2c8dd15807886ca234cdd06eba47fa65162:
>
>   hw/block/nvme: add support for the format nvm command (2021-03-16 22:30:47 
> +0100)
>
> 
> emulated nvme updates and fixes
>
> * fixes for Coverity CID 1450756, 1450757 and 1450758 (me)
> * fix for a bug in zone management receive (me)
> * metadata and end-to-end data protection support (me & Gollu Appalanaidu)
> * verify support (Gollu Appalanaidu)
> * multiple lba formats and format nvm support (Minwoo Im)
>
> and a couple of misc refactorings from me.

>  hw/block/nvme-dif.h|   53 ++
>  hw/block/nvme-ns.h |   50 +-
>  hw/block/nvme-subsys.h |2 +
>  hw/block/nvme.h|   44 +-
>  include/block/nvme.h   |   29 +-
>  hw/block/nvme-dif.c|  508 
>  hw/block/nvme-ns.c |  124 +++-
>  hw/block/nvme-subsys.c |7 +-
>  hw/block/nvme.c| 1257 
>  hw/block/meson.build   |2 +-
>  hw/block/trace-events  |   22 +-
>  11 files changed, 1939 insertions(+), 159 deletions(-)
>  create mode 100644 hw/block/nvme-dif.h
>  create mode 100644 hw/block/nvme-dif.c

Hi. This tag includes a submodule update which is not mentioned
in the cover letter or listed in the cover letter diffstat:

 roms/opensbi   |2 +-

so I suspect it was inadvertent. Please fix up and resend.

thanks
-- PMM

Re: [PULL 00/11] emulated nvme updates and fixes

[Peter Maydell]

On Thu, 18 Mar 2021 at 11:27, Klaus Jensen  wrote:
>
> On Mar 18 11:26, Peter Maydell wrote:
> > On Tue, 16 Mar 2021 at 21:47, Klaus Jensen  wrote:
> > Hi. This tag includes a submodule update which is not mentioned
> > in the cover letter or listed in the cover letter diffstat:
> >
> >  roms/opensbi   |2 +-
> >
> > so I suspect it was inadvertent. Please fix up and resend.
> >
>
> Oh crap. Sorry!

No worries -- git makes this a very easy mistake to make when
doing rebases. That's why I have a check for it in my 'apply
a pull request' scripts :-)

thanks
-- PMM

Re: [PULL 00/11] emulated nvme updates and fixes

[Klaus Jensen]

On Mar 18 11:26, Peter Maydell wrote:
> On Tue, 16 Mar 2021 at 21:47, Klaus Jensen  wrote:
> >
> > From: Klaus Jensen 
> >
> > Hi Peter,
> >
> > The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
> >
> >   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' 
> > into staging (2021-03-16 10:53:47 +)
> >
> > are available in the Git repository at:
> >
> >   git://git.infradead.org/qemu-nvme.git tags/nvme-next-pull-request
> >
> > for you to fetch changes up to e2c8dd15807886ca234cdd06eba47fa65162:
> >
> >   hw/block/nvme: add support for the format nvm command (2021-03-16 
> > 22:30:47 +0100)
> >
> > 
> > emulated nvme updates and fixes
> >
> > * fixes for Coverity CID 1450756, 1450757 and 1450758 (me)
> > * fix for a bug in zone management receive (me)
> > * metadata and end-to-end data protection support (me & Gollu Appalanaidu)
> > * verify support (Gollu Appalanaidu)
> > * multiple lba formats and format nvm support (Minwoo Im)
> >
> > and a couple of misc refactorings from me.
> 
> >  hw/block/nvme-dif.h|   53 ++
> >  hw/block/nvme-ns.h |   50 +-
> >  hw/block/nvme-subsys.h |2 +
> >  hw/block/nvme.h|   44 +-
> >  include/block/nvme.h   |   29 +-
> >  hw/block/nvme-dif.c|  508 
> >  hw/block/nvme-ns.c |  124 +++-
> >  hw/block/nvme-subsys.c |7 +-
> >  hw/block/nvme.c| 1257 
> >  hw/block/meson.build   |2 +-
> >  hw/block/trace-events  |   22 +-
> >  11 files changed, 1939 insertions(+), 159 deletions(-)
> >  create mode 100644 hw/block/nvme-dif.h
> >  create mode 100644 hw/block/nvme-dif.c
> 
> Hi. This tag includes a submodule update which is not mentioned
> in the cover letter or listed in the cover letter diffstat:
> 
>  roms/opensbi   |2 +-
> 
> so I suspect it was inadvertent. Please fix up and resend.
> 

Oh crap. Sorry!


signature.asc
Description: PGP signature

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Philippe Mathieu-Daudé]

On 3/18/21 12:21 PM, Peter Maydell wrote:
> On Thu, 18 Mar 2021 at 11:09, Philippe Mathieu-Daudé  
> wrote:
>> Still, I'm not sure it makes sense. If you want to migrate a such
>> machine, KVM can not virtualize it, so you'll be forced to use TCG
>> right? In that case cpu_tcg is built in and you have the A15.
>>
>> IOW the problem is not this patch, it is that since 82bf7ae84ce we
>> can not migrate A15.
> 
> Do you mean "we can't migrate a TCG A15" ? That would be a problem.

No problem here.

> Or do you mean "we can't migrate a KVM A15" ? That's entirely
> expected when we drop support for KVM A15 :-)

Yes, this is why I mentioned this is mostly a problem for downstream
distributions.

> Or do you mean "migration from KVM to TCG doesn't work?" That's
> a pre-existing thing I don't expect to work (we don't put anything
> in to stop it working, but I'm pretty sure there will be a bunch
> of things that mean it doesn't in practice work.)
> 
>> So we need both 1/ revert 82bf7ae84ce and 2/ be sure the kernel
>> support 32-bit host... Am I missing something?
> 
> We're definitely not reverting 82bf7ae84ce if we can avoid it...

I tend to agree. The problem is for the running VMs started before
82bf7ae84ce (so up to any fork based on v5.2). I don't know what
the forks are supposed to do with the running VMs if they want to
migrate them to newer QEMU (or upgrade the host QEMU).

I don't expect a guest being happy and reliable if we underneath
change its CPU by another one while migrating it...

KVM to TCG is not tested much indeed, and I don't think the performance
impact will be well accepted :)

Re: arm_cpu_post_init (Was: Re: arm: "max" CPU class hierarchy changes possible?)

[Claudio Fontana]

On 3/18/21 12:06 PM, Claudio Fontana wrote:
> On 3/11/21 8:10 PM, Andrew Jones wrote:
>> On Thu, Mar 11, 2021 at 06:33:15PM +, Peter Maydell wrote:
>>> On Thu, 11 Mar 2021 at 17:16, Claudio Fontana  wrote:
 Maybe Peter you could clarify similarly what the intended meaning of "max" 
 is on ARM?
>>>
>>> "max" is "best we can do, whatever that is". (On KVM this is "same as
>>> the host".)
>>> "host" is "whatever the host is (KVM only)".
>>>
 KVM: (aarch64-only): aarch64_max_initfn():

 The following comment in the code seems wrong to me:

 /* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
 host); */

 This is not exactly true:

 "-cpu max" calls kvm_arm_set_cpu_features_from_host(), (which checks 
 "dtb_compatible", and if not set gets the features from the host, if set 
 ...?)
 After that, calls aarch64_add_sve_properties() and then adds also 
 "svw-max-vq". This code is common with TCG.
> 
> 
> As part of this research I noticed that arm_cpu_post_init() is quite 
> confusing, seems really inconsistent to me.
> 
> Apparently the intention was to call it from the leaf classes:
> 
> commit 51e5ef459eca045d7e8afe880ee60190f0b75b26
> Author: Marc-André Lureau 
> Date:   Tue Nov 27 12:55:59 2018 +0400
> 
> arm: replace instance_post_init()
> 
> Replace arm_cpu_post_init() instance callback by calling it from leaf
> classes, to avoid potential ordering issue with other post_init callbacks.
> 
> Signed-off-by: Marc-André Lureau 
> Suggested-by: Igor Mammedov 
> Reviewed-by: Igor Mammedov 
> Acked-by: Eduardo Habkost 
> 
> 
> but then we end up calling it multiple times in the class hierarch, which is 
> a recipe for bugs, and makes it difficult to understand what 
> arm_cpu_post_init()
> even means, what calling this function is supposed to do.
> 
> For a "max" or "host" cpu on AArch64, this function is called:
> 
> for the ARM CPU base class, TYPE_ARM_CPU, in
> 
> cpu.c::arm_cpu_instance_init,
> 
> then later again for the TYPE_AARCH64_CPU class, child of TYPE_ARM_CPU, in
> 
> cpu64.c::aarch64_cpu_instance_init,
> 
> then later again for the TYPE_ARM_HOST_CPU class, child of TYPE_AARCH64_CPU, 
> in
> 
> cpu.c::arm_host_initfn.
> 
> Same for "max".
> 
> When looking at 32bit CPUs instead, only the ARM CPU base class ends up 
> calling arm_cpu_post_init.
> "Leaf" classes do not do it (see cpu_tcg.c).
> 
> What is then arm_cpu_post_init even supposed to mean?


And why do we have a separate arm_cpu_finalize_features()?

Nothing in the ARM cpu classes initializations ever seems to be "final" to me.



> 
> Thanks,
> 
> Claudio
> 
> 

 In the case of cpu host instead,

 "-cpu host" calls kvm_arm_set_cpu_features_from_host(), same as max, then 
 calls aarch64_add_sve_properties() but does NOT add "svw-max-vq".

 Is this a bug?
>>
>> It was left out intentionally. More below.
>>
>>>
>>> Maybe; that's a question for Richard or Drew...
>>>
 Are "max" and "host" for KVM supposed to be the same like with x86?
>>
>> Yes, but my understanding of "max" == "host" for KVM is that that only
>> applies to the perspective of the guest. What CPU and what CPU features
>> the guest can see should be exactly the same with either "max" or "host",
>> depending on the enabling/disabling of any optional CPU properties.
>>
>> The question here seems to be that, if one has a CPU property, does that
>> imply the other should have the same? Which would effectively allow the
>> two to be aliases (when KVM is enabled). I don't know, does x86 ensure
>> 100% property compatibility?
>>
>> I opted not to support sve-max-vq for "host" because I consider it a
>> legacy CPU property, one I didn't want to propagate. Indeed it may
>> make more sense to depreciate sve-max-vq than to "fix" this issue
>> by adding it to "host". Note, we can already create equivalent SVE
>> CPUs. The following are the same from the perspective of the guest
>>
>>  -accel kvm -cpu host,sve512=on
>>  -accel kvm -cpu max,sve512=on
>>
>> And, for TCG, these are the same from the perspective of the guest
>>  
>>  -accel tcg -cpu max,sve512=on
>>  -accel tcg -cpu max,sve-max-vq=4
>>
>> So we already don't need sve-max-vq.
>>
>> Thanks,
>> drew
>>
> 

Re: [RFC PATCH 1/2] modules: introduce target specific modules

[Philippe Mathieu-Daudé]

Hi Halil,

On 3/16/21 1:26 PM, Halil Pasic wrote:
> After some back-and-forth in [1] Daniel suggested that
> we could/should make qemu modules per-target by introducing a
> dedicated modules directory for each target, which can symlink the
> modules that do work with and do make sense for the given target.
> 
> That way we can avoid trying to load modules we know won't work and
> coming up with convoluted ways for making subsequent failures graceful.
> The topic of per-target modules was discussed before [1] but, the
> idea with the symlinks originates from [1].
> 
> This patch introduces  this new scheme of loading modules without
> actually introducing any changes to what modules are available to what
> targets. For the exploitation have look at 'hw/s390x: modularize
> virtio-gpu-ccw'.
> 
> [1] https://mail.gnu.org/archive/html/qemu-s390x/2021-03/msg00206.html
> 
> Signed-off-by: Halil Pasic 
> Suggested-by: "Daniel P. Berrangé" 
> ---
>  hw/s390x/meson.build   |  1 -
>  include/qemu/module.h  |  2 ++
>  meson.build| 43 +-
>  roms/SLOF  |  2 +-
>  roms/opensbi   |  2 +-
>  scripts/call_generated_script.sh   |  6 +
>  scripts/modules/target-symlinks.sh | 31 +
>  softmmu/runstate.c |  1 +
>  util/module.c  | 13 +++--
>  9 files changed, 95 insertions(+), 6 deletions(-)
>  create mode 100755 scripts/call_generated_script.sh
>  create mode 100755 scripts/modules/target-symlinks.sh

> diff --git a/include/qemu/module.h b/include/qemu/module.h
> index 944d403cbd..85a59fde81 100644
> --- a/include/qemu/module.h
> +++ b/include/qemu/module.h
> @@ -73,4 +73,6 @@ bool module_load_one(const char *prefix, const char 
> *lib_name, bool mayfail);
>  void module_load_qom_one(const char *type);
>  void module_load_qom_all(void);
>  
> +void set_emulator_modules_dir(char const *dir_name);
> +
>  #endif
> diff --git a/meson.build b/meson.build
> index a7d2dd429d..8926968182 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1749,6 +1749,7 @@ user_ss = ss.source_set()
>  util_ss = ss.source_set()
>  
>  modules = {}
> +modules_restricted = {}
>  hw_arch = {}
>  target_arch = {}
>  target_softmmu_arch = {}
> @@ -2092,14 +2093,54 @@ common_ss.add(hwcore)
>  # Targets #
>  ###
>  
> +module_targets = []
>  foreach m : block_mods + softmmu_mods
> -  shared_module(m.name(),
> +   module_targets += shared_module(m.name(),
>  name_prefix: '',
>  link_whole: m,
>  install: true,
>  install_dir: qemu_moddir)
>  endforeach
>  
> +foreach target : target_dirs
> +  if not target.endswith('-softmmu')
> +continue
> +  endif
> +  filtered_module_targets = []
> +  foreach m : module_targets
> +restricted_to = modules_restricted.get(m.name(), [])
> +if restricted_to.length() == 0 or restricted_to.contains(target)
> +  filtered_module_targets += m
> +endif
> +  endforeach
> +  s = custom_target('Make symbolic links script for ' + target + ' modules' ,
> +input: filtered_module_targets,
> +output: 'make_mod_symlinks_'+target+'.sh',
> +install: false,
> +depends: filtered_module_targets,
> +build_by_default: true,
> +build_always_stale: true,
> +command: [
> + meson.current_source_dir() / 
> 'scripts/modules/target-symlinks.sh',
> +  '@OUTPUT@',
> +  target,
> +  '@INPUT@'
> +])
> +
> +  # We run the script as a part of the build so things keep working form the
> +  # build tree (without requiring an instalation). I couldn't find a nicer 
> way.
> +  custom_target('Run symbolic links script for ' + target + ' modules' ,
> +depends: s,
> +output: 'make_mod_symlinks_'+target+'.sh.dummy',
> +install: false,
> +build_by_default: true,
> +build_always_stale: true,
> +command: [
> +  s.full_path(),
> + meson.current_build_dir()
> +])
> +  meson.add_install_script(meson.current_source_dir() / 
> 'scripts/call_generated_script.sh', s.full_path(), qemu_moddir)
> +endforeach
>  softmmu_ss.add(authz, blockdev, chardev, crypto, io, qmp)
>  common_ss.add(qom, qemuutil)
>  
> diff --git a/roms/SLOF b/roms/SLOF
> index 33a7322de1..e18ddad851 16
> --- a/roms/SLOF
> +++ b/roms/SLOF
> @@ -1 +1 @@
> -Subproject commit 33a7322de13e9dca4b38851a345a58d37e7a441d
> +Subproject commit e18ddad8516ff2cfe36ec130200318f7251aa78c
> diff --git a/roms/opensbi b/roms/opensbi
> index 234ed8e427..a98258d0b5 16
> --- a/roms/opensbi
> +++ b/roms/opensbi
> @@ -1 +1 @@
> -Subproject commit 234ed8e427f4d92903123199f6590d144e0d9351
> +Subproject commit a98258d0b537

Re: [PATCH v2 3/3] target/arm: Restrict v7A TCG cpus to TCG accel

[Peter Maydell]

On Thu, 18 Mar 2021 at 11:31, Philippe Mathieu-Daudé  wrote:
> I tend to agree. The problem is for the running VMs started before
> 82bf7ae84ce (so up to any fork based on v5.2). I don't know what
> the forks are supposed to do with the running VMs if they want to
> migrate them to newer QEMU (or upgrade the host QEMU).

Anybody with a Cortex-A15 KVM VM is just going to have to stay
with their pre-existing ancient hardware, their pre-existing
host kernel and their pre-existing QEMU binary. That's what
"we deprecated and then dropped support for this" means:
we no longer support running that kind of VM, so users who
were doing it need to either do something else instead, or
else just keep on going with the old versions they have.

thanks
-- PMM

[PULL v2 00/11] emulated nvme updates and fixes

[Klaus Jensen]

From: Klaus Jensen 

Hi Peter,

The following changes since commit b12498fc575f2ad30f09fe78badc7fef526e2d76:

  Merge remote-tracking branch 'remotes/vivier/tags/q800-for-6.0-pull-request' 
into staging (2021-03-18 10:05:37 +)

are available in the Git repository at:

  git://git.infradead.org/qemu-nvme.git tags/nvme-next-pull-request

for you to fetch changes up to dc04d25e2f3f7e26f7f97b860992076b5f04afdb:

  hw/block/nvme: add support for the format nvm command (2021-03-18 12:41:43 
+0100)


emulated nvme updates and fixes

* fixes for Coverity CID 1450756, 1450757 and 1450758 (me)
* fix for a bug in zone management receive (me)
* metadata and end-to-end data protection support (me & Gollu Appalanaidu)
* verify support (Gollu Appalanaidu)
* multiple lba formats and format nvm support (Minwoo Im)

and a couple of misc refactorings from me.

v2:
  - remove an unintended submodule update. Argh.



Gollu Appalanaidu (1):
  hw/block/nvme: add verify command

Klaus Jensen (8):
  hw/block/nvme: fix potential overflow
  hw/block/nvme: assert namespaces array indices
  hw/block/nvme: fix zone management receive reporting too many zones
  hw/block/nvme: add metadata support
  hw/block/nvme: end-to-end data protection
  hw/block/nvme: add non-mdts command size limit for verify
  hw/block/nvme: prefer runtime helpers instead of device parameters
  hw/block/nvme: pull lba format initialization

Minwoo Im (2):
  hw/block/nvme: support multiple lba formats
  hw/block/nvme: add support for the format nvm command

 hw/block/nvme-dif.h|   53 ++
 hw/block/nvme-ns.h |   50 +-
 hw/block/nvme-subsys.h |2 +
 hw/block/nvme.h|   44 +-
 include/block/nvme.h   |   29 +-
 hw/block/nvme-dif.c|  508 
 hw/block/nvme-ns.c |  124 +++-
 hw/block/nvme-subsys.c |7 +-
 hw/block/nvme.c| 1257 
 hw/block/meson.build   |2 +-
 hw/block/trace-events  |   22 +-
 11 files changed, 1939 insertions(+), 159 deletions(-)
 create mode 100644 hw/block/nvme-dif.h
 create mode 100644 hw/block/nvme-dif.c

-- 
2.30.1

Re: [External] Re: [RFC PATCH 0/9] Support for Virtio-fs daemon crash reconnection

[Christian Schoenebeck]

On Mittwoch, 17. März 2021 13:57:47 CET Jiachen Zhang wrote:
> On Wed, Mar 17, 2021 at 7:50 PM Christian Schoenebeck <
> 
> qemu_...@crudebyte.com> wrote:
> > On Mittwoch, 17. März 2021 11:05:32 CET Stefan Hajnoczi wrote:
> > > On Fri, Dec 18, 2020 at 05:39:34PM +0800, Jiachen Zhang wrote:
> > > > Thanks for the suggestions. Actually, we choose to save all state
> > > > information to QEMU because a virtiofsd has the same lifecycle as its
> > > > QEMU master. However, saving things to a file do avoid communication
> > 
> > with
> > 
> > > > QEMU, and we no longer need to increase the complexity of vhost-user
> > > > protocol. The suggestion to save fds to the systemd is also very
> > > > reasonable
> > > > if we don't consider the lifecycle issues, we will try it.
> > > 
> > > Hi,
> > > We recently discussed crash recovery in the virtio-fs bi-weekly call and
> > > I read some of this email thread because it's a topic I'm interested in.
> > 
> > I just had a quick fly over the patches so far. Shouldn't there be some
> > kind
> > of constraint for an automatic reconnection feature after a crash to
> > prevent
> > this being exploited by ROP brute force attacks?
> > 
> > E.g. adding some (maybe continuously increasing) delay and/or limiting the
> > amount of reconnects within a certain time frame would come to my mind.
> > 
> > Best regards,
> > Christian Schoenebeck
> 
> Thanks, Christian. I am still trying to figure out the details of the ROP
> attacks.
> 
> However, QEMU's vhost-user reconnection is based on chardev socket
> reconnection. The socket reconnection can be enabled by the "--chardev
> socket,...,reconnect=N" in QEMU command options, in which N means QEMU will
> try to connect the disconnected socket every N seconds. We can increase N
> to increase the reconnect delay. If we want to change the reconnect delay
> dynamically, I think we should change the chardev socket reconnection code.
> It is a more generic mechanism than vhost-user-fs and vhost-user backend.
> 
> By the way, I also considered the socket reconnection delay time in the
> performance aspect. As the reconnection delay increase, if an application
> in the guest is doing I/Os, it will suffer larger tail latency. And for
> now, the smallest delay is 1 second, which is rather large for
> high-performance virtual I/O devices today. I think maybe a more performant
> and safer reconnect delay adjustment mechanism should be considered in the
> future. What are your thoughts?

So with N=1 an attacker could e.g. bypass a 16-bit PAC by brute-force in ~18 
hours (e.g. on Arm if PAC + MTE was enabled). With 24-bit PAC (no MTE) it 
would be ~194 days. Independent of what architecture and defend mechanism is 
used, there is always the possibility though that some kind of side channel 
attack exists that might require a much lower amount of attempts. So in an 
untrusted environment I would personally limit the amount of automatic 
reconnects and rather accept a down time for further investigation if a 
suspicious high amount of crashes happened.

And yes, if a dynamic delay scheme was deployed in future then starting with a 
value smaller than 1 second would make sense.

Best regards,
Christian Schoenebeck

Re: [PULL v2 00/11] emulated nvme updates and fixes

[Klaus Jensen]

On Mar 18 12:57, Klaus Jensen wrote:
> From: Klaus Jensen 
> 
> Hi Peter,
> 
> The following changes since commit b12498fc575f2ad30f09fe78badc7fef526e2d76:
> 
>   Merge remote-tracking branch 
> 'remotes/vivier/tags/q800-for-6.0-pull-request' into staging (2021-03-18 
> 10:05:37 +)
> 
> are available in the Git repository at:
> 
>   git://git.infradead.org/qemu-nvme.git tags/nvme-next-pull-request
> 
> for you to fetch changes up to dc04d25e2f3f7e26f7f97b860992076b5f04afdb:
> 
>   hw/block/nvme: add support for the format nvm command (2021-03-18 12:41:43 
> +0100)
> 
> 
> emulated nvme updates and fixes
> 
> * fixes for Coverity CID 1450756, 1450757 and 1450758 (me)
> * fix for a bug in zone management receive (me)
> * metadata and end-to-end data protection support (me & Gollu Appalanaidu)
> * verify support (Gollu Appalanaidu)
> * multiple lba formats and format nvm support (Minwoo Im)
> 
> and a couple of misc refactorings from me.
> 
> v2:
>   - remove an unintended submodule update. Argh.
> 
> 
> 
> Gollu Appalanaidu (1):
>   hw/block/nvme: add verify command
> 
> Klaus Jensen (8):
>   hw/block/nvme: fix potential overflow
>   hw/block/nvme: assert namespaces array indices
>   hw/block/nvme: fix zone management receive reporting too many zones
>   hw/block/nvme: add metadata support
>   hw/block/nvme: end-to-end data protection
>   hw/block/nvme: add non-mdts command size limit for verify
>   hw/block/nvme: prefer runtime helpers instead of device parameters
>   hw/block/nvme: pull lba format initialization
> 
> Minwoo Im (2):
>   hw/block/nvme: support multiple lba formats
>   hw/block/nvme: add support for the format nvm command
> 
>  hw/block/nvme-dif.h|   53 ++
>  hw/block/nvme-ns.h |   50 +-
>  hw/block/nvme-subsys.h |2 +
>  hw/block/nvme.h|   44 +-
>  include/block/nvme.h   |   29 +-
>  hw/block/nvme-dif.c|  508 
>  hw/block/nvme-ns.c |  124 +++-
>  hw/block/nvme-subsys.c |7 +-
>  hw/block/nvme.c| 1257 
>  hw/block/meson.build   |2 +-
>  hw/block/trace-events  |   22 +-
>  11 files changed, 1939 insertions(+), 159 deletions(-)
>  create mode 100644 hw/block/nvme-dif.h
>  create mode 100644 hw/block/nvme-dif.c
> 
> -- 
> 2.30.1
> 

Following a convention I've seen on the list, I'm only re-sending the
cover letter since there are no changes to any of the patches, only the
tag.


signature.asc
Description: PGP signature

Re: [PULL 00/11] emulated nvme updates and fixes

[Klaus Jensen]

On Mar 18 11:28, Peter Maydell wrote:
> On Thu, 18 Mar 2021 at 11:27, Klaus Jensen  wrote:
> >
> > On Mar 18 11:26, Peter Maydell wrote:
> > > On Tue, 16 Mar 2021 at 21:47, Klaus Jensen  wrote:
> > > Hi. This tag includes a submodule update which is not mentioned
> > > in the cover letter or listed in the cover letter diffstat:
> > >
> > >  roms/opensbi   |2 +-
> > >
> > > so I suspect it was inadvertent. Please fix up and resend.
> > >
> >
> > Oh crap. Sorry!
> 
> No worries -- git makes this a very easy mistake to make when
> doing rebases. That's why I have a check for it in my 'apply
> a pull request' scripts :-)
> 

Out of curiosity, are there any obvious safe guards I can implement
myself to stop this from happening?


signature.asc
Description: PGP signature

Re: [RFC v2 05/13] vhost: Route guest->host notification through shadow virtqueue

[Eugenio Perez Martin]

On Thu, Mar 18, 2021 at 11:48 AM Eugenio Perez Martin
 wrote:
>
> On Thu, Mar 18, 2021 at 10:29 AM Jason Wang  wrote:
> >
> >
> > 在 2021/3/18 下午5:18, Eugenio Perez Martin 写道:
> > > On Thu, Mar 18, 2021 at 4:11 AM Jason Wang  wrote:
> > >>
> > >> 在 2021/3/18 上午12:47, Eugenio Perez Martin 写道:
> > >>> On Wed, Mar 17, 2021 at 3:05 AM Jason Wang  wrote:
> >  在 2021/3/16 下午6:31, Eugenio Perez Martin 写道:
> > > On Tue, Mar 16, 2021 at 8:18 AM Jason Wang  
> > > wrote:
> > >> 在 2021/3/16 上午3:48, Eugenio Pérez 写道:
> > >>> Shadow virtqueue notifications forwarding is disabled when vhost_dev
> > >>> stops, so code flow follows usual cleanup.
> > >>>
> > >>> Signed-off-by: Eugenio Pérez 
> > >>> ---
> > >>>  hw/virtio/vhost-shadow-virtqueue.h |   7 ++
> > >>>  include/hw/virtio/vhost.h  |   4 +
> > >>>  hw/virtio/vhost-shadow-virtqueue.c | 113 
> > >>> ++-
> > >>>  hw/virtio/vhost.c  | 143 
> > >>> -
> > >>>  4 files changed, 265 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/hw/virtio/vhost-shadow-virtqueue.h 
> > >>> b/hw/virtio/vhost-shadow-virtqueue.h
> > >>> index 6cc18d6acb..c891c6510d 100644
> > >>> --- a/hw/virtio/vhost-shadow-virtqueue.h
> > >>> +++ b/hw/virtio/vhost-shadow-virtqueue.h
> > >>> @@ -17,6 +17,13 @@
> > >>>
> > >>>  typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
> > >>>
> > >>> +bool vhost_shadow_vq_start(struct vhost_dev *dev,
> > >>> +   unsigned idx,
> > >>> +   VhostShadowVirtqueue *svq);
> > >>> +void vhost_shadow_vq_stop(struct vhost_dev *dev,
> > >>> +  unsigned idx,
> > >>> +  VhostShadowVirtqueue *svq);
> > >>> +
> > >>>  VhostShadowVirtqueue *vhost_shadow_vq_new(struct vhost_dev 
> > >>> *dev, int idx);
> > >>>
> > >>>  void vhost_shadow_vq_free(VhostShadowVirtqueue *vq);
> > >>> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
> > >>> index ac963bf23d..7ffdf9aea0 100644
> > >>> --- a/include/hw/virtio/vhost.h
> > >>> +++ b/include/hw/virtio/vhost.h
> > >>> @@ -55,6 +55,8 @@ struct vhost_iommu {
> > >>>  QLIST_ENTRY(vhost_iommu) iommu_next;
> > >>>  };
> > >>>
> > >>> +typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
> > >>> +
> > >>>  typedef struct VhostDevConfigOps {
> > >>>  /* Vhost device config space changed callback
> > >>>   */
> > >>> @@ -83,7 +85,9 @@ struct vhost_dev {
> > >>>  uint64_t backend_cap;
> > >>>  bool started;
> > >>>  bool log_enabled;
> > >>> +bool shadow_vqs_enabled;
> > >>>  uint64_t log_size;
> > >>> +VhostShadowVirtqueue **shadow_vqs;
> > >> Any reason that you don't embed the shadow virtqueue into
> > >> vhost_virtqueue structure?
> > >>
> > > Not really, it could be relatively big and I would prefer SVQ
> > > members/methods to remain hidden from any other part that includes
> > > vhost.h. But it could be changed, for sure.
> > >
> > >> (Note that there's a masked_notifier in struct vhost_virtqueue).
> > >>
> > > They are used differently: in SVQ the masked notifier is a pointer,
> > > and if it's NULL the SVQ code knows that device is not masked. The
> > > vhost_virtqueue is the real owner.
> >  Yes, but it's an example for embedding auxciliary data structures in 
> >  the
> >  vhost_virtqueue.
> > 
> > 
> > > It could be replaced by a boolean in SVQ or something like that, I
> > > experimented with a tri-state too (UNMASKED, MASKED, MASKED_NOTIFIED)
> > > and let vhost.c code to manage all the transitions. But I find clearer
> > > the pointer use, since it's the more natural for the
> > > vhost_virtqueue_mask, vhost_virtqueue_pending existing functions.
> > >
> > > This masking/unmasking is the part I dislike the most from this
> > > series, so I'm very open to alternatives.
> >  See below. I think we don't even need to care about that.
> > 
> > 
> > >>>  Error *migration_blocker;
> > >>>  const VhostOps *vhost_ops;
> > >>>  void *opaque;
> > >>> diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> > >>> b/hw/virtio/vhost-shadow-virtqueue.c
> > >>> index 4512e5b058..3e43399e9c 100644
> > >>> --- a/hw/virtio/vhost-shadow-virtqueue.c
> > >>> +++ b/hw/virtio/vhost-shadow-virtqueue.c
> > >>> @@ -8,9 +8,12 @@
> > >>>   */
> > >>>
> > >>>  #include "hw/virtio/vhost-shadow-virtqueue.h"
> > >>> +#include "hw/virtio/vhost.h"
> > >>> +
> > >>> +#include "standard-headers/linux/vhost_types.h"
> > >>>
> > >>>  #inclu