Re: [PATCH v2 5/6] spice: get monitors physical dimension

[Frediano Ziglio]

> 
> From: Marc-André Lureau 
> 
> Note that for consistency, we use the same logic as MonitorsConfig to
> figure out the associated monitor. However, I can't find traces of the
> discussion/patches about the "new spice-server" behaviour: it still uses
> the multiple-configurations path in git master.
> 

This part is now obsolete.

> Signed-off-by: Marc-André Lureau 
> ---
>  include/ui/console.h | 3 +++
>  ui/spice-display.c   | 9 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/include/ui/console.h b/include/ui/console.h
> index 353d2e49a1..e7303d8b98 100644
> --- a/include/ui/console.h
> +++ b/include/ui/console.h
> @@ -119,6 +119,9 @@ typedef struct DisplaySurface {
>  } DisplaySurface;
>  
>  typedef struct QemuUIInfo {
> +/* physical dimension */
> +uint16_t width_mm;
> +uint16_t height_mm;
>  /* geometry */
>  int   xoff;
>  int   yoff;
> diff --git a/ui/spice-display.c b/ui/spice-display.c
> index b304c13149..a10f72bc5c 100644
> --- a/ui/spice-display.c
> +++ b/ui/spice-display.c
> @@ -679,7 +679,16 @@ static int interface_client_monitors_config(QXLInstance
> *sin,
>  info.width  = mc->monitors[head].width;
>  info.height = mc->monitors[head].height;
>  }
> +#if SPICE_SERVER_VERSION >= 0x000e04 /* release 0.14.4 */
> +if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) {
> +VDAgentMonitorMM *mm = (void *)&mc->monitors[mc->num_of_monitors];
>  
> +if (mc->num_of_monitors > head) {

This check is the same of above. Won't be better to move al these block
inside the above if block and remove here?

> +info.width_mm = mm[head].width;
> +info.height_mm = mm[head].height;
> +}
> +}
> +#endif
>  trace_qemu_spice_ui_info(ssd->qxl.id, info.width, info.height);
>  dpy_set_ui_info(ssd->dcl.con, &info);
>  return 1;

Frediano

Re: [RFC v4 17/70] target/riscv: rvv-1.0: configure instructions

[Frank Chang]

On Sat, Sep 26, 2020 at 2:28 AM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 9/25/20 1:51 AM, Frank Chang wrote:
> > trans_vsetvli() uses gen_goto_tb() to save the computation in the link
> to the
> > next TB.
> > I know there was a discussion about this back in RVV v0.7.1:
> >
> https://patchew.org/QEMU/20200103033347.20909-1-zhiwei_...@c-sky.com/20200103033347.20909-5-zhiwei_...@c-sky.com/
> >
> > However, we had encountered an issue that looked like it was caused by
> the
> > linked TB.
> > The code snippet which cause the issue is:
> >
> > 000104a8 : 104a8: 0122ffd7 vsetvli t6,t0,e32,m4,tu,mu,d1
> 104ac:
> > 02036407 vle32.v v8,(t1) 104b0: 028a0a57 vadd.vv v20,v8,v20 104b4:
> 41f282b3 sub
> > t0,t0,t6 104b8: 002f9893 slli a7,t6,0x2 104bc: 9346 add t1,t1,a7 104be:
> > fe0295e3 bnez t0,104a8  104c2: 012f7057 vsetvli
> zero,t5,e32,m4,tu,mu,d1
> > .
> >
> > If $t0 is given with the value, e.g. 68.
> >  is expected to process 32 elements in each iteration.
> > That's it, the env->vl after vsetvli at 0x104a8 in each iteration would
> be:
> > 1st iteration: 32 (remaining elements to be processed: 68 - 32 = 36)
> > 2nd iteration: 32 (remaining elements to be processed: 36 - 32 = 4)
> > 3rd iteration: 4 (remaining elements to be processed: 4 - 4 = 0, will
> leave
> >  after 0x104be)
> >
> > vadd.vv at 0x104b0 is implemented with gvec for acceleration:
> >
> > if (a->vm && s->vl_eq_vlmax) {
> > gvec_fn(s->sew, vreg_ofs(s, a->rd),
> > vreg_ofs(s, a->rs2), vreg_ofs(s, a->rs1),
> > MAXSZ(s), MAXSZ(s));
> > } else {
> > uint32_t data = 0;
> >
> > data = FIELD_DP32(data, VDATA, VM, a->vm);
> > data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
> > tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
> >vreg_ofs(s, a->rs1), vreg_ofs(s, a->rs2),
> >cpu_env, 0, s->vlen / 8, data, fn);
> > }
> >
> > gvec function is used when a->vm and s->vl_eq_vlmax are both true.
> > However, s->vl_eq_vlmax, for the above case, is only true in 1st and 2nd
> > iterations.
> > In third iteration, env->vl is 4 which is not equal to vlmax = 32.
> > But as the TB where vadd.vv resides are already linked with vsetvli's TB,
> > it won't be retranslated and still use the same gvec function in the
> third
> > iteration.
> > The total elemented being proceeded would be: 32 + 32 + 32 = 96, instead
> of 68.
> >
> > I'm wondering under such conditions, is it still correct to use
> gen_goto_tb() here?
> > Or we should use lookup_and_goto_ptr() as in trans_vsetvl() to not link
> the TBs.
>
> You're correct -- because of vl_eq_vlmax we can't use goto_tb when using a
> variable input.
>
> It would be possible when using xN,x0 for VLMAX, or x0,x0 for reuse of the
> current vl, but I doubt it's worth special-casing that.
>
> I wonder if the goto_tb conversation happened before we introduced
> vl_eq_vlmax
> and forgot to re-evaluate, or if I just missed that in the first place.
> Anyway, thanks for finding this.
>
>
> r~
>

Thanks Richard, I'll include the fix in my next version patchset.

Frank Chang

Re: [PATCH] build: Build and install the info manual.

[Maxim Cournoyer]

Hello Peter,

Peter Maydell  writes:

> On Fri, 25 Sep 2020 at 07:27, Maxim Cournoyer  
> wrote:
>>
>> Take advantage of the Sphinx texinfo backend to generate a QEMU info
>> manual.  The texinfo format allows for more structure and info readers
>> provide more advanced navigation capabilities compared to manpages
>> readers.
>
> Not providing an info manual (or indeed any format other than HTML
> and manpages) was a deliberate design choice. The rationale is that
> checking that multiple document formats all ended up rendering
> correctly is more work than people will in practice put in (as
> demonstrated by various errors in the old HTML rendering, for
> instance).

It seems to me that any problem found in the texinfo rendering produced
by Sphinx would be a bug in Sphinx, which could simply be forwarded
upstream when encountered.  My experience with Sphinx-generated texinfo
manuals is rather good.  The CMake project allows producing an info
manual that way, for example, and the result is at least as usable as
their HTML-based doc (as an avid info user, I'd say more usable, given
most commands are indexed).

>> * configure (infodir): Add the --infodir option, which allows
>> configuring the directory under which the info manuals are installed.
>> * docs/index.rst: Include the top level documents to prevent
>> warnings (treated as errors by sphinx-build).
>
> This isn't the right thing. You should be pointing sphinx-build
> at each of the individual manuals (system, interop, etc) and
> generating one info file for each. This is because we generate
> manuals for each of these including the 'devel' manual, but
> we don't want to install 'devel', because it's developer-facing
> and not needed by end-users of QEMU.

Is this the only reason individual manuals are being generated?  It
makes sense for the manpages (which have their own macros), but
otherwise (for HTML and info) introduces a lot of complexity for not
much gain, in my opinion.  Users not wanting to know about devel
internals can simply skip that section; no harm done.

The individual manuals are all stitched back together using a top
index.html page (derived from index.html.in), anyway.  That'd be better
taken care of by Sphinx automatically upon generating the whole doc
tree, in my opinion, as it seems to be the way it was designed to work
and simplifies things all around.

I initially went the individual manual route and devised complicated
Make macros and got individual info manuals produced, only to find out I
wanted to replicate that index.html.in in the texinfo format (Texinfo is
as navigable as HTML, so having every QEMU manual under the same node as
different sections makes more sense in my opinion).  The individually
produced info manual were also all named 'QEMU Documentation' rather
than with their own more accurate names, because of directives in the
included the top-level conf.py.

> won't find you have problems with the orphan top level documents.
>
> (We really need to move those orphan docs into the right places
> in the manual structure at some point.)

We could simply put them in another section called "Others" as a
starting point.  For this patch we can also choose to ignore them rather
than include them, but if someone went to the length of writing those
docs, I'd argue it was to be read rather than forgotten :-).

>> * docs/meson.build (sphinxinfo): Add new target.
>
> You've forgotten your Signed-off-by: line.

I've added it in my local tree; will wait for your feedback on my above
comments before sending an updated patch.

Thanks for the review,

Maxim

[Bug 1070762] Re: savevm fails with inserted CD, "Device '%s' is writable but does not support snapshots."

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  savevm fails with inserted CD, "Device '%s' is writable but does not
  support  snapshots."

Status in QEMU:
  Expired

Bug description:
  Hi,

  yesterday unfortunately a customer reported a failed snapshot of his
  VM. Going through the logfile I discovered:

  "Device 'ide1-cd0' is writable but does not support snapshots"

  this is with qemu-1.2.0 and 1.0.1 at least...

  Why writeable?
  Even if I specify "-drive ...,readonly=on,snapshot=off" to qemu the 
monitor-command sees the CD-ROM-device as being writeable?!

  Somewhere I saw a "hint" for blockdev.c:
  === snip ===

  --- /tmp/blockdev.c   2012-10-24 11:37:10.0 +0200
  +++ blockdev.c2012-10-24 11:37:17.0 +0200
  @@ -551,6 +551,7 @@
   case IF_XEN:
   case IF_NONE:
   dinfo->media_cd = media == MEDIA_CDROM;
  + dinfo->bdrv->read_only = 1;
   break;
   case IF_SD:
   case IF_FLOPPY:

  === snap ===

  after installing with this small patch applied it works, so insert CD, savevm 
 succeeds.
  This should be fixed at all correct places, and the tags 
"readonly=on,snapshot=off" should do it, too. Or even just work after 
specifying a drive being a CD-rom should do the trick ;-)

  Another "bad habit" is, that the ISO/DVD-file has to be writeable to
  be changed?

  Thnx for attention and regards,

  Oliver.

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

Re: Re: [PATCH] Fix stack smashing when handling PR_GET_PDEATHSIG

[Stephen Long]

>>  linux-user/syscall.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 05f0391..91f9114 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -10256,7 +10256,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
>> abi_long arg1,
>>  int deathsig;
>>  ret = get_errno(prctl(arg1, &deathsig, arg3, arg4, arg5));
>>  if (!is_error(ret) && arg2
>> -&& put_user_ual(deathsig, arg2)) {
>> +&& put_user_s32(deathsig, arg2)) {
>>  return -TARGET_EFAULT;
>>  }
>>  return ret;

Hi Laurent, is it possible to get this patch into master?

Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925172604.2142227-1-pbonz...@redhat.com/



Hi,

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

Type: series
Message-id: 20200925172604.2142227-1-pbonz...@redhat.com
Subject: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi 
iothread

=== 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 ===

Switched to a new branch 'test'
c3f0c8f scsi/scsi_bus: fix races in REPORT LUNS
9de4834 virtio-scsi: use scsi_device_get
7da82c3 scsi/scsi_bus: Add scsi_device_get
eb46533 scsi/scsi-bus: scsi_device_find: don't return unrealized devices
8c11273 device-core: use atomic_set on .realized property
939dcba device-core: use RCU for list of children of a bus
0002336 device_core: use drain_call_rcu in in hmp_device_del/qmp_device_add
efc35ef scsi/scsi_bus: switch search direction in scsi_device_find
0deb2b0 scsi: switch to bus->check_address
f57e102 qdev: add "check if address free" callback for buses

=== OUTPUT BEGIN ===
1/10 Checking commit f57e10207f21 (qdev: add "check if address free" callback 
for buses)
2/10 Checking commit 0deb2b0d8478 (scsi: switch to bus->check_address)
ERROR: code indent should never use tabs
#53: FILE: hw/scsi/scsi-bus.c:137:
+^I^I^I^I int channel, int target, int lun,$

ERROR: code indent should never use tabs
#54: FILE: hw/scsi/scsi-bus.c:138:
+^I^I^I^I SCSIDevice **p_dev)$

WARNING: line over 80 characters
#69: FILE: hw/scsi/scsi-bus.c:153:
+static bool scsi_bus_check_address(BusState *qbus, DeviceState *qdev, Error 
**errp)

WARNING: line over 80 characters
#89: FILE: hw/scsi/scsi-bus.c:173:
+if (!scsi_bus_is_address_free(bus, dev->channel, dev->id, dev->lun, 
&d)) {

WARNING: line over 80 characters
#128: FILE: hw/scsi/scsi-bus.c:195:
+is_free = scsi_bus_is_address_free(bus, dev->channel, ++id, 
dev->lun, NULL);

WARNING: line over 80 characters
#141: FILE: hw/scsi/scsi-bus.c:205:
+is_free = scsi_bus_is_address_free(bus, dev->channel, dev->id, 
++lun, NULL);

total: 2 errors, 4 warnings, 182 lines checked

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

3/10 Checking commit efc35ef5a2ad (scsi/scsi_bus: switch search direction in 
scsi_device_find)
4/10 Checking commit 000233693d95 (device_core: use drain_call_rcu in in 
hmp_device_del/qmp_device_add)
5/10 Checking commit 939dcbab7a50 (device-core: use RCU for list of children of 
a bus)
6/10 Checking commit 8c112731188a (device-core: use atomic_set on .realized 
property)
7/10 Checking commit eb46533b2b49 (scsi/scsi-bus: scsi_device_find: don't 
return unrealized devices)
8/10 Checking commit 7da82c3d163f (scsi/scsi_bus: Add scsi_device_get)
9/10 Checking commit 9de4834b2871 (virtio-scsi: use scsi_device_get)
10/10 Checking commit c3f0c8f18f10 (scsi/scsi_bus: fix races in REPORT LUNS)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200925172604.2142227-1-pbonz...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925172604.2142227-1-pbonz...@redhat.com/



Hi,

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

Type: series
Message-id: 20200925172604.2142227-1-pbonz...@redhat.com
Subject: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi 
iothread

=== 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 ===

From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200925172604.2142227-1-pbonz...@redhat.com -> 
patchew/20200925172604.2142227-1-pbonz...@redhat.com
Switched to a new branch 'test'
9932c24 scsi/scsi_bus: fix races in REPORT LUNS
1b75dae virtio-scsi: use scsi_device_get
5cdf821 scsi/scsi_bus: Add scsi_device_get
47cdfc0 scsi/scsi-bus: scsi_device_find: don't return unrealized devices
75ce260 device-core: use atomic_set on .realized property
a417bc2 device-core: use RCU for list of children of a bus
8e81334 device_core: use drain_call_rcu in in hmp_device_del/qmp_device_add
ec790ac scsi/scsi_bus: switch search direction in scsi_device_find
b9c2f95 scsi: switch to bus->check_address
0519c6e qdev: add "check if address free" callback for buses

=== OUTPUT BEGIN ===
1/10 Checking commit 0519c6ec5850 (qdev: add "check if address free" callback 
for buses)
2/10 Checking commit b9c2f95892cb (scsi: switch to bus->check_address)
ERROR: code indent should never use tabs
#53: FILE: hw/scsi/scsi-bus.c:137:
+^I^I^I^I int channel, int target, int lun,$

ERROR: code indent should never use tabs
#54: FILE: hw/scsi/scsi-bus.c:138:
+^I^I^I^I SCSIDevice **p_dev)$

WARNING: line over 80 characters
#69: FILE: hw/scsi/scsi-bus.c:153:
+static bool scsi_bus_check_address(BusState *qbus, DeviceState *qdev, Error 
**errp)

WARNING: line over 80 characters
#89: FILE: hw/scsi/scsi-bus.c:173:
+if (!scsi_bus_is_address_free(bus, dev->channel, dev->id, dev->lun, 
&d)) {

WARNING: line over 80 characters
#128: FILE: hw/scsi/scsi-bus.c:195:
+is_free = scsi_bus_is_address_free(bus, dev->channel, ++id, 
dev->lun, NULL);

WARNING: line over 80 characters
#141: FILE: hw/scsi/scsi-bus.c:205:
+is_free = scsi_bus_is_address_free(bus, dev->channel, dev->id, 
++lun, NULL);

total: 2 errors, 4 warnings, 182 lines checked

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

3/10 Checking commit ec790aca5ae9 (scsi/scsi_bus: switch search direction in 
scsi_device_find)
4/10 Checking commit 8e81334e7b46 (device_core: use drain_call_rcu in in 
hmp_device_del/qmp_device_add)
5/10 Checking commit a417bc2b8f36 (device-core: use RCU for list of children of 
a bus)
6/10 Checking commit 75ce26036080 (device-core: use atomic_set on .realized 
property)
7/10 Checking commit 47cdfc0d2962 (scsi/scsi-bus: scsi_device_find: don't 
return unrealized devices)
8/10 Checking commit 5cdf82120022 (scsi/scsi_bus: Add scsi_device_get)
9/10 Checking commit 1b75daed11e0 (virtio-scsi: use scsi_device_get)
10/10 Checking commit 9932c24a76f7 (scsi/scsi_bus: fix races in REPORT LUNS)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200925172604.2142227-1-pbonz...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925172604.2142227-1-pbonz...@redhat.com/



Hi,

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

Type: series
Message-id: 20200925172604.2142227-1-pbonz...@redhat.com
Subject: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi 
iothread

=== 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 ===

Switched to a new branch 'test'
0791629 scsi/scsi_bus: fix races in REPORT LUNS
87daae1 virtio-scsi: use scsi_device_get
bca3b34 scsi/scsi_bus: Add scsi_device_get
f87edcf scsi/scsi-bus: scsi_device_find: don't return unrealized devices
4bcc453 device-core: use atomic_set on .realized property
ebe1f7c device-core: use RCU for list of children of a bus
6297cbe device_core: use drain_call_rcu in in hmp_device_del/qmp_device_add
318e1e4 scsi/scsi_bus: switch search direction in scsi_device_find
5ad95de scsi: switch to bus->check_address
998aee1 qdev: add "check if address free" callback for buses

=== OUTPUT BEGIN ===
1/10 Checking commit 998aee1a14ad (qdev: add "check if address free" callback 
for buses)
2/10 Checking commit 5ad95de05950 (scsi: switch to bus->check_address)
ERROR: code indent should never use tabs
#53: FILE: hw/scsi/scsi-bus.c:137:
+^I^I^I^I int channel, int target, int lun,$

ERROR: code indent should never use tabs
#54: FILE: hw/scsi/scsi-bus.c:138:
+^I^I^I^I SCSIDevice **p_dev)$

WARNING: line over 80 characters
#69: FILE: hw/scsi/scsi-bus.c:153:
+static bool scsi_bus_check_address(BusState *qbus, DeviceState *qdev, Error 
**errp)

WARNING: line over 80 characters
#89: FILE: hw/scsi/scsi-bus.c:173:
+if (!scsi_bus_is_address_free(bus, dev->channel, dev->id, dev->lun, 
&d)) {

WARNING: line over 80 characters
#128: FILE: hw/scsi/scsi-bus.c:195:
+is_free = scsi_bus_is_address_free(bus, dev->channel, ++id, 
dev->lun, NULL);

WARNING: line over 80 characters
#141: FILE: hw/scsi/scsi-bus.c:205:
+is_free = scsi_bus_is_address_free(bus, dev->channel, dev->id, 
++lun, NULL);

total: 2 errors, 4 warnings, 182 lines checked

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

3/10 Checking commit 318e1e496e9e (scsi/scsi_bus: switch search direction in 
scsi_device_find)
4/10 Checking commit 6297cbe94121 (device_core: use drain_call_rcu in in 
hmp_device_del/qmp_device_add)
5/10 Checking commit ebe1f7cd3ce0 (device-core: use RCU for list of children of 
a bus)
6/10 Checking commit 4bcc453b4b1c (device-core: use atomic_set on .realized 
property)
7/10 Checking commit f87edcfc20e5 (scsi/scsi-bus: scsi_device_find: don't 
return unrealized devices)
8/10 Checking commit bca3b34e3e66 (scsi/scsi_bus: Add scsi_device_get)
9/10 Checking commit 87daae1b9d04 (virtio-scsi: use scsi_device_get)
10/10 Checking commit 079162965856 (scsi/scsi_bus: fix races in REPORT LUNS)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200925172604.2142227-1-pbonz...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH] i386: Document when features can be added to kvm_default_props

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925211021.4158567-1-ehabk...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or 
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
  TESTiotest-qcow2: 024
socket_accept failed: Resource temporarily unavailable
**
ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: 
assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
../src/tests/qtest/libqtest.c:166: kill_qemu() tried to terminate QEMU process 
but encountered exit status 1 (expected 0)
ERROR qtest-aarch64: bios-tables-test - Bail out! 
ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: 
assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
make: *** [run-test-159] Error 1
make: *** Waiting for unfinished jobs
  TESTiotest-qcow2: 025
  TESTiotest-qcow2: 027
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', 
'--label', 'com.qemu.instance.uuid=1bf1802df7d443929b92e9534e4a83ff', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 
'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-q5cgi4gp/src/docker-src.2020-09-25-20.07.00.10236:/var/tmp/qemu:z,ro',
 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=1bf1802df7d443929b92e9534e4a83ff
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-q5cgi4gp/src'
make: *** [docker-run-test-quick@centos7] Error 2

real18m15.588s
user0m16.838s


The full log is available at
http://patchew.org/logs/20200925211021.4158567-1-ehabk...@redhat.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH] load_elf: Remove unused address variables from callers

[Alistair Francis]

On Wed, Sep 23, 2020 at 2:15 PM BALATON Zoltan  wrote:
>
> On Tue, 7 Jul 2020, BALATON Zoltan wrote:
> > On Tue, 7 Jul 2020, Alistair Francis wrote:
> >> On Sun, Jul 5, 2020 at 10:41 AM BALATON Zoltan  wrote:
> >>> Several callers of load_elf() pass pointers for lowaddr and highaddr
> >>> parameters which are then not used for anything. This may stem from a
> >>> misunderstanding that load_elf need a value here but in fact it can
> >>> take NULL to ignore these values. Remove such unused variables and
> >>> pass NULL instead from callers that don't need these.
> >>>
> >>> Signed-off-by: BALATON Zoltan 
> >>
> >> Reviewed-by: Alistair Francis 
> >
> > So this got a few review and acked by but since it touches multiple parts 
> > who
> > will actually send pull or merge it? I'd like to make sure this won't miss
> > the freeze deadline just because everybody thinks this should go in via some
> > other maintainer. What's the best way for this? Trivial maintainers or Peter
> > should handle such patches?
>
> Ping? Could someone please queue this patch? It still seems to apply
> cleanly.

I've got to send a register API PR, I'll add this one to it unless
someone else wants to take it.

Alistair

>
> Regards,
> BALATON Zoltan
>
> >>> ---
> >>>  hw/alpha/dp264.c   |  8 
> >>>  hw/arm/armv7m.c|  4 +---
> >>>  hw/cris/boot.c |  4 ++--
> >>>  hw/microblaze/boot.c   |  4 ++--
> >>>  hw/mips/fuloong2e.c|  8 
> >>>  hw/moxie/moxiesim.c|  4 ++--
> >>>  hw/nios2/boot.c|  4 ++--
> >>>  hw/ppc/mac_newworld.c  |  6 ++
> >>>  hw/ppc/mac_oldworld.c  |  6 ++
> >>>  hw/ppc/ppc440_bamboo.c |  9 +++--
> >>>  hw/ppc/sam460ex.c  | 12 +---
> >>>  hw/ppc/spapr.c | 11 ---
> >>>  hw/ppc/virtex_ml507.c  |  4 ++--
> >>>  hw/riscv/boot.c|  8 
> >>>  hw/xtensa/sim.c|  3 +--
> >>>  hw/xtensa/xtfpga.c |  3 +--
> >>>  16 files changed, 41 insertions(+), 57 deletions(-)
> >>>
> >>> diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
> >>> index f7751b18f6..4d24518d1d 100644
> >>> --- a/hw/alpha/dp264.c
> >>> +++ b/hw/alpha/dp264.c
> >>> @@ -62,8 +62,8 @@ static void clipper_init(MachineState *machine)
> >>>  qemu_irq rtc_irq;
> >>>  long size, i;
> >>>  char *palcode_filename;
> >>> -uint64_t palcode_entry, palcode_low, palcode_high;
> >>> -uint64_t kernel_entry, kernel_low, kernel_high;
> >>> +uint64_t palcode_entry;
> >>> +uint64_t kernel_entry, kernel_low;
> >>>  unsigned int smp_cpus = machine->smp.cpus;
> >>>
> >>>  /* Create up to 4 cpus.  */
> >>> @@ -113,7 +113,7 @@ static void clipper_init(MachineState *machine)
> >>>  exit(1);
> >>>  }
> >>>  size = load_elf(palcode_filename, NULL, cpu_alpha_superpage_to_phys,
> >>> -NULL, &palcode_entry, &palcode_low, &palcode_high,
> >>> NULL,
> >>> +NULL, &palcode_entry, NULL, NULL, NULL,
> >>>  0, EM_ALPHA, 0, 0);
> >>>  if (size < 0) {
> >>>  error_report("could not load palcode '%s'", palcode_filename);
> >>> @@ -132,7 +132,7 @@ static void clipper_init(MachineState *machine)
> >>>  uint64_t param_offset;
> >>>
> >>>  size = load_elf(kernel_filename, NULL,
> >>> cpu_alpha_superpage_to_phys,
> >>> -NULL, &kernel_entry, &kernel_low, &kernel_high,
> >>> NULL,
> >>> +NULL, &kernel_entry, &kernel_low, NULL, NULL,
> >>>  0, EM_ALPHA, 0, 0);
> >>>  if (size < 0) {
> >>>  error_report("could not load kernel '%s'", kernel_filename);
> >>> diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
> >>> index 3308211e9c..92f859d760 100644
> >>> --- a/hw/arm/armv7m.c
> >>> +++ b/hw/arm/armv7m.c
> >>> @@ -309,7 +309,6 @@ void armv7m_load_kernel(ARMCPU *cpu, const char
> >>> *kernel_filename, int mem_size)
> >>>  {
> >>>  int image_size;
> >>>  uint64_t entry;
> >>> -uint64_t lowaddr;
> >>>  int big_endian;
> >>>  AddressSpace *as;
> >>>  int asidx;
> >>> @@ -330,12 +329,11 @@ void armv7m_load_kernel(ARMCPU *cpu, const char
> >>> *kernel_filename, int mem_size)
> >>>
> >>>  if (kernel_filename) {
> >>>  image_size = load_elf_as(kernel_filename, NULL, NULL, NULL,
> >>> - &entry, &lowaddr, NULL,
> >>> + &entry, NULL, NULL,
> >>>   NULL, big_endian, EM_ARM, 1, 0, as);
> >>>  if (image_size < 0) {
> >>>  image_size = load_image_targphys_as(kernel_filename, 0,
> >>>  mem_size, as);
> >>> -lowaddr = 0;
> >>>  }
> >>>  if (image_size < 0) {
> >>>  error_report("Could not load kernel '%s'", kernel_filename);
> >>> diff --git a/hw/cris/boot.c b/hw/cris/boot.c
> >>> index b8947bc660..aa8d2756d6 100644
> >>> --- a/hw/cris/boot.c
> >>> +++ b/hw/cris/boot

Re: SEV guest debugging support for Qemu

[Paolo Bonzini]

On 26/09/20 01:48, Ashish Kalra wrote:
> Thanks for your input, i have one additional query with reference to this 
> support :
> 
> For all explicitly unecrypted guest memory regions such as S/W IOTLB bounce 
> buffers,
> dma_decrypted() allocated regions and for guest regions marked as 
> "__bss_decrypted",
> we need to ensure that DBG_DECRYPT API calls are bypassed for such
> regions and those regions are dumped as un-encrypted.

Yes those would be a bit different as they would be physical memory
accesses.  Those currently go through address_space_read in memory_dump
(monitor/misc.c), and would have to use the MemoryDebugOps instead.
That is the place to hook into in order to read the KVM page encryption
bitmap (which is not per-CPU, so another MemoryDebugOps entry
get_phys_addr_attrs?); the MemTxAttrs can then be passed to the read
function in the MemoryDebugOps.

> This guest memory regions encryption status is found using KVM's page 
> encryption bitmap
> support which is part of the page encryption bitmap hypercall interface of the
> KVM/QEMU SEV live migration patches.
> 
> As this additional debug support is dependent on the KVM's page encryption 
> bitmap
> support, are there any updates on KVM SEV live migration patches ?

Sorry about that, I've been busy with QEMU.  I'll review them as soon as
possible.

Paolo

Re: SEV guest debugging support for Qemu

[Ashish Kalra]

Hello Paolo,

On Fri, Sep 25, 2020 at 10:56:10PM +0200, Paolo Bonzini wrote:
> On 25/09/20 22:46, Ashish Kalra wrote:
> > I was also considering abstracting this vendor/SEV specific debug
> > interface via the CPUClass object, the CPUClass object aleady has cpu
> > specific methods for doing things like guest VA to GPA translations like the
> > get_phys_page_attrs_debug() method and it will be a simple and clean
> > approach to override this method with a SEV specific
> > get_phys_page_attrs_debug() if SEV guest is active and SEV debug policy
> > is allowed. [...]
> > 
> > I can probably add new interfaces/methods to this CPUClass object for
> > guest memory read/writes for debugging purpose and then invoke the same
> > from the generic cpu_memory_rw_debug() interface. 
> > 
> > Let me know your thougts on abstracting this debug interface via the
> > CPUClass object ? 
> > 
> > Or the other option is to introduce the new MemoryDebugOps you described
> > above and additionally apply SEV/SEV-ES considerations in CPUClass
> > methods such as gdb_read_register, gdb_write_register, etc.
> 
> Yes, this makes the most sense, however you're right that you don't need
> translate in MemoryDebugOps.  I don't think read/write should be moved
> to CPUClass, however, since you can use a MemTxAttr to tell the
> read/write MemoryDebugOps whether the page is encrypted or not.
> 

Thanks for your input, i have one additional query with reference to this 
support :

For all explicitly unecrypted guest memory regions such as S/W IOTLB bounce 
buffers,
dma_decrypted() allocated regions and for guest regions marked as 
"__bss_decrypted",
we need to ensure that DBG_DECRYPT API calls are bypassed for such
regions and those regions are dumped as un-encrypted.

This guest memory regions encryption status is found using KVM's page 
encryption bitmap
support which is part of the page encryption bitmap hypercall interface of the
KVM/QEMU SEV live migration patches.

As this additional debug support is dependent on the KVM's page encryption 
bitmap
support, are there any updates on KVM SEV live migration patches ?

Thanks,
Ashish

[PULL v7 00/87] Misc patches for 2020-09-24

[Paolo Bonzini]

The following changes since commit 8c1c07929feae876202ba26f07a540c5115c18cd:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2020-09-24 18:48:45 +0100)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to a92d54785437140cb83d47190d5fcbc12c8ad9fc:

  hw/net/can: Correct Kconfig dependencies (2020-09-25 19:01:51 -0400)


* SCSI fix (Dmitry, Li Feng, Li Qiang)
* memory API fixes (Eduardo)
* removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)
* ACPI fix for VMBus (Jon)
* relocatable install (myself)
* always remove docker containers (myself)
* serial cleanups (Philippe)
* vmware cpuid leaf for tsc and apic frequency (Sunil)
* KVM_FEATURE_ASYNC_PF_INT support (Vitaly)
* i386 XSAVE bugfix (Xiaoyao)
* QOM developer documentation in docs/devel (Eduardo)
* new checkpatch tests (Dov)
* x86_64 syscall fix (Douglas)
* interrupt-based APF fix (Vitaly)
* always create kvmclock (Vitaly)
* fix bios-tables-test (Eduardo)
* KVM PV features cleanup (myself)
* CAN FD (Pavel)

meson:
* fixes (Marc-André, Max, Stefan, Alexander, myself)
* moved libmpathpersist, cocoa, malloc tests (myself)
* support for 0.56 introspected test dependencies (myself)


Alexander Bulekov (1):
  oss-fuzz: move linker arg to fix coverage-build

Anthony PERARD (1):
  meson: fix installation of keymaps

Claudio Fontana (1):
  tests: add missing genh dependency

Daniel P. Berrangé (1):
  char: fix logging when chardev write fails

Dmitry Fomichev (1):
  scsi-generic: Fix HM-zoned device scan

Douglas Crosher (1):
  helper_syscall x86_64: clear exception_is_int

Dov Murik (1):
  checkpatch: Detect '%#' or '%0#' in printf-style format strings

Eduardo Habkost (10):
  memory: Convert IOMMUMemoryRegionClass doc comment to kernel-doc
  qom: Document all function parameters in doc comments
  qom: Use kernel-doc private/public tags in structs
  qom: Use ``code`` Sphinx syntax where appropriate
  qom: Add kernel-doc markup to introduction doc comment
  qom: Reformat section titles using Sphinx syntax
  qom: Indent existing code examples
  qom: Add code block markup to all code blocks
  docs: Create docs/devel/qom.rst
  bios-tables-test: Remove kernel-irqchip=off option

Igor Mammedov (5):
  numa: drop support for '-numa node' (without memory specified)
  doc: Cleanup "'-mem-path' fallback to RAM" deprecation text
  numa: remove fixup numa_state->num_nodes to MAX_NODES
  smp: drop support for deprecated (invalid topologies)
  cphp: remove deprecated cpu-add command(s)

Jan Charvat (5):
  net/can: Initial host SocketCan support for CAN FD.
  hw/net/can: sja1000 ignore CAN FD frames
  net/can: Add can_dlc2len and can_len2dlc for CAN FD.
  hw/net/can/ctucafd: Add CTU CAN FD core register definitions.
  hw/net/can: CTU CAN FD IP open hardware core emulation.

Jon Doron (1):
  acpi: i386: Move VMBus DSDT entry to SB

Li Feng (1):
  vhost-scsi: support inflight io track

Li Qiang (2):
  hw: megasas: return -1 when 'megasas_map_sgl' fails
  hw: megasas: consider 'iov_count=0' is an error in megasas_map_sgl

Marc-André Lureau (2):
  meson: fix MSI rule
  meson: error out if qemu_suffix starts with /

Paolo Bonzini (28):
  meson: clean up build_by_default
  ninjatool: rebuild multi-output targets if outputs are missing
  meson: move libudev test
  meson: move libmpathpersist test
  meson: extend libmpathpersist test for static linking
  configure: move malloc_trim/tcmalloc/jemalloc to meson
  configure: fix --meson=/path/to/meson
  configure: move cocoa option to Meson
  configure: do not limit Hypervisor.framework test to Darwin
  meson: qtest: set "depends" correctly
  mtest2make: add support for introspected test dependencies
  meson: report accelerator support
  oslib: do not call g_strdup from qemu_get_exec_dir
  fuzz: use qemu_get_exec_dir
  oslib-posix: default exec_dir to bindir
  cutils: introduce get_relocated_path
  oslib-posix: relocate path to /var
  module: relocate path to modules
  net: relocate paths to helpers and scripts
  vl: relocate paths to data directories
  vl: relocate path to configuration file
  qemu-bridge-helper: relocate path to default ACL
  qga: relocate path to default configuration and hook
  ui: relocate paths to icons and translations
  configure: use a platform-neutral prefix
  tests/tcg: reinstate or replace desired parts of rules.mak
  docs: Move object.h overview doc comment to qom.rst
  target/i386: kvm: do not use kvm_check_extension to find paravirtual 
capabilities

Pavel Pisa (2):
  hw/net/can: Documentation for CTU CAN FD IP open 

Re: [PATCH v4 0/6] Qemu SEV-ES guest support

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/cover.1601060620.git.thomas.lenda...@amd.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or 
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
  TESTiotest-qcow2: 029
socket_accept failed: Resource temporarily unavailable
**
ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: 
assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
../src/tests/qtest/libqtest.c:166: kill_qemu() tried to terminate QEMU process 
but encountered exit status 1 (expected 0)
ERROR qtest-x86_64: bios-tables-test - Bail out! 
ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: 
assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
make: *** [run-test-138] Error 1
make: *** Waiting for unfinished jobs
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or 
directory
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', 
'--label', 'com.qemu.instance.uuid=ac8de816386f43fbbd35e8eef7710385', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 
'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-hmf8po3g/src/docker-src.2020-09-25-18.40.32.24005:/var/tmp/qemu:z,ro',
 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=ac8de816386f43fbbd35e8eef7710385
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-hmf8po3g/src'
make: *** [docker-run-test-quick@centos7] Error 2

real17m23.414s
user0m21.953s


The full log is available at
http://patchew.org/logs/cover.1601060620.git.thomas.lenda...@amd.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v26 17/17] qapi: Add VFIO devices migration stats in Migration stats

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:19 +0530
Kirti Wankhede  wrote:

> Added amount of bytes transferred to the target VM by all VFIO devices
> 
> Signed-off-by: Kirti Wankhede 
> ---
> 
> Note: Comments from v25 for this patch are not addressed yet.
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg715620.html
> 
> Alex, need more pointer on documentation part raised Markus Armbruster.

I'm not sure what you're asking of me here.  Are we being asked to
justify that a vfio device has state that needs to be migrated and the
ability to dirty pages?
 
> 
>  hw/vfio/common.c| 20 
>  hw/vfio/migration.c | 10 ++
>  include/qemu/vfio-helpers.h |  3 +++
>  migration/migration.c   | 14 ++
>  monitor/hmp-cmds.c  |  6 ++
>  qapi/migration.json | 17 +
>  6 files changed, 70 insertions(+)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 7eeaa368187a..286cdaac8674 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -39,6 +39,7 @@
>  #include "trace.h"
>  #include "qapi/error.h"
>  #include "migration/migration.h"
> +#include "qemu/vfio-helpers.h"
>  
>  VFIOGroupList vfio_group_list =
>  QLIST_HEAD_INITIALIZER(vfio_group_list);
> @@ -292,6 +293,25 @@ const MemoryRegionOps vfio_region_ops = {
>   * Device state interfaces
>   */
>  
> +bool vfio_mig_active(void)
> +{
> +VFIOGroup *group;
> +VFIODevice *vbasedev;
> +
> +if (QLIST_EMPTY(&vfio_group_list)) {
> +return false;
> +}
> +
> +QLIST_FOREACH(group, &vfio_group_list, next) {
> +QLIST_FOREACH(vbasedev, &group->device_list, next) {
> +if (vbasedev->migration_blocker) {
> +return false;
> +}
> +}
> +}
> +return true;
> +}
> +
>  static bool vfio_devices_all_stopped_and_saving(VFIOContainer *container)
>  {
>  VFIOGroup *group;
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 822b68b4e015..c4226fa8b183 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -28,6 +28,7 @@
>  #include "pci.h"
>  #include "trace.h"
>  #include "hw/hw.h"
> +#include "qemu/vfio-helpers.h"
>  
>  /*
>   * Flags used as delimiter:
> @@ -40,6 +41,8 @@
>  #define VFIO_MIG_FLAG_DEV_SETUP_STATE   (0xef13ULL)
>  #define VFIO_MIG_FLAG_DEV_DATA_STATE(0xef14ULL)
>  
> +static int64_t bytes_transferred;
> +
>  static inline int vfio_mig_access(VFIODevice *vbasedev, void *val, int count,
>off_t off, bool iswrite)
>  {
> @@ -289,6 +292,7 @@ static int vfio_save_buffer(QEMUFile *f, VFIODevice 
> *vbasedev, uint64_t *size)
>  *size = data_size;
>  }
>  
> +bytes_transferred += data_size;
>  return ret;
>  }
>  
> @@ -770,6 +774,7 @@ static void vfio_migration_state_notifier(Notifier 
> *notifier, void *data)
>  }
>  
>  vfio_set_dirty_page_tracking(vbasedev, false);
> +bytes_transferred = 0;
>  }
>  }
>  
> @@ -820,6 +825,11 @@ static int vfio_migration_init(VFIODevice *vbasedev,
>  
>  /* -- */
>  
> +int64_t vfio_mig_bytes_transferred(void)
> +{
> +return bytes_transferred;
> +}
> +
>  int vfio_migration_probe(VFIODevice *vbasedev, Error **errp)
>  {
>  VFIOContainer *container = vbasedev->group->container;
> diff --git a/include/qemu/vfio-helpers.h b/include/qemu/vfio-helpers.h
> index 1f057c2b9e40..26a7df0767b1 100644
> --- a/include/qemu/vfio-helpers.h
> +++ b/include/qemu/vfio-helpers.h
> @@ -29,4 +29,7 @@ void qemu_vfio_pci_unmap_bar(QEMUVFIOState *s, int index, 
> void *bar,
>  int qemu_vfio_pci_init_irq(QEMUVFIOState *s, EventNotifier *e,
> int irq_type, Error **errp);
>  
> +bool vfio_mig_active(void);
> +int64_t vfio_mig_bytes_transferred(void);
> +
>  #endif
> diff --git a/migration/migration.c b/migration/migration.c
> index 58a5452471f9..b204bb1f6cd9 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -56,6 +56,7 @@
>  #include "net/announce.h"
>  #include "qemu/queue.h"
>  #include "multifd.h"
> +#include "qemu/vfio-helpers.h"
>  
>  #define MAX_THROTTLE  (32 << 20)  /* Migration transfer speed throttling 
> */
>  
> @@ -996,6 +997,17 @@ static void populate_disk_info(MigrationInfo *info)
>  }
>  }
>  
> +static void populate_vfio_info(MigrationInfo *info)
> +{
> +#ifdef CONFIG_LINUX
> +if (vfio_mig_active()) {
> +info->has_vfio = true;
> +info->vfio = g_malloc0(sizeof(*info->vfio));
> +info->vfio->transferred = vfio_mig_bytes_transferred();
> +}
> +#endif
> +}
> +
>  static void fill_source_migration_info(MigrationInfo *info)
>  {
>  MigrationState *s = migrate_get_current();
> @@ -1020,6 +1032,7 @@ static void fill_source_migration_info(MigrationInfo 
> *info)
>  populate_time_info(info, s);
>  populate_ram_info(info, s);
>  populate_disk_info(info

Re: [PATCH 00/16] qapi: static typing conversion, pt2

[John Snow]

On 9/22/20 5:12 PM, John Snow wrote:

based-on: <20200922210101.4081073-1-js...@redhat.com>
   [PATCH v2 00/38] qapi: static typing conversion, pt1

Hi, this series adds static type hints to the QAPI module.
This is part two!

Part 2: https://gitlab.com/jsnow/qemu/-/tree/python-qapi-cleanup-pt2
Everything: https://gitlab.com/jsnow/qemu/-/tree/python-qapi-cleanup-pt6



Thanks for reviews. I will not be re-spinning pt2 until pt1 is fully 
merged, but I have re-based on pt1-v3 and made some minor adjustments to 
accommodate new development in pt1.


You can find that staged here:
https://gitlab.com/jsnow/qemu/-/tree/python-qapi-cleanup-pt2


Here's the review status of pt2:

[01] qapi-expr-py-remove-info   # [SOB] JS [RB] CR,EH
[02] qapi-expr-py-check-for-dict# [SOB] JS [RB] CR,EH
[03] qapi-expr-py-constrain # [SOB] JS [RB] CR,EH
[04] qapi-expr-py-add-assertion-for # [SOB] JS [RB] CR,EH
[05] qapi-expr-py-move-string-check # [SOB] JS [RB] CR,EH
[06] qapi-expr-py-check-type-of # [SOB] JS [RB] EH
[07] qapi-expr-py-add-casts-in-a# [SOB] JS [RB] CR,EH
[08] qapi-expr-py-add-notational# [SOB] JS [RB] CR,EH
[09] qapi-expr-py-rewrite-check_if  # [SOB] JS [RB] CR,EH [TB] CR
[10] qapi-expr-py-remove-single # [SOB] JS [RB] CR,EH
[11] pylint-enable  # [SOB] JS [TB] CR,EH [RB] CR,EH
[12] qapi-expr-py-add-docstrings# [SOB] JS [RB] CR
[13] qapi-expr-modify-check_keys-to # [SOB] JS [RB] CR,EH
[14] qapi-expr-use-tuples-instead   # [SOB] JS [RB] CR,EH
[15] qapi-expr-move-related-checks  # [SOB] JS [RB] CR
[16] qapi-expr-use-an-expression# [SOB] JS [RB] CR,EH

As for the difflog so far:

Patches 2, 3, 7, 8 change import orderings (isort)
Patch 12 sees some docstrings rewritten to pass sphinx.
Patch 15 addresses Eduardo's review comments.

--js

Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925172604.2142227-1-pbonz...@redhat.com/



Hi,

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

Type: series
Message-id: 20200925172604.2142227-1-pbonz...@redhat.com
Subject: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi 
iothread

=== 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 ===

From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200925172604.2142227-1-pbonz...@redhat.com -> 
patchew/20200925172604.2142227-1-pbonz...@redhat.com
Switched to a new branch 'test'
fbea547 scsi/scsi_bus: fix races in REPORT LUNS
8732528 virtio-scsi: use scsi_device_get
4cb91a6 scsi/scsi_bus: Add scsi_device_get
c91de0a scsi/scsi-bus: scsi_device_find: don't return unrealized devices
f9b2cb5 device-core: use atomic_set on .realized property
7c7d163 device-core: use RCU for list of children of a bus
568c8ae device_core: use drain_call_rcu in in hmp_device_del/qmp_device_add
f594f95 scsi/scsi_bus: switch search direction in scsi_device_find
42b132a scsi: switch to bus->check_address
f0891a9 qdev: add "check if address free" callback for buses

=== OUTPUT BEGIN ===
1/10 Checking commit f0891a96af1b (qdev: add "check if address free" callback 
for buses)
2/10 Checking commit 42b132a31e18 (scsi: switch to bus->check_address)
ERROR: code indent should never use tabs
#53: FILE: hw/scsi/scsi-bus.c:137:
+^I^I^I^I int channel, int target, int lun,$

ERROR: code indent should never use tabs
#54: FILE: hw/scsi/scsi-bus.c:138:
+^I^I^I^I SCSIDevice **p_dev)$

WARNING: line over 80 characters
#69: FILE: hw/scsi/scsi-bus.c:153:
+static bool scsi_bus_check_address(BusState *qbus, DeviceState *qdev, Error 
**errp)

WARNING: line over 80 characters
#89: FILE: hw/scsi/scsi-bus.c:173:
+if (!scsi_bus_is_address_free(bus, dev->channel, dev->id, dev->lun, 
&d)) {

WARNING: line over 80 characters
#128: FILE: hw/scsi/scsi-bus.c:195:
+is_free = scsi_bus_is_address_free(bus, dev->channel, ++id, 
dev->lun, NULL);

WARNING: line over 80 characters
#141: FILE: hw/scsi/scsi-bus.c:205:
+is_free = scsi_bus_is_address_free(bus, dev->channel, dev->id, 
++lun, NULL);

total: 2 errors, 4 warnings, 182 lines checked

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

3/10 Checking commit f594f95b4779 (scsi/scsi_bus: switch search direction in 
scsi_device_find)
4/10 Checking commit 568c8aea7113 (device_core: use drain_call_rcu in in 
hmp_device_del/qmp_device_add)
5/10 Checking commit 7c7d163add9c (device-core: use RCU for list of children of 
a bus)
6/10 Checking commit f9b2cb585972 (device-core: use atomic_set on .realized 
property)
7/10 Checking commit c91de0a97535 (scsi/scsi-bus: scsi_device_find: don't 
return unrealized devices)
8/10 Checking commit 4cb91a6d49f4 (scsi/scsi_bus: Add scsi_device_get)
9/10 Checking commit 87325282af2e (virtio-scsi: use scsi_device_get)
10/10 Checking commit fbea547fe6c6 (scsi/scsi_bus: fix races in REPORT LUNS)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200925172604.2142227-1-pbonz...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v1 0/8] s390x/tcg: Implement some z14 facilities

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> With this patchset, I can boot a kernel compiled for z14 (requiring
> Miscellaneous-Instruction-Extensions Facility 2) (using -cpu max).

Excellent.

Looks like it wouldn't take too much additional work for z15, if you're of a
mind while we're at it.

Message-Security-Assist 9:
KDSA to ignore, like KMA.

Miscellaneous-Instruction-Extensions 3:
A bunch of logical operations, all of which
already have tcg primitives.

SELECT, which can re-use op_loc with different inputs.

MOVE RIGHT TO LEFT, which can't reuse do_helper_mvc
directly, but could be a copy with trivial changes.

Trivial changes to op_popcnt.

Vector-Enhancements 2:
Mostly load/store byte-reversed.
New vector shift insns.
FP/Int conversions.
Vector string search.


r~

Re: [PATCH] target/riscv: raise exception to HS-mode at get_physical_address

[Alistair Francis]

On Mon, Aug 24, 2020 at 1:43 AM Yifei Jiang  wrote:
>
> VS-stage translation at get_physical_address needs to translate pte
> address by G-stage translation. But the G-stage translation error
> can not be distinguished from VS-stage translation error in
> riscv_cpu_tlb_fill. On migration, destination needs to rebuild pte,
> and this G-stage translation error must be handled by HS-mode. So
> introduce TRANSLATE_STAGE2_FAIL so that riscv_cpu_tlb_fill could
> distinguish and raise it to HS-mode.
>
> Signed-off-by: Yifei Jiang 
> Signed-off-by: Yipeng Yin 

Thanks for the patch!

Sorry for the delay here.

> ---
>  target/riscv/cpu.h|  1 +
>  target/riscv/cpu_helper.c | 12 ++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index a804a5d0ba..8b3b368d6a 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -85,6 +85,7 @@ enum {
>  #define TRANSLATE_FAIL 1
>  #define TRANSLATE_SUCCESS 0
>  #define MMU_USER_IDX 3
> +#define TRANSLATE_G_STAGE_FAIL 4
>
>  #define MAX_RISCV_PMPS (16)
>
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index fd1d373b6f..1635b09c41 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -440,7 +440,10 @@ restart:
>   mmu_idx, false, true);
>
>  if (vbase_ret != TRANSLATE_SUCCESS) {
> -return vbase_ret;
> +env->guest_phys_fault_addr = (base |
> +  (addr &
> +   (TARGET_PAGE_SIZE - 1))) >> 2;

Can we set guest_phys_fault_addr in riscv_cpu_tlb_fill() instead?

> +return TRANSLATE_G_STAGE_FAIL;
>  }
>
>  pte_addr = vbase + idx * ptesize;
> @@ -728,12 +731,17 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, 
> int size,
>  ret = get_physical_address(env, &pa, &prot, address, access_type,
> mmu_idx, true, true);
>
> +if (ret == TRANSLATE_G_STAGE_FAIL) {
> +first_stage_error = false;
> +access_type = MMU_DATA_LOAD;
> +}
> +
>  qemu_log_mask(CPU_LOG_MMU,
>"%s 1st-stage address=%" VADDR_PRIx " ret %d physical "
>TARGET_FMT_plx " prot %d\n",
>__func__, address, ret, pa, prot);
>
> -if (ret != TRANSLATE_FAIL) {
> +if (ret != TRANSLATE_FAIL && ret != TRANSLATE_G_STAGE_FAIL) {

Otherwise this patch looks correct.

Alistair

>  /* Second stage lookup */
>  im_address = pa;
>
> --
> 2.19.1
>
>
>

Re: [PATCH v26 13/17] vfio: create mapped iova list when vIOMMU is enabled

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:15 +0530
Kirti Wankhede  wrote:

> Create mapped iova list when vIOMMU is enabled. For each mapped iova
> save translated address. Add node to list on MAP and remove node from
> list on UNMAP.
> This list is used to track dirty pages during migration.
> 
> Signed-off-by: Kirti Wankhede 
> ---
>  hw/vfio/common.c  | 58 
> ++-
>  include/hw/vfio/vfio-common.h |  8 ++
>  2 files changed, 60 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index d4959c036dd1..dc56cded2d95 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -407,8 +407,8 @@ static bool 
> vfio_listener_skipped_section(MemoryRegionSection *section)
>  }
>  
>  /* Called with rcu_read_lock held.  */
> -static bool vfio_get_vaddr(IOMMUTLBEntry *iotlb, void **vaddr,
> -   bool *read_only)
> +static bool vfio_get_xlat_addr(IOMMUTLBEntry *iotlb, void **vaddr,
> +   ram_addr_t *ram_addr, bool *read_only)
>  {
>  MemoryRegion *mr;
>  hwaddr xlat;
> @@ -439,8 +439,17 @@ static bool vfio_get_vaddr(IOMMUTLBEntry *iotlb, void 
> **vaddr,
>  return false;
>  }
>  
> -*vaddr = memory_region_get_ram_ptr(mr) + xlat;
> -*read_only = !writable || mr->readonly;
> +if (vaddr) {
> +*vaddr = memory_region_get_ram_ptr(mr) + xlat;
> +}
> +
> +if (ram_addr) {
> +*ram_addr = memory_region_get_ram_addr(mr) + xlat;
> +}
> +
> +if (read_only) {
> +*read_only = !writable || mr->readonly;
> +}
>  
>  return true;
>  }
> @@ -450,7 +459,6 @@ static void vfio_iommu_map_notify(IOMMUNotifier *n, 
> IOMMUTLBEntry *iotlb)
>  VFIOGuestIOMMU *giommu = container_of(n, VFIOGuestIOMMU, n);
>  VFIOContainer *container = giommu->container;
>  hwaddr iova = iotlb->iova + giommu->iommu_offset;
> -bool read_only;
>  void *vaddr;
>  int ret;
>  
> @@ -466,7 +474,10 @@ static void vfio_iommu_map_notify(IOMMUNotifier *n, 
> IOMMUTLBEntry *iotlb)
>  rcu_read_lock();
>  
>  if ((iotlb->perm & IOMMU_RW) != IOMMU_NONE) {
> -if (!vfio_get_vaddr(iotlb, &vaddr, &read_only)) {
> +ram_addr_t ram_addr;
> +bool read_only;
> +
> +if (!vfio_get_xlat_addr(iotlb, &vaddr, &ram_addr, &read_only)) {
>  goto out;
>  }
>  /*
> @@ -484,8 +495,28 @@ static void vfio_iommu_map_notify(IOMMUNotifier *n, 
> IOMMUTLBEntry *iotlb)
>   "0x%"HWADDR_PRIx", %p) = %d (%m)",
>   container, iova,
>   iotlb->addr_mask + 1, vaddr, ret);
> +} else {
> +VFIOIovaRange *iova_range;
> +
> +iova_range = g_malloc0(sizeof(*iova_range));
> +iova_range->iova = iova;
> +iova_range->size = iotlb->addr_mask + 1;
> +iova_range->ram_addr = ram_addr;
> +
> +QLIST_INSERT_HEAD(&giommu->iova_list, iova_range, next);
>  }
>  } else {
> +VFIOIovaRange *iova_range, *tmp;
> +
> +QLIST_FOREACH_SAFE(iova_range, &giommu->iova_list, next, tmp) {
> +if (iova_range->iova >= iova &&
> +iova_range->iova + iova_range->size <= iova +
> +   iotlb->addr_mask + 1) 
> {
> +QLIST_REMOVE(iova_range, next);
> +g_free(iova_range);
> +}
> +}
> +


This is some pretty serious overhead... can't we trigger a replay when
migration is enabled to build this information then?  We're looking at
potentially thousands of entries, so a list is probably also not a good
choice.  I don't think it's acceptable to incur this even when not
migrating (ie. the vast majority of the time).  Thanks,

Alex

>  ret = vfio_dma_unmap(container, iova, iotlb->addr_mask + 1);
>  if (ret) {
>  error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> @@ -642,6 +673,7 @@ static void vfio_listener_region_add(MemoryListener 
> *listener,
>  g_free(giommu);
>  goto fail;
>  }
> +QLIST_INIT(&giommu->iova_list);
>  QLIST_INSERT_HEAD(&container->giommu_list, giommu, giommu_next);
>  memory_region_iommu_replay(giommu->iommu, &giommu->n);
>  
> @@ -740,6 +772,13 @@ static void vfio_listener_region_del(MemoryListener 
> *listener,
>  QLIST_FOREACH(giommu, &container->giommu_list, giommu_next) {
>  if (MEMORY_REGION(giommu->iommu) == section->mr &&
>  giommu->n.start == section->offset_within_region) {
> +VFIOIovaRange *iova_range, *tmp;
> +
> +QLIST_FOREACH_SAFE(iova_range, &giommu->iova_list, next, 
> tmp) {
> +QLIST_REMOVE(iova_range, next);
> +g_free(iova_range);
> +}
> +
>  memory_region_unregister_iommu_notifier(section->mr,
>   

Re: [PATCH V1 03/32] savevm: QMP command for cprsave

[Steven Sistare]

On 9/25/2020 2:43 PM, Steven Sistare wrote:
> On 9/11/2020 12:43 PM, Dr. David Alan Gilbert wrote:
>> * Steve Sistare (steven.sist...@oracle.com) wrote:
>>> To enable live reboot, provide the cprsave QMP command and the VMS_REBOOT
>>> vmstate-saving operation, which saves the state of the virtual machine in a
>>> simple file.
>>>
>>> Syntax:
>>>   {'command':'cprsave', 'data':{'file':'str', 'mode':'str'}}
>>>
>>>   The mode argument must be 'reboot'.  Additional modes will be defined in
>>>   the future.
>>>
>>> Unlike the savevm command, cprsave supports any type of guest image and
>>> block device.  cprsave stops the VM so that guest ram and block devices are
>>> not modified after state is saved.  Guest ram must be mapped to a persistent
>>> memory file such as /dev/dax0.0.  The ram object vmstate handler and block
>>> device handler do not apply to VMS_REBOOT, so restrict them to VMS_MIGRATE
>>> or VMS_SNAPSHOT.  After cprsave completes successfully, qemu exits.
>>>
>>> After issuing cprsave, the caller may update qemu, update the host kernel,
>>> reboot, start qemu using the same arguments as the original process, and
>>> issue the cprload command to restore the guest.  cprload is added by
>>> subsequent patches.
>>>
>>> If the caller suspends the guest instead of stopping the VM, such as by
>>> issuing guest-suspend-ram to the qemu guest agent, then cprsave and cprload
>>> support guests with vfio devices.  The guest drivers suspend methods flush
>>> outstanding requests and re-initialize the devices, and thus there is no
>>> device state to save and restore.
>>>
>>> Signed-off-by: Steve Sistare 
>>> Signed-off-by: Maran Wilson 
>>
>> Going back a step; could you.
>>
>>> ---
>>>  include/migration/vmstate.h |  1 +
>>>  include/sysemu/sysemu.h |  2 ++
>>>  migration/block.c   |  1 +
>>>  migration/ram.c |  1 +
>>>  migration/savevm.c  | 59 
>>> +
>>>  monitor/qmp-cmds.c  |  6 +
>>>  qapi/migration.json | 14 +++
>>>  7 files changed, 84 insertions(+)
>>>
>>> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
>>> index fa575f9..c58551a 100644
>>> --- a/include/migration/vmstate.h
>>> +++ b/include/migration/vmstate.h
>>> @@ -161,6 +161,7 @@ typedef enum {
>>>  typedef enum {
>>>  VMS_MIGRATE  = (1U << 1),
>>>  VMS_SNAPSHOT = (1U << 2),
>>> +VMS_REBOOT   = (1U << 3),
>>>  VMS_MODE_ALL = ~0U
>>>  } VMStateMode;
>>>  
>>> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
>>> index 4b6a5c4..6fe86e6 100644
>>> --- a/include/sysemu/sysemu.h
>>> +++ b/include/sysemu/sysemu.h
>>> @@ -24,6 +24,8 @@ extern bool machine_init_done;
>>>  void qemu_add_machine_init_done_notifier(Notifier *notify);
>>>  void qemu_remove_machine_init_done_notifier(Notifier *notify);
>>>  
>>> +void save_cpr_snapshot(const char *file, const char *mode, Error **errp);
>>> +
>>>  extern int autostart;
>>>  
>>>  typedef enum {
>>> diff --git a/migration/block.c b/migration/block.c
>>> index 737b649..a69accb 100644
>>> --- a/migration/block.c
>>> +++ b/migration/block.c
>>> @@ -1023,6 +1023,7 @@ static SaveVMHandlers savevm_block_handlers = {
>>>  .load_state = block_load,
>>>  .save_cleanup = block_migration_cleanup,
>>>  .is_active = block_is_active,
>>> +.mode_mask = VMS_MIGRATE | VMS_SNAPSHOT,
>>>  };
>>>  
>>>  void blk_mig_init(void)
>>> diff --git a/migration/ram.c b/migration/ram.c
>>> index 76d4fee..f0d5d9f 100644
>>> --- a/migration/ram.c
>>> +++ b/migration/ram.c
>>> @@ -3795,6 +3795,7 @@ static SaveVMHandlers savevm_ram_handlers = {
>>>  .load_setup = ram_load_setup,
>>>  .load_cleanup = ram_load_cleanup,
>>>  .resume_prepare = ram_resume_prepare,
>>> +.mode_mask = VMS_MIGRATE | VMS_SNAPSHOT,
>>>  };
>>>  
>>>  void ram_mig_init(void)
>>> diff --git a/migration/savevm.c b/migration/savevm.c
>>> index ce02b6b..ff1a46e 100644
>>> --- a/migration/savevm.c
>>> +++ b/migration/savevm.c
>>> @@ -2680,6 +2680,65 @@ int qemu_load_device_state(QEMUFile *f)
>>>  return 0;
>>>  }
>>>  
>>> +static QEMUFile *qf_file_open(const char *filename, int flags, int mode,
>>> +  Error **errp)
>>> +{
>>> +QIOChannel *ioc;
>>> +int fd = qemu_open(filename, flags, mode);
>>> +
>>> +if (fd < 0) {
>>> +error_setg_errno(errp, errno, "%s(%s)", __func__, filename);
>>> +return NULL;
>>> +}
>>> +
>>> +ioc = QIO_CHANNEL(qio_channel_file_new_fd(fd));
>>> +
>>> +if (flags & O_WRONLY) {
>>> +return qemu_fopen_channel_output(ioc);
>>> +}
>>> +
>>> +return qemu_fopen_channel_input(ioc);
>>> +}
>>> +
>>> +void save_cpr_snapshot(const char *file, const char *mode, Error **errp)
>>> +{
>>> +int ret = 0;
>>> +QEMUFile *f;
>>> +VMStateMode op;
>>> +
>>> +if (!strcmp(mode, "reboot")) {
>>> +op = VMS_REBOOT;
>>> +} else {
>>> +error_setg(errp, "cprsave: bad mode %

Re: [PATCH v1 8/8] s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> As with the other crypto functions, we only implement subcode 0 (query)
> and no actual encryption/decryption. We now implement S390_FEAT_MSA_EXT_8.
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/gen-features.c | 1 +
>  target/s390x/insn-data.def  | 1 +
>  target/s390x/translate.c| 7 +++
>  3 files changed, 9 insertions(+)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v1 7/8] s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> We implement all relevant instructions.
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/gen-features.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v1 6/8] s390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> +static uint32_t cc_calc_muls_32(int64_t res)
> +{
> +/* Arithmetic shift with sign extension so we can compare against -1ull. 
> */
> +const uint64_t tmp = res >> 31;
> +
> +if (!res) {
> +return 0;
> +} else if (!(!tmp || tmp == -1ull)) {

Comparing signed vs unsigned.  Use -1 without suffix.

> +static uint64_t cc_calc_muls_64(int64_t res_high, uint64_t res_low)
> +{
> +const uint8_t tmp = res_low >> 63;
> +
> +if (!res_high && !res_low) {
> +return 0;
> +} else if (!(!res_high && !tmp) || !(res_high == -1ull && tmp)) {

This simplifies to res_high + tmp != 0.

Probably better to keep tmp as uint64_t; otherwise we're likely to have an
unnecessary zero-extension from uint8_t to uint64_t.
Or, drop 'tmp' altogether and use

  if (res_high + (res_low >> 63) != 0)

Otherwise, looks good.


r~

Re: I wanna fixes plugin on windows, any suggestion

[Yonggang Luo]

On Sat, Sep 26, 2020 at 4:59 AM Paolo Bonzini  wrote:
>
> On 25/09/20 22:50, Richard Henderson wrote:
> > On 9/25/20 12:25 PM, Paolo Bonzini wrote:
> >> On 25/09/20 21:23, 罗勇刚(Yonggang Luo) wrote:
> >>> That's what I am tring to fixes? what does  one import library per
> >>> emulator, can we do this like NodeJS does?
> >>>  NodeJS have NAPI support across platform. They create a windows .lib
from
> >>> node.exe
> >>
> >> You'd have to create a .lib for qemu-system-aarch64.exe, one for
> >> qemu-system-arm.exe, etc.  On Linux the same plugin will work for all
> >> emulators.
> >
> > Which is clearly silly.
> >
> > So what you'd do is create a common .lib that all of the plugins link
to, and
> > so do all of the qemu-foo.exe.
> >
> > This would probably involve creating a set of call-backs that
qemu-foo.exe
> > would need to pass to the common .lib at startup.  It's harder to do
with
> > windows than linux, but it's not impossible.
>
> Yes, or you can skip the .lib/.dll completely; you just place pointers
> to the callbacks in a struct and pass it to the plugin when it's loaded,
> through qemu_info_t.
I also got another idea to resolve this issue by loading these API by
dl_sym(NULL, "qemu_plug_api_function_name"),
so we won't change any current API. And creating a plugin_api.lib for
static linkage to(only for windows).
>
> Paolo
>


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

Re: [PULL v6 00/87] Misc patches for 2020-09-24

[Peter Maydell]

On Fri, 25 Sep 2020 at 20:51, Paolo Bonzini  wrote:
>
> The following changes since commit 8c1c07929feae876202ba26f07a540c5115c18cd:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2020-09-24 18:48:45 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to f19fc40acf2a4481f56165228f788f322d947f60:
>
>   hw/net/can: Correct Kconfig dependencies (2020-09-25 15:21:30 -0400)
>
> 
> * SCSI fix (Dmitry, Li Feng, Li Qiang)
> * memory API fixes (Eduardo)
> * removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)
> * ACPI fix for VMBus (Jon)
> * relocatable install (myself)
> * always remove docker containers (myself)
> * serial cleanups (Philippe)
> * vmware cpuid leaf for tsc and apic frequency (Sunil)
> * KVM_FEATURE_ASYNC_PF_INT support (Vitaly)
> * i386 XSAVE bugfix (Xiaoyao)
> * QOM developer documentation in docs/devel (Eduardo)
> * new checkpatch tests (Dov)
> * x86_64 syscall fix (Douglas)
> * interrupt-based APF fix (Vitaly)
> * always create kvmclock (Vitaly)
> * fix bios-tables-test (Eduardo)
> * KVM PV features cleanup (myself)
> * CAN FD (Pavel)
>
> meson:
> * fixes (Marc-André, Max, Stefan, Alexander, myself)
> * moved libmpathpersist, cocoa, malloc tests (myself)
> * support for 0.56 introspected test dependencies (myself)

This version fails on the BSDs:

Library util found: YES
Found pkg-config: /usr/local/bin/pkg-config (1.7.3)
Run-time dependency pixman-1 found: YES 0.40.0
Library pam found: YES
Library aio found: NO
Run-time dependency zlib found: YES 1.2.10
Run-time dependency xkbcommon found: YES 0.10.0
Library rt found: YES

../src/meson.build:274:3: ERROR: Unknown variable "target_os".

A full log can be found at
/usr/home/qemu/qemu-test.5nusiE/build/meson-logs/meson-log.txt

ERROR: meson setup failed

Windows crossbuild produces the meson.build error but then
somehow proceeds to link executables and succeed anyway(?!) :

C++ compiler for the host machine: i686-w64-mingw32.shared-g++ (gcc
5.5.0 "i686-w64-mingw32.shared-g++ (GCC) 5.5.0")
C++ linker for the host machine: i686-w64-mingw32.shared-g++ ld.bfd 2.28
Library m found: YES
Library util found: NO
Library ws2_32 found: YES
Library winmm found: YES
Windows resource compiler: GNU windres (GNU Binutils) 2.28
Dependency pixman-1 found: YES 0.33.6 (cached)
Library aio found: NO
Dependency zlib found: YES 1.2.11 (cached)
Found pkg-config: /usr/lib/mxe/usr/bin/i686-w64-mingw32.shared-pkg-config (0.28)
Run-time dependency xkbcommon found: NO (tried pkgconfig)
Library rt found: NO

../../meson.build:274:3: ERROR: Unknown variable "target_os".

A full log can be found at
/home/petmay01/qemu-for-merges/build/w32/meson-logs/meson-log.txt
Generating qemu-version.h with a meson_exe.py custom command
Compiling C object libqemu-i386-softmmu.fa.p/target_i386_cpu.c.obj
Compiling C object libqemu-x86_64-softmmu.fa.p/target_i386_cpu.c.obj
Linking target qemu-system-i386.exe
Linking target qemu-system-i386w.exe
Linking target qemu-system-x86_64.exe
Linking target qemu-system-x86_64w.exe
make: Leaving directory '/home/petmay01/qemu-for-merges/build/w32'
OK DONE windows crossbuilds

thanks
-- PMM

Re: [PATCH v26 05/17] vfio: Add VM state change handler to know state of VM

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:07 +0530
Kirti Wankhede  wrote:

> VM state change handler gets called on change in VM's state. This is used to 
> set
> VFIO device state to _RUNNING.
> 
> Signed-off-by: Kirti Wankhede 
> Reviewed-by: Neo Jia 
> Reviewed-by: Dr. David Alan Gilbert 
> ---
>  hw/vfio/migration.c   | 136 
> ++
>  hw/vfio/trace-events  |   3 +-
>  include/hw/vfio/vfio-common.h |   4 ++
>  3 files changed, 142 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 2f760f1f9c47..a30d628ba963 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -10,6 +10,7 @@
>  #include "qemu/osdep.h"
>  #include 
>  
> +#include "sysemu/runstate.h"
>  #include "hw/vfio/vfio-common.h"
>  #include "cpu.h"
>  #include "migration/migration.h"
> @@ -22,6 +23,58 @@
>  #include "exec/ram_addr.h"
>  #include "pci.h"
>  #include "trace.h"
> +#include "hw/hw.h"
> +
> +static inline int vfio_mig_access(VFIODevice *vbasedev, void *val, int count,
> +  off_t off, bool iswrite)
> +{
> +int ret;
> +
> +ret = iswrite ? pwrite(vbasedev->fd, val, count, off) :
> +pread(vbasedev->fd, val, count, off);
> +if (ret < count) {
> +error_report("vfio_mig_%s%d %s: failed at offset 0x%lx, err: %s",
> + iswrite ? "write" : "read", count * 8,
> + vbasedev->name, off, strerror(errno));

This would suggest from the log that there's, for example, a
vfio_mig_read8 function, which doesn't exist.

> +return (ret < 0) ? ret : -EINVAL;
> +}
> +return 0;
> +}
> +
> +static int vfio_mig_rw(VFIODevice *vbasedev, __u8 *buf, size_t count,
> +   off_t off, bool iswrite)
> +{
> +int ret, done = 0;
> +__u8 *tbuf = buf;
> +
> +while (count) {
> +int bytes = 0;
> +
> +if (count >= 8 && !(off % 8)) {
> +bytes = 8;
> +} else if (count >= 4 && !(off % 4)) {
> +bytes = 4;
> +} else if (count >= 2 && !(off % 2)) {
> +bytes = 2;
> +} else {
> +bytes = 1;
> +}
> +
> +ret = vfio_mig_access(vbasedev, tbuf, bytes, off, iswrite);
> +if (ret) {
> +return ret;
> +}
> +
> +count -= bytes;
> +done += bytes;
> +off += bytes;
> +tbuf += bytes;
> +}
> +return done;
> +}
> +
> +#define vfio_mig_read(f, v, c, o)   vfio_mig_rw(f, (__u8 *)v, c, o, 
> false)
> +#define vfio_mig_write(f, v, c, o)  vfio_mig_rw(f, (__u8 *)v, c, o, true)
>  
>  static void vfio_migration_region_exit(VFIODevice *vbasedev)
>  {
> @@ -70,6 +123,82 @@ err:
>  return ret;
>  }
>  
> +static int vfio_migration_set_state(VFIODevice *vbasedev, uint32_t mask,
> +uint32_t value)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +VFIORegion *region = &migration->region;
> +off_t dev_state_off = region->fd_offset +
> +  offsetof(struct vfio_device_migration_info, 
> device_state);
> +uint32_t device_state;
> +int ret;
> +
> +ret = vfio_mig_read(vbasedev, &device_state, sizeof(device_state),
> +dev_state_off);
> +if (ret < 0) {
> +return ret;
> +}
> +
> +device_state = (device_state & mask) | value;

Agree with Connie that mask and value args are not immediately obvious
how they're used.  I don't have a naming convention that would be more
clear and the names do make some sense once they're understood, but a
comment to indicate mask bits are preserved, value bits are set,
remaining bits are cleared would probably help the reader.

> +
> +if (!VFIO_DEVICE_STATE_VALID(device_state)) {
> +return -EINVAL;
> +}
> +
> +ret = vfio_mig_write(vbasedev, &device_state, sizeof(device_state),
> + dev_state_off);
> +if (ret < 0) {
> +ret = vfio_mig_read(vbasedev, &device_state, sizeof(device_state),
> +  dev_state_off);
> +if (ret < 0) {
> +return ret;

Seems like we're in pretty bad shape here, should this be combined with
below to trigger a hw_error?

> +}
> +
> +if (VFIO_DEVICE_STATE_IS_ERROR(device_state)) {
> +hw_error("%s: Device is in error state 0x%x",
> + vbasedev->name, device_state);
> +return -EFAULT;
> +}
> +}
> +
> +vbasedev->device_state = device_state;
> +trace_vfio_migration_set_state(vbasedev->name, device_state);
> +return 0;

So we return success even if we failed to write the desired state as
long as we were able to read back any non-error state?
vbasedev->device_state remains correct, but it seems confusing form a
caller perspective that a set-state can succeed but it's then necessary
to check the state.

> +}
> +
> +static void vfio_vmstate_change(void

Re: [PATCH v26 07/17] vfio: Register SaveVMHandlers for VFIO device

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:09 +0530
Kirti Wankhede  wrote:

> Define flags to be used as delimeter in migration file stream.
> Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
> region from these functions at source during saving or pre-copy phase.
> Set VFIO device state depending on VM's state. During live migration, VM is
> running when .save_setup is called, _SAVING | _RUNNING state is set for VFIO
> device. During save-restore, VM is paused, _SAVING state is set for VFIO 
> device.
> 
> Signed-off-by: Kirti Wankhede 
> Reviewed-by: Neo Jia 
> ---
>  hw/vfio/migration.c  | 91 
> 
>  hw/vfio/trace-events |  2 ++
>  2 files changed, 93 insertions(+)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index f650fe9fc3c8..8e8adaa25779 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -8,12 +8,15 @@
>   */
>  
>  #include "qemu/osdep.h"
> +#include "qemu/main-loop.h"
> +#include "qemu/cutils.h"
>  #include 
>  
>  #include "sysemu/runstate.h"
>  #include "hw/vfio/vfio-common.h"
>  #include "cpu.h"
>  #include "migration/migration.h"
> +#include "migration/vmstate.h"
>  #include "migration/qemu-file.h"
>  #include "migration/register.h"
>  #include "migration/blocker.h"
> @@ -25,6 +28,17 @@
>  #include "trace.h"
>  #include "hw/hw.h"
>  
> +/*
> + * Flags used as delimiter:
> + * 0x => MSB 32-bit all 1s
> + * 0xef10 => emulated (virtual) function IO
> + * 0x => 16-bits reserved for flags
> + */
> +#define VFIO_MIG_FLAG_END_OF_STATE  (0xef11ULL)
> +#define VFIO_MIG_FLAG_DEV_CONFIG_STATE  (0xef12ULL)
> +#define VFIO_MIG_FLAG_DEV_SETUP_STATE   (0xef13ULL)
> +#define VFIO_MIG_FLAG_DEV_DATA_STATE(0xef14ULL)
> +
>  static inline int vfio_mig_access(VFIODevice *vbasedev, void *val, int count,
>off_t off, bool iswrite)
>  {
> @@ -166,6 +180,65 @@ static int vfio_migration_set_state(VFIODevice 
> *vbasedev, uint32_t mask,
>  return 0;
>  }
>  
> +/* -- */
> +
> +static int vfio_save_setup(QEMUFile *f, void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +VFIOMigration *migration = vbasedev->migration;
> +int ret;
> +
> +trace_vfio_save_setup(vbasedev->name);
> +
> +qemu_put_be64(f, VFIO_MIG_FLAG_DEV_SETUP_STATE);
> +
> +if (migration->region.mmaps) {
> +qemu_mutex_lock_iothread();
> +ret = vfio_region_mmap(&migration->region);
> +qemu_mutex_unlock_iothread();

Please add a comment identifying why the iothread mutex lock is
necessary here.

> +if (ret) {
> +error_report("%s: Failed to mmap VFIO migration region %d: %s",
> + vbasedev->name, migration->region.nr,

We don't support multiple migration regions, is it useful to include
the region index here?

> + strerror(-ret));
> +error_report("%s: Falling back to slow path", vbasedev->name);
> +}
> +}
> +
> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_MASK,
> +   VFIO_DEVICE_STATE_SAVING);
> +if (ret) {
> +error_report("%s: Failed to set state SAVING", vbasedev->name);
> +return ret;
> +}

Again, doesn't match the function semantics that success only means the
device is in a non-error state, maybe the one that was asked for.

> +
> +qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);

What's the overall purpose of writing these markers into the migration
stream?  vfio_load_state() doesn't do anything with this other than
validate that the end-of-state immediately follows.  Is this a
placeholder for something in the future?

> +
> +ret = qemu_file_get_error(f);
> +if (ret) {
> +return ret;
> +}
> +
> +return 0;
> +}
> +
> +static void vfio_save_cleanup(void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +VFIOMigration *migration = vbasedev->migration;
> +
> +if (migration->region.mmaps) {
> +vfio_region_unmap(&migration->region);
> +}
> +trace_vfio_save_cleanup(vbasedev->name);
> +}
> +
> +static SaveVMHandlers savevm_vfio_handlers = {
> +.save_setup = vfio_save_setup,
> +.save_cleanup = vfio_save_cleanup,
> +};
> +
> +/* -- */
> +
>  static void vfio_vmstate_change(void *opaque, int running, RunState state)
>  {
>  VFIODevice *vbasedev = opaque;
> @@ -225,6 +298,8 @@ static int vfio_migration_init(VFIODevice *vbasedev,
> struct vfio_region_info *info)
>  {
>  int ret = -EINVAL;
> +char id[256] = "";
> +Object *obj;
>  
>  if (!vbasedev->ops->vfio_get_object) {
>  return ret;
> @@ -241,6 +316,22 @@ static int vfio_migration_init(VFIODevice *vbasedev,
>  return ret;
>  }
>  
> + 

Re: [PATCH v26 12/17] vfio: Add function to start and stop dirty pages tracking

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:14 +0530
Kirti Wankhede  wrote:

> Call VFIO_IOMMU_DIRTY_PAGES ioctl to start and stop dirty pages tracking
> for VFIO devices.
> 
> Signed-off-by: Kirti Wankhede 
> Reviewed-by: Dr. David Alan Gilbert 
> ---
>  hw/vfio/migration.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 4306f6316417..822b68b4e015 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -11,6 +11,7 @@
>  #include "qemu/main-loop.h"
>  #include "qemu/cutils.h"
>  #include 
> +#include 
>  
>  #include "sysemu/runstate.h"
>  #include "hw/vfio/vfio-common.h"
> @@ -355,6 +356,32 @@ static int vfio_load_device_config_state(QEMUFile *f, 
> void *opaque)
>  return qemu_file_get_error(f);
>  }
>  
> +static int vfio_set_dirty_page_tracking(VFIODevice *vbasedev, bool start)
> +{
> +int ret;
> +VFIOContainer *container = vbasedev->group->container;
> +struct vfio_iommu_type1_dirty_bitmap dirty = {
> +.argsz = sizeof(dirty),
> +};
> +
> +if (start) {
> +if (vbasedev->device_state & VFIO_DEVICE_STATE_SAVING) {
> +dirty.flags = VFIO_IOMMU_DIRTY_PAGES_FLAG_START;
> +} else {
> +return -EINVAL;
> +}
> +} else {
> +dirty.flags = VFIO_IOMMU_DIRTY_PAGES_FLAG_STOP;
> +}
> +
> +ret = ioctl(container->fd, VFIO_IOMMU_DIRTY_PAGES, &dirty);
> +if (ret) {
> +error_report("Failed to set dirty tracking flag 0x%x errno: %d",
> + dirty.flags, errno);
> +}

Maybe doesn't matter in the long run, but do you want to use -errno for
the return rather than -1 from the ioctl on error?  Thanks,

Alex

> +return ret;
> +}
> +
>  /* -- */
>  
>  static int vfio_save_setup(QEMUFile *f, void *opaque)
> @@ -386,6 +413,11 @@ static int vfio_save_setup(QEMUFile *f, void *opaque)
>  return ret;
>  }
>  
> +ret = vfio_set_dirty_page_tracking(vbasedev, true);
> +if (ret) {
> +return ret;
> +}
> +
>  qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
>  
>  ret = qemu_file_get_error(f);
> @@ -401,6 +433,8 @@ static void vfio_save_cleanup(void *opaque)
>  VFIODevice *vbasedev = opaque;
>  VFIOMigration *migration = vbasedev->migration;
>  
> +vfio_set_dirty_page_tracking(vbasedev, false);
> +
>  if (migration->region.mmaps) {
>  vfio_region_unmap(&migration->region);
>  }
> @@ -734,6 +768,8 @@ static void vfio_migration_state_notifier(Notifier 
> *notifier, void *data)
>  if (ret) {
>  error_report("%s: Failed to set state RUNNING", vbasedev->name);
>  }
> +
> +vfio_set_dirty_page_tracking(vbasedev, false);
>  }
>  }
>  

Re: [PATCH v26 06/17] vfio: Add migration state change notifier

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:08 +0530
Kirti Wankhede  wrote:

> Added migration state change notifier to get notification on migration state
> change. These states are translated to VFIO device state and conveyed to 
> vendor
> driver.
> 
> Signed-off-by: Kirti Wankhede 
> Reviewed-by: Neo Jia 
> Reviewed-by: Dr. David Alan Gilbert 
> ---
>  hw/vfio/migration.c   | 29 +
>  hw/vfio/trace-events  |  5 +++--
>  include/hw/vfio/vfio-common.h |  1 +
>  3 files changed, 33 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index a30d628ba963..f650fe9fc3c8 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -199,6 +199,28 @@ static void vfio_vmstate_change(void *opaque, int 
> running, RunState state)
>  }
>  }
>  
> +static void vfio_migration_state_notifier(Notifier *notifier, void *data)
> +{
> +MigrationState *s = data;
> +VFIODevice *vbasedev = container_of(notifier, VFIODevice, 
> migration_state);
> +int ret;
> +
> +trace_vfio_migration_state_notifier(vbasedev->name,
> +MigrationStatus_str(s->state));
> +
> +switch (s->state) {
> +case MIGRATION_STATUS_CANCELLING:
> +case MIGRATION_STATUS_CANCELLED:
> +case MIGRATION_STATUS_FAILED:
> +ret = vfio_migration_set_state(vbasedev,
> +  ~(VFIO_DEVICE_STATE_SAVING | 
> VFIO_DEVICE_STATE_RESUMING),
> +  VFIO_DEVICE_STATE_RUNNING);
> +if (ret) {
> +error_report("%s: Failed to set state RUNNING", vbasedev->name);
> +}

Here again the caller assumes success means the device has entered the
desired state, but as implemented it only means the device is in some
non-error state.

> +}
> +}
> +
>  static int vfio_migration_init(VFIODevice *vbasedev,
> struct vfio_region_info *info)
>  {
> @@ -221,6 +243,8 @@ static int vfio_migration_init(VFIODevice *vbasedev,
>  
>  vbasedev->vm_state = 
> qemu_add_vm_change_state_handler(vfio_vmstate_change,
>vbasedev);
> +vbasedev->migration_state.notify = vfio_migration_state_notifier;
> +add_migration_state_change_notifier(&vbasedev->migration_state);
>  return ret;
>  }
>  
> @@ -263,6 +287,11 @@ add_blocker:
>  
>  void vfio_migration_finalize(VFIODevice *vbasedev)
>  {
> +
> +if (vbasedev->migration_state.notify) {
> +remove_migration_state_change_notifier(&vbasedev->migration_state);
> +}
> +
>  if (vbasedev->vm_state) {
>  qemu_del_vm_change_state_handler(vbasedev->vm_state);
>  }
> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
> index 6524734bf7b4..bcb3fa7314d7 100644
> --- a/hw/vfio/trace-events
> +++ b/hw/vfio/trace-events
> @@ -149,5 +149,6 @@ vfio_display_edid_write_error(void) ""
>  
>  # migration.c
>  vfio_migration_probe(const char *name, uint32_t index) " (%s) Region %d"
> -vfio_migration_set_state(char *name, uint32_t state) " (%s) state %d"
> -vfio_vmstate_change(char *name, int running, const char *reason, uint32_t 
> dev_state) " (%s) running %d reason %s device state %d"
> +vfio_migration_set_state(const char *name, uint32_t state) " (%s) state %d"
> +vfio_vmstate_change(const char *name, int running, const char *reason, 
> uint32_t dev_state) " (%s) running %d reason %s device state %d"
> +vfio_migration_state_notifier(const char *name, const char *state) " (%s) 
> state %s"
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index 25e3b1a3b90a..49c7c7a0e29a 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -123,6 +123,7 @@ typedef struct VFIODevice {
>  VMChangeStateEntry *vm_state;
>  uint32_t device_state;
>  int vm_running;
> +Notifier migration_state;

Can this live in VFIOMigration?  Thanks,

Alex

>  } VFIODevice;
>  
>  struct VFIODeviceOps {

Re: [PATCH v26 08/17] vfio: Add save state functions to SaveVMHandlers

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:10 +0530
Kirti Wankhede  wrote:

> Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
> functions. These functions handles pre-copy and stop-and-copy phase.
> 
> In _SAVING|_RUNNING device state or pre-copy phase:
> - read pending_bytes. If pending_bytes > 0, go through below steps.
> - read data_offset - indicates kernel driver to write data to staging
>   buffer.
> - read data_size - amount of data in bytes written by vendor driver in
>   migration region.
> - read data_size bytes of data from data_offset in the migration region.
> - Write data packet to file stream as below:
> {VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data,
> VFIO_MIG_FLAG_END_OF_STATE }
> 
> In _SAVING device state or stop-and-copy phase
> a. read config space of device and save to migration file stream. This
>doesn't need to be from vendor driver. Any other special config state
>from driver can be saved as data in following iteration.
> b. read pending_bytes. If pending_bytes > 0, go through below steps.
> c. read data_offset - indicates kernel driver to write data to staging
>buffer.
> d. read data_size - amount of data in bytes written by vendor driver in
>migration region.
> e. read data_size bytes of data from data_offset in the migration region.
> f. Write data packet as below:
>{VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data}
> g. iterate through steps b to f while (pending_bytes > 0)
> h. Write {VFIO_MIG_FLAG_END_OF_STATE}
> 
> When data region is mapped, its user's responsibility to read data from
> data_offset of data_size before moving to next steps.
> 
> Signed-off-by: Kirti Wankhede 
> Reviewed-by: Neo Jia 
> ---
>  hw/vfio/migration.c   | 273 
> ++
>  hw/vfio/trace-events  |   6 +
>  include/hw/vfio/vfio-common.h |   1 +
>  3 files changed, 280 insertions(+)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 8e8adaa25779..4611bb972228 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -180,6 +180,154 @@ static int vfio_migration_set_state(VFIODevice 
> *vbasedev, uint32_t mask,
>  return 0;
>  }
>  
> +static void *get_data_section_size(VFIORegion *region, uint64_t data_offset,
> +   uint64_t data_size, uint64_t *size)
> +{
> +void *ptr = NULL;
> +uint64_t limit = 0;
> +int i;
> +
> +if (!region->mmaps) {
> +if (size) {
> +*size = data_size;
> +}
> +return ptr;
> +}
> +
> +for (i = 0; i < region->nr_mmaps; i++) {
> +VFIOMmap *map = region->mmaps + i;
> +
> +if ((data_offset >= map->offset) &&
> +(data_offset < map->offset + map->size)) {
> +
> +/* check if data_offset is within sparse mmap areas */
> +ptr = map->mmap + data_offset - map->offset;
> +if (size) {
> +*size = MIN(data_size, map->offset + map->size - 
> data_offset);
> +}
> +break;
> +} else if ((data_offset < map->offset) &&
> +   (!limit || limit > map->offset)) {
> +/*
> + * data_offset is not within sparse mmap areas, find size of
> + * non-mapped area. Check through all list since region->mmaps 
> list
> + * is not sorted.
> + */
> +limit = map->offset;
> +}
> +}
> +
> +if (!ptr && size) {
> +*size = limit ? limit - data_offset : data_size;

'limit - data_offset' doesn't take data_size into account, this should
be MIN(data_size, limit - data_offset).

> +}
> +return ptr;
> +}
> +
> +static int vfio_save_buffer(QEMUFile *f, VFIODevice *vbasedev, uint64_t 
> *size)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +VFIORegion *region = &migration->region;
> +uint64_t data_offset = 0, data_size = 0, sz;
> +int ret;
> +
> +ret = vfio_mig_read(vbasedev, &data_offset, sizeof(data_offset),
> +region->fd_offset + offsetof(struct 
> vfio_device_migration_info,
> + data_offset));
> +if (ret < 0) {
> +return ret;
> +}
> +
> +ret = vfio_mig_read(vbasedev, &data_size, sizeof(data_size),
> +region->fd_offset + offsetof(struct 
> vfio_device_migration_info,
> + data_size));
> +if (ret < 0) {
> +return ret;
> +}
> +
> +trace_vfio_save_buffer(vbasedev->name, data_offset, data_size,
> +   migration->pending_bytes);
> +
> +qemu_put_be64(f, data_size);
> +sz = data_size;
> +
> +while (sz) {
> +void *buf = NULL;

Unnecessary initialization.

> +uint64_t sec_size;
> +bool buf_allocated = false;
> +
> +buf = get_data_section_size(region, data_offset, sz, &sec_size);
> +
> +if (!buf) {
> +buf = g_try_malloc(sec_size

Re: [RFC PATCH v5 2/2] hw/riscv: sifive_u: Add backend drive support

[Alistair Francis]

On Tue, Sep 1, 2020 at 8:49 AM Green Wan  wrote:
>
> Add '-drive' support to OTP device. Allow users to assign a raw file
> as OTP image.

Do you mind writing an example command line argument in the commit message?

Also, do you have a test case for this? I would like to add it to my CI.

>
> Signed-off-by: Green Wan 
> ---
>  hw/riscv/sifive_u_otp.c | 50 +
>  include/hw/riscv/sifive_u_otp.h |  2 ++
>  2 files changed, 52 insertions(+)
>
> diff --git a/hw/riscv/sifive_u_otp.c b/hw/riscv/sifive_u_otp.c
> index b8369e9035..477c54c7b8 100644
> --- a/hw/riscv/sifive_u_otp.c
> +++ b/hw/riscv/sifive_u_otp.c
> @@ -24,6 +24,8 @@
>  #include "qemu/log.h"
>  #include "qemu/module.h"
>  #include "hw/riscv/sifive_u_otp.h"
> +#include "sysemu/blockdev.h"
> +#include "sysemu/block-backend.h"
>
>  #define WRITTEN_BIT_ON 0x1
>
> @@ -54,6 +56,16 @@ static uint64_t sifive_u_otp_read(void *opaque, hwaddr 
> addr, unsigned int size)
>  if ((s->pce & SIFIVE_U_OTP_PCE_EN) &&
>  (s->pdstb & SIFIVE_U_OTP_PDSTB_EN) &&
>  (s->ptrim & SIFIVE_U_OTP_PTRIM_EN)) {
> +
> +/* read from backend */
> +if (s->blk) {
> +int32_t buf;
> +
> +blk_pread(s->blk, s->pa * SIFIVE_U_OTP_FUSE_WORD, &buf,
> +  SIFIVE_U_OTP_FUSE_WORD);
> +return buf;
> +}
> +
>  return s->fuse[s->pa & SIFIVE_U_OTP_PA_MASK];
>  } else {
>  return 0xff;
> @@ -145,6 +157,12 @@ static void sifive_u_otp_write(void *opaque, hwaddr addr,
>  /* write bit data */
>  SET_FUSEARRAY_BIT(s->fuse, s->pa, s->paio, s->pdin);
>
> +/* write to backend */
> +if (s->blk) {
> +blk_pwrite(s->blk, s->pa * SIFIVE_U_OTP_FUSE_WORD, &val32,
> +   SIFIVE_U_OTP_FUSE_WORD, 0);
> +}
> +
>  /* update written bit */
>  SET_FUSEARRAY_BIT(s->fuse_wo, s->pa, s->paio, WRITTEN_BIT_ON);
>  }
> @@ -168,16 +186,48 @@ static const MemoryRegionOps sifive_u_otp_ops = {
>
>  static Property sifive_u_otp_properties[] = {
>  DEFINE_PROP_UINT32("serial", SiFiveUOTPState, serial, 0),
> +DEFINE_PROP_DRIVE("drive", SiFiveUOTPState, blk),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>
>  static void sifive_u_otp_realize(DeviceState *dev, Error **errp)
>  {
>  SiFiveUOTPState *s = SIFIVE_U_OTP(dev);
> +DriveInfo *dinfo;
>
>  memory_region_init_io(&s->mmio, OBJECT(dev), &sifive_u_otp_ops, s,
>TYPE_SIFIVE_U_OTP, SIFIVE_U_OTP_REG_SIZE);
>  sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->mmio);
> +
> +dinfo = drive_get_next(IF_NONE);
> +if (dinfo) {
> +int ret;
> +uint64_t perm;
> +int filesize;
> +BlockBackend *blk;
> +
> +blk = blk_by_legacy_dinfo(dinfo);

I think this should be:

blk = dinfo ? blk_by_legacy_dinfo(dinfo) : NULL;

> +filesize = SIFIVE_U_OTP_NUM_FUSES * SIFIVE_U_OTP_FUSE_WORD;
> +if (blk_getlength(blk) < filesize) {
> +qemu_log_mask(LOG_GUEST_ERROR, "OTP drive size < 16K\n");

You should probably be setting errp instead.

If a user specified a -drive argument, they probably want to error if
we aren't going to use it.

> +return;
> +}
> +
> +qdev_prop_set_drive(dev, "drive", blk);
> +
> +perm = BLK_PERM_CONSISTENT_READ |
> +(blk_is_read_only(s->blk) ? 0 : BLK_PERM_WRITE);
> +ret = blk_set_perm(s->blk, perm, BLK_PERM_ALL, errp);
> +if (ret < 0) {
> +qemu_log_mask(LOG_GUEST_ERROR, "set perm error.");

Is it worth printing the error?

> +}
> +
> +if (blk_pread(s->blk, 0, s->fuse, filesize) != filesize) {
> +qemu_log_mask(LOG_GUEST_ERROR,
> +  "failed to read the initial flash content");
> +return;

You don't need a return here.

Is this error fatal?

Alistair

> +}
> +}
>  }
>
>  static void sifive_u_otp_reset(DeviceState *dev)
> diff --git a/include/hw/riscv/sifive_u_otp.h b/include/hw/riscv/sifive_u_otp.h
> index 4a5a0acf48..9bc781fd4f 100644
> --- a/include/hw/riscv/sifive_u_otp.h
> +++ b/include/hw/riscv/sifive_u_otp.h
> @@ -45,6 +45,7 @@
>
>  #define SIFIVE_U_OTP_PA_MASK0xfff
>  #define SIFIVE_U_OTP_NUM_FUSES  0x1000
> +#define SIFIVE_U_OTP_FUSE_WORD  4
>  #define SIFIVE_U_OTP_SERIAL_ADDR0xfc
>
>  #define SIFIVE_U_OTP_REG_SIZE   0x1000
> @@ -78,6 +79,7 @@ typedef struct SiFiveUOTPState {
>  uint32_t fuse_wo[SIFIVE_U_OTP_NUM_FUSES];
>  /* config */
>  uint32_t serial;
> +BlockBackend *blk;
>  } SiFiveUOTPState;
>
>  #endif /* HW_SIFIVE_U_OTP_H */
> --
> 2.17.1
>
>

Re: [RFC PATCH v5 1/2] hw/riscv: sifive_u: Add write operation and write-once protection

[Alistair Francis]

On Tue, Sep 1, 2020 at 9:09 AM Green Wan  wrote:
>
>  - Add write operation to update fuse data bit when PWE bit is on.
>  - Add array, fuse_wo, to store the 'written' status for all bits
>of OTP to block the write operation.
>
> Signed-off-by: Green Wan 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/riscv/sifive_u_otp.c | 30 +-
>  include/hw/riscv/sifive_u_otp.h |  3 +++
>  2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/hw/riscv/sifive_u_otp.c b/hw/riscv/sifive_u_otp.c
> index f6ecbaa2ca..b8369e9035 100644
> --- a/hw/riscv/sifive_u_otp.c
> +++ b/hw/riscv/sifive_u_otp.c
> @@ -25,6 +25,14 @@
>  #include "qemu/module.h"
>  #include "hw/riscv/sifive_u_otp.h"
>
> +#define WRITTEN_BIT_ON 0x1
> +
> +#define SET_FUSEARRAY_BIT(map, i, off, bit)\
> +map[i] = bit ? (map[i] | bit << off) : (map[i] & ~(bit << off))
> +
> +#define GET_FUSEARRAY_BIT(map, i, off)\
> +((map[i] >> off) & 0x1)
> +
>  static uint64_t sifive_u_otp_read(void *opaque, hwaddr addr, unsigned int 
> size)
>  {
>  SiFiveUOTPState *s = opaque;
> @@ -123,7 +131,24 @@ static void sifive_u_otp_write(void *opaque, hwaddr addr,
>  s->ptrim = val32;
>  break;
>  case SIFIVE_U_OTP_PWE:
> -s->pwe = val32;
> +s->pwe = val32 & SIFIVE_U_OTP_PWE_EN;
> +
> +/* PWE is enabled. Ignore PAS=1 (no redundancy cell) */
> +if (s->pwe && !s->pas) {
> +if (GET_FUSEARRAY_BIT(s->fuse_wo, s->pa, s->paio)) {
> +qemu_log_mask(LOG_GUEST_ERROR,
> +  "Error: write idx<%u>, bit<%u>\n",
> +  s->pa, s->paio);
> +break;
> +}
> +
> +/* write bit data */
> +SET_FUSEARRAY_BIT(s->fuse, s->pa, s->paio, s->pdin);
> +
> +/* update written bit */
> +SET_FUSEARRAY_BIT(s->fuse_wo, s->pa, s->paio, WRITTEN_BIT_ON);
> +}
> +
>  break;
>  default:
>  qemu_log_mask(LOG_GUEST_ERROR, "%s: bad write: addr=0x%" HWADDR_PRIx
> @@ -165,6 +190,9 @@ static void sifive_u_otp_reset(DeviceState *dev)
>  /* Make a valid content of serial number */
>  s->fuse[SIFIVE_U_OTP_SERIAL_ADDR] = s->serial;
>  s->fuse[SIFIVE_U_OTP_SERIAL_ADDR + 1] = ~(s->serial);
> +
> +/* Initialize write-once map */
> +memset(s->fuse_wo, 0x00, sizeof(s->fuse_wo));
>  }
>
>  static void sifive_u_otp_class_init(ObjectClass *klass, void *data)
> diff --git a/include/hw/riscv/sifive_u_otp.h b/include/hw/riscv/sifive_u_otp.h
> index 639297564a..4a5a0acf48 100644
> --- a/include/hw/riscv/sifive_u_otp.h
> +++ b/include/hw/riscv/sifive_u_otp.h
> @@ -35,6 +35,8 @@
>  #define SIFIVE_U_OTP_PTRIM  0x34
>  #define SIFIVE_U_OTP_PWE0x38
>
> +#define SIFIVE_U_OTP_PWE_EN (1 << 0)
> +
>  #define SIFIVE_U_OTP_PCE_EN (1 << 0)
>
>  #define SIFIVE_U_OTP_PDSTB_EN   (1 << 0)
> @@ -73,6 +75,7 @@ typedef struct SiFiveUOTPState {
>  uint32_t ptrim;
>  uint32_t pwe;
>  uint32_t fuse[SIFIVE_U_OTP_NUM_FUSES];
> +uint32_t fuse_wo[SIFIVE_U_OTP_NUM_FUSES];
>  /* config */
>  uint32_t serial;
>  } SiFiveUOTPState;
> --
> 2.17.1
>
>

Re: [PATCH] i386: Document when features can be added to kvm_default_props

[Paolo Bonzini]

On 25/09/20 23:10, Eduardo Habkost wrote:
> It's very easy to mistakenly extend kvm_default_props to include
> features that require a kernel version that's too recent.  Add a
> comment warning about that, pointing to the documentation file
> where the minimum kernel version for KVM is documented.
> 
> Signed-off-by: Eduardo Habkost 
> ---
>  target/i386/cpu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 3ffd877dd51..c8558bb49ac 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4098,8 +4098,14 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  },
>  };
>  
> -/* KVM-specific features that are automatically added/removed
> +/*
> + * KVM-specific features that are automatically added/removed
>   * from all CPU models when KVM is enabled.
> + *
> + * NOTE: features can be enabled by default only if they were
> + *   already available in the oldest kernel version supported
> + *   by the KVM accelerator (see "OS requirements" section at
> + *   docs/system/target-i386.rst)
>   */
>  static PropValue kvm_default_props[] = {
>  { "kvmclock", "on" },
> 

Acked-by: Paolo Bonzini 

Re: [PATCH v1 5/8] s390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> +/* BRANCH INDIRECT ON CONDITION */
> +C(0xe347, BIC, RXY_b, MIE2,0, m2_64, 0, 0, bc, 0)
>  /* BRANCH ON CONDITION */
>  C(0x0700, BCR, RR_b,  Z,   0, r2_nz, 0, 0, bc, 0)
>  C(0x4700, BC,  RX_b,  Z,   0, a2, 0, 0, bc, 0)
> diff --git a/target/s390x/translate.c b/target/s390x/translate.c
> index b536491892..383edf7419 100644
> --- a/target/s390x/translate.c
> +++ b/target/s390x/translate.c
> @@ -1626,6 +1626,11 @@ static DisasJumpType op_bc(DisasContext *s, DisasOps 
> *o)
>  return DISAS_NEXT;
>  }
>  
> +/* For BIC the address came from memory, we need to wrap it again. */
> +if (s->fields.op2 == 0x47) {
> +gen_addi_and_wrap_i64(s, o->in2, o->in2, 0);
> +}

I'm not keen on this sort of per-opcode checks.

I'd prefer to add an in2_m2_64w() helper that performs the load and then wraps.


r~

Re: [PATCH v1 4/8] s390x/tcg: Implement MULTIPLY HALFWORD (MGH)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> Just like MULTIPLY HALFWORD IMMEDIATE (MGHI), only the second operand
> (signed 16 bit) comes from memory.
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/insn-data.def | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v6 00/21] Convert QAPI doc comments to generate rST instead of texinfo

[Peter Maydell]

On Fri, 25 Sep 2020 at 20:25,  wrote:

> In file included from ../src/qapi/qapi-schema.json:78:
> ../src/qapi/migration.json:1747:1: unexpected de-indent (expected at least 13 
> spaces)

This is yet another mis-indented line in a change to the QAPI
doc-comments (commit 4c437254b807). It hit master in the
latest migration pull after I'd sent out this patchseries
but before patchew got round to testing..

thanks
-- PMM

Re: [PATCH v1 3/8] s390x/tcg: Implement MULTIPLY (MG, MGRK)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> Multiply two signed 64bit values and store the 128bit result in r1 (0-63)
> and r1 + 1 (64-127).
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/insn-data.def |  2 ++
>  target/s390x/translate.c   | 13 +
>  2 files changed, 15 insertions(+)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v1 2/8] s390x/tcg: Implement SUBTRACT HALFWORD (SGH)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> Easy to wire up.
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/insn-data.def | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Richard Henderson 

r~

Re: [PATCH v1 1/8] s390x/tcg: Implement ADD HALFWORD (AGH)

[Richard Henderson]

On 9/22/20 3:31 AM, David Hildenbrand wrote:
> Easy, just like ADD HALFWORD IMMEDIATE (AGHI).
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/insn-data.def | 1 +
>  target/s390x/translate.c   | 1 +
>  2 files changed, 2 insertions(+)

Reviewed-by: Richard Henderson 

r~

[PATCH] i386: Document when features can be added to kvm_default_props

[Eduardo Habkost]

It's very easy to mistakenly extend kvm_default_props to include
features that require a kernel version that's too recent.  Add a
comment warning about that, pointing to the documentation file
where the minimum kernel version for KVM is documented.

Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ffd877dd51..c8558bb49ac 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4098,8 +4098,14 @@ static X86CPUDefinition builtin_x86_defs[] = {
 },
 };
 
-/* KVM-specific features that are automatically added/removed
+/*
+ * KVM-specific features that are automatically added/removed
  * from all CPU models when KVM is enabled.
+ *
+ * NOTE: features can be enabled by default only if they were
+ *   already available in the oldest kernel version supported
+ *   by the KVM accelerator (see "OS requirements" section at
+ *   docs/system/target-i386.rst)
  */
 static PropValue kvm_default_props[] = {
 { "kvmclock", "on" },
-- 
2.26.2

Re: SEV guest debugging support for Qemu

[Ashish Kalra]

Hello Paolo,

Thanks for your response.

On Fri, Sep 25, 2020 at 10:51:05AM +0200, Paolo Bonzini wrote:
> On 22/09/20 22:11, Ashish Kalra wrote:
> > This internally invokes the address_space_rw() accessor functions
> > which we had  "fixed" internally (as part of the earlier patch) to
> > invoke memory region specific debug ops. In our earlier approach we
> > were adding debug ops/callbacks to memory regions and as per comments
> > on our earlier patches, Paolo was not happy with this debug API for 
> > MemoryRegions and hence the SEV support for Qemu was merged without
> > the debug support.
> 
> My complaint was only about hooking into address_space_read and
> address_space_write; I think the hook should not touch general-purpose
> (non-debug) code if possible, so something like this:
> 
> typedef struct MemoryDebugOps {
> hwaddr (*translate)(CPUState *cpu, target_ulong addr,
> MemTxAttrs *attrs);
> MemTxResult (*read)(AddressSpace *as, hwaddr phys_addr,
> MemTxAttrs attrs, void *buf,
> hwaddr len);
> MemTxResult (*write)(AddressSpace *as, hwaddr phys_addr,
>  MemTxAttrs attrs, const void *buf,
>  hwaddr len);
> } MemoryDebugOps;
> 
> These ops would be used only by cpu_memory_rw_debug and would default to
> 
> static const MemoryDebugOps default_debug_ops = {
> .translate = cpu_get_phys_page_attrs_debug,
> .read = address_space_read,
> .write = address_space_write_rom
> };
> 
> static const MemoryDebugOps *debug_ops = &default_debug_ops;
> 

Yes, this looks like a good approach to proceed with.

I was also considering abstracting this vendor/SEV specific debug
interface via the CPUClass object, the CPUClass object aleady has cpu
specific methods for doing things like guest VA to GPA translations like the
get_phys_page_attrs_debug() method and it will be a simple and clean
approach to override this method with a SEV specific
get_phys_page_attrs_debug() if SEV guest is active and SEV debug policy
is allowed. This SEV specific method will then do guest page table walks
using the DBG_DECRYPT api and also clearing the c-bit bit on PxE copies.

One thought behind abstracting this vendor/SEV specific debug
interface via the CPUClass object is that the CPUClass object also has
methods for gdb register access such as
gdb_read_register()/gdb_write_register() which are invoked whenever
gdbstub does cpu register read/write. 

As part of this debug interface we also want to consider cpu register
access for SEV-ES, etc., for instance on SEV-ES we need to reject the
register access.  Again these gdb read/write methods in CPUClass object
can be overridden with SEV-ES specific variants which will then simply
return error when invoked. 

I can probably add new interfaces/methods to this CPUClass object for
guest memory read/writes for debugging purpose and then invoke the same
from the generic cpu_memory_rw_debug() interface. 

Let me know your thougts on abstracting this debug interface via the
CPUClass object ? 

Or the other option is to introduce the new MemoryDebugOps you described
above and additionally apply SEV/SEV-ES considerations in CPUClass
methods such as gdb_read_register, gdb_write_register, etc.

Thanks,
Ashish

Re: I wanna fixes plugin on windows, any suggestion

[Paolo Bonzini]

On 25/09/20 22:50, Richard Henderson wrote:
> On 9/25/20 12:25 PM, Paolo Bonzini wrote:
>> On 25/09/20 21:23, 罗勇刚(Yonggang Luo) wrote:
>>> That's what I am tring to fixes? what does  one import library per
>>> emulator, can we do this like NodeJS does?
>>>  NodeJS have NAPI support across platform. They create a windows .lib from
>>> node.exe
>>
>> You'd have to create a .lib for qemu-system-aarch64.exe, one for
>> qemu-system-arm.exe, etc.  On Linux the same plugin will work for all
>> emulators.
> 
> Which is clearly silly.
> 
> So what you'd do is create a common .lib that all of the plugins link to, and
> so do all of the qemu-foo.exe.
> 
> This would probably involve creating a set of call-backs that qemu-foo.exe
> would need to pass to the common .lib at startup.  It's harder to do with
> windows than linux, but it's not impossible.

Yes, or you can skip the .lib/.dll completely; you just place pointers
to the callbacks in a struct and pass it to the plugin when it's loaded,
through qemu_info_t.

Paolo

Re: SEV guest debugging support for Qemu

[Paolo Bonzini]

On 25/09/20 22:46, Ashish Kalra wrote:
> I was also considering abstracting this vendor/SEV specific debug
> interface via the CPUClass object, the CPUClass object aleady has cpu
> specific methods for doing things like guest VA to GPA translations like the
> get_phys_page_attrs_debug() method and it will be a simple and clean
> approach to override this method with a SEV specific
> get_phys_page_attrs_debug() if SEV guest is active and SEV debug policy
> is allowed. [...]
> 
> I can probably add new interfaces/methods to this CPUClass object for
> guest memory read/writes for debugging purpose and then invoke the same
> from the generic cpu_memory_rw_debug() interface. 
> 
> Let me know your thougts on abstracting this debug interface via the
> CPUClass object ? 
> 
> Or the other option is to introduce the new MemoryDebugOps you described
> above and additionally apply SEV/SEV-ES considerations in CPUClass
> methods such as gdb_read_register, gdb_write_register, etc.

Yes, this makes the most sense, however you're right that you don't need
translate in MemoryDebugOps.  I don't think read/write should be moved
to CPUClass, however, since you can use a MemTxAttr to tell the
read/write MemoryDebugOps whether the page is encrypted or not.

Paolo

Re: I wanna fixes plugin on windows, any suggestion

[Richard Henderson]

On 9/25/20 12:25 PM, Paolo Bonzini wrote:
> On 25/09/20 21:23, 罗勇刚(Yonggang Luo) wrote:
>> That's what I am tring to fixes? what does  one import library per
>> emulator, can we do this like NodeJS does?
>>  NodeJS have NAPI support across platform. They create a windows .lib from
>> node.exe
> 
> You'd have to create a .lib for qemu-system-aarch64.exe, one for
> qemu-system-arm.exe, etc.  On Linux the same plugin will work for all
> emulators.

Which is clearly silly.

So what you'd do is create a common .lib that all of the plugins link to, and
so do all of the qemu-foo.exe.

This would probably involve creating a set of call-backs that qemu-foo.exe
would need to pass to the common .lib at startup.  It's harder to do with
windows than linux, but it's not impossible.


r~

Re: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT

[Paolo Bonzini]

On 25/09/20 22:29, Eduardo Habkost wrote:
>> No, it's not possible.  KVM doesn't have a say on what the processor
>> writes in the tracing packets.
> Can KVM refuse to enable packet generation if CSbase is not zero
> and CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from
> host?

Yes, but the processor could change operating mode (and hence CSbase)
while tracing is active.  This is very unlikely, since it would require
nonzero CS-base and a 32-bit host, but in principle not impossible
(could be a firmware call, for example).

The only solution is for KVM to accept both, and for QEMU to refuse a
setting that does not match the host.

Paolo

[PATCH 2/3] nbd: Add new qemu:allocation-depth metacontext

[Eric Blake]

'qemu-img map' provides a way to determine which extents of an image
come from the top layer vs. inherited from a backing chain.  This is
useful information worth exposing over NBD.  There is a proposal to
add a QMP command block-dirty-bitmap-populate which can create a dirty
bitmap that reflects allocation information, at which point
qemu:dirty-bitmap:NAME can expose that information via the creation of
a temporary bitmap, but we can shorten the effort by adding a new
qemu:allocation-depth context that does the same thing without an
intermediate bitmap (this patch does not eliminate the need for that
proposal, as it will have other uses as well).

For this patch, I just encoded a tri-state value (unallocated, from
this layer, from any of the backing layers); we could instead or in
addition report an actual depth count per extent, if that proves more
useful.

Note that this patch does not actually enable any way to request a
server to enable this context; that will come in the next patch.

Signed-off-by: Eric Blake 
---
 docs/interop/nbd.txt |  22 +++--
 qapi/block-core.json |   6 ++-
 include/block/nbd.h  |   8 +++-
 nbd/server.c | 110 +++
 4 files changed, 132 insertions(+), 14 deletions(-)

diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index f3b3cacc9621..56efec7aee12 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -17,9 +17,9 @@ namespace "qemu".

 == "qemu" namespace ==

-The "qemu" namespace currently contains only one type of context,
-related to exposing the contents of a dirty bitmap alongside the
-associated disk contents.  That context has the following form:
+The "qemu" namespace currently contains two types of context.  The
+first is related to exposing the contents of a dirty bitmap alongside
+the associated disk contents.  That context has the following form:

 qemu:dirty-bitmap:

@@ -28,8 +28,21 @@ in reply for NBD_CMD_BLOCK_STATUS:

 bit 0: NBD_STATE_DIRTY, means that the extent is "dirty"

+The second is related to exposing the source of various extents within
+the image, with a single context named:
+
+qemu:allocation-depth
+
+In the allocation depth context, bits 0 and 1 form a tri-state value:
+
+bits 0-1 clear: NBD_STATE_DEPTH_UNALLOC, means the extent is unallocated
+bit 0 set: NBD_STATE_DEPTH_LOCAL, the extent is allocated in this image
+bit 1 set: NBD_STATE_DEPTH_BACKING, the extent is inherited from a
+   backing layer
+
 For NBD_OPT_LIST_META_CONTEXT the following queries are supported
-in addition to "qemu:dirty-bitmap:":
+in addition to the specific "qemu:allocation-depth" and
+"qemu:dirty-bitmap:":

 * "qemu:" - returns list of all available metadata contexts in the
 namespace.
@@ -55,3 +68,4 @@ the operation of that feature.
 NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
 * 4.2: NBD_FLAG_CAN_MULTI_CONN for shareable read-only exports,
 NBD_CMD_FLAG_FAST_ZERO
+* 5.2: NBD_CMD_BLOCK_STATUS for "qemu:allocation-depth"
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 3c16f1e11d6b..b3ec30a83cd7 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -5261,11 +5261,15 @@
 #  NBD client can use NBD_OPT_SET_META_CONTEXT with
 #  "qemu:dirty-bitmap:NAME" to inspect the bitmap. (since 4.0)
 #
+# @alloc: Also export the allocation map for @device, so the NBD client
+# can use NBD_OPT_SET_META_CONTEXT with "qemu:allocation-depth"
+# to inspect allocation details. (since 5.2)
+#
 # Since: 5.0
 ##
 { 'struct': 'BlockExportNbd',
   'data': {'device': 'str', '*name': 'str', '*description': 'str',
-   '*writable': 'bool', '*bitmap': 'str' } }
+   '*writable': 'bool', '*bitmap': 'str', '*alloc': 'bool' } }

 ##
 # @nbd-server-add:
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 9bc3bfaeecf8..71a2623f7842 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2016-2019 Red Hat, Inc.
+ *  Copyright (C) 2016-2020 Red Hat, Inc.
  *  Copyright (C) 2005  Anthony Liguori 
  *
  *  Network Block Device
@@ -257,6 +257,12 @@ enum {
 /* Extent flags for qemu:dirty-bitmap in NBD_REPLY_TYPE_BLOCK_STATUS */
 #define NBD_STATE_DIRTY (1 << 0)

+/* Extent flags for qemu:allocation-depth in NBD_REPLY_TYPE_BLOCK_STATUS */
+#define NBD_STATE_DEPTH_UNALLOC (0 << 0)
+#define NBD_STATE_DEPTH_LOCAL   (1 << 0)
+#define NBD_STATE_DEPTH_BACKING (2 << 0)
+#define NBD_STATE_DEPTH_MASK(0x3)
+
 static inline bool nbd_reply_type_is_error(int type)
 {
 return type & (1 << 15);
diff --git a/nbd/server.c b/nbd/server.c
index 0d2d7e52058f..02d5fb375b24 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -25,7 +25,8 @@
 #include "qemu/units.h"

 #define NBD_META_ID_BASE_ALLOCATION 0
-#define NBD_META_ID_DIRTY_BITMAP 1
+#define NBD_META_ID_ALLOCATION_DEPTH 1
+#define NBD_META_ID_DIRTY_BITMAP 2

 /*
  * NBD_MAX_BLOCK_STATUS_EXTENTS: 1 MiB of extents data. An empiric

[PATCH 0/3] Exposing backing-chain allocation over NBD

[Eric Blake]

I'm working on preparing my KVM Forum presentation on NBD, and ran
into a situation where I really wanted to do the equivalent of
'qemu-img map' over NBD for determining which portions of an overlay
image are changed from the backing layer.  So after less than 24 hours
hacking, I'm pretty pleased with the results.

Known caveats:

- Probably has lots of conflicts with Kevin's pending work on
  refactoring NBD for nicer use in qemu-storage-daemon

- Not yet tested with Vladimir's patches to fix bdrv_block_status bugs
  when the backing file is short (and therefore, applying this series
  without that is likely to make it possible to expose the same bugs
  of wrong information)

- I _still_ want to get QMP 'block-dirty-bitmap-populate' in qemu 5.2;
  with that in place, you could avoid the need for this series by
  instead populating a temporary bitmap and exposing that bitmap over
  NBD instead.  But that requires more work, both in coding (Peter
  Krempa and I still need to make sure we have the ideal QMP
  interface) and in usage (managing temporary bitmaps is more effort
  than a new bool toggle).

- And if we _did_ use block-dirty-bitmap-populate, I find myself
  wanting to be able to expose more than one bitmap at a time over
  NBD, which in turn means revisiting our current QAPI for
  nbd-server-add of '*bitmap':'str' to instead allow an alternate type
  that permits either "'str'" or "['str']", except that our QAPI
  generator does not yet support arrays in alternates, and is
  undergoing changes from John Snow for python cleanups...

- I am aware of long-standing qemu bugs where when we advertise a
  large minimum block size (say 4k) but the backing file has smaller
  granularity (such as 512), then we can violate NBD protocol by
  sending a reply to NBD_CMD_BLOCK_STATUS with misaligned data.  This
  adds yet another instance of being able to tickle that (rare) bug.
  I really need to revisit my patches to add
  bdrv_block_status_aligned...

Also available at:
https://repo.or.cz/qemu/ericb.git/shortlog/refs/tags/nbd-alloc-depth-v1

Eric Blake (3):
  nbd: Simplify meta-context parsing
  nbd: Add new qemu:allocation-depth metacontext
  nbd: Add 'qemu-nbd -A' to expose allocation depth

 docs/interop/nbd.txt   |  22 ++-
 docs/tools/qemu-nbd.rst|   6 +
 qapi/block-core.json   |  13 +-
 include/block/nbd.h|  15 +-
 blockdev-nbd.c |   3 +-
 nbd/server.c   | 294 -
 qemu-nbd.c |  16 +-
 tests/qemu-iotests/309 |  73 +
 tests/qemu-iotests/309.out |  22 +++
 tests/qemu-iotests/group   |   1 +
 10 files changed, 310 insertions(+), 155 deletions(-)
 create mode 100755 tests/qemu-iotests/309
 create mode 100644 tests/qemu-iotests/309.out

-- 
2.28.0

[PATCH 3/3] nbd: Add 'qemu-nbd -A' to expose allocation depth

[Eric Blake]

Allow the server to expose an additional metacontext to be requested
by savvy clients.  qemu-nbd adds a new option -A to expose the
qemu:allocation-depth metacontext through NBD_CMD_BLOCK_STATUS; this
can also be set via QMP when using nbd-server-add.

qemu as client can be hacked into viewing this new context by using
the now-misnamed x-dirty-bitmap option when creating an NBD blockdev;
although it is worth noting the decoding of how such context
information will appear in 'qemu-img map --output=json':

NBD_STATE_DEPTH_UNALLOC => "zero":false, "data":true
NBD_STATE_DEPTH_LOCAL => "zero":false, "data":false
NBD_STATE_DEPTH_BACKING => "zero":true, "data":true

libnbd as client is probably a nicer way to get at the information
without having to decipher such hacks in qemu as client. ;)

Signed-off-by: Eric Blake 
---
 docs/tools/qemu-nbd.rst|  6 
 qapi/block-core.json   |  7 ++--
 include/block/nbd.h|  7 ++--
 blockdev-nbd.c |  3 +-
 nbd/server.c   |  8 +++--
 qemu-nbd.c | 16 ++---
 tests/qemu-iotests/309 | 73 ++
 tests/qemu-iotests/309.out | 22 
 tests/qemu-iotests/group   |  1 +
 9 files changed, 129 insertions(+), 14 deletions(-)
 create mode 100755 tests/qemu-iotests/309
 create mode 100644 tests/qemu-iotests/309.out

diff --git a/docs/tools/qemu-nbd.rst b/docs/tools/qemu-nbd.rst
index 667861cb22e9..0e545a97cfa3 100644
--- a/docs/tools/qemu-nbd.rst
+++ b/docs/tools/qemu-nbd.rst
@@ -72,6 +72,12 @@ driver options if ``--image-opts`` is specified.

   Export the disk as read-only.

+.. option:: -A, --allocation-depth
+
+  Expose allocation depth information via the
+  ``qemu:allocation-depth`` context accessible through
+  NBD_OPT_SET_META_CONTEXT.
+
 .. option:: -B, --bitmap=NAME

   If *filename* has a qcow2 persistent bitmap *NAME*, expose
diff --git a/qapi/block-core.json b/qapi/block-core.json
index b3ec30a83cd7..84f7a7a34dc1 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3874,9 +3874,12 @@
 #
 # @tls-creds: TLS credentials ID
 #
-# @x-dirty-bitmap: A "qemu:dirty-bitmap:NAME" string to query in place of
+# @x-dirty-bitmap: A metacontext name such as "qemu:dirty-bitmap:NAME" or
+#  "qemu:allocation-depth" to query in place of the
 #  traditional "base:allocation" block status (see
-#  NBD_OPT_LIST_META_CONTEXT in the NBD protocol) (since 3.0)
+#  NBD_OPT_LIST_META_CONTEXT in the NBD protocol; and
+#  yes, naming this option x-context would have made
+#  more sense) (since 3.0)
 #
 # @reconnect-delay: On an unexpected disconnect, the nbd client tries to
 #   connect again until succeeding or encountering a serious
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 71a2623f7842..f660e0274ce3 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -336,9 +336,10 @@ typedef struct NBDClient NBDClient;

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, bool readonly, bool shared,
-  void (*close)(NBDExport *), bool writethrough,
-  BlockBackend *on_eject_blk, Error **errp);
+  bool alloc_depth, const char *bitmap, bool readonly,
+  bool shared, void (*close)(NBDExport *),
+  bool writethrough, BlockBackend *on_eject_blk,
+  Error **errp);
 void nbd_export_close(NBDExport *exp);
 void nbd_export_remove(NBDExport *exp, NbdServerRemoveMode mode, Error **errp);
 void nbd_export_get(NBDExport *exp);
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 1a95d89f0096..562ea3751b85 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -203,7 +203,8 @@ void qmp_nbd_server_add(BlockExportNbd *arg, Error **errp)
 arg->writable = false;
 }

-exp = nbd_export_new(bs, 0, len, arg->name, arg->description, arg->bitmap,
+exp = nbd_export_new(bs, 0, len, arg->name, arg->description,
+ arg->alloc, arg->bitmap,
  !arg->writable, !arg->writable,
  NULL, false, on_eject_blk, errp);
 if (!exp) {
diff --git a/nbd/server.c b/nbd/server.c
index 02d5fb375b24..f5e0e115b703 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1450,9 +1450,10 @@ static void nbd_eject_notifier(Notifier *n, void *data)

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, bool readonly, bool shared,
-  void (*close)(NBDExport *), bool writethrough,
-  BlockBackend *on_eject_blk, Error **errp)
+  bool alloc_depth, const c

[PATCH 1/3] nbd: Simplify meta-context parsing

[Eric Blake]

We had a premature optimization of trying to read as little from the
wire as possible while handling NBD_OPT_SET_META_CONTEXT in phases.
But in reality, we HAVE to read the entire string from the client
before we can get to the next command, and it is easier to just read
it all at once than it is to read it in pieces.  And once we do that,
several functions end up no longer performing I/O, and no longer need
to return a value.

While simplifying this, take advantage of g_str_has_prefix for less
repetition of boilerplate string length computation.

Our iotests still pass; I also checked that libnbd's testsuite (which
covers more corner cases of odd meta context requests) still passes.

Signed-off-by: Eric Blake 
---
 nbd/server.c | 172 ++-
 1 file changed, 47 insertions(+), 125 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 982de67816a7..0d2d7e52058f 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2016-2018 Red Hat, Inc.
+ *  Copyright (C) 2016-2020 Red Hat, Inc.
  *  Copyright (C) 2005  Anthony Liguori 
  *
  *  Network Block Device Server Side
@@ -792,135 +792,64 @@ static int nbd_negotiate_send_meta_context(NBDClient 
*client,
 return qio_channel_writev_all(client->ioc, iov, 2, errp) < 0 ? -EIO : 0;
 }

-/* Read strlen(@pattern) bytes, and set @match to true if they match @pattern.
- * @match is never set to false.
- *
- * Return -errno on I/O error, 0 if option was completely handled by
- * sending a reply about inconsistent lengths, or 1 on success.
- *
- * Note: return code = 1 doesn't mean that we've read exactly @pattern.
- * It only means that there are no errors.
+
+/*
+ * Check @ns with @len bytes, and set @match to true if it matches @pattern,
+ * or if @len is 0 and the client is performing _LIST_. @match is never set
+ * to false.
  */
-static int nbd_meta_pattern(NBDClient *client, const char *pattern, bool 
*match,
-Error **errp)
+static void nbd_meta_empty_or_pattern(NBDClient *client, const char *pattern,
+  const char *ns, uint32_t len,
+  bool *match, Error **errp)
 {
-int ret;
-char *query;
-size_t len = strlen(pattern);
-
-assert(len);
-
-query = g_malloc(len);
-ret = nbd_opt_read(client, query, len, errp);
-if (ret <= 0) {
-g_free(query);
-return ret;
-}
-
-if (strncmp(query, pattern, len) == 0) {
+if (len == 0) {
+if (client->opt == NBD_OPT_LIST_META_CONTEXT) {
+*match = true;
+}
+trace_nbd_negotiate_meta_query_parse("empty");
+} else if (strcmp(pattern, ns) == 0) {
 trace_nbd_negotiate_meta_query_parse(pattern);
 *match = true;
 } else {
 trace_nbd_negotiate_meta_query_skip("pattern not matched");
 }
-g_free(query);
-
-return 1;
-}
-
-/*
- * Read @len bytes, and set @match to true if they match @pattern, or if @len
- * is 0 and the client is performing _LIST_. @match is never set to false.
- *
- * Return -errno on I/O error, 0 if option was completely handled by
- * sending a reply about inconsistent lengths, or 1 on success.
- *
- * Note: return code = 1 doesn't mean that we've read exactly @pattern.
- * It only means that there are no errors.
- */
-static int nbd_meta_empty_or_pattern(NBDClient *client, const char *pattern,
- uint32_t len, bool *match, Error **errp)
-{
-if (len == 0) {
-if (client->opt == NBD_OPT_LIST_META_CONTEXT) {
-*match = true;
-}
-trace_nbd_negotiate_meta_query_parse("empty");
-return 1;
-}
-
-if (len != strlen(pattern)) {
-trace_nbd_negotiate_meta_query_skip("different lengths");
-return nbd_opt_skip(client, len, errp);
-}
-
-return nbd_meta_pattern(client, pattern, match, errp);
 }

 /* nbd_meta_base_query
  *
  * Handle queries to 'base' namespace. For now, only the base:allocation
- * context is available.  'len' is the amount of text remaining to be read from
- * the current name, after the 'base:' portion has been stripped.
- *
- * Return -errno on I/O error, 0 if option was completely handled by
- * sending a reply about inconsistent lengths, or 1 on success.
+ * context is available.  @len is the length of @ns, including the 'base:'
+ * prefix.
  */
-static int nbd_meta_base_query(NBDClient *client, NBDExportMetaContexts *meta,
-   uint32_t len, Error **errp)
+static void nbd_meta_base_query(NBDClient *client, NBDExportMetaContexts *meta,
+const char *ns, uint32_t len, Error **errp)
 {
-return nbd_meta_empty_or_pattern(client, "allocation", len,
- &meta->base_allocation, errp);
+nbd_meta_empty_or_pattern(client, "allocation", ns + 5, len - 5,
+  &meta->base_allocation, errp);

Re: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT

[Eduardo Habkost]

On Fri, Sep 25, 2020 at 10:23:49PM +0200, Paolo Bonzini wrote:
> On 25/09/20 18:54, Eduardo Habkost wrote:
> > On Fri, Sep 25, 2020 at 04:42:26PM +, Strong, Beeman wrote:
> >> LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which 
> >> requires 32-bit code.  In that case a LIP=0 implementation will provide 
> >> only the EIP offset from CSbase in IP packets (like TIP or FUP), while 
> >> LIP=1 implementation will provide the full LIP (CSbase + EIP offset).
> >>
> > Thanks.  Is it possible to make KVM emulate LIP=0 behavior
> > correctly on LIP=1 hosts, or vice versa?
> 
> No, it's not possible.  KVM doesn't have a say on what the processor
> writes in the tracing packets.

Can KVM refuse to enable packet generation if CSbase is not zero
and CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from
host?

-- 
Eduardo

Re: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT

[Paolo Bonzini]

On 25/09/20 18:54, Eduardo Habkost wrote:
> On Fri, Sep 25, 2020 at 04:42:26PM +, Strong, Beeman wrote:
>> LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which 
>> requires 32-bit code.  In that case a LIP=0 implementation will provide only 
>> the EIP offset from CSbase in IP packets (like TIP or FUP), while LIP=1 
>> implementation will provide the full LIP (CSbase + EIP offset).
>>
> Thanks.  Is it possible to make KVM emulate LIP=0 behavior
> correctly on LIP=1 hosts, or vice versa?

No, it's not possible.  KVM doesn't have a say on what the processor
writes in the tracing packets.

Paolo

Re: [PATCH v26 04/17] vfio: Add migration region initialization and finalize function

[Alex Williamson]

On Wed, 23 Sep 2020 04:54:06 +0530
Kirti Wankhede  wrote:

> Whether the VFIO device supports migration or not is decided based of
> migration region query. If migration region query is successful and migration
> region initialization is successful then migration is supported else
> migration is blocked.
> 
> Signed-off-by: Kirti Wankhede 
> Reviewed-by: Neo Jia 
> Acked-by: Dr. David Alan Gilbert 
> ---
>  hw/vfio/meson.build   |   1 +
>  hw/vfio/migration.c   | 142 
> ++
>  hw/vfio/trace-events  |   5 ++
>  include/hw/vfio/vfio-common.h |   9 +++
>  4 files changed, 157 insertions(+)
>  create mode 100644 hw/vfio/migration.c
> 
> diff --git a/hw/vfio/meson.build b/hw/vfio/meson.build
> index 37efa74018bc..da9af297a0c5 100644
> --- a/hw/vfio/meson.build
> +++ b/hw/vfio/meson.build
> @@ -2,6 +2,7 @@ vfio_ss = ss.source_set()
>  vfio_ss.add(files(
>'common.c',
>'spapr.c',
> +  'migration.c',
>  ))
>  vfio_ss.add(when: 'CONFIG_VFIO_PCI', if_true: files(
>'display.c',
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> new file mode 100644
> index ..2f760f1f9c47
> --- /dev/null
> +++ b/hw/vfio/migration.c
> @@ -0,0 +1,142 @@
> +/*
> + * Migration support for VFIO devices
> + *
> + * Copyright NVIDIA, Inc. 2020
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +#include 
> +
> +#include "hw/vfio/vfio-common.h"
> +#include "cpu.h"
> +#include "migration/migration.h"
> +#include "migration/qemu-file.h"
> +#include "migration/register.h"
> +#include "migration/blocker.h"
> +#include "migration/misc.h"
> +#include "qapi/error.h"
> +#include "exec/ramlist.h"
> +#include "exec/ram_addr.h"
> +#include "pci.h"
> +#include "trace.h"
> +
> +static void vfio_migration_region_exit(VFIODevice *vbasedev)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +
> +if (!migration) {
> +return;
> +}
> +
> +if (migration->region.size) {
> +vfio_region_exit(&migration->region);
> +vfio_region_finalize(&migration->region);
> +}
> +}
> +
> +static int vfio_migration_region_init(VFIODevice *vbasedev, int index)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +Object *obj = NULL;

Unnecessary initialization.

> +int ret = -EINVAL;

return -EINVAL below, this doesn't need to be initialized, use it for
storing actual return values.

> +
> +obj = vbasedev->ops->vfio_get_object(vbasedev);
> +if (!obj) {
> +return ret;
> +}

vfio_migration_init() tests whether the vbasedev->ops supports
vfio_get_object, then calls this, then calls vfio_get_object itself
(added in a later patch, with a strange inconsistency in failure modes).
Wouldn't it make more sense for vfio_migration_init() to pass the
Object since that function also needs it (eventually) and actually does
the existence test?

> +
> +ret = vfio_region_setup(obj, vbasedev, &migration->region, index,
> +"migration");
> +if (ret) {
> +error_report("%s: Failed to setup VFIO migration region %d: %s",
> + vbasedev->name, index, strerror(-ret));
> +goto err;
> +}
> +
> +if (!migration->region.size) {
> +ret = -EINVAL;
> +error_report("%s: Invalid region size of VFIO migration region %d: 
> %s",
> + vbasedev->name, index, strerror(-ret));
> +goto err;
> +}

If the caller were to pass obj, this is nothing more than a wrapper for
calling vfio_region_setup(), which suggests to me we might not even
need this as a separate function outside of vfio_migration_init().

> +
> +return 0;
> +
> +err:
> +vfio_migration_region_exit(vbasedev);
> +return ret;
> +}
> +
> +static int vfio_migration_init(VFIODevice *vbasedev,
> +   struct vfio_region_info *info)
> +{
> +int ret = -EINVAL;
> +
> +if (!vbasedev->ops->vfio_get_object) {
> +return ret;
> +}
> +
> +vbasedev->migration = g_new0(VFIOMigration, 1);
> +
> +ret = vfio_migration_region_init(vbasedev, info->index);
> +if (ret) {
> +error_report("%s: Failed to initialise migration region",
> + vbasedev->name);
> +g_free(vbasedev->migration);
> +vbasedev->migration = NULL;
> +}
> +
> +return ret;
> +}
> +
> +/* -- */
> +
> +int vfio_migration_probe(VFIODevice *vbasedev, Error **errp)
> +{
> +struct vfio_region_info *info = NULL;

Not sure this initialization is strictly necessary either, but it also
seems to be a common convention for this function, so either way.

Connie, does vfio_ccw_get_region() leak this?  It appears to call
vfio_get_dev_region_info() and vfio_get_region_info() several times with
the same pointer without freeing it b

Re: [PATCH] hw/scsi/lsi53c895a: Sanitize some trace events format

[Paolo Bonzini]

On 15/09/20 19:46, Philippe Mathieu-Daudé wrote:
> Make some lsi53c895a trace events more understandable.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/scsi/trace-events | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/scsi/trace-events b/hw/scsi/trace-events
> index 9a4a60ca635..ac4209f361e 100644
> --- a/hw/scsi/trace-events
> +++ b/hw/scsi/trace-events
> @@ -234,9 +234,9 @@ spapr_vscsi_do_crq(unsigned c0, unsigned c1) "crq: %02x 
> %02x ..."
>  
>  # lsi53c895a.c
>  lsi_reset(void) "Reset"
> -lsi_update_irq(int level, uint8_t dstat, uint8_t sist1, uint8_t sist0) 
> "Update IRQ level %d dstat 0x%02x sist 0x%02x0x%02x"
> +lsi_update_irq(int level, uint8_t dstat, uint8_t sist1, uint8_t sist0) 
> "Update IRQ level %d dstat 0x%02x sist 1:0x%02x 0:0x%02x"
>  lsi_update_irq_disconnected(void) "Handled IRQs & disconnected, looking for 
> pending processes"
> -lsi_script_scsi_interrupt(uint8_t stat1, uint8_t stat0, uint8_t sist1, 
> uint8_t sist0) "SCSI Interrupt 0x%02x0x%02x prev 0x%02x0x%02x"
> +lsi_script_scsi_interrupt(uint8_t stat1, uint8_t stat0, uint8_t sist1, 
> uint8_t sist0) "SCSI Interrupt stat 1:0x%02x 0:0x%02x sist 1:0x%02x 0:0x%02x"
>  lsi_script_dma_interrupt(uint8_t stat, uint8_t dstat) "DMA Interrupt 0x%x 
> prev 0x%x"
>  lsi_bad_phase_jump(uint32_t dsp) "Data phase mismatch jump to 0x%"PRIX32
>  lsi_bad_phase_interrupt(void) "Phase mismatch interrupt"
> 

The idea of the patch is that SIST0 and SIST1 are usually read in pairs.
 So it's a bit weird in the tracepoint format but it's actually more
understandable this way when you see it printed.

Laurent, can you please unqueue this?

Paolo

[PULL v6 00/87] Misc patches for 2020-09-24

[Paolo Bonzini]

The following changes since commit 8c1c07929feae876202ba26f07a540c5115c18cd:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2020-09-24 18:48:45 +0100)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to f19fc40acf2a4481f56165228f788f322d947f60:

  hw/net/can: Correct Kconfig dependencies (2020-09-25 15:21:30 -0400)


* SCSI fix (Dmitry, Li Feng, Li Qiang)
* memory API fixes (Eduardo)
* removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)
* ACPI fix for VMBus (Jon)
* relocatable install (myself)
* always remove docker containers (myself)
* serial cleanups (Philippe)
* vmware cpuid leaf for tsc and apic frequency (Sunil)
* KVM_FEATURE_ASYNC_PF_INT support (Vitaly)
* i386 XSAVE bugfix (Xiaoyao)
* QOM developer documentation in docs/devel (Eduardo)
* new checkpatch tests (Dov)
* x86_64 syscall fix (Douglas)
* interrupt-based APF fix (Vitaly)
* always create kvmclock (Vitaly)
* fix bios-tables-test (Eduardo)
* KVM PV features cleanup (myself)
* CAN FD (Pavel)

meson:
* fixes (Marc-André, Max, Stefan, Alexander, myself)
* moved libmpathpersist, cocoa, malloc tests (myself)
* support for 0.56 introspected test dependencies (myself)


Alexander Bulekov (1):
  oss-fuzz: move linker arg to fix coverage-build

Anthony PERARD (1):
  meson: fix installation of keymaps

Claudio Fontana (1):
  tests: add missing genh dependency

Daniel P. Berrangé (1):
  char: fix logging when chardev write fails

Dmitry Fomichev (1):
  scsi-generic: Fix HM-zoned device scan

Douglas Crosher (1):
  helper_syscall x86_64: clear exception_is_int

Dov Murik (1):
  checkpatch: Detect '%#' or '%0#' in printf-style format strings

Eduardo Habkost (10):
  memory: Convert IOMMUMemoryRegionClass doc comment to kernel-doc
  qom: Document all function parameters in doc comments
  qom: Use kernel-doc private/public tags in structs
  qom: Use ``code`` Sphinx syntax where appropriate
  qom: Add kernel-doc markup to introduction doc comment
  qom: Reformat section titles using Sphinx syntax
  qom: Indent existing code examples
  qom: Add code block markup to all code blocks
  docs: Create docs/devel/qom.rst
  bios-tables-test: Remove kernel-irqchip=off option

Igor Mammedov (5):
  numa: drop support for '-numa node' (without memory specified)
  doc: Cleanup "'-mem-path' fallback to RAM" deprecation text
  numa: remove fixup numa_state->num_nodes to MAX_NODES
  smp: drop support for deprecated (invalid topologies)
  cphp: remove deprecated cpu-add command(s)

Jan Charvat (5):
  net/can: Initial host SocketCan support for CAN FD.
  hw/net/can: sja1000 ignore CAN FD frames
  net/can: Add can_dlc2len and can_len2dlc for CAN FD.
  hw/net/can/ctucafd: Add CTU CAN FD core register definitions.
  hw/net/can: CTU CAN FD IP open hardware core emulation.

Jon Doron (1):
  acpi: i386: Move VMBus DSDT entry to SB

Li Feng (1):
  vhost-scsi: support inflight io track

Li Qiang (2):
  hw: megasas: return -1 when 'megasas_map_sgl' fails
  hw: megasas: consider 'iov_count=0' is an error in megasas_map_sgl

Marc-André Lureau (2):
  meson: fix MSI rule
  meson: error out if qemu_suffix starts with /

Paolo Bonzini (28):
  meson: clean up build_by_default
  ninjatool: rebuild multi-output targets if outputs are missing
  meson: move libudev test
  meson: move libmpathpersist test
  meson: extend libmpathpersist test for static linking
  configure: move malloc_trim/tcmalloc/jemalloc to meson
  configure: fix --meson=/path/to/meson
  configure: move cocoa option to Meson
  configure: do not limit Hypervisor.framework test to Darwin
  meson: qtest: set "depends" correctly
  mtest2make: add support for introspected test dependencies
  meson: report accelerator support
  oslib: do not call g_strdup from qemu_get_exec_dir
  fuzz: use qemu_get_exec_dir
  oslib-posix: default exec_dir to bindir
  cutils: introduce get_relocated_path
  oslib-posix: relocate path to /var
  module: relocate path to modules
  net: relocate paths to helpers and scripts
  vl: relocate paths to data directories
  vl: relocate path to configuration file
  qemu-bridge-helper: relocate path to default ACL
  qga: relocate path to default configuration and hook
  ui: relocate paths to icons and translations
  configure: use a platform-neutral prefix
  tests/tcg: reinstate or replace desired parts of rules.mak
  docs: Move object.h overview doc comment to qom.rst
  target/i386: kvm: do not use kvm_check_extension to find paravirtual 
capabilities

Pavel Pisa (2):
  hw/net/can: Documentation for CTU CAN FD IP open 

[PULL 30/87] meson: move libmpathpersist test

[Paolo Bonzini]

This is the first compiler/linker test that has been moved to Meson.
Add more section headings to keep things clearer.

This also fixes static linking to libmpathpersist, which has a
dependency on libmultipath but no pkg-config file to describe it.

Signed-off-by: Paolo Bonzini 
---
 configure | 77 +++-
 meson.build   | 81 +++
 meson_options.txt |  2 ++
 3 files changed, 80 insertions(+), 80 deletions(-)

diff --git a/configure b/configure
index c05d1a04e9..6cffe0fde8 100755
--- a/configure
+++ b/configure
@@ -403,7 +403,7 @@ netmap="no"
 sdl="auto"
 sdl_image="auto"
 virtfs=""
-mpath=""
+mpath="auto"
 vnc="enabled"
 sparse="no"
 vde=""
@@ -1116,9 +1116,9 @@ for opt do
   ;;
   --enable-virtfs) virtfs="yes"
   ;;
-  --disable-mpath) mpath="no"
+  --disable-mpath) mpath="disabled"
   ;;
-  --enable-mpath) mpath="yes"
+  --enable-mpath) mpath="enabled"
   ;;
   --disable-vnc) vnc="disabled"
   ;;
@@ -3851,57 +3851,6 @@ if test "$modules" = yes; then
 fi
 fi
 
-##
-# libmpathpersist probe
-
-if test "$mpath" != "no" ; then
-  # probe for the new API
-  cat > $TMPC <
-#include 
-unsigned mpath_mx_alloc_len = 1024;
-int logsink;
-static struct config *multipath_conf;
-extern struct udev *udev;
-extern struct config *get_multipath_config(void);
-extern void put_multipath_config(struct config *conf);
-struct udev *udev;
-struct config *get_multipath_config(void) { return multipath_conf; }
-void put_multipath_config(struct config *conf) { }
-
-int main(void) {
-udev = udev_new();
-multipath_conf = mpath_lib_init();
-return 0;
-}
-EOF
-  if compile_prog "" "-ludev -lmultipath -lmpathpersist" ; then
-mpathpersist=yes
-mpathpersist_new_api=yes
-  else
-# probe for the old API
-cat > $TMPC <
-#include 
-unsigned mpath_mx_alloc_len = 1024;
-int logsink;
-int main(void) {
-struct udev *udev = udev_new();
-mpath_lib_init(udev);
-return 0;
-}
-EOF
-if compile_prog "" "-ludev -lmultipath -lmpathpersist" ; then
-  mpathpersist=yes
-  mpathpersist_new_api=no
-else
-  mpathpersist=no
-fi
-  fi
-else
-  mpathpersist=no
-fi
-
 ##
 # pthread probe
 PTHREADLIBS_LIST="-pthread -lpthread -lpthreadGC2"
@@ -6343,23 +6292,11 @@ if test "$softmmu" = yes ; then
   fi
   virtfs=no
 fi
-if test "$mpath" != no && test "$mpathpersist" = yes ; then
-  mpath=yes
-else
-  if test "$mpath" = yes; then
-error_exit "Multipath requires libmpathpersist devel"
-  fi
-  mpath=no
-fi
   else
 if test "$virtfs" = yes; then
   error_exit "VirtFS is supported only on Linux"
 fi
 virtfs=no
-if test "$mpath" = yes; then
-  error_exit "Multipath is supported only on Linux"
-fi
-mpath=no
   fi
 fi
 
@@ -6900,12 +6837,6 @@ fi
 if test "$virtfs" = "yes" ; then
   echo "CONFIG_VIRTFS=y" >> $config_host_mak
 fi
-if test "$mpath" = "yes" ; then
-  echo "CONFIG_MPATH=y" >> $config_host_mak
-  if test "$mpathpersist_new_api" = "yes"; then
-echo "CONFIG_MPATH_NEW_API=y" >> $config_host_mak
-  fi
-fi
 if test "$vhost_scsi" = "yes" ; then
   echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
 fi
@@ -7995,7 +7926,7 @@ NINJA=${ninja:-$PWD/ninjatool} $meson setup \
 -Dstrip=$(if test "$strip_opt" = yes; then echo true; else echo false; 
fi) \
 -Db_pie=$(if test "$pie" = yes; then echo true; else echo false; fi) \
 -Db_coverage=$(if test "$gcov" = yes; then echo true; else echo false; 
fi) \
-   -Dsdl=$sdl -Dsdl_image=$sdl_image \
+   -Dmpath=$mpath -Dsdl=$sdl -Dsdl_image=$sdl_image \
-Dvnc=$vnc -Dvnc_sasl=$vnc_sasl -Dvnc_jpeg=$vnc_jpeg -Dvnc_png=$vnc_png 
\
-Dgettext=$gettext -Dxkbcommon=$xkbcommon -Du2f=$u2f\
 $cross_arg \
diff --git a/meson.build b/meson.build
index 81cd09d224..2497d37627 100644
--- a/meson.build
+++ b/meson.build
@@ -86,6 +86,14 @@ if 'SPARSE_CFLAGS' in config_host
'compile_commands.json'])
 endif
 
+###
+# Target-specific checks and dependencies #
+###
+
+if targetos != 'linux' and get_option('mpath').enabled()
+  error('Multipath is supported only on Linux')
+endif
+
 m = cc.find_library('m', required: false)
 util = cc.find_library('util', required: false)
 winmm = []
@@ -117,6 +125,11 @@ elif targetos == 'haiku'
 cc.find_library('network'),
 cc.find_library('bsd')]
 endif
+
+
+# Dependencies #
+
+
 # The path to glib.h is added to all compilation commands.  This was
 # grandfathered in from the QEMU Makefiles.
 add_project_arguments(config_host['GLIB_CFLAGS'].split(),
@@ -223,10 +236,6 @@ if 'CONFIG_SPICE' in config_host
  link_args: config_host['SPICE_LIBS'].split())
 endif
 rt = cc.find_l

[PULL 29/87] meson: move libudev test

[Paolo Bonzini]

Signed-off-by: Paolo Bonzini 
---
 configure   | 14 --
 meson.build |  7 ---
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/configure b/configure
index 01fce2e94b..c05d1a04e9 100755
--- a/configure
+++ b/configure
@@ -908,7 +908,6 @@ Linux)
   linux_user="yes"
   kvm="yes"
   QEMU_INCLUDES="-isystem ${source_path}/linux-headers -Ilinux-headers 
$QEMU_INCLUDES"
-  libudev="yes"
 ;;
 esac
 
@@ -6286,15 +6285,6 @@ if test "$libnfs" != "no" ; then
 fi
 
 ##
-# Do we have libudev
-if test "$libudev" != "no" ; then
-  if $pkg_config libudev && test "$static" != "yes"; then
-libudev="yes"
-libudev_libs=$($pkg_config --libs libudev)
-  else
-libudev="no"
-  fi
-fi
 
 # Exclude --warn-common with TSan to suppress warnings from the TSan libraries.
 if test "$solaris" = "no" && test "$tsan" = "no"; then
@@ -7463,10 +7453,6 @@ if test "$gcov" = "yes" ; then
   echo "CONFIG_GCOV=y" >> $config_host_mak
 fi
 
-if test "$libudev" != "no"; then
-echo "CONFIG_LIBUDEV=y" >> $config_host_mak
-echo "LIBUDEV_LIBS=$libudev_libs" >> $config_host_mak
-fi
 if test "$fuzzing" != "no"; then
 echo "CONFIG_FUZZ=y" >> $config_host_mak
 fi
diff --git a/meson.build b/meson.build
index c48ca0d12a..81cd09d224 100644
--- a/meson.build
+++ b/meson.build
@@ -257,8 +257,8 @@ if 'CONFIG_CURL' in config_host
 link_args: config_host['CURL_LIBS'].split())
 endif
 libudev = not_found
-if 'CONFIG_LIBUDEV' in config_host
-  libudev = declare_dependency(link_args: config_host['LIBUDEV_LIBS'].split())
+if target_os == 'linux' and (have_softmmu or have_tools)
+  libudev = dependency('libudev', static: enable_static)
 endif
 brlapi = not_found
 if 'CONFIG_BRLAPI' in config_host
@@ -440,6 +440,7 @@ has_gettid = cc.has_function('gettid')
 
 # Create config-host.h
 
+config_host_data.set('CONFIG_LIBUDEV', libudev.found())
 config_host_data.set('CONFIG_SDL', sdl.found())
 config_host_data.set('CONFIG_SDL_IMAGE', sdl_image.found())
 config_host_data.set('CONFIG_VNC', vnc.found())
@@ -1520,7 +1521,7 @@ summary_info += {'sheepdog support':  
config_host.has_key('CONFIG_SHEEPDOG')}
 summary_info += {'capstone':  config_host.has_key('CONFIG_CAPSTONE')}
 summary_info += {'libpmem support':   config_host.has_key('CONFIG_LIBPMEM')}
 summary_info += {'libdaxctl support': config_host.has_key('CONFIG_LIBDAXCTL')}
-summary_info += {'libudev':   config_host.has_key('CONFIG_LIBUDEV')}
+summary_info += {'libudev':   libudev.found()}
 summary_info += {'default devices':   config_host['CONFIG_MINIKCONF_MODE'] == 
'--defconfig'}
 summary_info += {'plugin support':config_host.has_key('CONFIG_PLUGIN')}
 summary_info += {'fuzzing support':   config_host.has_key('CONFIG_FUZZ')}
-- 
2.26.2

[PULL 09/87] target/i386: support KVM_FEATURE_ASYNC_PF_INT

[Paolo Bonzini]

From: Vitaly Kuznetsov 

Linux-5.8 introduced interrupt based mechanism for 'page ready' events
delivery and disabled the old, #PF based one (see commit 2635b5c4a0e4
"KVM: x86: interrupt based APF 'page ready' event delivery"). Linux
guest switches to using in in 5.9 (see commit b1d405751cd5 "KVM: x86:
Switch KVM guest to using interrupts for page ready APF delivery").
The feature has a new KVM_FEATURE_ASYNC_PF_INT bit assigned and
the interrupt vector is set in MSR_KVM_ASYNC_PF_INT MSR. Support this
in QEMU.

Signed-off-by: Vitaly Kuznetsov 
Message-Id: <20200908141206.357450-1-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 target/i386/cpu.c |  3 ++-
 target/i386/cpu.h |  1 +
 target/i386/kvm.c | 10 ++
 target/i386/machine.c | 19 +++
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ffd877dd5..0ea0630e1f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -799,7 +799,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 "kvmclock", "kvm-nopiodelay", "kvm-mmu", "kvmclock",
 "kvm-asyncpf", "kvm-steal-time", "kvm-pv-eoi", "kvm-pv-unhalt",
 NULL, "kvm-pv-tlb-flush", NULL, "kvm-pv-ipi",
-"kvm-poll-control", "kvm-pv-sched-yield", NULL, NULL,
+"kvm-poll-control", "kvm-pv-sched-yield", "kvm-asyncpf-int", NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 "kvmclock-stable-bit", NULL, NULL, NULL,
@@ -6988,6 +6988,7 @@ static void x86_cpu_initfn(Object *obj)
 object_property_add_alias(obj, "kvm_nopiodelay", obj, "kvm-nopiodelay");
 object_property_add_alias(obj, "kvm_mmu", obj, "kvm-mmu");
 object_property_add_alias(obj, "kvm_asyncpf", obj, "kvm-asyncpf");
+object_property_add_alias(obj, "kvm_asyncpf_int", obj, "kvm-asyncpf-int");
 object_property_add_alias(obj, "kvm_steal_time", obj, "kvm-steal-time");
 object_property_add_alias(obj, "kvm_pv_eoi", obj, "kvm-pv-eoi");
 object_property_add_alias(obj, "kvm_pv_unhalt", obj, "kvm-pv-unhalt");
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index f519d2bfd4..51c1d5f60a 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1492,6 +1492,7 @@ typedef struct CPUX86State {
 uint64_t wall_clock_msr;
 uint64_t steal_time_msr;
 uint64_t async_pf_en_msr;
+uint64_t async_pf_int_msr;
 uint64_t pv_eoi_en_msr;
 uint64_t poll_control_msr;
 
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 9efb07e7c8..06c2025c67 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -287,6 +287,7 @@ static const struct kvm_para_features {
 { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
 { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
 { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+{ KVM_CAP_ASYNC_PF_INT, KVM_FEATURE_ASYNC_PF_INT },
 };
 
 static int get_para_features(KVMState *s)
@@ -2821,6 +2822,9 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) {
 kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr);
 }
+if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF_INT)) {
+kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_int_msr);
+}
 if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) {
 kvm_msr_entry_add(cpu, MSR_KVM_PV_EOI_EN, env->pv_eoi_en_msr);
 }
@@ -3206,6 +3210,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) {
 kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, 0);
 }
+if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF_INT)) {
+kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_INT, 0);
+}
 if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) {
 kvm_msr_entry_add(cpu, MSR_KVM_PV_EOI_EN, 0);
 }
@@ -3446,6 +3453,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 case MSR_KVM_ASYNC_PF_EN:
 env->async_pf_en_msr = msrs[i].data;
 break;
+case MSR_KVM_ASYNC_PF_INT:
+env->async_pf_int_msr = msrs[i].data;
+break;
 case MSR_KVM_PV_EOI_EN:
 env->pv_eoi_en_msr = msrs[i].data;
 break;
diff --git a/target/i386/machine.c b/target/i386/machine.c
index b1acf7d0ef..233e46bb70 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -394,6 +394,13 @@ static bool async_pf_msr_needed(void *opaque)
 return cpu->env.async_pf_en_msr != 0;
 }
 
+static bool async_pf_int_msr_needed(void *opaque)
+{
+X86CPU *cpu = opaque;
+
+return cpu->env.async_pf_int_msr != 0;
+}
+
 static bool pv_eoi_msr_needed(void *opaque)
 {
 X86CPU *cpu = opaque;
@@ -467,6 +474,17 @@ static const VMStateDescription vmstate_async_pf_msr = {
 }
 };
 
+static const VMStateDescription vmstate_async_pf_int_msr = {
+.name = "cpu/async_pf_int_msr",
+.version_id = 1,
+  

Re: I wanna fixes plugin on windows, any suggestion

[Paolo Bonzini]

On 25/09/20 21:30, 罗勇刚(Yonggang Luo) wrote:
> 
>> You'd have to create a .lib for qemu-system-aarch64.exe, one for
>> qemu-system-arm.exe, etc.  On Linux the same plugin will work for all
>> emulators.
>>
> OK, this made the things clear, the possible solution is to using
> function pointer to expose
> all Plugin-API functions

Yes you could pass the functions in a struct.  You can talk to Alex
Bennee about that.

Paolo

Re: [PATCH v1 03/15] meson: move libmpathpersist test

[Alex Bennée]

Paolo Bonzini  writes:

> On 25/09/20 17:40, Alex Bennée wrote:
>> From: Paolo Bonzini 
>> 
>> This is the first compiler/linker test that has been moved to Meson.
>> Add more section headings to keep things clearer.
>> 
>> [thuth: Add check for mpathpersist.found() before showing 
>> mpathpersist_new_api]
>> 
>> Signed-off-by: Paolo Bonzini 
>> Signed-off-by: Thomas Huth 
>> Message-Id: <20200918103430.297167-3-th...@redhat.com>
>> Signed-off-by: Alex Bennée 
>> ---
>>  configure | 77 +++-
>>  meson.build   | 82 ++-
>>  meson_options.txt |  2 ++
>>  3 files changed, 80 insertions(+), 81 deletions(-)
>> 
>> diff --git a/configure b/configure
>> index 48bf437021f6..b81868cf0231 100755
>> --- a/configure
>> +++ b/configure
>> @@ -403,7 +403,7 @@ netmap="no"
>>  sdl="auto"
>>  sdl_image="auto"
>>  virtfs=""
>> -mpath=""
>> +mpath="auto"
>>  vnc="enabled"
>>  sparse="no"
>>  vde=""
>> @@ -1116,9 +1116,9 @@ for opt do
>>;;
>>--enable-virtfs) virtfs="yes"
>>;;
>> -  --disable-mpath) mpath="no"
>> +  --disable-mpath) mpath="disabled"
>>;;
>> -  --enable-mpath) mpath="yes"
>> +  --enable-mpath) mpath="enabled"
>>;;
>>--disable-vnc) vnc="disabled"
>>;;
>> @@ -3848,57 +3848,6 @@ if test "$modules" = yes; then
>>  fi
>>  fi
>>  
>> -##
>> -# libmpathpersist probe
>> -
>> -if test "$mpath" != "no" ; then
>> -  # probe for the new API
>> -  cat > $TMPC <> -#include 
>> -#include 
>> -unsigned mpath_mx_alloc_len = 1024;
>> -int logsink;
>> -static struct config *multipath_conf;
>> -extern struct udev *udev;
>> -extern struct config *get_multipath_config(void);
>> -extern void put_multipath_config(struct config *conf);
>> -struct udev *udev;
>> -struct config *get_multipath_config(void) { return multipath_conf; }
>> -void put_multipath_config(struct config *conf) { }
>> -
>> -int main(void) {
>> -udev = udev_new();
>> -multipath_conf = mpath_lib_init();
>> -return 0;
>> -}
>> -EOF
>> -  if compile_prog "" "-ludev -lmultipath -lmpathpersist" ; then
>> -mpathpersist=yes
>> -mpathpersist_new_api=yes
>> -  else
>> -# probe for the old API
>> -cat > $TMPC <> -#include 
>> -#include 
>> -unsigned mpath_mx_alloc_len = 1024;
>> -int logsink;
>> -int main(void) {
>> -struct udev *udev = udev_new();
>> -mpath_lib_init(udev);
>> -return 0;
>> -}
>> -EOF
>> -if compile_prog "" "-ludev -lmultipath -lmpathpersist" ; then
>> -  mpathpersist=yes
>> -  mpathpersist_new_api=no
>> -else
>> -  mpathpersist=no
>> -fi
>> -  fi
>> -else
>> -  mpathpersist=no
>> -fi
>> -
>>  ##
>>  # pthread probe
>>  PTHREADLIBS_LIST="-pthread -lpthread -lpthreadGC2"
>> @@ -6340,23 +6289,11 @@ if test "$softmmu" = yes ; then
>>fi
>>virtfs=no
>>  fi
>> -if test "$mpath" != no && test "$mpathpersist" = yes ; then
>> -  mpath=yes
>> -else
>> -  if test "$mpath" = yes; then
>> -error_exit "Multipath requires libmpathpersist devel"
>> -  fi
>> -  mpath=no
>> -fi
>>else
>>  if test "$virtfs" = yes; then
>>error_exit "VirtFS is supported only on Linux"
>>  fi
>>  virtfs=no
>> -if test "$mpath" = yes; then
>> -  error_exit "Multipath is supported only on Linux"
>> -fi
>> -mpath=no
>>fi
>>  fi
>>  
>> @@ -6897,12 +6834,6 @@ fi
>>  if test "$virtfs" = "yes" ; then
>>echo "CONFIG_VIRTFS=y" >> $config_host_mak
>>  fi
>> -if test "$mpath" = "yes" ; then
>> -  echo "CONFIG_MPATH=y" >> $config_host_mak
>> -  if test "$mpathpersist_new_api" = "yes"; then
>> -echo "CONFIG_MPATH_NEW_API=y" >> $config_host_mak
>> -  fi
>> -fi
>>  if test "$vhost_scsi" = "yes" ; then
>>echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
>>  fi
>> @@ -7992,7 +7923,7 @@ NINJA=${ninja:-$PWD/ninjatool} $meson setup \
>>  -Dstrip=$(if test "$strip_opt" = yes; then echo true; else echo 
>> false; fi) \
>>  -Db_pie=$(if test "$pie" = yes; then echo true; else echo false; 
>> fi) \
>>  -Db_coverage=$(if test "$gcov" = yes; then echo true; else echo 
>> false; fi) \
>> --Dsdl=$sdl -Dsdl_image=$sdl_image \
>> +-Dmpath=$mpath -Dsdl=$sdl -Dsdl_image=$sdl_image \
>>  -Dvnc=$vnc -Dvnc_sasl=$vnc_sasl -Dvnc_jpeg=$vnc_jpeg -Dvnc_png=$vnc_png 
>> \
>>  -Dgettext=$gettext -Dxkbcommon=$xkbcommon -Du2f=$u2f\
>>  $cross_arg \
>> diff --git a/meson.build b/meson.build
>> index 48724988972d..c09d869f9b02 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -81,6 +81,14 @@ if 'SPARSE_CFLAGS' in config_host
>> 'compile_commands.json'])
>>  endif
>>  
>> +###
>> +# Target-specific checks and dependencies #
>> +###
>> +
>> +if targetos != 'linux' and get_option('mpath').enabled()
>> +  error('Multip

Re: I wanna fixes plugin on windows, any suggestion

[Yonggang Luo]

On Sat, Sep 26, 2020 at 3:25 AM Paolo Bonzini  wrote:
>
> On 25/09/20 21:23, 罗勇刚(Yonggang Luo) wrote:
> > That's what I am tring to fixes? what does  one import library per
> > emulator, can we do this like NodeJS does?
> >  NodeJS have NAPI support across platform. They create a windows .lib
from
> > node.exe
>
> You'd have to create a .lib for qemu-system-aarch64.exe, one for
> qemu-system-arm.exe, etc.  On Linux the same plugin will work for all
> emulators.
>
OK, this made the things clear, the possible solution is to using function
pointer to expose
all Plugin-API functions
> Paolo
>


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

Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925172604.2142227-1-pbonz...@redhat.com/



Hi,

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

Type: series
Message-id: 20200925172604.2142227-1-pbonz...@redhat.com
Subject: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi 
iothread

=== 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 ===

From https://github.com/patchew-project/qemu
 * [new tag] patchew/20200925172604.2142227-1-pbonz...@redhat.com -> 
patchew/20200925172604.2142227-1-pbonz...@redhat.com
Switched to a new branch 'test'
21c2380 scsi/scsi_bus: fix races in REPORT LUNS
aacd230 virtio-scsi: use scsi_device_get
f9f8f08 scsi/scsi_bus: Add scsi_device_get
c66050f scsi/scsi-bus: scsi_device_find: don't return unrealized devices
bb9fbd3 device-core: use atomic_set on .realized property
bd87593 device-core: use RCU for list of children of a bus
51a8ebe device_core: use drain_call_rcu in in hmp_device_del/qmp_device_add
a595aa2 scsi/scsi_bus: switch search direction in scsi_device_find
6739a20 scsi: switch to bus->check_address
c4ed079 qdev: add "check if address free" callback for buses

=== OUTPUT BEGIN ===
1/10 Checking commit c4ed0795a36d (qdev: add "check if address free" callback 
for buses)
2/10 Checking commit 6739a205e683 (scsi: switch to bus->check_address)
ERROR: code indent should never use tabs
#53: FILE: hw/scsi/scsi-bus.c:137:
+^I^I^I^I int channel, int target, int lun,$

ERROR: code indent should never use tabs
#54: FILE: hw/scsi/scsi-bus.c:138:
+^I^I^I^I SCSIDevice **p_dev)$

WARNING: line over 80 characters
#69: FILE: hw/scsi/scsi-bus.c:153:
+static bool scsi_bus_check_address(BusState *qbus, DeviceState *qdev, Error 
**errp)

WARNING: line over 80 characters
#89: FILE: hw/scsi/scsi-bus.c:173:
+if (!scsi_bus_is_address_free(bus, dev->channel, dev->id, dev->lun, 
&d)) {

WARNING: line over 80 characters
#128: FILE: hw/scsi/scsi-bus.c:195:
+is_free = scsi_bus_is_address_free(bus, dev->channel, ++id, 
dev->lun, NULL);

WARNING: line over 80 characters
#141: FILE: hw/scsi/scsi-bus.c:205:
+is_free = scsi_bus_is_address_free(bus, dev->channel, dev->id, 
++lun, NULL);

total: 2 errors, 4 warnings, 182 lines checked

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

3/10 Checking commit a595aa288f19 (scsi/scsi_bus: switch search direction in 
scsi_device_find)
4/10 Checking commit 51a8ebe64c5f (device_core: use drain_call_rcu in in 
hmp_device_del/qmp_device_add)
5/10 Checking commit bd87593ffb6e (device-core: use RCU for list of children of 
a bus)
6/10 Checking commit bb9fbd3d7a25 (device-core: use atomic_set on .realized 
property)
7/10 Checking commit c66050f657ae (scsi/scsi-bus: scsi_device_find: don't 
return unrealized devices)
8/10 Checking commit f9f8f0888e58 (scsi/scsi_bus: Add scsi_device_get)
9/10 Checking commit aacd2301cef8 (virtio-scsi: use scsi_device_get)
10/10 Checking commit 21c238042be7 (scsi/scsi_bus: fix races in REPORT LUNS)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20200925172604.2142227-1-pbonz...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v6 00/21] Convert QAPI doc comments to generate rST instead of texinfo

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925162316.21205-1-peter.mayd...@linaro.org/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or 
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
Generating trace-scsi.h with a meson_exe.py custom command
In file included from ../src/qapi/qapi-schema.json:78:
../src/qapi/migration.json:1747:1: unexpected de-indent (expected at least 13 
spaces)
make: *** [CUSTOM_COMMAND@d09afa93bc2.stamp] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 709, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', 
'--label', 'com.qemu.instance.uuid=a2209dd2d512478b8d26c94a5b889ce1', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 
'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-tvzj2v5u/src/docker-src.2020-09-25-15.22.42.19873:/var/tmp/qemu:z,ro',
 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=a2209dd2d512478b8d26c94a5b889ce1
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-tvzj2v5u/src'
make: *** [docker-run-test-quick@centos7] Error 2

real3m9.538s
user0m19.483s


The full log is available at
http://patchew.org/logs/20200925162316.21205-1-peter.mayd...@linaro.org/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v6 00/21] Convert QAPI doc comments to generate rST instead of texinfo

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200925162316.21205-1-peter.mayd...@linaro.org/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

 perl-Encode-devel   x86_64  4:3.07-457.fc32
  updates   41 k
 perl-Envnoarch  1.04-440.fc32  
  fedora19 k
 perl-Errno  x86_64  1.30-456.fc32  
  updates   24 k
 perl-Error  noarch  1:0.17029-1.fc32   
  fedora42 k
 perl-Exporter   noarch  5.74-2.fc32
  fedora32 k
 perl-ExtUtils-CBuilder  noarch  1:0.280234-2.fc32  
  fedora47 k
 perl-ExtUtils-Command   noarch  2:7.46-1.fc32  
  updates   14 k
---
(648/845): perl-Digest-SHA-6.02-442.fc32.x86_64 647 kB/s |  64 kB 00:00
(649/845): perl-Encode-Locale-1.05-15.fc32.noar 196 kB/s |  19 kB 00:00
(650/845): perl-Env-1.04-440.fc32.noarch.rpm166 kB/s |  19 kB 00:00
(651/845): perl-Error-0.17029-1.fc32.noarch.rpm 371 kB/s |  42 kB 00:00
(652/845): perl-Exporter-5.74-2.fc32.noarch.rpm 331 kB/s |  32 kB 00:00
(653/845): perl-ExtUtils-CBuilder-0.280234-2.fc 478 kB/s |  47 kB 00:00
(654/845): perl-ExtUtils-Manifest-1.72-440.fc32 358 kB/s |  34 kB 00:00
---
  Installing   : perl-DB_File-1.853-2.fc32.x86_64   302/869 
  Installing   : perl-Devel-Size-0.83-5.fc32.x86_64 303/869 
  Installing   : perl-Env-1.04-440.fc32.noarch  304/869 
  Installing   : perl-Error-1:0.17029-1.fc32.noarch 305/869 
  Installing   : perl-IPC-SysV-2.07-442.fc32.x86_64 306/869 
  Installing   : perl-IPC-System-Simple-1.30-1.fc32.noarch  307/869 
  Installing   : perl-autodie-2.32-2.fc32.noarch308/869 
---
  Verifying: perl-Digest-SHA-1:6.02-442.fc32.x86_64 648/869 
  Verifying: perl-Encode-Locale-1.05-15.fc32.noarch 649/869 
  Verifying: perl-Env-1.04-440.fc32.noarch  650/869 
  Verifying: perl-Error-1:0.17029-1.fc32.noarch 651/869 
  Verifying: perl-Exporter-5.74-2.fc32.noarch   652/869 
  Verifying: perl-ExtUtils-CBuilder-1:0.280234-2.fc32.noarch653/869 
  Verifying: perl-ExtUtils-Install-2.14-441.fc32.noarch 654/869 
---
  perl-Encode-devel-4:3.07-457.fc32.x86_64  
  perl-Env-1.04-440.fc32.noarch 
  perl-Errno-1.30-456.fc32.x86_64   
  perl-Error-1:0.17029-1.fc32.noarch
  perl-Exporter-5.74-2.fc32.noarch  
  perl-ExtUtils-CBuilder-1:0.280234-2.fc32.noarch   
  perl-ExtUtils-Command-2:7.46-1.fc32.noarch
---
Host machine cpu: x86_64
Target machine cpu family: x86
Target machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or 
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
Generating trace-hw_alpha.h with a meson_exe.py custom command
In file included from ../src/qapi/qapi-schema.json:78:
../src/qapi/migration.json:1747:1: unexpected de-indent (expected at least 13 
spaces)
make: *** [Makefile.ninja:39: CUSTOM_COMMAND@d09afa93bc2.stamp] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 709, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', 
'--label', 'com.qemu.instance.uuid=8e891e79f2d34224a1d3856f15796b12', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 
'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-9zsv4zbd/src/docker-src.2020-09-25-15.22.55.20619:/var/tmp/qemu:z,ro',
 'qemu/fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=8e891e79f2d34224a1d3856f15796b12
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-9zsv4zbd

Re: I wanna fixes plugin on windows, any suggestion

[Paolo Bonzini]

On 25/09/20 21:23, 罗勇刚(Yonggang Luo) wrote:
> That's what I am tring to fixes? what does  one import library per
> emulator, can we do this like NodeJS does?
>  NodeJS have NAPI support across platform. They create a windows .lib from
> node.exe

You'd have to create a .lib for qemu-system-aarch64.exe, one for
qemu-system-arm.exe, etc.  On Linux the same plugin will work for all
emulators.

Paolo

Re: I wanna fixes plugin on windows, any suggestion

[Yonggang Luo]

On Sat, Sep 26, 2020 at 3:20 AM Paolo Bonzini  wrote:
>
> On 25/09/20 21:12, 罗勇刚(Yonggang Luo) wrote:
> > currently the empty.c plugin are failed of linkage error
> >
> > The fowlloing are the failing message:
> > Compiling C object tests/plugin/libbb.dll.p/bb.c.obj
> > Linking target tests/plugin/libempty.dll
> > Linking target tests/plugin/libinsn.dll
> > Linking target tests/plugin/libmem.dll
> > ../tests/plugin/bb.c: In function 'vcpu_tb_exec':
> > ../tests/plugin/bb.c:75:29: error: cast from pointer to integer of
> > different size [-Werror=pointer-to-int-cast]
> >75 | unsigned long n_insns = (unsigned long)udata;
> >   | ^
> > ../tests/plugin/bb.c: In function 'vcpu_tb_trans':
> > ../tests/plugin/bb.c:95:46: error: cast to pointer from integer of
> > different size [-Werror=int-to-pointer-cast]
> >95 |  (void *)n_insns);
> >   |  ^
>
> Plugins cannot work on Windows, because they would be specific to one
> executable as far as I know.  Plugins would have to link with the
> emulator's import library, but there would be one import library per
> emulator.
That's what I am tring to fixes? what does  one import library per
emulator, can we do this like NodeJS does?
 NodeJS have NAPI support across platform. They create a windows .lib from
node.exe
>
> Paolo
>
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libempty.dll.p/empty.c.obj: in function
`qemu_plugin_install':
> > C:\work\xemu\qemu\build/../tests/plugin/empty.c:30: undefined reference
> > to `qemu_plugin_register_vcpu_tb_trans_cb'
> > cc1.exe: all warnings being treated as errors
> > collect2.exe: error: ld returned 1 exit status
> > make: *** [Makefile.ninja:2433：tests/plugin/libempty.dll] 错误 1
> > make: *** 正在等待未完成的任务
> > make: *** [Makefile.ninja:2420：tests/plugin/libbb.dll.p/bb.c.obj] 错误 1
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_tb_trans':
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:29: undefined reference
> > to `qemu_plugin_tb_n_insns'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:33: undefined reference
> > to `qemu_plugin_tb_get_insn'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:36: undefined reference
> > to `qemu_plugin_register_vcpu_insn_exec_inline'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:39: undefined reference
> > to `qemu_plugin_register_vcpu_insn_exec_cb'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libinsn.dll.p/insn.c.obj: in function `plugin_exit':
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:48: undefined reference
> > to `qemu_plugin_outs'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libinsn.dll.p/insn.c.obj: in function
`qemu_plugin_install':
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:59: undefined reference
> > to `qemu_plugin_register_vcpu_tb_trans_cb'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\work\xemu\qemu\build/../tests/plugin/insn.c:60: undefined reference
> > to `qemu_plugin_register_atexit_cb'
> > collect2.exe: error: ld returned 1 exit status
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libmem.dll.p/mem.c.obj: in function `plugin_exit':
> > C:\work\xemu\qemu\build/../tests/plugin/mem.c:33: undefined reference to
> > `qemu_plugin_outs'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libmem.dll.p/mem.c.obj: in function `vcpu_mem':
> > C:\work\xemu\qemu\build/../tests/plugin/mem.c:41: undefined reference to
> > `qemu_plugin_get_hwaddr'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\work\xemu\qemu\build/../tests/plugin/mem.c:42: undefined reference to
> > `qemu_plugin_hwaddr_is_io'
> >
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > tests/plugin/libmem.dll.p/mem.c.obj: in function `vcpu_tb_trans':
> > C:\work\xemu\qemu\build/../tests/plugin/mem.c:54: undefined reference to
> > `qemu_plugin_tb_n_insns'
> >
C:/CI-Tools/msys64/mingw64

Re: [PATCH] target/i386: support KVM_FEATURE_ASYNC_PF_INT

[Paolo Bonzini]

On 12/09/20 08:02, Paolo Bonzini wrote:
> @@ -4209,6 +4209,7 @@ static PropValue kvm_default_props[] = {
>  { "kvmclock", "on" },
>  { "kvm-nopiodelay", "on" },
>  { "kvm-asyncpf", "on" },
> +{ "kvm-asyncpf-int", "on" },
>  { "kvm-steal-time", "on" },
>  { "kvm-pv-eoi", "on" },

This would warn on old kernels.  I removed it.

Paolo

Re: I wanna fixes plugin on windows, any suggestion

[Paolo Bonzini]

On 25/09/20 21:12, 罗勇刚(Yonggang Luo) wrote:
> currently the empty.c plugin are failed of linkage error
> 
> The fowlloing are the failing message:
> Compiling C object tests/plugin/libbb.dll.p/bb.c.obj
> Linking target tests/plugin/libempty.dll
> Linking target tests/plugin/libinsn.dll
> Linking target tests/plugin/libmem.dll
> ../tests/plugin/bb.c: In function 'vcpu_tb_exec':
> ../tests/plugin/bb.c:75:29: error: cast from pointer to integer of
> different size [-Werror=pointer-to-int-cast]
>    75 |     unsigned long n_insns = (unsigned long)udata;
>       |                             ^
> ../tests/plugin/bb.c: In function 'vcpu_tb_trans':
> ../tests/plugin/bb.c:95:46: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
>    95 |                                              (void *)n_insns);
>       |                                              ^

Plugins cannot work on Windows, because they would be specific to one
executable as far as I know.  Plugins would have to link with the
emulator's import library, but there would be one import library per
emulator.

Paolo

> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libempty.dll.p/empty.c.obj: in function `qemu_plugin_install':
> C:\work\xemu\qemu\build/../tests/plugin/empty.c:30: undefined reference
> to `qemu_plugin_register_vcpu_tb_trans_cb'
> cc1.exe: all warnings being treated as errors
> collect2.exe: error: ld returned 1 exit status
> make: *** [Makefile.ninja:2433：tests/plugin/libempty.dll] 错误 1
> make: *** 正在等待未完成的任务
> make: *** [Makefile.ninja:2420：tests/plugin/libbb.dll.p/bb.c.obj] 错误 1
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_tb_trans':
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:29: undefined reference
> to `qemu_plugin_tb_n_insns'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:33: undefined reference
> to `qemu_plugin_tb_get_insn'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:36: undefined reference
> to `qemu_plugin_register_vcpu_insn_exec_inline'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:39: undefined reference
> to `qemu_plugin_register_vcpu_insn_exec_cb'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libinsn.dll.p/insn.c.obj: in function `plugin_exit':
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:48: undefined reference
> to `qemu_plugin_outs'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libinsn.dll.p/insn.c.obj: in function `qemu_plugin_install':
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:59: undefined reference
> to `qemu_plugin_register_vcpu_tb_trans_cb'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/insn.c:60: undefined reference
> to `qemu_plugin_register_atexit_cb'
> collect2.exe: error: ld returned 1 exit status
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libmem.dll.p/mem.c.obj: in function `plugin_exit':
> C:\work\xemu\qemu\build/../tests/plugin/mem.c:33: undefined reference to
> `qemu_plugin_outs'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libmem.dll.p/mem.c.obj: in function `vcpu_mem':
> C:\work\xemu\qemu\build/../tests/plugin/mem.c:41: undefined reference to
> `qemu_plugin_get_hwaddr'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/mem.c:42: undefined reference to
> `qemu_plugin_hwaddr_is_io'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> tests/plugin/libmem.dll.p/mem.c.obj: in function `vcpu_tb_trans':
> C:\work\xemu\qemu\build/../tests/plugin/mem.c:54: undefined reference to
> `qemu_plugin_tb_n_insns'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/mem.c:58: undefined reference to
> `qemu_plugin_tb_get_insn'
> C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\work\xemu\qemu\build/../tests/plugin/mem.c:61: undefined reference to
> `qemu_plugin_registe

[PATCH v4 0/6] Qemu SEV-ES guest support

[Tom Lendacky]

From: Tom Lendacky 

This patch series provides support for launching an SEV-ES guest.

Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section "15.35 Encrypted State (SEV-ES)" [1].

In order to allow a hypervisor to perform functions on behalf of a guest,
there is architectural support for notifying a guest's operating system
when certain types of VMEXITs are about to occur. This allows the guest to
selectively share information with the hypervisor to satisfy the requested
function. The notification is performed using a new exception, the VMM
Communication exception (#VC). The information is shared through the
Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
The GHCB format and the protocol for using it is documented in "SEV-ES
Guest-Hypervisor Communication Block Standardization" [2].

The main areas of the Qemu code that are updated to support SEV-ES are
around the SEV guest launch process and AP booting in order to support
booting multiple vCPUs.

There are no new command line switches required. Instead, the desire for
SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
object indicates that SEV-ES is required.

The SEV launch process is updated in two ways. The first is that a the
KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
invoked, no direct changes to the guest register state can be made.

AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
is typically used to boot the APs. However, the hypervisor is not allowed
to update the guest registers. For the APs, the reset vector must be known
in advance. An OVMF method to provide a known reset vector address exists
by providing an SEV information block, identified by UUID, near the end of
the firmware [3]. OVMF will program the jump to the actual reset vector in
this area of memory. Since the memory location is known in advance, an AP
can be created with the known reset vector address as its starting CS:IP.
The GHCB document [2] talks about how SMP booting under SEV-ES is
performed. SEV-ES also requires the use of the in-kernel irqchip support
in order to minimize the changes required to Qemu to support AP booting.

[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://developer.amd.com/wp-content/resources/56421.pdf
[3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset 
vector")

https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847

---

These patches are based on commit:
d0ed6a69d3 ("Update version for v5.1.0 release")

(I tried basing on the latest Qemu commit, but I was having build issues
that level)

A version of the tree can be found at:
https://github.com/AMDESE/qemu/tree/sev-es-v12

Changes since v3:
- Use the QemuUUID structure for GUID definitions
- Use SEV-ES policy bit definition from target/i386/sev_i386.h
- Update SMM support to a per-VM check in order to check SMM capability
  at the VM level since SEV-ES guests don't currently support SMM
- Make the CPU resettable check an arch-specific check

Changes since v2:
- Add in-kernel irqchip requirement for SEV-ES guests

Changes since v1:
- Fixed checkpatch.pl errors/warnings

Tom Lendacky (6):
  sev/i386: Add initial support for SEV-ES
  sev/i386: Require in-kernel irqchip support for SEV-ES guests
  sev/i386: Allow AP booting under SEV-ES
  sev/i386: Don't allow a system reset under an SEV-ES guest
  kvm/i386: Use a per-VM check for SMM capability
  sev/i386: Enable an SEV-ES guest based on SEV policy

 accel/kvm/kvm-all.c   |  69 
 accel/stubs/kvm-stub.c|   5 ++
 hw/i386/pc_sysfw.c|  10 +++-
 include/sysemu/cpus.h |   2 +
 include/sysemu/hw_accel.h |   5 ++
 include/sysemu/kvm.h  |  26 +
 include/sysemu/sev.h  |   3 ++
 softmmu/cpus.c|   5 ++
 softmmu/vl.c  |   5 +-
 target/arm/kvm.c  |   5 ++
 target/i386/cpu.c |   1 +
 target/i386/kvm.c |  10 +++-
 target/i386/sev-stub.c|   5 ++
 target/i386/sev.c | 109 +-
 target/i386/sev_i386.h|   1 +
 target/mips/kvm.c |   5 ++
 target/ppc/kvm.c  |   5 ++
 target/s390x/kvm.c|   5 ++
 18 files changed, 271 insertions(+), 5 deletions(-)

-- 
2.28.0

I wanna fixes plugin on windows, any suggestion

[Yonggang Luo]

currently the empty.c plugin are failed of linkage error

The fowlloing are the failing message:
Compiling C object tests/plugin/libbb.dll.p/bb.c.obj
Linking target tests/plugin/libempty.dll
Linking target tests/plugin/libinsn.dll
Linking target tests/plugin/libmem.dll
../tests/plugin/bb.c: In function 'vcpu_tb_exec':
../tests/plugin/bb.c:75:29: error: cast from pointer to integer of
different size [-Werror=pointer-to-int-cast]
   75 | unsigned long n_insns = (unsigned long)udata;
  | ^
../tests/plugin/bb.c: In function 'vcpu_tb_trans':
../tests/plugin/bb.c:95:46: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
   95 |  (void *)n_insns);
  |  ^
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libempty.dll.p/empty.c.obj: in function `qemu_plugin_install':
C:\work\xemu\qemu\build/../tests/plugin/empty.c:30: undefined reference to
`qemu_plugin_register_vcpu_tb_trans_cb'
cc1.exe: all warnings being treated as errors
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile.ninja:2433：tests/plugin/libempty.dll] 错误 1
make: *** 正在等待未完成的任务
make: *** [Makefile.ninja:2420：tests/plugin/libbb.dll.p/bb.c.obj] 错误 1
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_tb_trans':
C:\work\xemu\qemu\build/../tests/plugin/insn.c:29: undefined reference to
`qemu_plugin_tb_n_insns'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/insn.c:33: undefined reference to
`qemu_plugin_tb_get_insn'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/insn.c:36: undefined reference to
`qemu_plugin_register_vcpu_insn_exec_inline'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/insn.c:39: undefined reference to
`qemu_plugin_register_vcpu_insn_exec_cb'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libinsn.dll.p/insn.c.obj: in function `plugin_exit':
C:\work\xemu\qemu\build/../tests/plugin/insn.c:48: undefined reference to
`qemu_plugin_outs'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libinsn.dll.p/insn.c.obj: in function `qemu_plugin_install':
C:\work\xemu\qemu\build/../tests/plugin/insn.c:59: undefined reference to
`qemu_plugin_register_vcpu_tb_trans_cb'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/insn.c:60: undefined reference to
`qemu_plugin_register_atexit_cb'
collect2.exe: error: ld returned 1 exit status
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libmem.dll.p/mem.c.obj: in function `plugin_exit':
C:\work\xemu\qemu\build/../tests/plugin/mem.c:33: undefined reference to
`qemu_plugin_outs'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libmem.dll.p/mem.c.obj: in function `vcpu_mem':
C:\work\xemu\qemu\build/../tests/plugin/mem.c:41: undefined reference to
`qemu_plugin_get_hwaddr'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/mem.c:42: undefined reference to
`qemu_plugin_hwaddr_is_io'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libmem.dll.p/mem.c.obj: in function `vcpu_tb_trans':
C:\work\xemu\qemu\build/../tests/plugin/mem.c:54: undefined reference to
`qemu_plugin_tb_n_insns'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/mem.c:58: undefined reference to
`qemu_plugin_tb_get_insn'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/mem.c:61: undefined reference to
`qemu_plugin_register_vcpu_mem_inline'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\work\xemu\qemu\build/../tests/plugin/mem.c:65: undefined reference to
`qemu_plugin_register_vcpu_mem_cb'
C:/CI-Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
tests/plugin/libmem.dll.p/mem.c.obj: in function `qemu_plugin_i

Re: [PATCH v4 0/6] Qemu SEV-ES guest support

[Tom Lendacky]

On 9/25/20 2:03 PM, Tom Lendacky wrote:
> From: Tom Lendacky 
> 
> This patch series provides support for launching an SEV-ES guest.
> 
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
> 
> In order to allow a hypervisor to perform functions on behalf of a guest,
> there is architectural support for notifying a guest's operating system
> when certain types of VMEXITs are about to occur. This allows the guest to
> selectively share information with the hypervisor to satisfy the requested
> function. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
> 
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
> 
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
> 
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
> 
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
> 
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset 
> vector")
>  
> https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
> 
> ---
> 
> These patches are based on commit:
> d0ed6a69d3 ("Update version for v5.1.0 release")
> 
> (I tried basing on the latest Qemu commit, but I was having build issues
> that level)

Sorry, forgot to update this part...

These patches are based on commit:
1bd5556f66 ("Merge remote-tracking branch 
'remotes/kraxel/tags/audio-20200923-pull-request' into staging")

Thanks,
Tom

> 
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v12
> 
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
>at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
> 
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
> 
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
> 
> Tom Lendacky (6):
>sev/i386: Add initial support for SEV-ES
>sev/i386: Require in-kernel irqchip support for SEV-ES guests
>sev/i386: Allow AP booting under SEV-ES
>sev/i386: Don't allow a system reset under an SEV-ES guest
>kvm/i386: Use a per-VM check for SMM capability
>sev/i386: Enable an SEV-ES guest based on SEV policy
> 
>   accel/kvm/kvm-all.c   |  69 
>   accel/stubs/kvm-stub.c|   5 ++
>   hw/i386/pc_sysfw.c|  10 +++-
>   include/sysemu/cpus.h |   2 +
>   include/sysemu/hw_accel.h |   5 ++
>   include/sysemu/kvm.h  |  26 +
>   include/sysemu/sev.h  |   3 ++
>   softmmu/cpus.c|   5 ++
>   softmmu/vl.c  |   5 +-
>   target/arm/kvm.c  |   5 ++
>   target/i386/cpu.c |   1 +
>   target/i386/kvm.c |  10 +++-
>   target/i386/sev-stub.c|   5 ++
>   target/i386/sev.c | 109 +-
>   target/i386/sev_i386.h|   1 +
>   t

[PATCH v4 6/6] sev/i386: Enable an SEV-ES guest based on SEV policy

[Tom Lendacky]

From: Tom Lendacky 

Update the sev_es_enabled() function return value to be based on the SEV
policy that has been specified. SEV-ES is enabled if SEV is enabled and
the SEV-ES policy bit is set in the policy object.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Tom Lendacky 
---
 target/i386/sev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/sev.c b/target/i386/sev.c
index 9c081173db..d3342f5cb2 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -377,7 +377,7 @@ sev_enabled(void)
 bool
 sev_es_enabled(void)
 {
-return false;
+return sev_enabled() && (sev_guest->policy & SEV_POLICY_ES);
 }
 
 uint64_t
-- 
2.28.0

[PATCH v4 2/6] sev/i386: Require in-kernel irqchip support for SEV-ES guests

[Tom Lendacky]

From: Tom Lendacky 

In prep for AP booting, require the use of in-kernel irqchip support. This
lessens the Qemu support burden required to boot APs.

Signed-off-by: Tom Lendacky 
---
 target/i386/sev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/i386/sev.c b/target/i386/sev.c
index af6b88691f..0d4bd3cd75 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -774,6 +774,12 @@ sev_guest_init(const char *id)
 sev->api_minor = status.api_minor;
 
 if (sev_es_enabled()) {
+if (!kvm_kernel_irqchip_allowed()) {
+error_report("%s: SEV-ES guests require in-kernel irqchip support",
+ __func__);
+goto err;
+}
+
 if (!(status.flags & SEV_STATUS_FLAGS_CONFIG_ES)) {
 error_report("%s: guest policy requires SEV-ES, but "
  "host SEV-ES support unavailable",
-- 
2.28.0

Re: [PULL v5 00/87] Misc patches for 2020-09-24

[Paolo Bonzini]

Il ven 25 set 2020, 20:44 Peter Maydell  ha
scritto:

> On Fri, 25 Sep 2020 at 14:20, Paolo Bonzini  wrote:
> >
> > The following changes since commit
> 8c1c07929feae876202ba26f07a540c5115c18cd:
> >
> >   Merge remote-tracking branch
> 'remotes/stefanha/tags/block-pull-request' into staging (2020-09-24
> 18:48:45 +0100)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.com/bonzini/qemu.git tags/for-upstream
> >
> > for you to fetch changes up to e627cc59f0ad4949c9635b72a3149c9fabc044e8:
> >
> >   hw/net/can: Correct Kconfig dependencies (2020-09-25 09:04:23 -0400)
> >
> > 
> > * SCSI fix (Dmitry, Li Feng, Li Qiang)
> > * memory API fixes (Eduardo)
> > * removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)
> > * ACPI fix for VMBus (Jon)
> > * relocatable install (myself)
> > * always remove docker containers (myself)
> > * serial cleanups (Philippe)
> > * vmware cpuid leaf for tsc and apic frequency (Sunil)
> > * KVM_FEATURE_ASYNC_PF_INT support (Vitaly)
> > * i386 XSAVE bugfix (Xiaoyao)
> > * QOM developer documentation in docs/devel (Eduardo)
> > * new checkpatch tests (Dov)
> > * x86_64 syscall fix (Douglas)
> > * interrupt-based APF fix (Vitaly)
> > * always create kvmclock (Vitaly)
> > * fix bios-tables-test (Eduardo)
> > * KVM PV features cleanup (myself)
> > * CAN FD (Pavel)
> >
> > meson:
> > * fixes (Marc-André, Max, Stefan, Alexander, myself)
> > * moved libmpathpersist, cocoa, malloc tests (myself)
> > * support for 0.56 introspected test dependencies (myself)
>
> This passes all the tests, but generates some new warnings:
>
> In the all-linux-static build:
>
> Library rt found: YES
> Found pkg-config: /usr/bin/pkg-config (0.29.1)
> WARNING: Static library 'udev' not found for dependency 'libudev', may
> not be statically linked
> Run-time dependency libudev found: YES 237
> Library devmapper found: NO


> That looks like it's gone wrong -- if we're doing a static
> build and it can't find the static library that means the
> dependency should be a "NO", not "YES", shouldn't it ?
>

No, it's always been like that; the configure script also proceeded with
the dependency and fingers crossed. Meson warns which is the right thing to
do. I will make the test dependent on have_softmmu || have_tools (or
whatever it needs to be) so that the warning is hidden.

Thanks,

Paolo

Also, lots of these during 'make check' on the x86-64 Linux build:
>
> qemu-system-i386: warning: host doesn't support requested feature:
> CPUID.4001H:EAX.kvm-asyncpf-int [bit 14]

[PATCH v4 5/6] kvm/i386: Use a per-VM check for SMM capability

[Tom Lendacky]

From: Tom Lendacky 

SMM is not currently supported for an SEV-ES guest by KVM. Change the SMM
capability check from a KVM-wide check to a per-VM check in order to have
a finer-grained SMM capability check.

Suggested-by: Sean Christopherson 
Signed-off-by: Tom Lendacky 
---
 target/i386/kvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index eefd1a11b6..917cdf8055 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -134,7 +134,7 @@ int kvm_has_pit_state2(void)
 
 bool kvm_has_smm(void)
 {
-return kvm_check_extension(kvm_state, KVM_CAP_X86_SMM);
+return kvm_vm_check_extension(kvm_state, KVM_CAP_X86_SMM);
 }
 
 bool kvm_has_adjust_clock_stable(void)
-- 
2.28.0

[PATCH v4 1/6] sev/i386: Add initial support for SEV-ES

[Tom Lendacky]

From: Tom Lendacky 

Provide initial support for SEV-ES. This includes creating a function to
indicate the guest is an SEV-ES guest (which will return false until all
support is in place), performing the proper SEV initialization and
ensuring that the guest CPU state is measured as part of the launch.

Co-developed-by: Jiri Slaby 
Signed-off-by: Jiri Slaby 
Signed-off-by: Tom Lendacky 
---
 target/i386/cpu.c  |  1 +
 target/i386/sev-stub.c |  5 +
 target/i386/sev.c  | 44 --
 target/i386/sev_i386.h |  1 +
 4 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ffd877dd5..ca0e17ed07 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5940,6 +5940,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
 break;
 case 0x801F:
 *eax = sev_enabled() ? 0x2 : 0;
+*eax |= sev_es_enabled() ? 0x8 : 0;
 *ebx = sev_get_cbit_position();
 *ebx |= sev_get_reduced_phys_bits() << 6;
 *ecx = 0;
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index 88e3f39a1e..040ac90563 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -49,3 +49,8 @@ SevCapability *sev_get_capabilities(Error **errp)
 error_setg(errp, "SEV is not available in this QEMU");
 return NULL;
 }
+
+bool sev_es_enabled(void)
+{
+return false;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 93c4d60b82..af6b88691f 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -358,6 +358,12 @@ sev_enabled(void)
 return !!sev_guest;
 }
 
+bool
+sev_es_enabled(void)
+{
+return false;
+}
+
 uint64_t
 sev_get_me_mask(void)
 {
@@ -578,6 +584,20 @@ sev_launch_update_data(SevGuestState *sev, uint8_t *addr, 
uint64_t len)
 return ret;
 }
 
+static int
+sev_launch_update_vmsa(SevGuestState *sev)
+{
+int ret, fw_error;
+
+ret = sev_ioctl(sev->sev_fd, KVM_SEV_LAUNCH_UPDATE_VMSA, NULL, &fw_error);
+if (ret) {
+error_report("%s: LAUNCH_UPDATE_VMSA ret=%d fw_error=%d '%s'",
+__func__, ret, fw_error, fw_error_to_str(fw_error));
+}
+
+return ret;
+}
+
 static void
 sev_launch_get_measure(Notifier *notifier, void *unused)
 {
@@ -590,6 +610,14 @@ sev_launch_get_measure(Notifier *notifier, void *unused)
 return;
 }
 
+if (sev_es_enabled()) {
+/* measure all the VM save areas before getting launch_measure */
+ret = sev_launch_update_vmsa(sev);
+if (ret) {
+exit(1);
+}
+}
+
 measurement = g_new0(struct kvm_sev_launch_measure, 1);
 
 /* query the measurement blob length */
@@ -684,7 +712,7 @@ sev_guest_init(const char *id)
 {
 SevGuestState *sev;
 char *devname;
-int ret, fw_error;
+int ret, fw_error, cmd;
 uint32_t ebx;
 uint32_t host_cbitpos;
 struct sev_user_data_status status = {};
@@ -745,8 +773,20 @@ sev_guest_init(const char *id)
 sev->api_major = status.api_major;
 sev->api_minor = status.api_minor;
 
+if (sev_es_enabled()) {
+if (!(status.flags & SEV_STATUS_FLAGS_CONFIG_ES)) {
+error_report("%s: guest policy requires SEV-ES, but "
+ "host SEV-ES support unavailable",
+ __func__);
+goto err;
+}
+cmd = KVM_SEV_ES_INIT;
+} else {
+cmd = KVM_SEV_INIT;
+}
+
 trace_kvm_sev_init();
-ret = sev_ioctl(sev->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
+ret = sev_ioctl(sev->sev_fd, cmd, NULL, &fw_error);
 if (ret) {
 error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
  __func__, ret, fw_error, fw_error_to_str(fw_error));
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 4db6960f60..4f9a5e9b21 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -29,6 +29,7 @@
 #define SEV_POLICY_SEV  0x20
 
 extern bool sev_enabled(void);
+extern bool sev_es_enabled(void);
 extern uint64_t sev_get_me_mask(void);
 extern SevInfo *sev_get_info(void);
 extern uint32_t sev_get_cbit_position(void);
-- 
2.28.0

[PATCH v4 3/6] sev/i386: Allow AP booting under SEV-ES

[Tom Lendacky]

From: Tom Lendacky 

When SEV-ES is enabled, it is not possible modify the guests register
state after it has been initially created, encrypted and measured.

Normally, an INIT-SIPI-SIPI request is used to boot the AP. However, the
hypervisor cannot emulate this because it cannot update the AP register
state. For the very first boot by an AP, the reset vector CS segment
value and the EIP value must be programmed before the register has been
encrypted and measured.

Signed-off-by: Tom Lendacky 
---
 accel/kvm/kvm-all.c| 64 ++
 accel/stubs/kvm-stub.c |  5 
 hw/i386/pc_sysfw.c | 10 ++-
 include/sysemu/kvm.h   | 16 +++
 include/sysemu/sev.h   |  3 ++
 target/i386/kvm.c  |  2 ++
 target/i386/sev.c  | 59 ++
 7 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index ad8b315b35..08b66642dd 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -39,6 +39,7 @@
 #include "qemu/main-loop.h"
 #include "trace.h"
 #include "hw/irq.h"
+#include "sysemu/kvm.h"
 #include "sysemu/sev.h"
 #include "qapi/visitor.h"
 #include "qapi/qapi-types-common.h"
@@ -120,6 +121,12 @@ struct KVMState
 /* memory encryption */
 void *memcrypt_handle;
 int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+int (*memcrypt_save_reset_vector)(void *handle, void *flash_ptr,
+  uint64_t flash_size, uint32_t *addr);
+
+uint32_t reset_cs;
+uint32_t reset_ip;
+bool reset_data_valid;
 
 /* For "info mtree -f" to tell if an MR is registered in KVM */
 int nr_as;
@@ -239,6 +246,62 @@ int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
 return 1;
 }
 
+void kvm_memcrypt_set_reset_vector(CPUState *cpu)
+{
+X86CPU *x86;
+CPUX86State *env;
+
+/* Only update if we have valid reset information */
+if (!kvm_state->reset_data_valid) {
+return;
+}
+
+/* Do not update the BSP reset state */
+if (cpu->cpu_index == 0) {
+return;
+}
+
+x86 = X86_CPU(cpu);
+env = &x86->env;
+
+cpu_x86_load_seg_cache(env, R_CS, 0xf000, kvm_state->reset_cs, 0x,
+   DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
+   DESC_R_MASK | DESC_A_MASK);
+
+env->eip = kvm_state->reset_ip;
+}
+
+int kvm_memcrypt_save_reset_vector(void *flash_ptr, uint64_t flash_size)
+{
+CPUState *cpu;
+uint32_t addr;
+int ret;
+
+if (kvm_memcrypt_enabled() &&
+kvm_state->memcrypt_save_reset_vector) {
+
+addr = 0;
+ret = kvm_state->memcrypt_save_reset_vector(kvm_state->memcrypt_handle,
+flash_ptr, flash_size,
+&addr);
+if (ret) {
+return ret;
+}
+
+if (addr) {
+kvm_state->reset_cs = addr & 0x;
+kvm_state->reset_ip = addr & 0x;
+kvm_state->reset_data_valid = true;
+
+CPU_FOREACH(cpu) {
+kvm_memcrypt_set_reset_vector(cpu);
+}
+}
+}
+
+return 0;
+}
+
 /* Called with KVMMemoryListener.slots_lock held */
 static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
 {
@@ -2193,6 +2256,7 @@ static int kvm_init(MachineState *ms)
 }
 
 kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
+kvm_state->memcrypt_save_reset_vector = sev_es_save_reset_vector;
 }
 
 ret = kvm_arch_init(ms, s);
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 82f118d2df..3aece9b513 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -114,6 +114,11 @@ int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
   return 1;
 }
 
+int kvm_memcrypt_save_reset_vector(void *flash_ptr, uint64_t flash_size)
+{
+return -ENOSYS;
+}
+
 #ifndef CONFIG_USER_ONLY
 int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
 {
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b6c0822fe3..321ff94261 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -156,7 +156,8 @@ static void pc_system_flash_map(PCMachineState *pcms,
 PFlashCFI01 *system_flash;
 MemoryRegion *flash_mem;
 void *flash_ptr;
-int ret, flash_size;
+uint64_t flash_size;
+int ret;
 
 assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
 
@@ -204,6 +205,13 @@ static void pc_system_flash_map(PCMachineState *pcms,
 if (kvm_memcrypt_enabled()) {
 flash_ptr = memory_region_get_ram_ptr(flash_mem);
 flash_size = memory_region_size(flash_mem);
+
+ret = kvm_memcrypt_save_reset_vector(flash_ptr, flash_size);
+if (ret) {
+error_report("failed to locate and/or save reset vector");
+exit(1);
+}
+

[PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest

[Tom Lendacky]

From: Tom Lendacky 

An SEV-ES guest does not allow register state to be altered once it has
been measured. When an SEV-ES guest issues a reboot command, Qemu will
reset the vCPU state and resume the guest. This will cause failures under
SEV-ES. Prevent that from occuring by introducing an arch-specific
callback that returns a boolean indicating whether vCPUs are resettable.

Cc: Peter Maydell 
Cc: Aurelien Jarno 
Cc: Jiaxun Yang 
Cc: Aleksandar Rikalo 
Cc: David Gibson 
Cc: David Hildenbrand 
Signed-off-by: Tom Lendacky 
---
 accel/kvm/kvm-all.c   |  5 +
 include/sysemu/cpus.h |  2 ++
 include/sysemu/hw_accel.h |  5 +
 include/sysemu/kvm.h  | 10 ++
 softmmu/cpus.c|  5 +
 softmmu/vl.c  |  5 -
 target/arm/kvm.c  |  5 +
 target/i386/kvm.c |  6 ++
 target/mips/kvm.c |  5 +
 target/ppc/kvm.c  |  5 +
 target/s390x/kvm.c|  5 +
 11 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 08b66642dd..a161fff813 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2388,6 +2388,11 @@ void kvm_flush_coalesced_mmio_buffer(void)
 s->coalesced_flush_in_progress = false;
 }
 
+bool kvm_cpu_check_are_resettable(void)
+{
+return kvm_arch_cpu_check_are_resettable();
+}
+
 static void do_kvm_cpu_synchronize_state(CPUState *cpu, run_on_cpu_data arg)
 {
 if (!cpu->vcpu_dirty) {
diff --git a/include/sysemu/cpus.h b/include/sysemu/cpus.h
index 3c1da6a018..d3e6cdf126 100644
--- a/include/sysemu/cpus.h
+++ b/include/sysemu/cpus.h
@@ -24,6 +24,8 @@ void dump_drift_info(void);
 void qemu_cpu_kick_self(void);
 void qemu_timer_notify_cb(void *opaque, QEMUClockType type);
 
+bool cpus_are_resettable(void);
+
 void cpu_synchronize_all_states(void);
 void cpu_synchronize_all_post_reset(void);
 void cpu_synchronize_all_post_init(void);
diff --git a/include/sysemu/hw_accel.h b/include/sysemu/hw_accel.h
index e128f8b06b..6d387226d4 100644
--- a/include/sysemu/hw_accel.h
+++ b/include/sysemu/hw_accel.h
@@ -17,6 +17,11 @@
 #include "sysemu/hvf.h"
 #include "sysemu/whpx.h"
 
+static inline bool cpu_check_are_resettable(void)
+{
+return kvm_enabled() ? kvm_cpu_check_are_resettable() : true;
+}
+
 static inline void cpu_synchronize_state(CPUState *cpu)
 {
 if (kvm_enabled()) {
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b7ff481d61..51a12c83ed 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -581,4 +581,14 @@ int kvm_get_max_memslots(void);
 /* Notify resamplefd for EOI of specific interrupts. */
 void kvm_resample_fd_notify(int gsi);
 
+/**
+ * kvm_cpu_check_are_resettable - return whether CPUs can be reset
+ *
+ * Returns: true: CPUs are resettable
+ *  false: CPUs are not resettable
+ */
+bool kvm_cpu_check_are_resettable(void);
+
+bool kvm_arch_cpu_check_are_resettable(void);
+
 #endif
diff --git a/softmmu/cpus.c b/softmmu/cpus.c
index e3b98065c9..ee9c46527c 100644
--- a/softmmu/cpus.c
+++ b/softmmu/cpus.c
@@ -927,6 +927,11 @@ void hw_error(const char *fmt, ...)
 abort();
 }
 
+bool cpus_are_resettable(void)
+{
+return cpu_check_are_resettable();
+}
+
 void cpu_synchronize_all_states(void)
 {
 CPUState *cpu;
diff --git a/softmmu/vl.c b/softmmu/vl.c
index f7b103467c..1f54c6b416 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1475,7 +1475,10 @@ void qemu_system_guest_crashloaded(GuestPanicInformation 
*info)
 
 void qemu_system_reset_request(ShutdownCause reason)
 {
-if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
+if (!cpus_are_resettable()) {
+error_report("cpus are not resettable, terminating");
+shutdown_requested = reason;
+} else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
 shutdown_requested = reason;
 } else {
 reset_requested = reason;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 0dcb9bfe13..f9584a1425 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -1029,3 +1029,8 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)
 {
 return (data - 32) & 0x;
 }
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+return true;
+}
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 7c2a3a123b..eefd1a11b6 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -26,6 +26,7 @@
 #include "sysemu/kvm_int.h"
 #include "sysemu/runstate.h"
 #include "kvm_i386.h"
+#include "sev_i386.h"
 #include "hyperv.h"
 #include "hyperv-proto.h"
 
@@ -4738,3 +4739,8 @@ bool kvm_has_waitpkg(void)
 {
 return has_msr_umwait;
 }
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+return !sev_es_enabled();
+}
diff --git a/target/mips/kvm.c b/target/mips/kvm.c
index 72637a1e02..ad612e74c1 100644
--- a/target/mips/kvm.c
+++ b/target/mips/kvm.c
@@ -1296,3 +1296,8 @@ int mips_kvm_type(MachineState *machine, const char 
*vm_type)
 
 return -1;
 }
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+return tru

Re: [PATCH v10 7/7] Versal: Connect DWC3 controller with virt-versal

[Edgar E. Iglesias]

On Thu, Sep 24, 2020 at 07:50:56PM +0530, Sai Pavan Boddu wrote:
> From: Vikram Garhwal 
> 
> Connect dwc3 controller and usb2-reg module to xlnx-versal SOC, its placed
> in iou of lpd domain and configure it as dual port host controller. Add the
> respective guest dts nodes for "xlnx-versal-virt" machine.

Hi Sai,

One minor comment inline.

And a question, could you please post an example command-line for this?


> 
> Signed-off-by: Vikram Garhwal 
> Signed-off-by: Sai Pavan Boddu 
> ---
>  hw/arm/xlnx-versal-virt.c| 58 
> 
>  hw/arm/xlnx-versal.c | 34 ++
>  include/hw/arm/xlnx-versal.h | 14 +++
>  3 files changed, 106 insertions(+)
> 
> diff --git a/hw/arm/xlnx-versal-virt.c b/hw/arm/xlnx-versal-virt.c
> index 03e2320..f0ac5ba 100644
> --- a/hw/arm/xlnx-versal-virt.c
> +++ b/hw/arm/xlnx-versal-virt.c
> @@ -39,6 +39,8 @@ struct VersalVirt {
>  uint32_t ethernet_phy[2];
>  uint32_t clk_125Mhz;
>  uint32_t clk_25Mhz;
> +uint32_t usb;
> +uint32_t dwc;
>  } phandle;
>  struct arm_boot_info binfo;
>  
> @@ -66,6 +68,8 @@ static void fdt_create(VersalVirt *s)
>  s->phandle.clk_25Mhz = qemu_fdt_alloc_phandle(s->fdt);
>  s->phandle.clk_125Mhz = qemu_fdt_alloc_phandle(s->fdt);
>  
> +s->phandle.usb = qemu_fdt_alloc_phandle(s->fdt);
> +s->phandle.dwc = qemu_fdt_alloc_phandle(s->fdt);
>  /* Create /chosen node for load_dtb.  */
>  qemu_fdt_add_subnode(s->fdt, "/chosen");
>  
> @@ -148,6 +152,59 @@ static void fdt_add_timer_nodes(VersalVirt *s)
>   compat, sizeof(compat));
>  }
>  
> +static void fdt_add_usb_xhci_nodes(VersalVirt *s)
> +{
> +const char clocknames[] = "bus_clk\0ref_clk";
> +char *name = g_strdup_printf("/usb@%" PRIx32, MM_USB2_CTRL_REGS);
> +const char compat[] = "xlnx,versal-dwc3";
> +
> +qemu_fdt_add_subnode(s->fdt, name);
> +qemu_fdt_setprop(s->fdt, name, "compatible",
> + compat, sizeof(compat));
> +qemu_fdt_setprop_sized_cells(s->fdt, name, "reg",
> + 2, MM_USB2_CTRL_REGS,
> + 2, MM_USB2_CTRL_REGS_SIZE);
> +qemu_fdt_setprop(s->fdt, name, "clock-names",
> + clocknames, sizeof(clocknames));
> +qemu_fdt_setprop_cells(s->fdt, name, "clocks",
> +   s->phandle.clk_25Mhz, s->phandle.clk_125Mhz);
> +qemu_fdt_setprop(s->fdt, name, "ranges", NULL, 0);
> +qemu_fdt_setprop_cell(s->fdt, name, "#address-cells", 2);
> +qemu_fdt_setprop_cell(s->fdt, name, "#size-cells", 2);
> +qemu_fdt_setprop_cell(s->fdt, name, "phandle", s->phandle.usb);
> +g_free(name);
> +
> +{
> +const char irq_name[] = "dwc_usb3";
> +const char compat[] = "snps,dwc3";
> +
> +name = g_strdup_printf("/usb@%" PRIx32 "/dwc3@%" PRIx32,
> +   MM_USB2_CTRL_REGS, MM_USB_XHCI_0);
> +qemu_fdt_add_subnode(s->fdt, name);
> +qemu_fdt_setprop(s->fdt, name, "compatible",
> + compat, sizeof(compat));
> +qemu_fdt_setprop_sized_cells(s->fdt, name, "reg",
> + 2, MM_USB_XHCI_0, 2, 
> MM_USB_XHCI_0_SIZE);
> +qemu_fdt_setprop(s->fdt, name, "interrupt-names",
> + irq_name, sizeof(irq_name));
> +qemu_fdt_setprop_cells(s->fdt, name, "interrupts",
> +   GIC_FDT_IRQ_TYPE_SPI, VERSAL_USB0_IRQ_0,
> +   GIC_FDT_IRQ_FLAGS_LEVEL_HI);
> +qemu_fdt_setprop_cell(s->fdt, name,
> +  "snps,quirk-frame-length-adjustment", 0x20);
> +qemu_fdt_setprop_cells(s->fdt, name, "#stream-id-cells", 1);
> +qemu_fdt_setprop_string(s->fdt, name, "dr_mode", "host");
> +qemu_fdt_setprop_string(s->fdt, name, "phy-names", "usb3-phy");
> +qemu_fdt_setprop(s->fdt, name, "snps,dis_u2_susphy_quirk", NULL, 0);
> +qemu_fdt_setprop(s->fdt, name, "snps,dis_u3_susphy_quirk", NULL, 0);
> +qemu_fdt_setprop(s->fdt, name, "snps,refclk_fladj", NULL, 0);
> +qemu_fdt_setprop(s->fdt, name, "snps,mask_phy_reset", NULL, 0);
> +qemu_fdt_setprop_cell(s->fdt, name, "phandle", s->phandle.dwc);
> +qemu_fdt_setprop_string(s->fdt, name, "maximum-speed", "high-speed");
> +g_free(name);
> +}
> +}
> +
>  static void fdt_add_uart_nodes(VersalVirt *s)
>  {
>  uint64_t addrs[] = { MM_UART1, MM_UART0 };
> @@ -515,6 +572,7 @@ static void versal_virt_init(MachineState *machine)
>  fdt_add_gic_nodes(s);
>  fdt_add_timer_nodes(s);
>  fdt_add_zdma_nodes(s);
> +fdt_add_usb_xhci_nodes(s);
>  fdt_add_sd_nodes(s);
>  fdt_add_rtc_node(s);
>  fdt_add_cpu_nodes(s, psci_conduit);
> diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
> index 12ba6c4..64b0d0a 100644
> --- a/hw/arm/xln

Re: virtiofs vs 9p performance(Re: tools/virtiofs: Multi threading seems to hurt performance)

[Dr. David Alan Gilbert]

* Christian Schoenebeck (qemu_...@crudebyte.com) wrote:
> On Freitag, 25. September 2020 15:05:38 CEST Dr. David Alan Gilbert wrote:
> > > > 9p ( mount -t 9p -o trans=virtio kernel /mnt
> > > > -oversion=9p2000.L,cache=mmap,msize=1048576 ) test: (g=0): rw=randrw,
> > > 
> > > Bottleneck --^
> > > 
> > > By increasing 'msize' you would encounter better 9P I/O results.
> > 
> > OK, I thought that was bigger than the default;  what number should I
> > use?
> 
> It depends on the underlying storage hardware. In other words: you have to 
> try 
> increasing the 'msize' value to a point where you no longer notice a negative 
> performance impact (or almost). Which is fortunately quite easy to test on 
> guest like:
> 
>   dd if=/dev/zero of=test.dat bs=1G count=12
>   time cat test.dat > /dev/null
> 
> I would start with an absolute minimum msize of 10MB. I would recommend 
> something around 100MB maybe for a mechanical hard drive. With a PCIe flash 
> you probably would rather pick several hundred MB or even more.
> 
> That unpleasant 'msize' issue is a limitation of the 9p protocol: client 
> (guest) must suggest the value of msize on connection to server (host). 
> Server 
> can only lower, but not raise it. And the client in turn obviously cannot see 
> host's storage device(s), so client is unable to pick a good value by itself. 
> So it's a suboptimal handshake issue right now.

It doesn't seem to be making a vast difference here:



9p mount -t 9p -o trans=virtio kernel /mnt 
-oversion=9p2000.L,cache=mmap,msize=104857600

Run status group 0 (all jobs):
   READ: bw=62.5MiB/s (65.6MB/s), 62.5MiB/s-62.5MiB/s (65.6MB/s-65.6MB/s), 
io=3070MiB (3219MB), run=49099-49099msec
  WRITE: bw=20.9MiB/s (21.9MB/s), 20.9MiB/s-20.9MiB/s (21.9MB/s-21.9MB/s), 
io=1026MiB (1076MB), run=49099-49099msec

9p mount -t 9p -o trans=virtio kernel /mnt 
-oversion=9p2000.L,cache=mmap,msize=1048576000

Run status group 0 (all jobs):
   READ: bw=65.2MiB/s (68.3MB/s), 65.2MiB/s-65.2MiB/s (68.3MB/s-68.3MB/s), 
io=3070MiB (3219MB), run=47104-47104msec
  WRITE: bw=21.8MiB/s (22.8MB/s), 21.8MiB/s-21.8MiB/s (22.8MB/s-22.8MB/s), 
io=1026MiB (1076MB), run=47104-47104msec


Dave

> Many users don't even know this 'msize' parameter exists and hence run with 
> the Linux kernel's default value of just 8kB. For QEMU 5.2 I addressed this 
> by 
> logging a performance warning on host side for making users at least aware 
> about this issue. The long-term plan is to pass a good msize value from host 
> to guest via virtio (like it's already done for the available export tags) 
> and 
> the Linux kernel would default to that instead.
> 
> Best regards,
> Christian Schoenebeck
> 
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PULL 7/8] gitlab: create a build-deprecated target

[Peter Maydell]

On Fri, 25 Sep 2020 at 19:34, Richard Henderson
 wrote:
>
> On 9/25/20 8:54 AM, Peter Maydell wrote:
> > On Wed, 16 Sep 2020 at 14:52, Philippe Mathieu-Daudé  
> > wrote:
> >> Should we stop building the ppc64abi32 target instead?
> >>
> >> From c609274b853 ("docs/system/deprecated: mark
> >> ppc64abi32-linux-user for deprecation"):
> >>
> >>  The ppc64abi32 architecture has a number of issues which regularly
> >>  trip up our CI testing and is suspected to be quite broken. For that
> >>  reason the maintainers strongly suspect no one actually uses it.
> >
> > It still builds fine and it also runs the 'ls' binary in
> > the linux-user-test collection (ie the 32-bit PPC binary).
>
> But signal handling is completely wrong

That is also true for sparc linux-user (RT signal frames
completely unimplemented)...

Anyway, my point was mostly that there is a class of programs
which do run OK on it, so we should continue to build and test
it to the level we do today until the deprecation period runs
out. It is not so badly broken as to be a candidate for dropping
immediately.

thanks
-- PMM

Re: [PULL v5 00/87] Misc patches for 2020-09-24

[Peter Maydell]

On Fri, 25 Sep 2020 at 14:20, Paolo Bonzini  wrote:
>
> The following changes since commit 8c1c07929feae876202ba26f07a540c5115c18cd:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2020-09-24 18:48:45 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to e627cc59f0ad4949c9635b72a3149c9fabc044e8:
>
>   hw/net/can: Correct Kconfig dependencies (2020-09-25 09:04:23 -0400)
>
> 
> * SCSI fix (Dmitry, Li Feng, Li Qiang)
> * memory API fixes (Eduardo)
> * removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)
> * ACPI fix for VMBus (Jon)
> * relocatable install (myself)
> * always remove docker containers (myself)
> * serial cleanups (Philippe)
> * vmware cpuid leaf for tsc and apic frequency (Sunil)
> * KVM_FEATURE_ASYNC_PF_INT support (Vitaly)
> * i386 XSAVE bugfix (Xiaoyao)
> * QOM developer documentation in docs/devel (Eduardo)
> * new checkpatch tests (Dov)
> * x86_64 syscall fix (Douglas)
> * interrupt-based APF fix (Vitaly)
> * always create kvmclock (Vitaly)
> * fix bios-tables-test (Eduardo)
> * KVM PV features cleanup (myself)
> * CAN FD (Pavel)
>
> meson:
> * fixes (Marc-André, Max, Stefan, Alexander, myself)
> * moved libmpathpersist, cocoa, malloc tests (myself)
> * support for 0.56 introspected test dependencies (myself)

This passes all the tests, but generates some new warnings:

In the all-linux-static build:

Library rt found: YES
Found pkg-config: /usr/bin/pkg-config (0.29.1)
WARNING: Static library 'udev' not found for dependency 'libudev', may
not be statically linked
Run-time dependency libudev found: YES 237
Library devmapper found: NO

That looks like it's gone wrong -- if we're doing a static
build and it can't find the static library that means the
dependency should be a "NO", not "YES", shouldn't it ?

Also, lots of these during 'make check' on the x86-64 Linux build:

qemu-system-i386: warning: host doesn't support requested feature:
CPUID.4001H:EAX.kvm-asyncpf-int [bit 14]

thanks
-- PMM

Re: [PATCH V1 03/32] savevm: QMP command for cprsave

[Steven Sistare]

On 9/11/2020 12:43 PM, Dr. David Alan Gilbert wrote:
> * Steve Sistare (steven.sist...@oracle.com) wrote:
>> To enable live reboot, provide the cprsave QMP command and the VMS_REBOOT
>> vmstate-saving operation, which saves the state of the virtual machine in a
>> simple file.
>>
>> Syntax:
>>   {'command':'cprsave', 'data':{'file':'str', 'mode':'str'}}
>>
>>   The mode argument must be 'reboot'.  Additional modes will be defined in
>>   the future.
>>
>> Unlike the savevm command, cprsave supports any type of guest image and
>> block device.  cprsave stops the VM so that guest ram and block devices are
>> not modified after state is saved.  Guest ram must be mapped to a persistent
>> memory file such as /dev/dax0.0.  The ram object vmstate handler and block
>> device handler do not apply to VMS_REBOOT, so restrict them to VMS_MIGRATE
>> or VMS_SNAPSHOT.  After cprsave completes successfully, qemu exits.
>>
>> After issuing cprsave, the caller may update qemu, update the host kernel,
>> reboot, start qemu using the same arguments as the original process, and
>> issue the cprload command to restore the guest.  cprload is added by
>> subsequent patches.
>>
>> If the caller suspends the guest instead of stopping the VM, such as by
>> issuing guest-suspend-ram to the qemu guest agent, then cprsave and cprload
>> support guests with vfio devices.  The guest drivers suspend methods flush
>> outstanding requests and re-initialize the devices, and thus there is no
>> device state to save and restore.
>>
>> Signed-off-by: Steve Sistare 
>> Signed-off-by: Maran Wilson 
> 
> Going back a step; could you.
> 
>> ---
>>  include/migration/vmstate.h |  1 +
>>  include/sysemu/sysemu.h |  2 ++
>>  migration/block.c   |  1 +
>>  migration/ram.c |  1 +
>>  migration/savevm.c  | 59 
>> +
>>  monitor/qmp-cmds.c  |  6 +
>>  qapi/migration.json | 14 +++
>>  7 files changed, 84 insertions(+)
>>
>> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
>> index fa575f9..c58551a 100644
>> --- a/include/migration/vmstate.h
>> +++ b/include/migration/vmstate.h
>> @@ -161,6 +161,7 @@ typedef enum {
>>  typedef enum {
>>  VMS_MIGRATE  = (1U << 1),
>>  VMS_SNAPSHOT = (1U << 2),
>> +VMS_REBOOT   = (1U << 3),
>>  VMS_MODE_ALL = ~0U
>>  } VMStateMode;
>>  
>> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
>> index 4b6a5c4..6fe86e6 100644
>> --- a/include/sysemu/sysemu.h
>> +++ b/include/sysemu/sysemu.h
>> @@ -24,6 +24,8 @@ extern bool machine_init_done;
>>  void qemu_add_machine_init_done_notifier(Notifier *notify);
>>  void qemu_remove_machine_init_done_notifier(Notifier *notify);
>>  
>> +void save_cpr_snapshot(const char *file, const char *mode, Error **errp);
>> +
>>  extern int autostart;
>>  
>>  typedef enum {
>> diff --git a/migration/block.c b/migration/block.c
>> index 737b649..a69accb 100644
>> --- a/migration/block.c
>> +++ b/migration/block.c
>> @@ -1023,6 +1023,7 @@ static SaveVMHandlers savevm_block_handlers = {
>>  .load_state = block_load,
>>  .save_cleanup = block_migration_cleanup,
>>  .is_active = block_is_active,
>> +.mode_mask = VMS_MIGRATE | VMS_SNAPSHOT,
>>  };
>>  
>>  void blk_mig_init(void)
>> diff --git a/migration/ram.c b/migration/ram.c
>> index 76d4fee..f0d5d9f 100644
>> --- a/migration/ram.c
>> +++ b/migration/ram.c
>> @@ -3795,6 +3795,7 @@ static SaveVMHandlers savevm_ram_handlers = {
>>  .load_setup = ram_load_setup,
>>  .load_cleanup = ram_load_cleanup,
>>  .resume_prepare = ram_resume_prepare,
>> +.mode_mask = VMS_MIGRATE | VMS_SNAPSHOT,
>>  };
>>  
>>  void ram_mig_init(void)
>> diff --git a/migration/savevm.c b/migration/savevm.c
>> index ce02b6b..ff1a46e 100644
>> --- a/migration/savevm.c
>> +++ b/migration/savevm.c
>> @@ -2680,6 +2680,65 @@ int qemu_load_device_state(QEMUFile *f)
>>  return 0;
>>  }
>>  
>> +static QEMUFile *qf_file_open(const char *filename, int flags, int mode,
>> +  Error **errp)
>> +{
>> +QIOChannel *ioc;
>> +int fd = qemu_open(filename, flags, mode);
>> +
>> +if (fd < 0) {
>> +error_setg_errno(errp, errno, "%s(%s)", __func__, filename);
>> +return NULL;
>> +}
>> +
>> +ioc = QIO_CHANNEL(qio_channel_file_new_fd(fd));
>> +
>> +if (flags & O_WRONLY) {
>> +return qemu_fopen_channel_output(ioc);
>> +}
>> +
>> +return qemu_fopen_channel_input(ioc);
>> +}
>> +
>> +void save_cpr_snapshot(const char *file, const char *mode, Error **errp)
>> +{
>> +int ret = 0;
>> +QEMUFile *f;
>> +VMStateMode op;
>> +
>> +if (!strcmp(mode, "reboot")) {
>> +op = VMS_REBOOT;
>> +} else {
>> +error_setg(errp, "cprsave: bad mode %s", mode);
>> +return;
>> +}
>> +
>> +f = qf_file_open(file, O_CREAT | O_WRONLY | O_TRUNC, 0600, errp);
>> +if (!f) {
>> +return;
>> +}
>> +
>> 

Re: [PULL 7/8] gitlab: create a build-deprecated target

[Richard Henderson]

On 9/25/20 8:54 AM, Peter Maydell wrote:
> On Wed, 16 Sep 2020 at 14:52, Philippe Mathieu-Daudé  wrote:
>> Should we stop building the ppc64abi32 target instead?
>>
>> From c609274b853 ("docs/system/deprecated: mark
>> ppc64abi32-linux-user for deprecation"):
>>
>>  The ppc64abi32 architecture has a number of issues which regularly
>>  trip up our CI testing and is suspected to be quite broken. For that
>>  reason the maintainers strongly suspect no one actually uses it.
> 
> It still builds fine and it also runs the 'ls' binary in
> the linux-user-test collection (ie the 32-bit PPC binary).

But signal handling is completely wrong, so
tests/tcg/multiarch/linux-test.c will fail.


r~

Re: [RFC v4 53/70] target/riscv: rvv-1.0: floating-point slide instructions

[Richard Henderson]

On 9/25/20 1:21 AM, Frank Chang wrote:
> I'm happy to reuse vslide1up_vx helper functions.
> 
> However, opfvf_trans() takes helper prototype of:
> /typedef void gen_helper_opfvf(TCGv_ptr, TCGv_ptr, TCGv_i64, TCGv_ptr,
>                               TCGv_env, TCGv_i32);/
> but vslide1up_vx helper function's prototype is:
> /typedef void gen_helper_opivx(TCGv_ptr, TCGv_ptr, TCGv, TCGv_ptr,
>                               TCGv_env, TCGv_i32);/
> 
> The third argument has different types, not sure if it's worth it to sync them
> all to TCGv_i64.

Ah, yes.

It could be useful to always widen to TCGv_i64 -- that's what gvec does in
general.  But I certainly won't insist.


r~

Re: [RFC v4 17/70] target/riscv: rvv-1.0: configure instructions

[Richard Henderson]

On 9/25/20 1:51 AM, Frank Chang wrote:
> trans_vsetvli() uses gen_goto_tb() to save the computation in the link to the
> next TB.
> I know there was a discussion about this back in RVV v0.7.1:
> https://patchew.org/QEMU/20200103033347.20909-1-zhiwei_...@c-sky.com/20200103033347.20909-5-zhiwei_...@c-sky.com/
> 
> However, we had encountered an issue that looked like it was caused by the
> linked TB.
> The code snippet which cause the issue is:
> 
> 000104a8 : 104a8: 0122ffd7 vsetvli t6,t0,e32,m4,tu,mu,d1 104ac:
> 02036407 vle32.v v8,(t1) 104b0: 028a0a57 vadd.vv v20,v8,v20 104b4: 41f282b3 
> sub
> t0,t0,t6 104b8: 002f9893 slli a7,t6,0x2 104bc: 9346 add t1,t1,a7 104be:
> fe0295e3 bnez t0,104a8  104c2: 012f7057 vsetvli zero,t5,e32,m4,tu,mu,d1
> .
> 
> If $t0 is given with the value, e.g. 68.
>  is expected to process 32 elements in each iteration.
> That's it, the env->vl after vsetvli at 0x104a8 in each iteration would be:
> 1st iteration: 32 (remaining elements to be processed: 68 - 32 = 36)
> 2nd iteration: 32 (remaining elements to be processed: 36 - 32 = 4)
> 3rd iteration: 4 (remaining elements to be processed: 4 - 4 = 0, will leave
>  after 0x104be)
> 
> vadd.vv at 0x104b0 is implemented with gvec for acceleration:
> 
> if (a->vm && s->vl_eq_vlmax) {
>     gvec_fn(s->sew, vreg_ofs(s, a->rd),
>             vreg_ofs(s, a->rs2), vreg_ofs(s, a->rs1),
>             MAXSZ(s), MAXSZ(s));
> } else {
>     uint32_t data = 0;
> 
>     data = FIELD_DP32(data, VDATA, VM, a->vm);
>     data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
>     tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
>                        vreg_ofs(s, a->rs1), vreg_ofs(s, a->rs2),
>                        cpu_env, 0, s->vlen / 8, data, fn);
> }
> 
> gvec function is used when a->vm and s->vl_eq_vlmax are both true.
> However, s->vl_eq_vlmax, for the above case, is only true in 1st and 2nd
> iterations.
> In third iteration, env->vl is 4 which is not equal to vlmax = 32.
> But as the TB where vadd.vv resides are already linked with vsetvli's TB,
> it won't be retranslated and still use the same gvec function in the third
> iteration.
> The total elemented being proceeded would be: 32 + 32 + 32 = 96, instead of 
> 68.
> 
> I'm wondering under such conditions, is it still correct to use gen_goto_tb() 
> here?
> Or we should use lookup_and_goto_ptr() as in trans_vsetvl() to not link the 
> TBs.

You're correct -- because of vl_eq_vlmax we can't use goto_tb when using a
variable input.

It would be possible when using xN,x0 for VLMAX, or x0,x0 for reuse of the
current vl, but I doubt it's worth special-casing that.

I wonder if the goto_tb conversation happened before we introduced vl_eq_vlmax
and forgot to re-evaluate, or if I just missed that in the first place.
Anyway, thanks for finding this.


r~

Re: [PATCH v4 09/14] hw/block/nvme: Support Zoned Namespace Command Set

[Klaus Jensen]

On Sep 24 03:20, Dmitry Fomichev wrote:
> The emulation code has been changed to advertise NVM Command Set when
> "zoned" device property is not set (default) and Zoned Namespace
> Command Set otherwise.
> 
> Handlers for three new NVMe commands introduced in Zoned Namespace
> Command Set specification are added, namely for Zone Management
> Receive, Zone Management Send and Zone Append.
> 
> Device initialization code has been extended to create a proper
> configuration for zoned operation using device properties.
> 
> Read/Write command handler is modified to only allow writes at the
> write pointer if the namespace is zoned. For Zone Append command,
> writes implicitly happen at the write pointer and the starting write
> pointer value is returned as the result of the command. Write Zeroes
> handler is modified to add zoned checks that are identical to those
> done as a part of Write flow.
> 
> The code to support for Zone Descriptor Extensions is not included in
> this commit and ZDES 0 is always reported. A later commit in this
> series will add ZDE support.
> 
> This commit doesn't yet include checks for active and open zone
> limits. It is assumed that there are no limits on either active or
> open zones.
> 
> Signed-off-by: Niklas Cassel 
> Signed-off-by: Hans Holmberg 
> Signed-off-by: Ajay Joshi 
> Signed-off-by: Chaitanya Kulkarni 
> Signed-off-by: Matias Bjorling 
> Signed-off-by: Aravind Ramesh 
> Signed-off-by: Shin'ichiro Kawasaki 
> Signed-off-by: Adam Manzanares 
> Signed-off-by: Dmitry Fomichev 
> ---
>  block/nvme.c |2 +-
>  hw/block/nvme.c  | 1057 --
>  include/block/nvme.h |6 +-
>  3 files changed, 1026 insertions(+), 39 deletions(-)
> 
> diff --git a/block/nvme.c b/block/nvme.c
> index 05485fdd11..7a513c9a17 100644
> --- a/block/nvme.c
> +++ b/block/nvme.c
> @@ -682,11 +1005,77 @@ static uint16_t nvme_rw(NvmeCtrl *n, NvmeRequest *req)
>  return status;
>  }
>  
> +if (n->params.zoned) {
> +zone_idx = nvme_zone_idx(n, slba);
> +assert(zone_idx < n->num_zones);
> +zone = &ns->zone_array[zone_idx];
> +
> +if (is_write) {
> +status = nvme_check_zone_write(zone, slba, nlb);
> +if (status != NVME_SUCCESS) {
> +trace_pci_nvme_err_zone_write_not_ok(slba, nlb, status);
> +return status | NVME_DNR;
> +}
> +
> +assert(nvme_wp_is_valid(zone));
> +if (append) {
> +if (unlikely(slba != zone->d.zslba)) {
> +trace_pci_nvme_err_append_not_at_start(slba, 
> zone->d.zslba);
> +return NVME_ZONE_INVALID_WRITE | NVME_DNR;
> +}
> +if (data_size > (n->page_size << n->zasl)) {
> +trace_pci_nvme_err_append_too_large(slba, nlb, n->zasl);
> +return NVME_INVALID_FIELD | NVME_DNR;
> +}
> +slba = zone->w_ptr;
> +} else if (unlikely(slba != zone->w_ptr)) {
> +trace_pci_nvme_err_write_not_at_wp(slba, zone->d.zslba,
> +   zone->w_ptr);
> +return NVME_ZONE_INVALID_WRITE | NVME_DNR;
> +}
> +req->fill_ofs = -1LL;
> +} else {
> +status = nvme_check_zone_read(n, zone, slba, nlb,
> +  n->params.cross_zone_read);
> +if (status != NVME_SUCCESS) {
> +trace_pci_nvme_err_zone_read_not_ok(slba, nlb, status);
> +return status | NVME_DNR;
> +}
> +
> +if (slba + nlb > zone->w_ptr) {
> +/*
> + * All or some data is read above the WP. Need to
> + * fill out the buffer area that has no backing data
> + * with a predefined data pattern (zeros by default)
> + */
> +if (slba >= zone->w_ptr) {
> +req->fill_ofs = 0;
> +} else {
> +req->fill_ofs = ((zone->w_ptr - slba) << data_shift);
> +}

If Read Across Zone Boundaries is enabled and the read in zone A
includes LBAs above the write pointer, but crossing into a full zone
(zone B), then you are gonna overwrite the valid data in zone B with the
fill pattern.


signature.asc
Description: PGP signature

Re: [PATCH v2 07/20] block/block-copy: add ratelimit to block-copy

[Vladimir Sementsov-Ogievskiy]

22.07.2020 14:05, Max Reitz wrote:

On 01.06.20 20:11, Vladimir Sementsov-Ogievskiy wrote:

We are going to directly use one async block-copy operation for backup
job, so we need rate limitator.


%s/limitator/limiter/g, I think.


We want to maintain current backup behavior: only background copying is
limited and copy-before-write operations only participate in limit
calculation. Therefore we need one rate limitator for block-copy state
and boolean flag for block-copy call state for actual limitation.

Note, that we can't just calculate each chunk in limitator after
successful copying: it will not save us from starting a lot of async
sub-requests which will exceed limit too much. Instead let's use the
following scheme on sub-request creation:
1. If at the moment limit is not exceeded, create the request and
account it immediately.
2. If at the moment limit is already exceeded, drop create sub-request
and handle limit instead (by sleep).
With this approach we'll never exceed the limit more than by one
sub-request (which pretty much matches current backup behavior).


Sounds reasonable.


Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
  include/block/block-copy.h |  8 +++
  block/block-copy.c | 44 ++
  2 files changed, 52 insertions(+)

diff --git a/include/block/block-copy.h b/include/block/block-copy.h
index 600984c733..d40e691123 100644
--- a/include/block/block-copy.h
+++ b/include/block/block-copy.h
@@ -59,6 +59,14 @@ BlockCopyCallState *block_copy_async(BlockCopyState *s,
   int64_t max_chunk,
   BlockCopyAsyncCallbackFunc cb);
  
+/*

+ * Set speed limit for block-copy instance. All block-copy operations related 
to
+ * this BlockCopyState will participate in speed calculation, but only
+ * block_copy_async calls with @ratelimit=true will be actually limited.
+ */
+void block_copy_set_speed(BlockCopyState *s, BlockCopyCallState *call_state,
+  uint64_t speed);
+
  BdrvDirtyBitmap *block_copy_dirty_bitmap(BlockCopyState *s);
  void block_copy_set_skip_unallocated(BlockCopyState *s, bool skip);
  
diff --git a/block/block-copy.c b/block/block-copy.c

index 4114d1fd25..851d9c8aaf 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -26,6 +26,7 @@
  #define BLOCK_COPY_MAX_BUFFER (1 * MiB)
  #define BLOCK_COPY_MAX_MEM (128 * MiB)
  #define BLOCK_COPY_MAX_WORKERS 64
+#define BLOCK_COPY_SLICE_TIME 1ULL /* ns */
  
  static coroutine_fn int block_copy_task_entry(AioTask *task);
  
@@ -36,11 +37,13 @@ typedef struct BlockCopyCallState {

  int64_t bytes;
  int max_workers;
  int64_t max_chunk;
+bool ratelimit;
  BlockCopyAsyncCallbackFunc cb;
  
  /* State */

  bool failed;
  bool finished;
+QemuCoSleepState *sleep_state;
  
  /* OUT parameters */

  bool error_is_read;
@@ -103,6 +106,9 @@ typedef struct BlockCopyState {
  void *progress_opaque;
  
  SharedResource *mem;

+
+uint64_t speed;
+RateLimit rate_limit;
  } BlockCopyState;
  
  static BlockCopyTask *find_conflicting_task(BlockCopyState *s,

@@ -611,6 +617,21 @@ block_copy_dirty_clusters(BlockCopyCallState *call_state)
  }
  task->zeroes = ret & BDRV_BLOCK_ZERO;
  
+if (s->speed) {

+if (call_state->ratelimit) {
+uint64_t ns = ratelimit_calculate_delay(&s->rate_limit, 0);
+if (ns > 0) {
+block_copy_task_end(task, -EAGAIN);
+g_free(task);
+qemu_co_sleep_ns_wakeable(QEMU_CLOCK_REALTIME, ns,
+  &call_state->sleep_state);
+continue;
+}
+}
+
+ratelimit_calculate_delay(&s->rate_limit, task->bytes);
+}
+


Looks good.


  trace_block_copy_process(s, task->offset);
  
  co_get_from_shres(s->mem, task->bytes);

@@ -649,6 +670,13 @@ out:
  return ret < 0 ? ret : found_dirty;
  }
  
+static void block_copy_kick(BlockCopyCallState *call_state)

+{
+if (call_state->sleep_state) {
+qemu_co_sleep_wake(call_state->sleep_state);
+}
+}
+
  /*
   * block_copy_common
   *
@@ -729,6 +757,7 @@ BlockCopyCallState *block_copy_async(BlockCopyState *s,
  .s = s,
  .offset = offset,
  .bytes = bytes,
+.ratelimit = ratelimit,


Hm, same problem/question as in patch 6: Should the @ratelimit parameter
really be added in patch 5 if it’s used only now?


  .cb = cb,
  .max_workers = max_workers ?: BLOCK_COPY_MAX_WORKERS,
  .max_chunk = max_chunk,
@@ -752,3 +781,18 @@ void block_copy_set_skip_unallocated(BlockCopyState *s, 
bool skip)
  {
  s->skip_unallocated = skip;
  }
+
+void block_copy_set_speed(BlockCopyState *s, BlockCopyCallState *call_state,
+  uint64_t speed)
+{
+uint64_t old_speed = s->speed;
+
+

Re: [PATCH v5] hw/i386/pc: add max combined fw size as machine configuration option

[Philippe Mathieu-Daudé]

On 9/25/20 7:17 PM, McMillan, Erich wrote:
> Additionally HPi is not a mistake, corporate requires that we refer to
> ourselves as Hewlett Packard Inc since the split in 2015. I will perhaps
> update this to be the full name for clarity.

Maybe worth be explicit, else it is confusing (since your
email is hp.com and not hpi.com).

> 
>  
> 
>  
> 
> *From:*McMillan, Erich
> *Sent:* Friday, September 25, 2020 12:15 PM
> *To:* Laszlo Ersek ; qemu-devel@nongnu.org
> *Cc:* dgilb...@redhat.com; m...@redhat.com; marcel.apfelb...@gmail.com;
> imamm...@redhat.com; kra...@redhat.com
> *Subject:* RE: [PATCH v5] hw/i386/pc: add max combined fw size as
> machine configuration option
> 
>  
> 
> Hi Laszlo,
> 
>  
> 
> Thank you for the feedback, apologies that I missed the exact line
> references I was moving too fast.
> 
> I appreciate you taking the time to explain the nuances.
> 
>  
> 
> On an unrelated note, it seems that my patches are no longer appearing
> in https://lists.nongnu.org/archive/html/qemu-devel/2020-09/index.html
> is this because I need to cc qemu-devel@nongnu.org
>  rather than –to?

It is:
https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg09212.html

The archive is updated twice an hour I guess.

> 
>  
> 
> -Erich

Re: [PATCH V1 10/32] kvmclock: restore paused KVM clock

[Steven Sistare]

On 9/11/2020 1:50 PM, Dr. David Alan Gilbert wrote:
> * Steve Sistare (steven.sist...@oracle.com) wrote:
>> If the VM is paused when the KVM clock is serialized to a file, record
>> that the clock is valid, so the value will be reused rather than
>> overwritten after cprload with a new call to KVM_GET_CLOCK here:
>>
>> kvmclock_vm_state_change()
>> if (running)
>> ...
>> else
>> if (s->clock_valid)
>> return; <-- instead, return here
>>
>> kvm_update_clock()
>>kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data)  <-- overwritten
>>
>> Signed-off-by: Steve Sistare 
>> ---
>>  hw/i386/kvm/clock.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
>> index 6428335..161991a 100644
>> --- a/hw/i386/kvm/clock.c
>> +++ b/hw/i386/kvm/clock.c
>> @@ -285,18 +285,22 @@ static int kvmclock_pre_save(void *opaque)
>>  if (!s->runstate_paused) {
>>  kvm_update_clock(s);
>>  }
>> +if (!runstate_is_running()) {
>> +s->clock_valid = true;
>> +}
>>  
>>  return 0;
>>  }
>>  
>>  static const VMStateDescription kvmclock_vmsd = {
>>  .name = "kvmclock",
>> -.version_id = 1,
>> +.version_id = 2,
>>  .minimum_version_id = 1,
>>  .pre_load = kvmclock_pre_load,
>>  .pre_save = kvmclock_pre_save,
>>  .fields = (VMStateField[]) {
>>  VMSTATE_UINT64(clock, KVMClockState),
>> +VMSTATE_BOOL_V(clock_valid, KVMClockState, 2),
>>  VMSTATE_END_OF_LIST()
> 
> We always try and avoid bumping version_id unless we're
> desperate because it breaks backwards migration.
> 
> Didn't you already know from the stored migration state
> (in the globalstate) if the loaded VM was running?
> 
> It's also not clear to me why you're avoiding reloading the state;
> have you preserved that some other way?

This patch was needed only for an early version of cprload which had some 
gratuitous
vmstate transitions.  I will happily drop this patch.

- Steve

>>  },
>>  .subsections = (const VMStateDescription * []) {
>> -- 
>> 1.8.3.1
>>

RE: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT

[Strong, Beeman]

LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which 
requires 32-bit code.  In that case a LIP=0 implementation will provide only 
the EIP offset from CSbase in IP packets (like TIP or FUP), while LIP=1 
implementation will provide the full LIP (CSbase + EIP offset).

-Original Message-
From: Eduardo Habkost  
Sent: Friday, September 25, 2020 9:16 AM
To: Kang, Luwei 
Cc: pbonz...@redhat.com; r...@twiddle.net; qemu-devel@nongnu.org; Strong, 
Beeman 
Subject: Re: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for 
Intel PT

On Tue, Feb 25, 2020 at 05:38:30AM +0800, Luwei Kang wrote:
> The Intel PT packets which contain IP payloads will have LIP values, 
> and it will include the CS base component if the 
> CPUID.(EAX=14H,ECX=0H).ECX.[bit31]
> is set. But it will disabled the Intel PT in kvm guest because of the 
> need of live migration safe(c078ca9 i386: Disable Intel PT if packets 
> IP payloads have LIP values).
> 
> This patch will revert the previous limitation because the Intel new 
> hardware will set this bit and LIP == RIP for most/all real code.

"works most of the time" might be good enough if it's a conscious user choice, 
but not for something we might be enabling by default.  Under which conditions 
this wouldn't work?  Can we detect those conditions somehow?

To allow live migration between LIP=0 and LIP=1 hosts, we need KVM to be able 
to properly emulate LIP=0 on LIP=1 hosts.  Does the hardware make this possible?

If KVM can't emulate LIP=0 on a LIP=1 host, what you can do here is to make the 
flag configurable and check if the configured value matches the one in the 
host.  This way we can support both types of hosts, just not allow live 
migration between them.


> 
> Signed-off-by: Luwei Kang 
> ---
>  target/i386/cpu.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 
> 69f518a..8c0d1e4 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -688,8 +688,6 @@ static CPUCacheInfo legacy_l3_cache = {
>   * bit[02]: Support Single-Range Output scheme;
>   */
>  #define INTEL_PT_MINIMAL_ECX 0x7
> -/* generated packets which contain IP payloads have LIP values */
> -#define INTEL_PT_IP_LIP  (1 << 31)
>  #define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable 
> address ranges */  #define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
>  #define INTEL_PT_MTC_BITMAP  (0x0249 << 16) /* Support ART(0,3,6,9) */
> @@ -6281,8 +6279,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool 
> verbose)
> ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
> INTEL_PT_ADDR_RANGES_NUM) ||
> ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> -(INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) ||
> -   (ecx_0 & INTEL_PT_IP_LIP)) {
> +(INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
>  /*
>   * Processor Trace capabilities aren't configurable, so if the
>   * host can't emulate the capabilities we report on
> --
> 1.8.3.1
> 

-- 
Eduardo

Re: [PATCH v5] hw/i386/pc: add max combined fw size as machine configuration option

[Dr. David Alan Gilbert]

* McMillan, Erich (erich.mcmil...@hp.com) wrote:
> Additionally HPi is not a mistake, corporate requires that we refer to 
> ourselves as Hewlett Packard Inc since the split in 2015. I will perhaps 
> update this to be the full name for clarity.

Please note that no one outside of HP knows what HPi is; so you might
want to spell it out a bit.

Dave

> 
> From: McMillan, Erich
> Sent: Friday, September 25, 2020 12:15 PM
> To: Laszlo Ersek ; qemu-devel@nongnu.org
> Cc: dgilb...@redhat.com; m...@redhat.com; marcel.apfelb...@gmail.com; 
> imamm...@redhat.com; kra...@redhat.com
> Subject: RE: [PATCH v5] hw/i386/pc: add max combined fw size as machine 
> configuration option
> 
> Hi Laszlo,
> 
> Thank you for the feedback, apologies that I missed the exact line references 
> I was moving too fast.
> I appreciate you taking the time to explain the nuances.
> 
> On an unrelated note, it seems that my patches are no longer appearing in 
> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/index.html is this 
> because I need to cc qemu-devel@nongnu.org 
> rather than –to?
> 
> -Erich
> 
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, September 25, 2020 2:00 AM
> To: McMillan, Erich mailto:erich.mcmil...@hp.com>>; 
> qemu-devel@nongnu.org
> Cc: dgilb...@redhat.com; 
> m...@redhat.com; 
> marcel.apfelb...@gmail.com; 
> imamm...@redhat.com; 
> kra...@redhat.com
> Subject: Re: [PATCH v5] hw/i386/pc: add max combined fw size as machine 
> configuration option
> 
> Hi Erich,
> 
> when processing review feedback, please pay attention to *where* the
> review comments are inserted, in response to your patch email.
> 
> I'm pointing this out not because I want to annoy you with my
> obsessions, but because I consider this discussion a kind of "git +
> mailing lists" training for you. (In accordance with your first message
> on the topic.)
> 
> Please see specifics below:
> 
> On 09/25/20 05:36, Erich Mcmillan wrote:
> > From: Erich McMillan mailto:erich.mcmil...@hp.com>>
> >
> > At HPi we have a need for increased fw size to enable testing of our custom 
> > fw.
> >
> > Signed-off-by: Erich McMillan 
> > mailto:erich.mcmil...@hp.com>>
> >
> > Change since v4:
> > Add explicit return to pc_machine_set_max_fw_size.
> > Remove /* default */ from max_fw_size initialization.
> > ---
> >
> > hw/i386/pc.c | 52 
> > hw/i386/pc_sysfw.c | 13 ++-
> > include/hw/i386/pc.h | 2 ++
> > 3 files changed, 56 insertions(+), 11 deletions(-)
> 
> Please refer to my earlier feedback, archived at the following location:
> 
> 8fdbf9f1-5125-1c39-4ec7-f99f017d4345@redhat.com">http://mid.mail-archive.com/8fdbf9f1-5125-1c39-4ec7-f99f017d4345@redhat.com<8fdbf9f1-5125-1c39-4ec7-f99f017d4345@redhat.com">http://mid.mail-archive.com/8fdbf9f1-5125-1c39-4ec7-f99f017d4345@redhat.com>
> 
> As I say in that message, the v(n)->v(n+1) changelog belongs 'between
> the "---" separator and the diffstat'. In that message, I marked the
> specific location with [*].
> 
> Basically the "---" separator terminates the commit message, and the
> first "diff --git" line starts the code changes. What's between them is
> thrown away, when the patch is applied. So in that throwaway area,
> git-format-patch places the diffstat automatically (because it gives
> reviewers a helpful overview of the patch, but is not useful for patch
> application). And that's also the area where the v(n)->v(n+1) changelog
> should be included. Traditionally, we place that log above the diffstat.
> 
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index d11daacc23..6e66cbbc41 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1869,6 +1869,51 @@ static void pc_machine_set_max_ram_below_4g(Object 
> > *obj, Visitor *v,
> > pcms->max_ram_below_4g = value;
> > }
> >
> > +static void pc_machine_get_max_fw_size(Object *obj, Visitor *v,
> > + const char *name, void *opaque,
> > + Error **errp)
> > +{
> > + PCMachineState *pcms = PC_MACHINE(obj);
> > + uint64_t value = pcms->max_fw_size;
> > +
> > + visit_type_size(v, name, &value, errp);
> > +}
> > +
> > +static void pc_machine_set_max_fw_size(Object *obj, Visitor *v,
> > + const char *name, void *opaque,
> > + Error **errp)
> > +{
> > + PCMachineState *pcms = PC_MACHINE(obj);
> > + Error *error = NULL;
> > + uint64_t value;
> > +
> > + visit_type_size(v, name, &value, &error);
> > + if (error) {
> > + error_propagate(errp, error);
> > + return;
> > + }
> > +
> > + /*
> > + * We don't have a theoretically justifiable exact lower bound on the base
> > + * address of any flash mapping. In practice, the IO-APIC MMIO range is
> > + * [0xFEE0..0xFEE01000] -- see IO_APIC_DEFAULT_ADDRESS --, leaving free
> > + * only 18MB-4KB below 4G. For now, restrict the cumulative mapping 

[PATCH v6] hw/i386/pc: add max combined fw size as machine configuration option

[Erich Mcmillan]

From: Erich McMillan 

At Hewlett Packard Inc. we have a need for increased fw size to enable testing 
of our custom fw.
Move return statement for early return

Signed-off-by: Erich McMillan 
---

Changes since v5:

 Move return statement for pc_machine_set_max_fw_size() to follow 
error_setg() as early return.

 hw/i386/pc.c | 51 
 hw/i386/pc_sysfw.c   | 13 ++-
 include/hw/i386/pc.h |  2 ++
 3 files changed, 55 insertions(+), 11 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index d11daacc23..70c8c9adcf 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1869,6 +1869,50 @@ static void pc_machine_set_max_ram_below_4g(Object *obj, 
Visitor *v,
 pcms->max_ram_below_4g = value;
 }
 
+static void pc_machine_get_max_fw_size(Object *obj, Visitor *v,
+   const char *name, void *opaque,
+   Error **errp)
+{
+PCMachineState *pcms = PC_MACHINE(obj);
+uint64_t value = pcms->max_fw_size;
+
+visit_type_size(v, name, &value, errp);
+}
+
+static void pc_machine_set_max_fw_size(Object *obj, Visitor *v,
+   const char *name, void *opaque,
+   Error **errp)
+{
+PCMachineState *pcms = PC_MACHINE(obj);
+Error *error = NULL;
+uint64_t value;
+
+visit_type_size(v, name, &value, &error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
+
+/*
+* We don't have a theoretically justifiable exact lower bound on the base
+* address of any flash mapping. In practice, the IO-APIC MMIO range is
+* [0xFEE0..0xFEE01000] -- see IO_APIC_DEFAULT_ADDRESS --, leaving free
+* only 18MB-4KB below 4G. For now, restrict the cumulative mapping to 8MB 
in
+* size.
+*/
+if (value > 16 * MiB) {
+error_setg(errp,
+   "User specified max allowed firmware size %" PRIu64 " is "
+   "greater than 16MiB. If combined firwmare size exceeds "
+   "16MiB the system may not boot, or experience intermittent"
+   "stability issues.",
+   value);
+return;
+}
+
+pcms->max_fw_size = value;
+}
+
 static void pc_machine_initfn(Object *obj)
 {
 PCMachineState *pcms = PC_MACHINE(obj);
@@ -1884,6 +1928,7 @@ static void pc_machine_initfn(Object *obj)
 pcms->smbus_enabled = true;
 pcms->sata_enabled = true;
 pcms->pit_enabled = true;
+pcms->max_fw_size = 8 * MiB;
 
 pc_system_flash_create(pcms);
 pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
@@ -2004,6 +2049,12 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 
 object_class_property_add_bool(oc, PC_MACHINE_PIT,
 pc_machine_get_pit, pc_machine_set_pit);
+
+object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size",
+pc_machine_get_max_fw_size, pc_machine_set_max_fw_size,
+NULL, NULL);
+object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE,
+"Maximum combined firmware size");
 }
 
 static const TypeInfo pc_machine_info = {
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b6c0822fe3..22450ba0ef 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -39,15 +39,6 @@
 #include "hw/block/flash.h"
 #include "sysemu/kvm.h"
 
-/*
- * We don't have a theoretically justifiable exact lower bound on the base
- * address of any flash mapping. In practice, the IO-APIC MMIO range is
- * [0xFEE0..0xFEE01000] -- see IO_APIC_DEFAULT_ADDRESS --, leaving free
- * only 18MB-4KB below 4G. For now, restrict the cumulative mapping to 8MB in
- * size.
- */
-#define FLASH_SIZE_LIMIT (8 * MiB)
-
 #define FLASH_SECTOR_SIZE 4096
 
 static void pc_isa_bios_init(MemoryRegion *rom_memory,
@@ -182,10 +173,10 @@ static void pc_system_flash_map(PCMachineState *pcms,
 }
 if ((hwaddr)size != size
 || total_size > HWADDR_MAX - size
-|| total_size + size > FLASH_SIZE_LIMIT) {
+|| total_size + size > pcms->max_fw_size) {
 error_report("combined size of system firmware exceeds "
  "%" PRIu64 " bytes",
- FLASH_SIZE_LIMIT);
+ pcms->max_fw_size);
 exit(1);
 }
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index fe52e165b2..f7c8e7cbfe 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -43,6 +43,7 @@ struct PCMachineState {
 bool smbus_enabled;
 bool sata_enabled;
 bool pit_enabled;
+uint64_t max_fw_size;
 
 /* NUMA information: */
 uint64_t numa_nodes;
@@ -59,6 +60,7 @@ struct PCMachineState {
 #define PC_MACHINE_SMBUS"smbus"
 #define PC_MACHINE_SATA "sata"
 #define PC_MACHINE_PIT  "pit"
+#define PC_MACHINE_MAX_FW_SIZE  "max-fw-size"
 
 /**
  * PCMachineClass:
-- 
2.25.1

Re: [PATCH] vhost: Ignore vrings in dirty log when using a vIOMMU

[Greg Kurz]

Cc'ing Jason since this was detected using vhost-net.

On Fri, 25 Sep 2020 19:29:43 +0200
Greg Kurz  wrote:

> When a vIOMMU is present, any address comming from the guest is an IO
> virtual address, including those of the vrings. The backend's accesses
> to the vrings happen through vIOMMU translation : the backend hence
> only logs the final guest physical address, not the IO virtual one.
> It thus doesn't make sense to make room for the vring addresses in the
> dirty log in this case.
> 
> This fixes a crash of the source when migrating a guest using in-kernel
> vhost-net and iommu_platform=on on POWER, because DMA regions are put
> at very high addresses and the resulting log size is likely to cause
> g_malloc0() to abort.
> 
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879349
> Signed-off-by: Greg Kurz 
> ---
>  hw/virtio/vhost.c |   38 --
>  1 file changed, 24 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 1a1384e7a642..0b83d6b8e65e 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -106,6 +106,20 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
>  }
>  }
>  
> +static int vhost_dev_has_iommu(struct vhost_dev *dev)
> +{
> +VirtIODevice *vdev = dev->vdev;
> +
> +/*
> + * For vhost, VIRTIO_F_IOMMU_PLATFORM means the backend support
> + * incremental memory mapping API via IOTLB API. For platform that
> + * does not have IOMMU, there's no need to enable this feature
> + * which may cause unnecessary IOTLB miss/update trnasactions.
> + */
> +return vdev->dma_as != &address_space_memory &&
> +   virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
> +}
> +
>  static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
> MemoryRegionSection *section,
> hwaddr first,
> @@ -130,6 +144,11 @@ static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
>range_get_last(reg->guest_phys_addr,
>   reg->memory_size));
>  }
> +
> +if (vhost_dev_has_iommu(dev)) {
> +return 0;
> +}
> +
>  for (i = 0; i < dev->nvqs; ++i) {
>  struct vhost_virtqueue *vq = dev->vqs + i;
>  
> @@ -172,6 +191,11 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev)
> reg->memory_size);
>  log_size = MAX(log_size, last / VHOST_LOG_CHUNK + 1);
>  }
> +
> +if (vhost_dev_has_iommu(dev)) {
> +return log_size;
> +}
> +
>  for (i = 0; i < dev->nvqs; ++i) {
>  struct vhost_virtqueue *vq = dev->vqs + i;
>  
> @@ -287,20 +311,6 @@ static inline void vhost_dev_log_resize(struct vhost_dev 
> *dev, uint64_t size)
>  dev->log_size = size;
>  }
>  
> -static int vhost_dev_has_iommu(struct vhost_dev *dev)
> -{
> -VirtIODevice *vdev = dev->vdev;
> -
> -/*
> - * For vhost, VIRTIO_F_IOMMU_PLATFORM means the backend support
> - * incremental memory mapping API via IOTLB API. For platform that
> - * does not have IOMMU, there's no need to enable this feature
> - * which may cause unnecessary IOTLB miss/update trnasactions.
> - */
> -return vdev->dma_as != &address_space_memory &&
> -   virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
> -}
> -
>  static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
>hwaddr *plen, bool is_write)
>  {
> 
> 
> 

Re: Minix 1.1 with QEMU

[John Snow]

On 9/23/20 1:00 PM, Will Senn wrote:

On 9/23/20 11:53 AM, Philippe Mathieu-Daudé wrote:

Hi Will,

On 9/23/20 6:45 PM, Will Senn wrote:

Long time user, first time poster :)

So, I'd like to be able to run Minix 1.1 on my Macbook Pro mid-2012
w/16gb RAM (MacOS 10.14.6 Mojave). Qemu will run pretty ancient OS'es
such as DOS 2.0, which I use all of the time. However, I'm having some
difficulty getting Minix to run. I am able to boot the first floppy, but
when I change to the second floppy, the system freezes and I can't tell
what is going on. Here's what I did to get this far:

brew install qemu

qemu-system-i386 --version
QEMU emulator version 5.1.0

mkdir ~/workspaces/retro-workspace/minix-1.1
cd ~/workspaces/retro-workspace/minix-1.1
aria2c
http://download.minix3.org/previous-versions/bzipped/Intel-1.1.tar.bz2
tar xvjf Intel-1.1.tar.bz2
cp Intel-1.1/floppy_disk1 ./Disk01.img
cp Intel-1.1/floppy_disk2 ./Disk02.img
cp Intel-1.1/floppy_disk3 ./Disk03.img
cp Intel-1.1/floppy_disk4 ./Disk04.img


qemu-system-i386 -drive
file=Disk01.img,format=raw,if=floppy,media=disk,readonly=off,index=0,snapshot=on
\
   -boot a \
   -no-fd-bootchk \
   -monitortelnet::,server,nowait  -serial mon:stdio

Qemu boots to the Minix 1.1 Boot screen and says to swap to floppy 2, so
in the monitor:
change floppy0 Disk02.img raw

I press l (el) and it scans the disk, lists the files on the disk and
reports no errors, but when I press =, it does a carriage return and
just sits there. I'm pretty sure this is the Minix going bye bye and not
necessarily QEMU, but I'm wondering if there is a way to see what QEMU
thinks it is doing or if it is what's hung? Usually, at this point,
Minix reads the disk contents into a Ramdisk and boots Minix.



You can turn on tracing! See docs/devel/tracing.txt for more. You can 
also run QEMU under GDB and break on floppy functions to see what's 
going on if you are so inclined.



Food for thought... Minix expects to run on an IBM PC (5150), IBM PC XT
(5160), or compatible, and therefore the I/O is written for whatever
floppy controller was extant at that time (I'm guessing here), so if
that's different than modern day floppies, I suppose this could cause
the problem I'm experiencing here. Is there a way to see the floppy
controller activity in QEMU? Similarly, I gather it expects a CGA
compatible monitor (EGA/VGA, etc should be fine).

Can you try adding '-machine isapc', which is closer to the 5150?


I appreciate your help on this.

Minix 1.1 works 'ok' in 86Box and other IBM PC emulations, so I know the
floppies are fine.

Thanks!

Will



--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


Phillipe,

My new incantation is:

qemu-system-i386 -machine isapc -drive 
file=Disk01.img,format=raw,if=floppy,media=disk,readonly=off,index=0,snapshot=on 
-boot a   -no-fd-bootchk   -monitor telnet::,server,nowait -serial 
mon:stdio


with the same outcome :(. Thanks for the suggestion, I'll keep it in 
mind for other projects.


Will

--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



This isn't the first time I've seen a report of floppy disks behaving 
poorly in older operating systems.


I'm afraid I don't have the time to really investigate these issues, but 
I am happy to take patches.


--js

[PATCH] vhost: Ignore vrings in dirty log when using a vIOMMU

[Greg Kurz]

When a vIOMMU is present, any address comming from the guest is an IO
virtual address, including those of the vrings. The backend's accesses
to the vrings happen through vIOMMU translation : the backend hence
only logs the final guest physical address, not the IO virtual one.
It thus doesn't make sense to make room for the vring addresses in the
dirty log in this case.

This fixes a crash of the source when migrating a guest using in-kernel
vhost-net and iommu_platform=on on POWER, because DMA regions are put
at very high addresses and the resulting log size is likely to cause
g_malloc0() to abort.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879349
Signed-off-by: Greg Kurz 
---
 hw/virtio/vhost.c |   38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 1a1384e7a642..0b83d6b8e65e 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -106,6 +106,20 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
 }
 }
 
+static int vhost_dev_has_iommu(struct vhost_dev *dev)
+{
+VirtIODevice *vdev = dev->vdev;
+
+/*
+ * For vhost, VIRTIO_F_IOMMU_PLATFORM means the backend support
+ * incremental memory mapping API via IOTLB API. For platform that
+ * does not have IOMMU, there's no need to enable this feature
+ * which may cause unnecessary IOTLB miss/update trnasactions.
+ */
+return vdev->dma_as != &address_space_memory &&
+   virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
+}
+
 static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
MemoryRegionSection *section,
hwaddr first,
@@ -130,6 +144,11 @@ static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
   range_get_last(reg->guest_phys_addr,
  reg->memory_size));
 }
+
+if (vhost_dev_has_iommu(dev)) {
+return 0;
+}
+
 for (i = 0; i < dev->nvqs; ++i) {
 struct vhost_virtqueue *vq = dev->vqs + i;
 
@@ -172,6 +191,11 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev)
reg->memory_size);
 log_size = MAX(log_size, last / VHOST_LOG_CHUNK + 1);
 }
+
+if (vhost_dev_has_iommu(dev)) {
+return log_size;
+}
+
 for (i = 0; i < dev->nvqs; ++i) {
 struct vhost_virtqueue *vq = dev->vqs + i;
 
@@ -287,20 +311,6 @@ static inline void vhost_dev_log_resize(struct vhost_dev 
*dev, uint64_t size)
 dev->log_size = size;
 }
 
-static int vhost_dev_has_iommu(struct vhost_dev *dev)
-{
-VirtIODevice *vdev = dev->vdev;
-
-/*
- * For vhost, VIRTIO_F_IOMMU_PLATFORM means the backend support
- * incremental memory mapping API via IOTLB API. For platform that
- * does not have IOMMU, there's no need to enable this feature
- * which may cause unnecessary IOTLB miss/update trnasactions.
- */
-return vdev->dma_as != &address_space_memory &&
-   virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
-}
-
 static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
   hwaddr *plen, bool is_write)
 {

Re: [PATCH 00/16] hw/block/nvme: zoned namespace command set

[Klaus Jensen]

On Sep 25 17:06, Dmitry Fomichev wrote:
> > From: Klaus Jensen 
> > 
> >   * Standard blockdev-based approach to persistent state. The
> > 
> > implementation uses a plain blockdev associated with the nvme-ns
> > 
> > device for storing state persistently. This same 'pstate' blockdev
> > 
> > is also used for logical block allocation tracking.
> > 
> 
> Is persistent state mandatory or optional? Sorry for asking, but I am
> still catching up with your other patches. I think having it optional is
> a big benefit for performance testing.
> 

Yes, the 'pstate' blockdev is optional.

> > 
> > 
> >   * Relies on automatic configuration of DLFEAT according to what the
> > 
> > underlying blockdev provides (i.e. BDRV_O_UNMAP for guaranteeing
> > 
> > zeroes on discarded blocks) for handling reads in the gaps between
> > 
> > write pointer, ZCAP and ZSZE. Issues discards for zone resets. This
> > 
> > removes the zero filling.
> > 
> 
> Doesn't this make non-zero fill patterns impossible? In many storage
> environments, vendors and admins are adamant about having varying
> fill patterns to see who caused the data corruption if there is one.
> Not sure how important this for the particular application, but WDC
> series provides the functionality to specify the fill pattern.
> 

That *is* a good point.

By default I think it should default to either the 0x00 fill pattern (if
supported by the underlying blockdev), or "no fill pattern reported"
when 0x00's cannot be guaranteed. But, an option to enable filling with,
say 0xff, like you do in your series, would be nice.


signature.asc
Description: PGP signature

[PATCH 10/10] scsi/scsi_bus: fix races in REPORT LUNS

[Paolo Bonzini]

From: Maxim Levitsky 

Currently scsi_target_emulate_report_luns iterates over the child device list
twice, and there is no guarantee that this list is the same in both iterations.

The reason for iterating twice is that the first iteration calculates
how much memory to allocate.  However if we use a dynamic array we can
avoid iterating twice, and therefore we avoid this race.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1866707

Signed-off-by: Maxim Levitsky 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20200913160259.32145-10-mlevi...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 hw/scsi/scsi-bus.c | 68 ++
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index eda8cb7e70..b901e701f0 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -438,19 +438,23 @@ struct SCSITargetReq {
 static void store_lun(uint8_t *outbuf, int lun)
 {
 if (lun < 256) {
+/* Simple logical unit addressing method*/
+outbuf[0] = 0;
 outbuf[1] = lun;
-return;
+} else {
+/* Flat space addressing method */
+outbuf[0] = 0x40 | (lun >> 8);
+outbuf[1] = (lun & 255);
 }
-outbuf[1] = (lun & 255);
-outbuf[0] = (lun >> 8) | 0x40;
 }
 
 static bool scsi_target_emulate_report_luns(SCSITargetReq *r)
 {
 BusChild *kid;
-int i, len, n;
 int channel, id;
-bool found_lun0;
+uint8_t tmp[8] = {0};
+int len = 0;
+GByteArray *buf;
 
 if (r->req.cmd.xfer < 16) {
 return false;
@@ -458,46 +462,40 @@ static bool scsi_target_emulate_report_luns(SCSITargetReq 
*r)
 if (r->req.cmd.buf[2] > 2) {
 return false;
 }
+
+/* reserve space for 63 LUNs*/
+buf = g_byte_array_sized_new(512);
+
 channel = r->req.dev->channel;
 id = r->req.dev->id;
-found_lun0 = false;
-n = 0;
 
-RCU_READ_LOCK_GUARD();
+/* add size (will be updated later to correct value */
+g_byte_array_append(buf, tmp, 8);
+len += 8;
 
-QTAILQ_FOREACH_RCU(kid, &r->req.bus->qbus.children, sibling) {
-DeviceState *qdev = kid->child;
-SCSIDevice *dev = SCSI_DEVICE(qdev);
+/* add LUN0 */
+g_byte_array_append(buf, tmp, 8);
+len += 8;
 
-if (dev->channel == channel && dev->id == id) {
-if (dev->lun == 0) {
-found_lun0 = true;
+WITH_RCU_READ_LOCK_GUARD() {
+QTAILQ_FOREACH_RCU(kid, &r->req.bus->qbus.children, sibling) {
+DeviceState *qdev = kid->child;
+SCSIDevice *dev = SCSI_DEVICE(qdev);
+
+if (dev->channel == channel && dev->id == id && dev->lun != 0) {
+store_lun(tmp, dev->lun);
+g_byte_array_append(buf, tmp, 8);
+len += 8;
 }
-n += 8;
 }
 }
-if (!found_lun0) {
-n += 8;
-}
-
-scsi_target_alloc_buf(&r->req, n + 8);
-
-len = MIN(n + 8, r->req.cmd.xfer & ~7);
-memset(r->buf, 0, len);
-stl_be_p(&r->buf[0], n);
-i = found_lun0 ? 8 : 16;
-QTAILQ_FOREACH_RCU(kid, &r->req.bus->qbus.children, sibling) {
-DeviceState *qdev = kid->child;
-SCSIDevice *dev = SCSI_DEVICE(qdev);
 
-if (dev->channel == channel && dev->id == id) {
-store_lun(&r->buf[i], dev->lun);
-i += 8;
-}
-}
+r->buf_len = len;
+r->buf = g_byte_array_free(buf, FALSE);
+r->len = MIN(len, r->req.cmd.xfer & ~7);
 
-assert(i == n + 8);
-r->len = len;
+/* store the LUN list length */
+stl_be_p(&r->buf[0], len - 8);
 return true;
 }
 
-- 
2.26.2

[PATCH 09/10] virtio-scsi: use scsi_device_get

[Paolo Bonzini]

From: Maxim Levitsky 

This will help us to avoid the scsi device disappearing
after we took a reference to it.

It doesn't by itself forbid case when we try to access
an unrealized device

Suggested-by: Stefan Hajnoczi 
Signed-off-by: Maxim Levitsky 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20200913160259.32145-9-mlevi...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 hw/scsi/virtio-scsi.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 971afbb217..3db9a8aae9 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -33,7 +33,7 @@ static inline int virtio_scsi_get_lun(uint8_t *lun)
 return ((lun[2] << 8) | lun[3]) & 0x3FFF;
 }
 
-static inline SCSIDevice *virtio_scsi_device_find(VirtIOSCSI *s, uint8_t *lun)
+static inline SCSIDevice *virtio_scsi_device_get(VirtIOSCSI *s, uint8_t *lun)
 {
 if (lun[0] != 1) {
 return NULL;
@@ -41,7 +41,7 @@ static inline SCSIDevice *virtio_scsi_device_find(VirtIOSCSI 
*s, uint8_t *lun)
 if (lun[2] != 0 && !(lun[2] >= 0x40 && lun[2] < 0x80)) {
 return NULL;
 }
-return scsi_device_find(&s->bus, 0, lun[1], virtio_scsi_get_lun(lun));
+return scsi_device_get(&s->bus, 0, lun[1], virtio_scsi_get_lun(lun));
 }
 
 void virtio_scsi_init_req(VirtIOSCSI *s, VirtQueue *vq, VirtIOSCSIReq *req)
@@ -256,7 +256,7 @@ static inline void virtio_scsi_ctx_check(VirtIOSCSI *s, 
SCSIDevice *d)
  *  case of async cancellation. */
 static int virtio_scsi_do_tmf(VirtIOSCSI *s, VirtIOSCSIReq *req)
 {
-SCSIDevice *d = virtio_scsi_device_find(s, req->req.tmf.lun);
+SCSIDevice *d = virtio_scsi_device_get(s, req->req.tmf.lun);
 SCSIRequest *r, *next;
 BusChild *kid;
 int target;
@@ -370,10 +370,10 @@ static int virtio_scsi_do_tmf(VirtIOSCSI *s, 
VirtIOSCSIReq *req)
 
 rcu_read_lock();
 QTAILQ_FOREACH_RCU(kid, &s->bus.qbus.children, sibling) {
- d = SCSI_DEVICE(kid->child);
- if (d->channel == 0 && d->id == target) {
-qdev_reset_all(&d->qdev);
- }
+SCSIDevice *d1 = SCSI_DEVICE(kid->child);
+if (d1->channel == 0 && d1->id == target) {
+qdev_reset_all(&d1->qdev);
+}
 }
 rcu_read_unlock();
 
@@ -386,14 +386,17 @@ static int virtio_scsi_do_tmf(VirtIOSCSI *s, 
VirtIOSCSIReq *req)
 break;
 }
 
+object_unref(OBJECT(d));
 return ret;
 
 incorrect_lun:
 req->resp.tmf.response = VIRTIO_SCSI_S_INCORRECT_LUN;
+object_unref(OBJECT(d));
 return ret;
 
 fail:
 req->resp.tmf.response = VIRTIO_SCSI_S_BAD_TARGET;
+object_unref(OBJECT(d));
 return ret;
 }
 
@@ -564,7 +567,7 @@ static int virtio_scsi_handle_cmd_req_prepare(VirtIOSCSI 
*s, VirtIOSCSIReq *req)
 }
 }
 
-d = virtio_scsi_device_find(s, req->req.cmd.lun);
+d = virtio_scsi_device_get(s, req->req.cmd.lun);
 if (!d) {
 req->resp.cmd.response = VIRTIO_SCSI_S_BAD_TARGET;
 virtio_scsi_complete_cmd_req(req);
@@ -580,10 +583,12 @@ static int virtio_scsi_handle_cmd_req_prepare(VirtIOSCSI 
*s, VirtIOSCSIReq *req)
 req->sreq->cmd.xfer > req->qsgl.size)) {
 req->resp.cmd.response = VIRTIO_SCSI_S_OVERRUN;
 virtio_scsi_complete_cmd_req(req);
+object_unref(OBJECT(d));
 return -ENOBUFS;
 }
 scsi_req_ref(req->sreq);
 blk_io_plug(d->conf.blk);
+object_unref(OBJECT(d));
 return 0;
 }
 
-- 
2.26.2

[PATCH 08/10] scsi/scsi_bus: Add scsi_device_get

[Paolo Bonzini]

From: Maxim Levitsky 

Add scsi_device_get which finds the scsi device
and takes a reference to it.

Suggested-by: Stefan Hajnoczi 
Signed-off-by: Maxim Levitsky 
Message-Id: <20200913160259.32145-8-mlevi...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
Compared to Maxim's patch, I am avoiding the extra argument
to do_scsi_device_find by moving the RCU_READ_LOCK_GUARD()
out of do_scsi_device_find itself.

 hw/scsi/scsi-bus.c | 11 +++
 include/hw/scsi/scsi.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 7599113efe..eda8cb7e70 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -73,6 +73,17 @@ SCSIDevice *scsi_device_find(SCSIBus *bus, int channel, int 
id, int lun)
 return do_scsi_device_find(bus, channel, id, lun, false);
 }
 
+SCSIDevice *scsi_device_get(SCSIBus *bus, int channel, int id, int lun)
+{
+SCSIDevice *d;
+RCU_READ_LOCK_GUARD();
+d = do_scsi_device_find(bus, channel, id, lun, false);
+if (d) {
+object_ref(d);
+}
+return d;
+}
+
 static void scsi_device_realize(SCSIDevice *s, Error **errp)
 {
 SCSIDeviceClass *sc = SCSI_DEVICE_GET_CLASS(s);
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index 7a55cdbd74..09fa5c9d2a 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -190,6 +190,7 @@ int scsi_device_get_sense(SCSIDevice *dev, uint8_t *buf, 
int len, bool fixed);
 int scsi_SG_IO_FROM_DEV(BlockBackend *blk, uint8_t *cmd, uint8_t cmd_size,
 uint8_t *buf, uint8_t buf_size);
 SCSIDevice *scsi_device_find(SCSIBus *bus, int channel, int target, int lun);
+SCSIDevice *scsi_device_get(SCSIBus *bus, int channel, int target, int lun);
 
 /* scsi-generic.c. */
 extern const SCSIReqOps scsi_generic_req_ops;
-- 
2.26.2