Re: [PATCH v2] Makefile: Remove generated files when doing 'distclean' (and 'clean')

[Paolo Bonzini]

On 15/06/20 07:17, Thomas Huth wrote:
> That depends ... Marc-André, Paolo, what's the status of the meson patch
> series? Do you think it will be merged for the next release already? If
> so, it does not make much sense to respin my distclean patch. Otherwise
> I could do another iteration...

I prefer to aim for 5.2, making it the very first series merged there
and forcing everyone else to rebase.

Paolo

Re: [PATCH] qga: fix assert regression on guest-shutdown

[Christian Ehrhardt]

On Tue, Jun 9, 2020 at 1:15 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

>
>
> On Thu, Jun 4, 2020 at 3:43 PM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
>>
>>
>> On Thu, Jun 4, 2020 at 11:46 AM Marc-André Lureau <
>> marcandre.lur...@redhat.com> wrote:
>>
>>> Since commit 781f2b3d1e ("qga: process_event() simplification"),
>>> send_response() is called unconditionally, but will assert when "rsp" is
>>> NULL. This may happen with QCO_NO_SUCCESS_RESP commands, such as
>>> "guest-shutdown".
>>>
>>> Fixes: 781f2b3d1e5ef389b44016a897fd55e7a780bf35
>>> Cc: Michael Roth 
>>> Reported-by: Christian Ehrhardt 
>>> Signed-off-by: Marc-André Lureau 
>>> ---
>>>  qga/main.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/qga/main.c b/qga/main.c
>>> index f0e454f28d3..3febf3b0fdf 100644
>>> --- a/qga/main.c
>>> +++ b/qga/main.c
>>> @@ -531,7 +531,11 @@ static int send_response(GAState *s, const QDict
>>> *rsp)
>>>  QString *payload_qstr, *response_qstr;
>>>  GIOStatus status;
>>>
>>> -g_assert(rsp && s->channel);
>>> +g_assert(s->channel);
>>> +
>>> +if (!rsp) {
>>> +return 0;
>>> +}
>>>
>>>
>>>
>> Thanks Marc-André,
>> LGTM and should fix the issues I was seeing.
>>
>> Reviewed-by: Christian Ehrhardt 
>>
>
> In the meantime I also got to test this against the initially reported
> issue, LGTM as well (ran as no-change backport onto 4.2).
>
> Tested-by: Christian Ehrhardt 
>

This LGTM with 2*reviews 1*tested and 11 days on the list without any
negative feedback.
I just wanted to re-check if there is anything else left for this to be
committed?

[PATCH] hw/scsi/megasas: Fix possible out-of-bounds array access in tracepoints

[Thomas Huth]

Some tracepoints in megasas.c use a guest-controlled value as an index
into the mfi_frame_desc[] array. Thus a malicious guest could cause an
out-of-bounds error here. Fortunately, the impact is very low since this
can only happen when the corresponding tracepoints have been enabled
before, but the problem should be fixed anyway with a proper check.

Buglink: https://bugs.launchpad.net/qemu/+bug/1882065
Signed-off-by: Thomas Huth 
---
 hw/scsi/megasas.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index af18c88b65..aa930226f8 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -54,10 +54,6 @@
 #define MEGASAS_FLAG_USE_QUEUE64   1
 #define MEGASAS_MASK_USE_QUEUE64   (1 << MEGASAS_FLAG_USE_QUEUE64)
 
-static const char *mfi_frame_desc[] = {
-"MFI init", "LD Read", "LD Write", "LD SCSI", "PD SCSI",
-"MFI Doorbell", "MFI Abort", "MFI SMP", "MFI Stop"};
-
 typedef struct MegasasCmd {
 uint32_t index;
 uint16_t flags;
@@ -183,6 +179,20 @@ static void megasas_frame_set_scsi_status(MegasasState *s,
 stb_pci_dma(pci, frame + offsetof(struct mfi_frame_header, scsi_status), 
v);
 }
 
+static inline const char *mfi_frame_desc(unsigned int cmd)
+{
+static const char *mfi_frame_descs[] = {
+"MFI init", "LD Read", "LD Write", "LD SCSI", "PD SCSI",
+"MFI Doorbell", "MFI Abort", "MFI SMP", "MFI Stop"
+};
+
+if (cmd < ARRAY_SIZE(mfi_frame_descs)) {
+return mfi_frame_descs[cmd];
+}
+
+return "Unknown";
+}
+
 /*
  * Context is considered opaque, but the HBA firmware is running
  * in little endian mode. So convert it to little endian, too.
@@ -1670,25 +1680,25 @@ static int megasas_handle_scsi(MegasasState *s, 
MegasasCmd *cmd,
 if (is_logical) {
 if (target_id >= MFI_MAX_LD || lun_id != 0) {
 trace_megasas_scsi_target_not_present(
-mfi_frame_desc[frame_cmd], is_logical, target_id, lun_id);
+mfi_frame_desc(frame_cmd), is_logical, target_id, lun_id);
 return MFI_STAT_DEVICE_NOT_FOUND;
 }
 }
 sdev = scsi_device_find(&s->bus, 0, target_id, lun_id);
 
 cmd->iov_size = le32_to_cpu(cmd->frame->header.data_len);
-trace_megasas_handle_scsi(mfi_frame_desc[frame_cmd], is_logical,
+trace_megasas_handle_scsi(mfi_frame_desc(frame_cmd), is_logical,
   target_id, lun_id, sdev, cmd->iov_size);
 
 if (!sdev || (megasas_is_jbod(s) && is_logical)) {
 trace_megasas_scsi_target_not_present(
-mfi_frame_desc[frame_cmd], is_logical, target_id, lun_id);
+mfi_frame_desc(frame_cmd), is_logical, target_id, lun_id);
 return MFI_STAT_DEVICE_NOT_FOUND;
 }
 
 if (cdb_len > 16) {
 trace_megasas_scsi_invalid_cdb_len(
-mfi_frame_desc[frame_cmd], is_logical,
+mfi_frame_desc(frame_cmd), is_logical,
 target_id, lun_id, cdb_len);
 megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE));
 cmd->frame->header.scsi_status = CHECK_CONDITION;
@@ -1706,7 +1716,7 @@ static int megasas_handle_scsi(MegasasState *s, 
MegasasCmd *cmd,
 cmd->req = scsi_req_new(sdev, cmd->index, lun_id, cdb, cmd);
 if (!cmd->req) {
 trace_megasas_scsi_req_alloc_failed(
-mfi_frame_desc[frame_cmd], target_id, lun_id);
+mfi_frame_desc(frame_cmd), target_id, lun_id);
 megasas_write_sense(cmd, SENSE_CODE(NO_SENSE));
 cmd->frame->header.scsi_status = BUSY;
 s->event_count++;
@@ -1751,17 +1761,17 @@ static int megasas_handle_io(MegasasState *s, 
MegasasCmd *cmd, int frame_cmd)
 }
 
 trace_megasas_handle_io(cmd->index,
-mfi_frame_desc[frame_cmd], target_id, lun_id,
+mfi_frame_desc(frame_cmd), target_id, lun_id,
 (unsigned long)lba_start, (unsigned 
long)lba_count);
 if (!sdev) {
 trace_megasas_io_target_not_present(cmd->index,
-mfi_frame_desc[frame_cmd], target_id, lun_id);
+mfi_frame_desc(frame_cmd), target_id, lun_id);
 return MFI_STAT_DEVICE_NOT_FOUND;
 }
 
 if (cdb_len > 16) {
 trace_megasas_scsi_invalid_cdb_len(
-mfi_frame_desc[frame_cmd], 1, target_id, lun_id, cdb_len);
+mfi_frame_desc(frame_cmd), 1, target_id, lun_id, cdb_len);
 megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE));
 cmd->frame->header.scsi_status = CHECK_CONDITION;
 s->event_count++;
@@ -1781,7 +1791,7 @@ static int megasas_handle_io(MegasasState *s, MegasasCmd 
*cmd, int frame_cmd)
 lun_id, cdb, cmd);
 if (!cmd->req) {
 trace_megasas_scsi_req_alloc_failed(
-mfi_frame_desc[frame_cmd], target_id, lun_id);
+mfi_frame_desc(frame_cmd), target_id, lun_id);
 megasas_write_sense(cmd, SENSE_C

Re: [PATCH v2] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Thomas Huth]

On 15/06/2020 08.57, Philippe Mathieu-Daudé wrote:
> The git-submodule.sh script is called by make and initialize the
> submodules listed in the GIT_SUBMODULES variable generated by
> ./configure.
> 
> Add SLOF when we build the ppc64-softmmu target for the pSeries
> machines (which use SLOF). This fixes:
> 
>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
> path 'roms/SLOF'
>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
> resolve host: git.qemu.org
>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
> '/home/travis/build/user/qemu/roms/SLOF' failed
>   Failed to clone 'roms/SLOF'. Retry scheduled
>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
> resolve host: git.qemu.org
>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
> '/home/travis/build/user/qemu/roms/SLOF' failed
>   Failed to clone 'roms/SLOF' a second time, aborting
>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
> exited with 1.
> 
> Reported-by: Mark Cave-Ayland 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> CI: https://travis-ci.org/github/philmd/qemu/jobs/698406512#L1596
> ---
>  configure   | 12 
>  .travis.yml |  1 -
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 7c2adf36e5..f297a4b68f 100755
> --- a/configure
> +++ b/configure
> @@ -2248,6 +2248,18 @@ if test "$edk2_blobs" = "yes" && ! has bzip2; then
>error_exit "The bzip2 program is required for building QEMU"
>  fi
>  
> +###
> +# SLOF is mandatory for the pSeries
> +for target in $target_list; do
> +  case $target in
> +ppc64-softmmu)

I know it's confusing, but actually, SLOF is not required for building
ppc64-softmmu. It's required for building the s390-ccw firmware on
s390x, since it is using the libnet code from SLOF for network booting.
And that can only be built right now when we're on a s390x host and GCC
is installed.

There is already a check in configure (look for "Only build s390-ccw
bios" ...), so I'd suggest that you add the git_submodules line there
instead.

 Thanks,
  Thomas


> +  if test -e "${source_path}/.git" ; then
> +  git_submodules="${git_submodules} roms/SLOF"
> +  fi
> +;;
> +  esac
> +done
> +
>  feature_not_found() {
>feature=$1
>remedy=$2
> diff --git a/.travis.yml b/.travis.yml
> index ec6367af1f..220855c1f0 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -496,7 +496,6 @@ jobs:
>  - CONFIG="--disable-containers 
> --target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
>  - UNRELIABLE=true
>script:
> -- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>  - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
>  - |
>if [ "$BUILD_RC" -eq 0 ] ; then
> 

Re: [PATCH v8 00/10] accel: Allow targets to use Kconfig

[Philippe Mathieu-Daudé]

Hi Paolo,

FYI this series applies cleanly on current master
(7d3660e798 merging your for-upstream 3575b0aea9).

On 6/8/20 6:38 PM, Philippe Mathieu-Daudé wrote:
> Missing review:
> - 03/10 MAINTAINERS: Cover the HAX accelerator stub
> - 04/10 configure: Generate rule to calculate base arch of target
> 
> This series include generic patches I took of the KVM/ARM
> specific series which will follow.
> 
> - Update accelerators in MAINTAINERS
> - Add accel/Kconfig
> - Allow targets to use their how Kconfig
> 
> Since v7:
> - Generate base-arch() (Alex)
> - Do not deprecate HAXM
> 
> Since v6:
> - Fixed typo 'startwith' -> 'startswith' (armbru)
> 
> Since v5:
> - Fixed typo in patch #4 subject
> - Added David R-b tag
> - Stripped --- comments
> 
> Since v4:
> - Addressed rth review comments in rules.mak
> 
> Since v3:
> - Fixed base-arch() rule (rth)
> - Dropped 'semihosting: Make the feature depend of TCG'
> 
> Since v2:
> - Addressed Thomas review comments
> - Fixed problem when including TARGET instead of BASE_TARGET
> 
> Since v1:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg689024.html
> - Drop HVF MAINTAINERS patch (merged elsewhere)
> - Kconfig-select SEMIHOSTING (bonzini)
> - Drop user-mode selection patches
> - consider m68k/nios2/xtensa/riscv (pm215)
> - reword Kconfig SEMIHOSTING description (pm215)
> - reset some of rth R-b tags
> 
> Previous RFC for semihosting posted earlier:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg631218.html
> 
> Alex Bennée (1):
>   configure: Generate rule to calculate the base architecture of a
> target
> 
> Philippe Mathieu-Daudé (9):
>   MAINTAINERS: Fix KVM path expansion glob
>   MAINTAINERS: Add an 'overall' entry for accelerators
>   MAINTAINERS: Cover the HAX accelerator stub
>   Makefile: Remove dangerous EOL trailing backslash
>   Makefile: Write MINIKCONF variables as one entry per line
>   accel/Kconfig: Extract accel selectors into their own config
>   accel/Kconfig: Add the TCG selector
>   Makefile: Allow target-specific optional Kconfig
>   accel/tcg: Add stub for probe_access()
> 
>  configure  | 19 +++
>  Makefile   | 15 +++
>  accel/stubs/tcg-stub.c |  7 +++
>  Kconfig.host   |  7 ---
>  MAINTAINERS| 14 +-
>  accel/Kconfig  |  9 +
>  6 files changed, 59 insertions(+), 12 deletions(-)
>  create mode 100644 accel/Kconfig
> 

Re: [PATCH] linux-user: mremap fails with EFAULT if address range overlaps with stack guard

[Tobias Koch]

Hi Laurent,

the code in musl libc probing the stack is in

    https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c

The setup in elfload.c does work, but only when reserved_va is not set. In that 
case, any stack guard violation is
handled by the host kernel and thus results in the expected EFAULT.

However, in case of e.g. a 32bit target being emulated on a 64bit host, 
reserved_va is set and the current code in
mmap.c will only produce a more generic ENOMEM, deviating from the kernel's 
behavior.


On 5/7/20 5:35 PM, Laurent Vivier wrote:
> Le 05/03/2020 à 22:05, Tobias Koch a écrit :
>> If the address range starting at old_address overlaps with the stack guard it
>> is invalid and mremap must fail with EFAULT. The musl c library relies on 
>> this
>> behavior to detect the stack size, which it does by doing consecutive mremaps
>> until it hits the stack guard. Without this patch, software (such as the Ruby
>> interpreter) that calls pthread_getattr_np under musl will crash on 32 bit
>> targets emulated on a 64 bit host.
> Could you share some pointers to the code that is doing this?
>
> We have already this kind of code in linux-user/elfload.c,
> setup_arg_pages(): could you check why it doesn't work?
>
> Thanks,
> Laurent

Re: [PATCH v3 00/11] hw/sd/sdcard: Fix CVE-2020-13253 & cleanups

[Philippe Mathieu-Daudé]

On 6/5/20 12:22 PM, Philippe Mathieu-Daudé wrote:
> Patches 2 & 3 fix CVE-2020-13253.

Ping for the CVE fix?...

> The rest are (accumulated) cleanups.
> 
> Supersedes: <20200604182502.24228-1-f4...@amsat.org>
> 
> Philippe Mathieu-Daudé (11):
>   MAINTAINERS: Cc qemu-block mailing list
>   hw/sd/sdcard: Update coding style to make checkpatch.pl happy
>   hw/sd/sdcard: Do not switch to ReceivingData if address is invalid
>   hw/sd/sdcard: Restrict Class 6 commands to SCSD cards
>   hw/sd/sdcard: Update the SDState documentation
>   hw/sd/sdcard: Simplify cmd_valid_while_locked()
>   hw/sd/sdcard: Constify sd_crc*()'s message argument
>   hw/sd/sdcard: Make iolen unsigned
>   hw/sd/sdcard: Correctly display the command name in trace events
>   hw/sd/sdcard: Display offset in read/write_data() trace events
>   hw/sd/sdcard: Simplify realize() a bit
> 
>  hw/sd/sd.c | 122 +
>  MAINTAINERS|   1 +
>  hw/sd/trace-events |   4 +-
>  3 files changed, 83 insertions(+), 44 deletions(-)
> 

Re: [PATCH] hw/scsi/megasas: Fix possible out-of-bounds array access in tracepoints

[Philippe Mathieu-Daudé]

On 6/15/20 9:26 AM, Thomas Huth wrote:
> Some tracepoints in megasas.c use a guest-controlled value as an index
> into the mfi_frame_desc[] array. Thus a malicious guest could cause an
> out-of-bounds error here. Fortunately, the impact is very low since this
> can only happen when the corresponding tracepoints have been enabled
> before, but the problem should be fixed anyway with a proper check.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1882065
> Signed-off-by: Thomas Huth 
> ---
>  hw/scsi/megasas.c | 36 +++-
>  1 file changed, 23 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
> index af18c88b65..aa930226f8 100644
> --- a/hw/scsi/megasas.c
> +++ b/hw/scsi/megasas.c
> @@ -54,10 +54,6 @@
>  #define MEGASAS_FLAG_USE_QUEUE64   1
>  #define MEGASAS_MASK_USE_QUEUE64   (1 << MEGASAS_FLAG_USE_QUEUE64)
>  
> -static const char *mfi_frame_desc[] = {
> -"MFI init", "LD Read", "LD Write", "LD SCSI", "PD SCSI",
> -"MFI Doorbell", "MFI Abort", "MFI SMP", "MFI Stop"};
> -
>  typedef struct MegasasCmd {
>  uint32_t index;
>  uint16_t flags;
> @@ -183,6 +179,20 @@ static void megasas_frame_set_scsi_status(MegasasState 
> *s,
>  stb_pci_dma(pci, frame + offsetof(struct mfi_frame_header, scsi_status), 
> v);
>  }
>  
> +static inline const char *mfi_frame_desc(unsigned int cmd)
> +{
> +static const char *mfi_frame_descs[] = {
> +"MFI init", "LD Read", "LD Write", "LD SCSI", "PD SCSI",
> +"MFI Doorbell", "MFI Abort", "MFI SMP", "MFI Stop"
> +};
> +
> +if (cmd < ARRAY_SIZE(mfi_frame_descs)) {
> +return mfi_frame_descs[cmd];
> +}
> +
> +return "Unknown";
> +}
> +
>  /*
>   * Context is considered opaque, but the HBA firmware is running
>   * in little endian mode. So convert it to little endian, too.
> @@ -1670,25 +1680,25 @@ static int megasas_handle_scsi(MegasasState *s, 
> MegasasCmd *cmd,
>  if (is_logical) {
>  if (target_id >= MFI_MAX_LD || lun_id != 0) {
>  trace_megasas_scsi_target_not_present(
> -mfi_frame_desc[frame_cmd], is_logical, target_id, lun_id);
> +mfi_frame_desc(frame_cmd), is_logical, target_id, lun_id);
>  return MFI_STAT_DEVICE_NOT_FOUND;
>  }
>  }
>  sdev = scsi_device_find(&s->bus, 0, target_id, lun_id);
>  
>  cmd->iov_size = le32_to_cpu(cmd->frame->header.data_len);
> -trace_megasas_handle_scsi(mfi_frame_desc[frame_cmd], is_logical,
> +trace_megasas_handle_scsi(mfi_frame_desc(frame_cmd), is_logical,
>target_id, lun_id, sdev, cmd->iov_size);
>  
>  if (!sdev || (megasas_is_jbod(s) && is_logical)) {
>  trace_megasas_scsi_target_not_present(
> -mfi_frame_desc[frame_cmd], is_logical, target_id, lun_id);
> +mfi_frame_desc(frame_cmd), is_logical, target_id, lun_id);
>  return MFI_STAT_DEVICE_NOT_FOUND;
>  }
>  
>  if (cdb_len > 16) {
>  trace_megasas_scsi_invalid_cdb_len(
> -mfi_frame_desc[frame_cmd], is_logical,
> +mfi_frame_desc(frame_cmd), is_logical,
>  target_id, lun_id, cdb_len);
>  megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE));
>  cmd->frame->header.scsi_status = CHECK_CONDITION;
> @@ -1706,7 +1716,7 @@ static int megasas_handle_scsi(MegasasState *s, 
> MegasasCmd *cmd,
>  cmd->req = scsi_req_new(sdev, cmd->index, lun_id, cdb, cmd);
>  if (!cmd->req) {
>  trace_megasas_scsi_req_alloc_failed(
> -mfi_frame_desc[frame_cmd], target_id, lun_id);
> +mfi_frame_desc(frame_cmd), target_id, lun_id);
>  megasas_write_sense(cmd, SENSE_CODE(NO_SENSE));
>  cmd->frame->header.scsi_status = BUSY;
>  s->event_count++;
> @@ -1751,17 +1761,17 @@ static int megasas_handle_io(MegasasState *s, 
> MegasasCmd *cmd, int frame_cmd)
>  }
>  
>  trace_megasas_handle_io(cmd->index,
> -mfi_frame_desc[frame_cmd], target_id, lun_id,
> +mfi_frame_desc(frame_cmd), target_id, lun_id,
>  (unsigned long)lba_start, (unsigned 
> long)lba_count);
>  if (!sdev) {
>  trace_megasas_io_target_not_present(cmd->index,
> -mfi_frame_desc[frame_cmd], target_id, lun_id);
> +mfi_frame_desc(frame_cmd), target_id, lun_id);
>  return MFI_STAT_DEVICE_NOT_FOUND;
>  }
>  
>  if (cdb_len > 16) {
>  trace_megasas_scsi_invalid_cdb_len(
> -mfi_frame_desc[frame_cmd], 1, target_id, lun_id, cdb_len);
> +mfi_frame_desc(frame_cmd), 1, target_id, lun_id, cdb_len);
>  megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE));
>  cmd->frame->header.scsi_status = CHECK_CONDITION;
>  s->event_count++;
> @@ -1781,7 +1791,7 @@ static int megasas_handle_io(MegasasState *s, 
> MegasasCmd *cmd, int frame_cmd)
>

Re: [PATCH 1/4] migration/savevm: respect qemu_fclose() error code in save_snapshot()

[Vladimir Sementsov-Ogievskiy]

11.06.2020 20:11, Denis V. Lunev wrote:

qemu_fclose() could return error, f.e. if bdrv_co_flush() will return
the error.

This validation will become more important once we will start waiting of
asynchronous IO operations, started from bdrv_write_vmstate(), which are
coming soon.

Signed-off-by: Denis V. Lunev
CC: Kevin Wolf
CC: Max Reitz
CC: Stefan Hajnoczi
CC: Fam Zheng
CC: Juan Quintela
CC: "Dr. David Alan Gilbert"
CC: Vladimir Sementsov-Ogievskiy
CC: Denis Plotnikov


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

[Bug 1883414] Re: Cannot build qemu-5.0.0 from tarball

[Thomas Huth]

Where did you download the tarball from?

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

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

Title:
  Cannot build qemu-5.0.0 from tarball

Status in QEMU:
  Incomplete

Bug description:
  Cannot build qemu 5.0.0 from the release tarball. Building from git-
  clone succeeds.

  After downloading and unpacking the 5.0.0 tarball, I typed the
  following:

  mkdir build
  cd build
  ../configure

  Then got the following error message:

  ERROR: missing file /home/uri/qemu-5.0.0/ui/keycodemapdb/README

  This is not a GIT checkout but module content appears to
  be missing. Do not use 'git archive' or GitHub download links
  to acquire QEMU source archives. Non-GIT builds are only
  supported with source archives linked from:

https://www.qemu.org/download/#source

  Developers working with GIT can use scripts/archive-source.sh
  if they need to create valid source archives.

  It appears the ui/keycodemapdb is missing some files that are obtained
  from a git submodule in a git tree.

  Building from a git clone succeeds.

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

Re: [PATCH v2] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Philippe Mathieu-Daudé]

On 6/15/20 9:31 AM, Thomas Huth wrote:
> On 15/06/2020 08.57, Philippe Mathieu-Daudé wrote:
>> The git-submodule.sh script is called by make and initialize the
>> submodules listed in the GIT_SUBMODULES variable generated by
>> ./configure.
>>
>> Add SLOF when we build the ppc64-softmmu target for the pSeries
>> machines (which use SLOF). This fixes:
>>
>>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
>> path 'roms/SLOF'
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF'. Retry scheduled
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF' a second time, aborting
>>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
>> exited with 1.
>>
>> Reported-by: Mark Cave-Ayland 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> CI: https://travis-ci.org/github/philmd/qemu/jobs/698406512#L1596
>> ---
>>  configure   | 12 
>>  .travis.yml |  1 -
>>  2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 7c2adf36e5..f297a4b68f 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2248,6 +2248,18 @@ if test "$edk2_blobs" = "yes" && ! has bzip2; then
>>error_exit "The bzip2 program is required for building QEMU"
>>  fi
>>  
>> +###
>> +# SLOF is mandatory for the pSeries
>> +for target in $target_list; do
>> +  case $target in
>> +ppc64-softmmu)
> 
> I know it's confusing, but actually, SLOF is not required for building
> ppc64-softmmu. It's required for building the s390-ccw firmware on
> s390x, since it is using the libnet code from SLOF for network booting.
> And that can only be built right now when we're on a s390x host and GCC
> is installed.
> 
> There is already a check in configure (look for "Only build s390-ccw
> bios" ...), so I'd suggest that you add the git_submodules line there
> instead.

I'v been looking at that and got confuse indeed, in particular because
only the s390x container has this failure, but SLOF documentation only
comments pSeries.

Will respin.

> 
>  Thanks,
>   Thomas
> 
> 
>> +  if test -e "${source_path}/.git" ; then
>> +  git_submodules="${git_submodules} roms/SLOF"
>> +  fi
>> +;;
>> +  esac
>> +done
>> +
>>  feature_not_found() {
>>feature=$1
>>remedy=$2
>> diff --git a/.travis.yml b/.travis.yml
>> index ec6367af1f..220855c1f0 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -496,7 +496,6 @@ jobs:
>>  - CONFIG="--disable-containers 
>> --target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
>>  - UNRELIABLE=true
>>script:
>> -- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>  - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
>>  - |
>>if [ "$BUILD_RC" -eq 0 ] ; then
>>
> 

Re: [PATCH v2] Makefile: Remove generated files when doing 'distclean' (and 'clean')

[Thomas Huth]

On 15/06/2020 09.13, Paolo Bonzini wrote:
> On 15/06/20 07:17, Thomas Huth wrote:
>> That depends ... Marc-André, Paolo, what's the status of the meson patch
>> series? Do you think it will be merged for the next release already? If
>> so, it does not make much sense to respin my distclean patch. Otherwise
>> I could do another iteration...
> 
> I prefer to aim for 5.2, making it the very first series merged there
> and forcing everyone else to rebase.

Ok, so I think it's likely really not worth the effort to respin this
rather cosmetic patch just for one single release.

Aleksandar, I won't work on this patch anymore, but if it is still
important for you, feel free to take the patch and send an updated version.

 Thomas

Re: [PATCH v2] hmp: Make json format optional for qom-set

[David Hildenbrand]

On 15.06.20 08:17, Markus Armbruster wrote:
> David Hildenbrand  writes:
> 
>> Commit 7d2ef6dcc1cf ("hmp: Simplify qom-set") switched to the json
>> parser, making it possible to specify complex types. However, with this
>> change it is no longer possible to specify proper sizes (e.g., 2G, 128M),
>> turning the interface harder to use for properties that consume sizes.
>>
>> Let's switch back to the previous handling and allow to specify passing
>> json via the "-j" parameter.
> 
> Two issues:
> 
> 1. Makes qom-get and qom-set inconsistent
> 
>qom-get formats as JSON, always.
> 
>qom-set parses the string visitor's undocumented ad hoc language by
>default.  You can make it parse JSON by passing -j.

This is the same language the QEMU cmdline uses, no?

> 
>Not a show stopper, but sure ugly.  I feel documentation should point
>it out.

Sure, we can fine-tune the documentation. For now we didn't have any
qom-get users, in contrast to qom-set. Not sure if it makes sense to
implement the same functionality for qom-get.

For now I can e.g.,

"echo "qom-set vm1 requested-size 256M" | sudo nc -U /var/tmp/mon_src"

then I can

echo "qom-get vm1 requested-size " | sudo nc -U /var/tmp/mon_src
-> 268435456

which is a value I can punch back into qom-set. At least for sizes this
works. Not perfect, not bad. Opinions?


> 
> 2. Rearms the string visitor death trap
> 
>If you try to qom-set a property whose ->set() uses something the
>string input visitor doesn't support, QEMU crashes.  I'm not aware of
>such a ->set(), but this is a death trap all the same.  Mind, I
>didn't actually *look* for such a ->set().  Details:

Thanks. Maybe I am missing something important, but this sounds like we
are missing a bunch of checks+errors. (wouldn't we be able to crash
using the QEMU cmdline as well when setting such properties?).

> 
> Subject: Re: [RFC PATCH] qom: Implement qom-get HMP command
> Date: Sat, 02 May 2020 08:02:43 +0200 (6 weeks, 2 days, 4 minutes ago)
> Message-ID: <87a72q6fi4@dusky.pond.sub.org>
> https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg00178.html
> 
>Since we've had this death trap in the code for a number of years, I
>can't call its restoration a show stopper.  It does feel like an
>unadvisable risk, though.
> 

As long as there are no better alternatives to punch in data in the same
format the QEMU cmdline consumes, I think this is perfectly reasonable.
No good reason to make a HMP interface harder to use by humans IMHO.

Thanks!

-- 
Thanks,

David / dhildenb

Re: [PATCH 2/4] block/aio_task: allow start/wait task from any coroutine

[Vladimir Sementsov-Ogievskiy]

11.06.2020 20:11, Denis V. Lunev wrote:

From: Vladimir Sementsov-Ogievskiy 

Currently, aio task pool assumes that there is a main coroutine, which
creates tasks and wait for them. Let's remove the restriction by using
CoQueue. Code becomes clearer, interface more obvious.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Denis V. Lunev 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Vladimir Sementsov-Ogievskiy 
CC: Denis Plotnikov 
---
  block/aio_task.c | 21 ++---
  1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/block/aio_task.c b/block/aio_task.c
index 88989fa248..cf62e5c58b 100644
--- a/block/aio_task.c
+++ b/block/aio_task.c
@@ -27,11 +27,10 @@
  #include "block/aio_task.h"
  
  struct AioTaskPool {

-Coroutine *main_co;
  int status;
  int max_busy_tasks;
  int busy_tasks;
-bool waiting;
+CoQueue waiters;
  };
  
  static void coroutine_fn aio_task_co(void *opaque)

@@ -52,31 +51,23 @@ static void coroutine_fn aio_task_co(void *opaque)
  
  g_free(task);
  
-if (pool->waiting) {

-pool->waiting = false;
-aio_co_wake(pool->main_co);
-}
+qemu_co_queue_restart_all(&pool->waiters);
  }
  
  void coroutine_fn aio_task_pool_wait_one(AioTaskPool *pool)

  {
  assert(pool->busy_tasks > 0);
-assert(qemu_coroutine_self() == pool->main_co);
  
-pool->waiting = true;

-qemu_coroutine_yield();
+qemu_co_queue_wait(&pool->waiters, NULL);
  
-assert(!pool->waiting);

  assert(pool->busy_tasks < pool->max_busy_tasks);


As we wake up several coroutines now, I'm afraid this assertion may start to 
fire.
And aio_task_pool_wait_one() becomes useless as a public API (still, it's used 
only locally, so we can make it static).

I'll send updated patch after reviewing the rest of the series.


  }
  
  void coroutine_fn aio_task_pool_wait_slot(AioTaskPool *pool)

  {
-if (pool->busy_tasks < pool->max_busy_tasks) {
-return;
+while (pool->busy_tasks >= pool->max_busy_tasks) {
+aio_task_pool_wait_one(pool);
  }
-
-aio_task_pool_wait_one(pool);
  }
  
  void coroutine_fn aio_task_pool_wait_all(AioTaskPool *pool)

@@ -98,8 +89,8 @@ AioTaskPool *coroutine_fn aio_task_pool_new(int 
max_busy_tasks)
  {
  AioTaskPool *pool = g_new0(AioTaskPool, 1);
  
-pool->main_co = qemu_coroutine_self();

  pool->max_busy_tasks = max_busy_tasks;
+qemu_co_queue_init(&pool->waiters);
  
  return pool;

  }




--
Best regards,
Vladimir

[PATCH v3] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Philippe Mathieu-Daudé]

The git-submodule.sh script is called by make and initialize the
submodules listed in the GIT_SUBMODULES variable generated by
./configure.

SLOF is required for building the s390-ccw firmware on s390x, since
it is using the libnet code from SLOF for network booting.

Add it to the GIT_SUBMODULES when buildint the s390-ccw firmware,
to fix:

  $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
  Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for path 
'roms/SLOF'
  Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
  fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
resolve host: git.qemu.org
  fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
'/home/travis/build/user/qemu/roms/SLOF' failed
  Failed to clone 'roms/SLOF'. Retry scheduled
  Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
  fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
resolve host: git.qemu.org
  fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
'/home/travis/build/user/qemu/roms/SLOF' failed
  Failed to clone 'roms/SLOF' a second time, aborting
  The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
exited with 1.

Reported-by: Mark Cave-Ayland 
Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 configure   | 5 +
 .travis.yml | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index bb7fd12612..927e4a3d06 100755
--- a/configure
+++ b/configure
@@ -6533,6 +6533,11 @@ if test "$cpu" = "s390x" ; then
   write_c_skeleton
   if compile_prog "-march=z900" ""; then
 roms="$roms s390-ccw"
+# SLOF is required for building the s390-ccw firmware on s390x,
+# since it is using the libnet code from SLOF for network booting.
+if test -e "${source_path}/.git" ; then
+  git_submodules="${git_submodules} roms/SLOF"
+fi
   fi
 fi
 
diff --git a/.travis.yml b/.travis.yml
index ec6367af1f..220855c1f0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -496,7 +496,6 @@ jobs:
 - CONFIG="--disable-containers 
--target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
 - UNRELIABLE=true
   script:
-- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
 - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
 - |
   if [ "$BUILD_RC" -eq 0 ] ; then
-- 
2.21.3

Re: [PATCH 3/4] block, migration: add bdrv_flush_vmstate helper

[Vladimir Sementsov-Ogievskiy]

11.06.2020 20:11, Denis V. Lunev wrote:

Right now bdrv_fclose() is just calling bdrv_flush().

The problem is that migration code is working inefficently from black
layer terms and are frequently called for very small pieces of not
properly aligned data. Block layer is capable to work this way, but
this is very slow.

This patch is a preparation for the introduction of the intermediate
buffer at block driver state. It would be beneficial to separate
conventional bdrv_flush() from closing QEMU file from migration code.

The patch also forces bdrv_flush_vmstate() operation inside
synchronous blk_save_vmstate() operation. This helper is used from
qemu-io only.

Signed-off-by: Denis V. Lunev 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Vladimir Sementsov-Ogievskiy 
CC: Denis Plotnikov 
---
  block/block-backend.c |  6 +-
  block/io.c| 39 +++
  include/block/block.h |  1 +
  migration/savevm.c|  3 +++
  4 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/block/block-backend.c b/block/block-backend.c
index 9342a475cb..2107ace699 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -2177,7 +2177,7 @@ int blk_truncate(BlockBackend *blk, int64_t offset, bool 
exact,
  int blk_save_vmstate(BlockBackend *blk, const uint8_t *buf,
   int64_t pos, int size)
  {
-int ret;
+int ret, ret2;
  
  if (!blk_is_available(blk)) {

  return -ENOMEDIUM;
@@ -2187,6 +2187,10 @@ int blk_save_vmstate(BlockBackend *blk, const uint8_t 
*buf,
  if (ret < 0) {
  return ret;
  }
+ret2 = bdrv_flush_vmstate(blk_bs(blk));
+if (ret2 < 0) {
+return ret;
+}
  
  if (ret == size && !blk->enable_write_cache) {

  ret = bdrv_flush(blk_bs(blk));
diff --git a/block/io.c b/block/io.c
index 121ce17a49..fbf352f39d 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2725,6 +2725,45 @@ int bdrv_readv_vmstate(BlockDriverState *bs, 
QEMUIOVector *qiov, int64_t pos)
  return bdrv_rw_vmstate(bs, qiov, pos, true);
  }
  
+

+typedef struct FlushVMStateCo {
+BlockDriverState *bs;
+int ret;
+} FlushVMStateCo;
+
+static int coroutine_fn bdrv_co_flush_vmstate(BlockDriverState *bs)
+{
+return 0;
+}
+
+static void coroutine_fn bdrv_flush_vmstate_co_entry(void *opaque)
+{
+FlushVMStateCo *rwco = opaque;
+
+rwco->ret = bdrv_co_flush_vmstate(rwco->bs);
+aio_wait_kick();
+}
+
+int bdrv_flush_vmstate(BlockDriverState *bs)
+{
+Coroutine *co;
+FlushVMStateCo flush_co = {
+.bs = bs,
+.ret = NOT_DONE,
+};
+
+if (qemu_in_coroutine()) {
+/* Fast-path if already in coroutine context */
+bdrv_flush_vmstate_co_entry(&flush_co);
+} else {
+co = qemu_coroutine_create(bdrv_flush_vmstate_co_entry, &flush_co);
+bdrv_coroutine_enter(bs, co);
+BDRV_POLL_WHILE(bs, flush_co.ret == NOT_DONE);
+}
+
+return flush_co.ret;
+}


In block/io.c, since 7d2410cea154bf, these coroutine wrappers are using 
bdrv_run_co() instead.
I hope, it's an intermediate state, and my series with auto-generated wrappers 
will be applied, still, now we should use bdrv_run_co()-based approach for 
consistency.

Otherwise, patch looks OK for me, just add a new interface, doing nothing for 
now. Still, would be good to add a comment in block.h, that bdrv_flush_vmsate 
is needed after bdrv_save_vmstate.


+
  /**/
  /* async I/Os */
  
diff --git a/include/block/block.h b/include/block/block.h

index 25e299605e..024525b87d 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -572,6 +572,7 @@ int bdrv_save_vmstate(BlockDriverState *bs, const uint8_t 
*buf,
  
  int bdrv_load_vmstate(BlockDriverState *bs, uint8_t *buf,

int64_t pos, int size);
+int bdrv_flush_vmstate(BlockDriverState *bs);
  
  void bdrv_img_create(const char *filename, const char *fmt,

   const char *base_filename, const char *base_fmt,
diff --git a/migration/savevm.c b/migration/savevm.c
index 0ff5bb40ed..9698c909d7 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -150,6 +150,9 @@ static ssize_t block_get_buffer(void *opaque, uint8_t *buf, 
int64_t pos,
  
  static int bdrv_fclose(void *opaque, Error **errp)

  {
+int err = bdrv_flush_vmstate(opaque);
+if (err < 0)
+return err;
  return bdrv_flush(opaque);
  }
  




--
Best regards,
Vladimir

Re: [PATCH v2 1/2] qemu-options.hx: Mark all hmat-cache attributes required

[Markus Armbruster]

Cc: the people involved in commit c412a48d4d "numa: Extend CLI to
provide memory side cache information".

Michal Privoznik  writes:

> The documentation to `-numa hmat-cache` says that @node-id, @size
> and @level are the only required attributes. The rest
> (@associativity, @policy and @line) is optional. Well, not quite
> - if I try to start QEMU with only the three required attributes
> defined the QAPI code is complaining about associativity missing.

Only because @associativity visited first.

> According to QAPI all attributes are required. Make the docs
> reflect that.

Correct.

> Signed-off-by: Michal Privoznik 
> ---
>  qemu-options.hx | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 93bde2bbc8..b1a399079a 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -188,7 +188,7 @@ DEF("numa", HAS_ARG, QEMU_OPTION_numa,
>  "-numa dist,src=source,dst=destination,val=distance\n"
>  "-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n"
>  "-numa 
> hmat-lb,initiator=node,target=node,hierarchy=memory|first-level|second-level|third-level,data-type=access-latency|read-latency|write-latency[,latency=lat][,bandwidth=bw]\n"
> -"-numa 
> hmat-cache,node-id=node,size=size,level=level[,associativity=none|direct|complex][,policy=none|write-back|write-through][,line=size]\n",
> +"-numa 
> hmat-cache,node-id=node,size=size,level=level,associativity=none|direct|complex,policy=none|write-back|write-through,line=size\n",
>  QEMU_ARCH_ALL)
>  SRST
>  ``-numa 
> node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``
> @@ -201,7 +201,7 @@ SRST
>\ 
>  ``-numa 
> hmat-lb,initiator=node,target=node,hierarchy=hierarchy,data-type=tpye[,latency=lat][,bandwidth=bw]``
>\ 
> -``-numa 
> hmat-cache,node-id=node,size=size,level=level[,associativity=str][,policy=str][,line=size]``
> +``-numa 
> hmat-cache,node-id=node,size=size,level=level,associativity=str,policy=str,line=size``
>  Define a NUMA node and assign RAM and VCPUs to it. Set the NUMA
>  distance from a source node to a destination node. Set the ACPI
>  Heterogeneous Memory Attributes for the given nodes.

Assuming non-optional is what we want:
Reviewed-by: Markus Armbruster 

Re: [PATCH v2 2/2] qemu-options.hx: Document hmat-lb and hmat-cache order

[Markus Armbruster]

Michal Privoznik  writes:

> To simplify internal implementation the hmat-cache parsing code
> expects hmat-lb to be already parsed. This means, that hmat-lb
> arguments must come before hmat-cache. Document this restriction
> so that management applications can follow it.
>
> Signed-off-by: Michal Privoznik 
> ---
>  qemu-options.hx | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index b1a399079a..3fe9e6d6a0 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -319,6 +319,9 @@ SRST
>  'none/direct(direct-mapped)/complex(complex cache indexing)'. policy
>  is the write policy. line is the cache Line size in bytes.
>  
> +Please note, that due to internal implementation, '\ ``hmat-cache``\ '
> +must be configured only after '\ ``hmat-lb``\ ' option.
> +
>  For example, the following options describe 2 NUMA nodes. Node 0 has
>  2 cpus and a ram, node 1 has only a ram. The processors in node 0
>  access memory in node 0 with access-latency 5 nanoseconds,

What happens when we do it wrong?

Can we catch doing it wrong somehow?  I figure that would be much better
than merely documenting it.

Re: [PATCH v3] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Thomas Huth]

On 15/06/2020 09.49, Philippe Mathieu-Daudé wrote:
> The git-submodule.sh script is called by make and initialize the
> submodules listed in the GIT_SUBMODULES variable generated by
> ./configure.
> 
> SLOF is required for building the s390-ccw firmware on s390x, since
> it is using the libnet code from SLOF for network booting.
> 
> Add it to the GIT_SUBMODULES when buildint the s390-ccw firmware,

s/buildint/building/

> to fix:
> 
>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
> path 'roms/SLOF'
>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
> resolve host: git.qemu.org
>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
> '/home/travis/build/user/qemu/roms/SLOF' failed
>   Failed to clone 'roms/SLOF'. Retry scheduled
>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
> resolve host: git.qemu.org
>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
> '/home/travis/build/user/qemu/roms/SLOF' failed
>   Failed to clone 'roms/SLOF' a second time, aborting
>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
> exited with 1.

I still somehow doubt that this will really fix the issue that you've
seen here (why should it matter where the submodule is checked out?),
but the patch is a good idea anyway, so:

Reviewed-by: Thomas Huth 


> Reported-by: Mark Cave-Ayland 
> Suggested-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  configure   | 5 +
>  .travis.yml | 1 -
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index bb7fd12612..927e4a3d06 100755
> --- a/configure
> +++ b/configure
> @@ -6533,6 +6533,11 @@ if test "$cpu" = "s390x" ; then
>write_c_skeleton
>if compile_prog "-march=z900" ""; then
>  roms="$roms s390-ccw"
> +# SLOF is required for building the s390-ccw firmware on s390x,
> +# since it is using the libnet code from SLOF for network booting.
> +if test -e "${source_path}/.git" ; then
> +  git_submodules="${git_submodules} roms/SLOF"
> +fi
>fi
>  fi
>  
> diff --git a/.travis.yml b/.travis.yml
> index ec6367af1f..220855c1f0 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -496,7 +496,6 @@ jobs:
>  - CONFIG="--disable-containers 
> --target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
>  - UNRELIABLE=true
>script:
> -- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>  - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
>  - |
>if [ "$BUILD_RC" -eq 0 ] ; then
> 

Re: [PATCH v3] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Philippe Mathieu-Daudé]

On 6/15/20 10:13 AM, Thomas Huth wrote:
> On 15/06/2020 09.49, Philippe Mathieu-Daudé wrote:
>> The git-submodule.sh script is called by make and initialize the
>> submodules listed in the GIT_SUBMODULES variable generated by
>> ./configure.
>>
>> SLOF is required for building the s390-ccw firmware on s390x, since
>> it is using the libnet code from SLOF for network booting.
>>
>> Add it to the GIT_SUBMODULES when buildint the s390-ccw firmware,
> 
> s/buildint/building/
> 
>> to fix:
>>
>>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
>> path 'roms/SLOF'
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF'. Retry scheduled
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF' a second time, aborting
>>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
>> exited with 1.
> 
> I still somehow doubt that this will really fix the issue that you've
> seen here (why should it matter where the submodule is checked out?),

Yeah I still don't understand why the previous checkouts succeeded.

Is git.qemu.org cached by a CDN?

Maybe we can reduce the pressure by adding a 'prepare-sources' step,
then pass it as artifact within Travis-CI premises:
https://docs.travis-ci.com/user/build-stages/#specifying-stage-order-and-conditions

Alex, what do you think?

> but the patch is a good idea anyway, so:
> 
> Reviewed-by: Thomas Huth 
> 
> 
>> Reported-by: Mark Cave-Ayland 
>> Suggested-by: Thomas Huth 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  configure   | 5 +
>>  .travis.yml | 1 -
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index bb7fd12612..927e4a3d06 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6533,6 +6533,11 @@ if test "$cpu" = "s390x" ; then
>>write_c_skeleton
>>if compile_prog "-march=z900" ""; then
>>  roms="$roms s390-ccw"
>> +# SLOF is required for building the s390-ccw firmware on s390x,
>> +# since it is using the libnet code from SLOF for network booting.
>> +if test -e "${source_path}/.git" ; then
>> +  git_submodules="${git_submodules} roms/SLOF"
>> +fi
>>fi
>>  fi
>>  
>> diff --git a/.travis.yml b/.travis.yml
>> index ec6367af1f..220855c1f0 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -496,7 +496,6 @@ jobs:
>>  - CONFIG="--disable-containers 
>> --target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
>>  - UNRELIABLE=true
>>script:
>> -- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>  - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
>>  - |
>>if [ "$BUILD_RC" -eq 0 ] ; then
>>
> 

[Bug 1883414] Re: Cannot build qemu-5.0.0 from tarball

[Uri Simchoni]

I just tried it again it didn't reproduce - all files were there. I
don't have the original tarball that caused me to open this bug, as I
just moved to git clone and continued with that.

Appologies and please close this bug.

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

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

Title:
  Cannot build qemu-5.0.0 from tarball

Status in QEMU:
  Invalid

Bug description:
  Cannot build qemu 5.0.0 from the release tarball. Building from git-
  clone succeeds.

  After downloading and unpacking the 5.0.0 tarball, I typed the
  following:

  mkdir build
  cd build
  ../configure

  Then got the following error message:

  ERROR: missing file /home/uri/qemu-5.0.0/ui/keycodemapdb/README

  This is not a GIT checkout but module content appears to
  be missing. Do not use 'git archive' or GitHub download links
  to acquire QEMU source archives. Non-GIT builds are only
  supported with source archives linked from:

https://www.qemu.org/download/#source

  Developers working with GIT can use scripts/archive-source.sh
  if they need to create valid source archives.

  It appears the ui/keycodemapdb is missing some files that are obtained
  from a git submodule in a git tree.

  Building from a git clone succeeds.

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

Re: [PATCH v8 0/4] vhost-user block device backend implementation

[Stefano Garzarella]

On Mon, Jun 15, 2020 at 02:46:40AM +0800, Coiby Xu wrote:
> Hi Stefano Garzarella,
> 
> On Thu, Jun 11, 2020 at 02:37:03PM +0200, Stefano Garzarella wrote:
> > Hi Coiby Xu,
> > 
> > On Fri, Jun 05, 2020 at 07:35:34AM +0800, Coiby Xu wrote:
> > > v8
> > >  - re-try connecting to socket server to fix asan error
> > >  - fix license naming issue
> > > 
> > > v7
> > >  - fix docker-test-debug@fedora errors by freeing malloced memory
> > > 
> > > v6
> > >  - add missing license header and include guard
> > >  - vhost-user server only serve one client one time
> > >  - fix a bug in custom vu_message_read
> > >  - using qemu-storage-daemon to start vhost-user-blk-server
> > >  - a bug fix to pass docker-test-clang@ubuntu
> > > 
> > > v5:
> > >  * re-use vu_kick_cb in libvhost-user
> > >  * keeping processing VhostUserMsg in the same coroutine until there is
> > >detachment/attachment of AIOContext
> > >  * Spawn separate coroutine for each VuVirtqElement
> > >  * Other changes including relocating vhost-user-blk-server.c, coding
> > >style etc.
> > > 
> > > v4:
> > >  * add object properties in class_init
> > >  * relocate vhost-user-blk-test
> > >  * other changes including using SocketAddress, coding style, etc.
> > > 
> > > v3:
> > >  * separate generic vhost-user-server code from vhost-user-blk-server
> > >code
> > >  * re-write vu_message_read and kick hander function as coroutines to
> > >directly call blk_co_preadv, blk_co_pwritev, etc.
> > >  * add aio_context notifier functions to support multi-threading model
> > >  * other fixes regarding coding style, warning report, etc.
> > > 
> > > v2:
> > >  * Only enable this feature for Linux because eventfd is a Linux-specific
> > >feature
> > > 
> > > 
> > > This patch series is an implementation of vhost-user block device
> > > backend server, thanks to Stefan and Kevin's guidance.
> > > 
> > > Vhost-user block device backend server is a UserCreatable object and can 
> > > be
> > > started using object_add,
> > > 
> > >  (qemu) object_add 
> > > vhost-user-blk-server,id=ID,unix-socket=/tmp/vhost-user-blk_vhost.socket,node-name=DRIVE_NAME,writable=off,blk-size=512
> > >  (qemu) object_del ID
> > > 
> > > or appending the "-object" option when starting QEMU,
> > > 
> > >   $ -object 
> > > vhost-user-blk-server,id=disk,unix-socket=/tmp/vhost-user-blk_vhost.socket,node-name=DRIVE_NAME,writable=off,blk-size=512
> > > 
> > > Then vhost-user client can connect to the server backend.
> > > For example, QEMU could act as a client,
> > > 
> > >   $ -m 256 -object memory-backend-memfd,id=mem,size=256M,share=on -numa 
> > > node,memdev=mem -chardev 
> > > socket,id=char1,path=/tmp/vhost-user-blk_vhost.socket -device 
> > > vhost-user-blk-pci,id=blk0,chardev=char1
> > > 
> > > And guest OS could access this vhost-user block device after mounting it.
> > > 
> > > Coiby Xu (4):
> > >   Allow vu_message_read to be replaced
> > >   generic vhost user server
> > >   vhost-user block device backend server
> > >   new qTest case to test the vhost-user-blk-server
> > > 
> > >  block/Makefile.objs|   1 +
> > >  block/export/vhost-user-blk-server.c   | 716 
> > >  block/export/vhost-user-blk-server.h   |  34 +
> > >  contrib/libvhost-user/libvhost-user-glib.c |   2 +-
> > >  contrib/libvhost-user/libvhost-user.c  |  11 +-
> > >  contrib/libvhost-user/libvhost-user.h  |  21 +
> > >  softmmu/vl.c   |   4 +
> > >  tests/Makefile.include |   3 +-
> > >  tests/qtest/Makefile.include   |   2 +
> > >  tests/qtest/libqos/vhost-user-blk.c| 130 
> > >  tests/qtest/libqos/vhost-user-blk.h|  44 ++
> > >  tests/qtest/libqtest.c |  54 +-
> > >  tests/qtest/libqtest.h |  38 ++
> > >  tests/qtest/vhost-user-blk-test.c  | 737 +
> > >  tests/vhost-user-bridge.c  |   2 +
> > >  tools/virtiofsd/fuse_virtio.c  |   4 +-
> > >  util/Makefile.objs |   1 +
> > >  util/vhost-user-server.c   | 406 
> > >  util/vhost-user-server.h   |  59 ++
> > >  19 files changed, 2229 insertions(+), 40 deletions(-)
> > >  create mode 100644 block/export/vhost-user-blk-server.c
> > >  create mode 100644 block/export/vhost-user-blk-server.h
> > >  create mode 100644 tests/qtest/libqos/vhost-user-blk.c
> > >  create mode 100644 tests/qtest/libqos/vhost-user-blk.h
> > >  create mode 100644 tests/qtest/vhost-user-blk-test.c
> > >  create mode 100644 util/vhost-user-server.c
> > >  create mode 100644 util/vhost-user-server.h
> > > 
> > 
> > Should we add an entry in the MAINTAINERS file for some of the new files?
> > (e.g. util/vhost-user-server.*)
> 
> Yes, please. Thank you!

I think the best thing should be to edit MAINTAINERS in this series,
since you're adding new files, but I don't know who will maintain

RE: [PATCH 1/2] migration/colo: fix typo in the COLO Framework module

[Zhanghailiang]

Reviewed-by: zhanghailiang 


> -Original Message-
> From: Like Xu [mailto:like...@linux.intel.com]
> Sent: Sunday, June 14, 2020 4:45 PM
> To: qemu-devel@nongnu.org
> Cc: Like Xu ; Zhanghailiang
> 
> Subject: [PATCH 1/2] migration/colo: fix typo in the COLO Framework
> module
> 
> Cc: Hailiang Zhang 
> Signed-off-by: Like Xu 
> ---
>  docs/COLO-FT.txt | 8 
>  migration/colo.c | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt index
> c8e1740935..fdc0207cff 100644
> --- a/docs/COLO-FT.txt
> +++ b/docs/COLO-FT.txt
> @@ -10,7 +10,7 @@ See the COPYING file in the top-level directory.
>  This document gives an overview of COLO's design and how to use it.
> 
>  == Background ==
> -Virtual machine (VM) replication is a well known technique for providing
> +Virtual machine (VM) replication is a well-known technique for
> +providing
>  application-agnostic software-implemented hardware fault tolerance,  also
> known as "non-stop service".
> 
> @@ -103,7 +103,7 @@ Primary side.
> 
>  COLO Proxy:
>  Delivers packets to Primary and Secondary, and then compare the responses
> from -both side. Then decide whether to start a checkpoint according to
> some rules.
> +both sides. Then decide whether to start a checkpoint according to some
> rules.
>  Please refer to docs/colo-proxy.txt for more information.
> 
>  Note:
> @@ -146,12 +146,12 @@ in test procedure.
> 
>  == Test procedure ==
>  Note: Here we are running both instances on the same host for testing,
> -change the IP Addresses if you want to run it on two hosts. Initally
> +change the IP Addresses if you want to run it on two hosts. Initially
>  127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
> 
>  == Startup qemu ==
>  1. Primary:
> -Note: Initally, $imagefolder/primary.qcow2 needs to be copied to all hosts.
> +Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
>  You don't need to change any IP's here, because 0.0.0.0 listens on any
> interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
> instance.
> diff --git a/migration/colo.c b/migration/colo.c index
> ea7d1e9d4e..80788d46b5 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -632,7 +632,7 @@ out:
>  /*
>   * It is safe to unregister notifier after failover finished.
>   * Besides, colo_delay_timer and colo_checkpoint_sem can't be
> - * released befor unregister notifier, or there will be use-after-free
> + * released before unregister notifier, or there will be
> + use-after-free
>   * error.
>   */
>  colo_compare_unregister_notifier(&packets_compare_notifier);
> --
> 2.21.3

Re: [PATCH for-5.1 V4 1/4] hw/mips: Implement the kvm_type() hook in MachineClass

[Thomas Huth]

On 15/06/2020 02.52, Huacai Chen wrote:
> Hi, Aleksandar,
> 
> On Sun, Jun 14, 2020 at 4:07 PM Aleksandar Markovic
>  wrote:
>>
>>
>>
>> уто, 2. јун 2020. у 04:38 Huacai Chen  је написао/ла:
>>>
>>> MIPS has two types of KVM: TE & VZ, and TE is the default type. Now we
>>> can't create a VZ guest in QEMU because it lacks the kvm_type() hook in
>>> MachineClass. Besides, libvirt uses a null-machine to detect the kvm
>>> capability, so by default it will return "KVM not supported" on a VZ
>>> platform. Thus, null-machine also need the kvm_type() hook.
>>>
>>> Reviewed-by: Aleksandar Markovic 
>>> Signed-off-by: Huacai Chen 
>>> Co-developed-by: Jiaxun Yang 
>>> ---
>>
>> Huacai,
>>
>> Please take a look at Peter's remarks at:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg01878.html
>>
>> ...and refactor this patch for v5. My general advice: The simpler, the 
>> batter.
>>
> OK, I will rework this patch.

 Hi,

is there maybe also a way to do this without moving null-machine.o from
common-obj-y to obj-y, and to avoid the target-specific hacks in this
file ? We just moved the null-machine from obj-y to common-obj-y two
years ago (see commit 3858ff763985fb9e), since it's more desirable to
have as much code in common-obj to save compilation time and maybe to be
able to link a qemu with more than one target CPU in one binary one day...

ppc64 has also more than one kvm_type (kvm-hv and kvm-pr), and
apparently it also works without hacks to the null-machine code there
... so maybe you can peek into the ppc64 code to see how it is solved there?

 Thomas


>>>  hw/core/Makefile.objs  |  2 +-
>>>  hw/core/null-machine.c |  4 
>>>  hw/mips/Makefile.objs  |  2 +-
>>>  hw/mips/common.c   | 42 ++
>>>  include/hw/mips/mips.h |  3 +++
>>>  5 files changed, 51 insertions(+), 2 deletions(-)
>>>  create mode 100644 hw/mips/common.c
>>>
>>> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
>>> index 1d540ed..b5672f4 100644
>>> --- a/hw/core/Makefile.objs
>>> +++ b/hw/core/Makefile.objs
>>> @@ -17,11 +17,11 @@ common-obj-$(CONFIG_SOFTMMU) += 
>>> vm-change-state-handler.o
>>>  common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o
>>>  common-obj-$(CONFIG_SOFTMMU) += sysbus.o
>>>  common-obj-$(CONFIG_SOFTMMU) += machine.o
>>> -common-obj-$(CONFIG_SOFTMMU) += null-machine.o
>>>  common-obj-$(CONFIG_SOFTMMU) += loader.o
>>>  common-obj-$(CONFIG_SOFTMMU) += machine-hmp-cmds.o
>>>  common-obj-$(CONFIG_SOFTMMU) += numa.o
>>>  common-obj-$(CONFIG_SOFTMMU) += clock-vmstate.o
>>> +obj-$(CONFIG_SOFTMMU) += null-machine.o
>>>  obj-$(CONFIG_SOFTMMU) += machine-qmp-cmds.o
>>>
>>>  common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
>>> diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
>>> index cb47d9d..94a36f9 100644
>>> --- a/hw/core/null-machine.c
>>> +++ b/hw/core/null-machine.c
>>> @@ -17,6 +17,7 @@
>>>  #include "sysemu/sysemu.h"
>>>  #include "exec/address-spaces.h"
>>>  #include "hw/core/cpu.h"
>>> +#include "hw/mips/mips.h"
>>>
>>>  static void machine_none_init(MachineState *mch)
>>>  {
>>> @@ -50,6 +51,9 @@ static void machine_none_machine_init(MachineClass *mc)
>>>  mc->max_cpus = 1;
>>>  mc->default_ram_size = 0;
>>>  mc->default_ram_id = "ram";
>>> +#ifdef TARGET_MIPS
>>> +mc->kvm_type = mips_kvm_type;
>>> +#endif
>>>  }
>>>
>>>  DEFINE_MACHINE("none", machine_none_machine_init)
>>> diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
>>> index 739e2b7..3b3e6ea 100644
>>> --- a/hw/mips/Makefile.objs
>>> +++ b/hw/mips/Makefile.objs
>>> @@ -1,4 +1,4 @@
>>> -obj-y += addr.o mips_int.o
>>> +obj-y += addr.o common.o mips_int.o
>>>  obj-$(CONFIG_R4K) += r4k.o
>>>  obj-$(CONFIG_MALTA) += gt64xxx_pci.o malta.o
>>>  obj-$(CONFIG_MIPSSIM) += mipssim.o
>>> diff --git a/hw/mips/common.c b/hw/mips/common.c
>>> new file mode 100644
>>> index 000..4d8e141
>>> --- /dev/null
>>> +++ b/hw/mips/common.c
>>> @@ -0,0 +1,42 @@
>>> +/*
>>> + * Common MIPS routines
>>> + *
>>> + * Copyright (c) 2020 Huacai Chen (che...@lemote.com)
>>> + * This code is licensed under the GNU GPL v2.
>>> + */
>>> +
>>> +#include 
>>> +#include "qemu/osdep.h"
>>> +#include "qemu-common.h"
>>> +#include "hw/boards.h"
>>> +#include "hw/mips/mips.h"
>>> +#include "sysemu/kvm_int.h"
>>> +
>>> +#ifndef CONFIG_KVM
>>> +
>>> +int mips_kvm_type(MachineState *machine, const char *vm_type)
>>> +{
>>> +return 0;
>>> +}
>>> +
>>> +#else
>>> +
>>> +int mips_kvm_type(MachineState *machine, const char *vm_type)
>>> +{
>>> +int r;
>>> +KVMState *s = KVM_STATE(machine->accelerator);
>>> +
>>> +r = kvm_check_extension(s, KVM_CAP_MIPS_VZ);
>>> +if (r > 0) {
>>> +return KVM_VM_MIPS_VZ;
>>> +}
>>> +
>>> +r = kvm_check_extension(s, KVM_CAP_MIPS_TE);
>>> +if (r > 0) {
>>> +return KVM_VM_MIPS_TE;
>>> +}
>>> +
>>> +return -1;
>>> +}
>>> +
>>> +#endif
>>> diff --git a/include/hw/mips/mips.h b/include/hw/mips/mips.h
>>> index 0af4c3d

Re: [PATCH 0/6] Add several Power ISA 3.1 32/64-bit vector instructions

[David Gibson]

On Fri, Jun 12, 2020 at 09:47:58PM -0700, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20200613042029.22321-1-...@linux.ibm.com/

I will need you to fix these stype errors and repost.

> 
> 
> 
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Message-id: 20200613042029.22321-1-...@linux.ibm.com
> Subject: [PATCH 0/6] Add several Power ISA 3.1 32/64-bit vector instructions
> Type: series
> 
> === 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'
> d39f30e target/ppc: add vdiv{su}{wd} vmod{su}{wd} instructions
> 966b641 fix the prototype of muls64/mulu64
> 42111c5 target/ppc: add vmulh{su}d instructions
> c96e996 targetc/ppc: add vmulh{su}w instructions
> c52004c target/ppc: add vmulld instruction
> 1061e4e target/ppc: add byte-reverse br[dwh] instructions
> 
> === OUTPUT BEGIN ===
> 1/6 Checking commit 1061e4ead5bc (target/ppc: add byte-reverse br[dwh] 
> instructions)
> ERROR: code indent should never use tabs
> #26: FILE: target/ppc/translate.c:6977:
> +^ITCGv_i64 temp = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #28: FILE: target/ppc/translate.c:6979:
> +^Itcg_gen_bswap64_i64(temp, cpu_gpr[rS(ctx->opcode)]);$
> 
> WARNING: line over 80 characters
> #29: FILE: target/ppc/translate.c:6980:
> +   tcg_gen_st_i64(temp, cpu_env, offsetof(CPUPPCState, 
> gpr[rA(ctx->opcode)]));
> 
> ERROR: code indent should never use tabs
> #29: FILE: target/ppc/translate.c:6980:
> +^Itcg_gen_st_i64(temp, cpu_env, offsetof(CPUPPCState, 
> gpr[rA(ctx->opcode)]));$
> 
> ERROR: code indent should never use tabs
> #31: FILE: target/ppc/translate.c:6982:
> +^Itcg_temp_free_i64(temp);$
> 
> ERROR: code indent should never use tabs
> #37: FILE: target/ppc/translate.c:6988:
> +^ITCGv_i64 temp = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #38: FILE: target/ppc/translate.c:6989:
> +^ITCGv_i64 lsb = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #39: FILE: target/ppc/translate.c:6990:
> +^ITCGv_i64 msb = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #41: FILE: target/ppc/translate.c:6992:
> +^Itcg_gen_movi_i64(lsb, 0xull);$
> 
> ERROR: code indent should never use tabs
> #42: FILE: target/ppc/translate.c:6993:
> +^Itcg_gen_and_i64(temp, lsb, cpu_gpr[rS(ctx->opcode)]);$
> 
> ERROR: code indent should never use tabs
> #43: FILE: target/ppc/translate.c:6994:
> +^Itcg_gen_bswap32_i64(lsb, temp);$
> 
> ERROR: trailing whitespace
> #44: FILE: target/ppc/translate.c:6995:
> +^I$
> 
> ERROR: code indent should never use tabs
> #44: FILE: target/ppc/translate.c:6995:
> +^I$
> 
> ERROR: code indent should never use tabs
> #45: FILE: target/ppc/translate.c:6996:
> +^Itcg_gen_shri_i64(msb, cpu_gpr[rS(ctx->opcode)], 32);$
> 
> ERROR: code indent should never use tabs
> #46: FILE: target/ppc/translate.c:6997:
> +^Itcg_gen_bswap32_i64(temp, msb);$
> 
> ERROR: code indent should never use tabs
> #47: FILE: target/ppc/translate.c:6998:
> +^Itcg_gen_shli_i64(msb, temp, 32);$
> 
> ERROR: trailing whitespace
> #48: FILE: target/ppc/translate.c:6999:
> +^I$
> 
> ERROR: code indent should never use tabs
> #48: FILE: target/ppc/translate.c:6999:
> +^I$
> 
> ERROR: code indent should never use tabs
> #49: FILE: target/ppc/translate.c:7000:
> +^Itcg_gen_or_i64(temp, lsb, msb);$
> 
> WARNING: line over 80 characters
> #51: FILE: target/ppc/translate.c:7002:
> +   tcg_gen_st_i64(temp, cpu_env, offsetof(CPUPPCState, 
> gpr[rA(ctx->opcode)]));
> 
> ERROR: code indent should never use tabs
> #51: FILE: target/ppc/translate.c:7002:
> +^Itcg_gen_st_i64(temp, cpu_env, offsetof(CPUPPCState, 
> gpr[rA(ctx->opcode)]));$
> 
> ERROR: code indent should never use tabs
> #53: FILE: target/ppc/translate.c:7004:
> +^Itcg_temp_free_i64(temp);$
> 
> ERROR: code indent should never use tabs
> #54: FILE: target/ppc/translate.c:7005:
> +^Itcg_temp_free_i64(lsb);$
> 
> ERROR: code indent should never use tabs
> #55: FILE: target/ppc/translate.c:7006:
> +^Itcg_temp_free_i64(msb);$
> 
> ERROR: code indent should never use tabs
> #61: FILE: target/ppc/translate.c:7012:
> +^ITCGv_i64 temp = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #62: FILE: target/ppc/translate.c:7013:
> +^ITCGv_i64 t0 = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #63: FILE: target/ppc/translate.c:7014:
> +^ITCGv_i64 t1 = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #64: FILE: target/ppc/translate.c:7015:
> +^ITCGv_i64 t2 = tcg_temp_new_i64();$
> 
> ERROR: code indent should never use tabs
> #65: FILE: target/ppc/translate.c:7016:
> +^ITCGv_i64 t3 = tcg_temp_new_i64();$
> 
> ERROR: code

Re: [PATCH] target/mips: Fix PageMask with variable page size

[Peter Maydell]

On Sun, 14 Jun 2020 at 22:52, Aleksandar Markovic
 wrote:
> When you change machine.c the way you did it, you need to bump the version. 
> Please see git log on machine.c for details.

>> --- a/target/mips/cpu.h
>> +++ b/target/mips/cpu.h
>> @@ -617,7 +617,8 @@ struct CPUMIPSState {
>>  /*
>>   * CP0 Register 5
>>   */
>> -int32_t CP0_PageMask;
>> +target_ulong CP0_PageMask;
>> +#define CP0PM_MASK 13

Does CP0_PageMask ever actually hold a value that won't fit
in an int32_t? If not, it might be preferable to avoid changing
its type to avoid the migration compat break, even if MIPS
doesn't have any versioned boards where we have a strict
don't-break-compat promise to users.

thanks
-- PMM

Re: [PATCH] target/mips: Fix PageMask with variable page size

[Jiaxun Yang]

在 2020/6/15 17:13, Peter Maydell 写道:

On Sun, 14 Jun 2020 at 22:52, Aleksandar Markovic
 wrote:

When you change machine.c the way you did it, you need to bump the version. 
Please see git log on machine.c for details.



--- a/target/mips/cpu.h
+++ b/target/mips/cpu.h
@@ -617,7 +617,8 @@ struct CPUMIPSState {
  /*
   * CP0 Register 5
   */
-int32_t CP0_PageMask;
+target_ulong CP0_PageMask;
+#define CP0PM_MASK 13


Does CP0_PageMask ever actually hold a value that won't fit
in an int32_t? If not, it might be preferable to avoid changing
its type to avoid the migration compat break, even if MIPS
doesn't have any versioned boards where we have a strict
don't-break-compat promise to users.


In Release2, PageMask was extended to 64bit on MIPS64 processors.

Is it necessary to follow that?

Thanks.



thanks
-- PMM



--
- Jiaxun

Re: [PATCH v3] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Daniel P . Berrangé]

On Mon, Jun 15, 2020 at 09:49:19AM +0200, Philippe Mathieu-Daudé wrote:
> The git-submodule.sh script is called by make and initialize the
> submodules listed in the GIT_SUBMODULES variable generated by
> ./configure.
> 
> SLOF is required for building the s390-ccw firmware on s390x, since
> it is using the libnet code from SLOF for network booting.
> 
> Add it to the GIT_SUBMODULES when buildint the s390-ccw firmware,
> to fix:
> 
>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
> path 'roms/SLOF'
>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
> resolve host: git.qemu.org
>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
> '/home/travis/build/user/qemu/roms/SLOF' failed
>   Failed to clone 'roms/SLOF'. Retry scheduled
>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
> resolve host: git.qemu.org
>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
> '/home/travis/build/user/qemu/roms/SLOF' failed
>   Failed to clone 'roms/SLOF' a second time, aborting
>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
> exited with 1.

The "git-submodule.sh" script just invokes "git submodule". So if
you are getting DNS failures from "git submodule", using git-submodule.sh
instead is not going to fix the problem.

> 
> Reported-by: Mark Cave-Ayland 
> Suggested-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  configure   | 5 +
>  .travis.yml | 1 -
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index bb7fd12612..927e4a3d06 100755
> --- a/configure
> +++ b/configure
> @@ -6533,6 +6533,11 @@ if test "$cpu" = "s390x" ; then
>write_c_skeleton
>if compile_prog "-march=z900" ""; then
>  roms="$roms s390-ccw"
> +# SLOF is required for building the s390-ccw firmware on s390x,
> +# since it is using the libnet code from SLOF for network booting.
> +if test -e "${source_path}/.git" ; then
> +  git_submodules="${git_submodules} roms/SLOF"
> +fi
>fi
>  fi

This whole bit of configure looks a bit dubious.

For all the other firmware images we ship as pre-built blobs, we never
try to re-build them even if the host compiler supports it. So I don't
think we need to make SLOF special. If someone wants to build SLOF
they should do so explicitly. IOW, I'd just remove this code that
automatically enables rebuilds of it, which will presumable fix the
DNS problem by virtue of never running that code.


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

Re: [PATCH v3 4/4] spapr: Forbid nested KVM-HV in pre-power9 compat mode

[Greg Kurz]

On Sat, 13 Jun 2020 17:18:04 +1000
David Gibson  wrote:

> On Thu, Jun 11, 2020 at 03:40:33PM +0200, Greg Kurz wrote:
> > Nested KVM-HV only works on POWER9.
> > 
> > Signed-off-by: Greg Kurz 
> > Reviewed-by: Laurent Vivier 
> 
> Hrm.  I have mixed feelings about this.  It does bring forward an
> error that we'd otherwise only discover when we try to load the kvm
> module in the guest.
> 
> On the other hand, it's kind of a layering violation - really it's
> KVM's business to report what it can and can't do, rather than having
> qemu anticipate it.
> 

Agreed and it seems that we can probably get KVM to report that
already. I'll have closer look.

> Allowing POWER8 compat for an L2 is something we hope to have in the
> fairly near future.

Ok but I guess we don't want to start an L2 in compat POWER8 mode
with cap-nested-hv=on, do we ?

>  Allowing POWER8 compat for L1, which is what this
> covers, is, I'll admit, likely to never happen.
> 
> 
> > ---
> >  HW/ppc/spapr_caps.c |   10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> > index 27cf2b38af27..dfe3b419daaa 100644
> > --- a/hw/ppc/spapr_caps.c
> > +++ b/hw/ppc/spapr_caps.c
> > @@ -391,6 +391,8 @@ static void cap_nested_kvm_hv_apply(SpaprMachineState 
> > *spapr,
> >  uint8_t val, Error **errp)
> >  {
> >  ERRP_AUTO_PROPAGATE();
> > +PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
> > +
> >  if (!val) {
> >  /* capability disabled by default */
> >  return;
> > @@ -400,6 +402,14 @@ static void cap_nested_kvm_hv_apply(SpaprMachineState 
> > *spapr,
> >  error_setg(errp, "No Nested KVM-HV support in TCG");
> >  error_append_hint(errp, "Try appending -machine 
> > cap-nested-hv=off\n");
> >  } else if (kvm_enabled()) {
> > +if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_3_00, 0,
> > +  spapr->max_compat_pvr)) {
> > +error_setg(errp, "Nested KVM-HV only supported on POWER9");
> > +error_append_hint(errp,
> > +  "Try appending -machine 
> > max-cpu-compat=power9\n");
> > +return;
> > +}
> > +
> >  if (!kvmppc_has_cap_nested_kvm_hv()) {
> >  error_setg(errp,
> > "KVM implementation does not support Nested 
> > KVM-HV");
> > 
> > 
> 



pgp40aswN_k78.pgp
Description: OpenPGP digital signature

Re: [PATCH] target/mips: Fix PageMask with variable page size

[Peter Maydell]

On Mon, 15 Jun 2020 at 10:17, Jiaxun Yang  wrote:
>
>
>
> 在 2020/6/15 17:13, Peter Maydell 写道:
> > On Sun, 14 Jun 2020 at 22:52, Aleksandar Markovic
> >  wrote:
> >> When you change machine.c the way you did it, you need to bump the 
> >> version. Please see git log on machine.c for details.
> >
> >>> --- a/target/mips/cpu.h
> >>> +++ b/target/mips/cpu.h
> >>> @@ -617,7 +617,8 @@ struct CPUMIPSState {
> >>>   /*
> >>>* CP0 Register 5
> >>>*/
> >>> -int32_t CP0_PageMask;
> >>> +target_ulong CP0_PageMask;
> >>> +#define CP0PM_MASK 13
> >
> > Does CP0_PageMask ever actually hold a value that won't fit
> > in an int32_t? If not, it might be preferable to avoid changing
> > its type to avoid the migration compat break, even if MIPS
> > doesn't have any versioned boards where we have a strict
> > don't-break-compat promise to users.
>
> In Release2, PageMask was extended to 64bit on MIPS64 processors.
>
> Is it necessary to follow that?

Ah, I see. I'd assumed that you were only fixing the
variable-page-size change (which shouldn't require a
change in the type), but as Aleksandar says you've
mixed in a new feature implementation in the same commit
(which from what you're saying does need the type to change).
If the new feature means the register is now 64 bits then
it is possible to implement this in a migration-compatible
way by using a vmstate subsection; I'll leave it up to
Aleksandar whether that complexity is something that makes
sense for MIPS targets or if it's better to just break migration
compat by bumping the version.

thanks
-- PMM

Re: [PATCH 4/4] block/io: improve savevm performance

[Vladimir Sementsov-Ogievskiy]

11.06.2020 20:11, Denis V. Lunev wrote:

This patch does 2 standard basic things:
- it creates intermediate buffer for all writes from QEMU migration code
   to block driver,
- this buffer is sent to disk asynchronously, allowing several writes to
   run in parallel.

Thus bdrv_vmstate_write() is becoming asynchronous. All pending operations
completion are performed in newly invented bdrv_flush_vmstate().

In general, migration code is fantastically inefficent (by observation),
buffers are not aligned and sent with arbitrary pieces, a lot of time
less than 100 bytes at a chunk, which results in read-modify-write
operations if target file descriptor is opened with O_DIRECT. It should
also be noted that all operations are performed into unallocated image
blocks, which also suffer due to partial writes to such new clusters
even on cached file descriptors.

Snapshot creation time (2 GB Fedora-31 VM running over NVME storage):
 original fixed
cached:  1.79s   1.27s
non-cached:  3.29s   0.81s

The difference over HDD would be more significant :)

Signed-off-by: Denis V. Lunev 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Vladimir Sementsov-Ogievskiy 
CC: Denis Plotnikov 
---
  block/io.c| 121 +-
  include/block/block_int.h |   8 +++
  2 files changed, 127 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c
index fbf352f39d..698f1eef76 100644
--- a/block/io.c
+++ b/block/io.c
@@ -26,6 +26,7 @@
  #include "trace.h"
  #include "sysemu/block-backend.h"
  #include "block/aio-wait.h"
+#include "block/aio_task.h"
  #include "block/blockjob.h"
  #include "block/blockjob_int.h"
  #include "block/block_int.h"
@@ -2633,6 +2634,102 @@ typedef struct BdrvVmstateCo {
  int ret;
  } BdrvVmstateCo;
  
+typedef struct BdrvVMStateTask {

+AioTask task;
+
+BlockDriverState *bs;
+int64_t offset;
+void *buf;
+size_t bytes;
+} BdrvVMStateTask;
+
+typedef struct BdrvSaveVMState {
+AioTaskPool *pool;
+BdrvVMStateTask *t;
+} BdrvSaveVMState;
+
+
+static coroutine_fn int bdrv_co_vmstate_save_task_entry(AioTask *task)
+{
+int err = 0;
+BdrvVMStateTask *t = container_of(task, BdrvVMStateTask, task);
+
+if (t->bytes != 0) {
+QEMUIOVector local_qiov;
+qemu_iovec_init_buf(&local_qiov, t->buf, t->bytes);


Consider special oneliner for this case:

QEMUIOVector qiov = QEMU_IOVEC_INIT_BUF(qiov, t->buf, t->bytes);


+
+bdrv_inc_in_flight(t->bs);
+err = t->bs->drv->bdrv_save_vmstate(t->bs, &local_qiov, t->offset);
+bdrv_dec_in_flight(t->bs);
+}
+
+qemu_vfree(t->buf);
+return err;
+}
+
+static BdrvVMStateTask *bdrv_vmstate_task_create(BlockDriverState *bs,
+ int64_t pos, size_t size)
+{
+BdrvVMStateTask *t = g_new(BdrvVMStateTask, 1);
+
+*t = (BdrvVMStateTask) {
+.task.func = bdrv_co_vmstate_save_task_entry,
+.buf = qemu_blockalign(bs, size),
+.offset = pos,
+.bs = bs,
+};
+
+return t;
+}
+
+static int bdrv_co_do_save_vmstate(BlockDriverState *bs, QEMUIOVector *qiov,
+   int64_t pos)
+{
+BdrvSaveVMState *state = bs->savevm_state;
+BdrvVMStateTask *t;
+size_t buf_size = MAX(bdrv_get_cluster_size(bs), 1 * MiB);
+size_t to_copy;
+size_t off;
+
+if (state == NULL) {
+state = g_new(BdrvSaveVMState, 1);
+*state = (BdrvSaveVMState) {
+.pool = aio_task_pool_new(BDRV_VMSTATE_WORKERS_MAX),
+.t = bdrv_vmstate_task_create(bs, pos, buf_size),
+};
+
+bs->savevm_state = state;
+}
+
+if (aio_task_pool_status(state->pool) < 0) {
+return aio_task_pool_status(state->pool);


So, on failure, we still need flush, to cleanup the state. I think better is to 
cleanup it
immediately here (goto fail, etc.).

Aha, actually in blk_save_vmstate(), you don't do bdrv_flush_vmstate() if 
bdrv_save_vmstate()
failed.


+}
+
+t = state->t;
+if (t->offset + t->bytes != pos) {
+/* Normally this branch is not reachable from migration */


Aha, like a cache-miss. OK


+return bs->drv->bdrv_save_vmstate(bs, qiov, pos);
+}
+
+off = 0;
+while (1) {
+to_copy = MIN(qiov->size - off, buf_size - t->bytes);
+qemu_iovec_to_buf(qiov, off, t->buf + t->bytes, to_copy);
+t->bytes += to_copy;
+if (t->bytes < buf_size) {
+return qiov->size;
+}
+
+aio_task_pool_start_task(state->pool, &t->task);
+
+pos += to_copy;
+off += to_copy;
+state->t = t = bdrv_vmstate_task_create(bs, pos, buf_size);
+}
+
+return qiov->size;


this is unreachable actually. So, I'd drop it or do "break" in a loop instead 
of return.


+}
+
  static int coroutine_fn
  bdrv_co_rw_vmstate(Bloc

Re: [PATCH 1/2] linux-user: Add thunk argument types for SIOCGSTAMP and SIOCGSTAMPNS

[Laurent Vivier]

Le 12/06/2020 à 18:40, Filip Bozuta a écrit :
> From: Filip Bozuta 
> 
> Socket ioctls SIOCGSTAMP and SIOCGSTAMPNS, used for timestamping the socket
> connection, are defined in file "ioctls.h" differently from other ioctls.
> The reason for this difference is explained in the comments above their 
> definition.
> These ioctls didn't have defined thunk argument types before changes from this
> patch. They have special handling functions ("do_ioctl_SIOCGSTAMP" and
> "do_ioctl_SIOCGSTAMPNS") that take care of setting values for approppriate 
> argument
> types (struct timeval and struct timespec) and thus no thunk argument types 
> were
> needed for their implementation. But this patch adds those argument type 
> definitions
> in file "syscall_types.h" and "ioctls.h" as it is needed for printing 
> arguments
> of these ioctls with strace.
> 
> Implementation notes:
> 
> There are two variants of these ioctls: SIOCGSTAMP_OLD/SIOCGSTAM_NEW and
> SIOCGSTAMPNS_OLD/SIOCGSTAMPNS_NEW. One is the old existing definition and 
> the
> other is the 2038 safe variant used for 32-bit architectures. These 
> variants
> use types "struct timeval/timeval64" and "struct timespec/timespec64" 
> respectively.
> That is the reason why corresponding structure definitions were added in 
> file
> "syscall_types.h". STRUCT_timeval definition was already inside the file 
> as
> it is used by another implemented ioctl.
> 
> Signed-off-by: Filip Bozuta 
> ---
>  linux-user/ioctls.h| 12 
>  linux-user/syscall_types.h | 12 
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
> index 0defa1d8c1..68d43f71cc 100644
> --- a/linux-user/ioctls.h
> +++ b/linux-user/ioctls.h
> @@ -279,13 +279,17 @@
> * FIXME: create a macro to define this kind of entry
> */
>{ TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
> -"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
> +"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP,
> +{ MK_PTR(MK_STRUCT(STRUCT_timeval)) } },
>{ TARGET_SIOCGSTAMPNS_OLD, TARGET_SIOCGSTAMPNS_OLD,
> -"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS },
> +"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS,
> +{ MK_PTR(MK_STRUCT(STRUCT_timespec)) } },
>{ TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMP_NEW,
> -"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP },
> +"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP,
> +{ MK_PTR(MK_STRUCT(STRUCT_timeval64)) } },
>{ TARGET_SIOCGSTAMPNS_NEW, TARGET_SIOCGSTAMPNS_NEW,
> -"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS },
> +"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS,
> +{ MK_PTR(MK_STRUCT(STRUCT_timespec64)) } },
>  
>IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
>IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(TYPE_INT))
> diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
> index 4e12c1661e..a5ad5a9ddc 100644
> --- a/linux-user/syscall_types.h
> +++ b/linux-user/syscall_types.h
> @@ -137,10 +137,22 @@ STRUCT(snd_timer_params,
> TYPE_INT, /* filter */
> MK_ARRAY(TYPE_CHAR, 60)) /* reserved */
>  
> +STRUCT(timeval,
> +   TYPE_LONG, /* tv_sec */
> +   TYPE_LONG) /* tv_usec */

You have to manage the case when tv_usec is int.
See linux-user/syscall_defs.h, target_timeval (and
target__kernel_sock_timeval)

> +
> +STRUCT(timeval64,
> +   TYPE_LONGLONG, /* tv_sec */
> +   TYPE_LONGLONG) /* tv_usec */

perhaps you could call this "target__kernel_sock_timeval" as it is in
linux-user/syscall_defs.h.

> +
>  STRUCT(timespec,
> TYPE_LONG, /* tv_sec */
> TYPE_LONG) /* tv_nsec */
>  
> +STRUCT(timespec64,
> +   TYPE_LONGLONG, /* tv_sec */
> +   TYPE_LONGLONG) /* tv_nsec */
> +

ditto: target__kernel_timespec

>  STRUCT(snd_timer_status,
> MK_STRUCT(STRUCT_timespec), /* tstamp */
> TYPE_INT, /* resolution */
> 

KVM call for 2016-06-16

[Juan Quintela]

Hi

Please, send any topic that you are interested in covering.
There is already a topic from last call:

Last minute suggestion after recent IRC chat with Alex Bennée and
Thomas Huth:

"Move some of the build/CI infrastructure to GitLab."

Pro/Con?

 - GitLab does not offer s390x/ppc64el => keep Travis for these?

How to coordinate efforts?

What we want to improve? Priorities?

Who can do which task / is motivated.

What has bugged us recently:
- Cross-build images (currently rebuilt all the time on Shippable)

Long term interests:

- Collect quality metrics
  . build time
  . test duration
  . performances
  . binary size
  . runtime memory used

- Collect code coverage

Note, this is orthogonal to the "Gating CI" task Cleber is working on:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg688150.html




At the end of Monday I will send an email with the agenda or the
cancellation of the call, so hurry up.

After discussions on the QEMU Summit, we are going to have always open a
KVM call where you can add topics.

 Call details:

By popular demand, a google calendar public entry with it

  
https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

(Let me know if you have any problems with the calendar entry.  I just
gave up about getting right at the same time CEST, CET, EDT and DST).

If you need phone number details,  contact me privately

Thanks, Juan.

Re: [PATCH 2/4] block/aio_task: allow start/wait task from any coroutine

[Vladimir Sementsov-Ogievskiy]

15.06.2020 10:47, Vladimir Sementsov-Ogievskiy wrote:

11.06.2020 20:11, Denis V. Lunev wrote:

From: Vladimir Sementsov-Ogievskiy 

Currently, aio task pool assumes that there is a main coroutine, which
creates tasks and wait for them. Let's remove the restriction by using
CoQueue. Code becomes clearer, interface more obvious.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Denis V. Lunev 
CC: Kevin Wolf 
CC: Max Reitz 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Vladimir Sementsov-Ogievskiy 
CC: Denis Plotnikov 
---
  block/aio_task.c | 21 ++---
  1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/block/aio_task.c b/block/aio_task.c
index 88989fa248..cf62e5c58b 100644
--- a/block/aio_task.c
+++ b/block/aio_task.c
@@ -27,11 +27,10 @@
  #include "block/aio_task.h"
  struct AioTaskPool {
-    Coroutine *main_co;
  int status;
  int max_busy_tasks;
  int busy_tasks;
-    bool waiting;
+    CoQueue waiters;
  };
  static void coroutine_fn aio_task_co(void *opaque)
@@ -52,31 +51,23 @@ static void coroutine_fn aio_task_co(void *opaque)
  g_free(task);
-    if (pool->waiting) {
-    pool->waiting = false;
-    aio_co_wake(pool->main_co);
-    }
+    qemu_co_queue_restart_all(&pool->waiters);
  }
  void coroutine_fn aio_task_pool_wait_one(AioTaskPool *pool)
  {
  assert(pool->busy_tasks > 0);
-    assert(qemu_coroutine_self() == pool->main_co);
-    pool->waiting = true;
-    qemu_coroutine_yield();
+    qemu_co_queue_wait(&pool->waiters, NULL);
-    assert(!pool->waiting);
  assert(pool->busy_tasks < pool->max_busy_tasks);


As we wake up several coroutines now, I'm afraid this assertion may start to 
fire.
And aio_task_pool_wait_one() becomes useless as a public API (still, it's used 
only locally, so we can make it static).

I'll send updated patch after reviewing the rest of the series.



Hm, OK, we have two kinds of waiters: waiting for a slot and for all tasks to 
finish. So, either we need two queues, or do like this patch (one queue, but 
wake-up all waiters, for them to check does their condition satisfied or not).

I'm OK with this patch with the following squashed-in:

diff --git a/include/block/aio_task.h b/include/block/aio_task.h
index 50bc1e1817..50b1c036c5 100644
--- a/include/block/aio_task.h
+++ b/include/block/aio_task.h
@@ -48,7 +48,6 @@ bool aio_task_pool_empty(AioTaskPool *pool);
 void coroutine_fn aio_task_pool_start_task(AioTaskPool *pool, AioTask *task);
 
 void coroutine_fn aio_task_pool_wait_slot(AioTaskPool *pool);

-void coroutine_fn aio_task_pool_wait_one(AioTaskPool *pool);
 void coroutine_fn aio_task_pool_wait_all(AioTaskPool *pool);
 
 #endif /* BLOCK_AIO_TASK_H */

diff --git a/block/aio_task.c b/block/aio_task.c
index cf62e5c58b..7ba15ff41f 100644
--- a/block/aio_task.c
+++ b/block/aio_task.c
@@ -54,26 +54,17 @@ static void coroutine_fn aio_task_co(void *opaque)
 qemu_co_queue_restart_all(&pool->waiters);
 }
 
-void coroutine_fn aio_task_pool_wait_one(AioTaskPool *pool)

-{
-assert(pool->busy_tasks > 0);
-
-qemu_co_queue_wait(&pool->waiters, NULL);
-
-assert(pool->busy_tasks < pool->max_busy_tasks);
-}
-
 void coroutine_fn aio_task_pool_wait_slot(AioTaskPool *pool)
 {
 while (pool->busy_tasks >= pool->max_busy_tasks) {
-aio_task_pool_wait_one(pool);
+qemu_co_queue_wait(&pool->waiters, NULL);
 }
 }
 
 void coroutine_fn aio_task_pool_wait_all(AioTaskPool *pool)

 {
 while (pool->busy_tasks > 0) {
-aio_task_pool_wait_one(pool);
+qemu_co_queue_wait(&pool->waiters, NULL);
 }
 }
 




--
Best regards,
Vladimir

Re: [PATCH v2] hmp: Make json format optional for qom-set

[Dr. David Alan Gilbert]

* Markus Armbruster (arm...@redhat.com) wrote:
> David Hildenbrand  writes:
> 
> > Commit 7d2ef6dcc1cf ("hmp: Simplify qom-set") switched to the json
> > parser, making it possible to specify complex types. However, with this
> > change it is no longer possible to specify proper sizes (e.g., 2G, 128M),
> > turning the interface harder to use for properties that consume sizes.
> >
> > Let's switch back to the previous handling and allow to specify passing
> > json via the "-j" parameter.
> 
> Two issues:
> 
> 1. Makes qom-get and qom-set inconsistent
> 
>qom-get formats as JSON, always.
> 
>qom-set parses the string visitor's undocumented ad hoc language by
>default.  You can make it parse JSON by passing -j.
> 
>Not a show stopper, but sure ugly.  I feel documentation should point
>it out.

I can imagine one way around this owuld be to remove the flag and make
it happen in the failure case; i.e.:

obj = qobject_from_json(value, &err);
if (err == NULL) {
qmp_qom_set(path, property, obj, &err);
} else {
somehow check if it parses with the integer parser and if it
does use object_property_parse
}

unfortunately that else path is a bit messy, because you need to pick a
parser in this case and then if that fails probably present the json
error message not it's error.

> 2. Rearms the string visitor death trap
> 
>If you try to qom-set a property whose ->set() uses something the
>string input visitor doesn't support, QEMU crashes.  I'm not aware of
>such a ->set(), but this is a death trap all the same.  Mind, I
>didn't actually *look* for such a ->set().  Details:
> 
> Subject: Re: [RFC PATCH] qom: Implement qom-get HMP command
> Date: Sat, 02 May 2020 08:02:43 +0200 (6 weeks, 2 days, 4 minutes ago)
> Message-ID: <87a72q6fi4@dusky.pond.sub.org>
> https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg00178.html
> 
>Since we've had this death trap in the code for a number of years, I
>can't call its restoration a show stopper.  It does feel like an
>unadvisable risk, though.

That just needs fixing in qom somewhere; it shouldn't assert - people
are too free with asserts.

Dave

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

Re: [PATCH v7 0/9] iotests: Dump QCOW2 dirty bitmaps metadata

[Vladimir Sementsov-Ogievskiy]

12.06.2020 03:04, Andrey Shinkevich wrote:

Note: based on the Vladimir's series
   [v5 00/13] iotests: Dump QCOW2 dirty bitmaps metadata


It's merged to master, so, based on master. (except for 01, which is not 
needed, thanks to Eric)



Add dirty bitmap information to QCOW2 metadata dump in the qcow2_format.py.

v7:
   01: Fix for magic hexadecimal output in 291
   02: Bitmap table output format improvement.
   03: Incremental change in the test 291 output.

v6:
   01: Fixing capitalization of header extension constant.
   (Suggested by Eric)
   02: The cluster size global variable discarded and passed as a parameter.
   03: Re-based to Vladimir's v5 series.
   04: The code of passing qcow2.py JSON format key moved to separate patch.
   05: Making dict(s) for dumping in JSON format was substituted with a copy
   of __dict__.

v5: The Vladimir's preliminary series
v4: The Vladimir's preliminary series

Andrey Shinkevich (9):
   iotests: Fix for magic hexadecimal output in 291
   qcow2: Fix capitalization of header extension constant.
   qcow2_format.py: make printable data an extension class member
   qcow2_format.py: Dump bitmap directory information
   qcow2_format.py: pass cluster size to substructures
   qcow2_format.py: Dump bitmap table serialized entries
   qcow2.py: Introduce '-j' key to dump in JSON format
   qcow2_format.py: collect fields to dump in JSON format
   qcow2_format.py: support dumping metadata in JSON format

  block/qcow2.c  |   2 +-
  docs/interop/qcow2.txt |   2 +-
  tests/qemu-iotests/291.out | 112 ++-
  tests/qemu-iotests/qcow2.py|  20 +++-
  tests/qemu-iotests/qcow2_format.py | 217 ++---
  5 files changed, 327 insertions(+), 26 deletions(-)




--
Best regards,
Vladimir

Re: [PATCH v7 1/9] iotests: Fix for magic hexadecimal output in 291

[Vladimir Sementsov-Ogievskiy]

12.06.2020 03:04, Andrey Shinkevich wrote:

This issue was introduced in the earlier patch:
"qcow2_format: refactor QcowHeaderExtension as a subclass of
Qcow2Struct".

Signed-off-by: Andrey Shinkevich 


This change was squashed to original commit


---
  tests/qemu-iotests/291.out | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/qemu-iotests/291.out b/tests/qemu-iotests/291.out
index 1d4f9cd..ccfcdc5 100644
--- a/tests/qemu-iotests/291.out
+++ b/tests/qemu-iotests/291.out
@@ -16,17 +16,17 @@ wrote 1048576/1048576 bytes at offset 2097152
  1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
  Check resulting qcow2 header extensions:
  Header extension:
-magic 3799591626 (Backing format)
+magic 0xe2792aca (Backing format)
  length5
  data  'qcow2'
  
  Header extension:

-magic 1745090647 (Feature table)
+magic 0x6803f857 (Feature table)
  length336
  data  
  
  Header extension:

-magic 595929205 (Bitmaps)
+magic 0x23852875 (Bitmaps)
  length24
  nb_bitmaps2
  reserved320
@@ -86,12 +86,12 @@ Format specific information:
  corrupt: false
  Check resulting qcow2 header extensions:
  Header extension:
-magic 1745090647 (Feature table)
+magic 0x6803f857 (Feature table)
  length336
  data  
  
  Header extension:

-magic 595929205 (Bitmaps)
+magic 0x23852875 (Bitmaps)
  length24
  nb_bitmaps3
  reserved320




--
Best regards,
Vladimir

Re: [PATCH v3] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Thomas Huth]

On 15/06/2020 11.19, Daniel P. Berrangé wrote:
> On Mon, Jun 15, 2020 at 09:49:19AM +0200, Philippe Mathieu-Daudé wrote:
>> The git-submodule.sh script is called by make and initialize the
>> submodules listed in the GIT_SUBMODULES variable generated by
>> ./configure.
>>
>> SLOF is required for building the s390-ccw firmware on s390x, since
>> it is using the libnet code from SLOF for network booting.
>>
>> Add it to the GIT_SUBMODULES when buildint the s390-ccw firmware,
>> to fix:
>>
>>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
>> path 'roms/SLOF'
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF'. Retry scheduled
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF' a second time, aborting
>>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
>> exited with 1.
> 
> The "git-submodule.sh" script just invokes "git submodule". So if
> you are getting DNS failures from "git submodule", using git-submodule.sh
> instead is not going to fix the problem.
> 
>>
>> Reported-by: Mark Cave-Ayland 
>> Suggested-by: Thomas Huth 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  configure   | 5 +
>>  .travis.yml | 1 -
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index bb7fd12612..927e4a3d06 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6533,6 +6533,11 @@ if test "$cpu" = "s390x" ; then
>>write_c_skeleton
>>if compile_prog "-march=z900" ""; then
>>  roms="$roms s390-ccw"
>> +# SLOF is required for building the s390-ccw firmware on s390x,
>> +# since it is using the libnet code from SLOF for network booting.
>> +if test -e "${source_path}/.git" ; then
>> +  git_submodules="${git_submodules} roms/SLOF"
>> +fi
>>fi
>>  fi
> 
> This whole bit of configure looks a bit dubious.
> 
> For all the other firmware images we ship as pre-built blobs, we never
> try to re-build them even if the host compiler supports it.

All the other firmwares have separate projects and repositories, so it's
normal that we don't try to rebuild them from the QEMU repo. But the
s390-ccw firmware is part of the QEMU repository (for some good
reasons), so of course we should build it during the QEMU build process
if possible. And no, please don't suggest to move it to a separate
repository instead, IIRC we've had this discussion in the past already,
and it is easier if it stays in the current place.

> So I don't think we need to make SLOF special.

We are not talking about SLOF here. We are talking about the s390-ccw
firmware which is part of the QEMU repository (see pc-bios/s390-ccw). It
just requires the SLOF submodule for building its network booting part,
since it re-uses the network stack from SLOF.

 Thomas

Re: KVM call for 2016-06-16

[Philippe Mathieu-Daudé]

Hi Juan,

On 6/15/20 11:34 AM, Juan Quintela wrote:
> 
> Hi
> 
> Please, send any topic that you are interested in covering.
> There is already a topic from last call:

This topic was already discussed in the last call :)

> 
> Last minute suggestion after recent IRC chat with Alex Bennée and
> Thomas Huth:
> 
> "Move some of the build/CI infrastructure to GitLab."
> 
> Pro/Con?
> 
>  - GitLab does not offer s390x/ppc64el => keep Travis for these?
> 
> How to coordinate efforts?
> 
> What we want to improve? Priorities?
> 
> Who can do which task / is motivated.
> 
> What has bugged us recently:
> - Cross-build images (currently rebuilt all the time on Shippable)
> 
> Long term interests:
> 
> - Collect quality metrics
>   . build time
>   . test duration
>   . performances
>   . binary size
>   . runtime memory used
> 
> - Collect code coverage
> 
> Note, this is orthogonal to the "Gating CI" task Cleber is working on:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg688150.html
> 
> 
> 
> 
> At the end of Monday I will send an email with the agenda or the
> cancellation of the call, so hurry up.
> 
> After discussions on the QEMU Summit, we are going to have always open a
> KVM call where you can add topics.
> 
>  Call details:
> 
> By popular demand, a google calendar public entry with it
> 
>   
> https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
> 
> (Let me know if you have any problems with the calendar entry.  I just
> gave up about getting right at the same time CEST, CET, EDT and DST).
> 
> If you need phone number details,  contact me privately
> 
> Thanks, Juan.
> 
> 

Re: [PATCH v7 2/9] qcow2: Fix capitalization of header extension constant.

[Vladimir Sementsov-Ogievskiy]

12.06.2020 03:04, Andrey Shinkevich wrote:

Make the capitalization of the hexadecimal numbers consistent for the
QCOW2 header extension constants in docs/interop/qcow2.txt.

Suggested-by: Eric Blake
Signed-off-by: Andrey Shinkevich



Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH v7 3/9] qcow2_format.py: make printable data an extension class member

[Vladimir Sementsov-Ogievskiy]

12.06.2020 03:04, Andrey Shinkevich wrote:

Let us differ binary data type from string one for the extension data
variable and keep the string as the QcowHeaderExtension class member.


Keep my r-b, but I just want to note, that I missed, what is the actual aim of 
this change..



Signed-off-by: Andrey Shinkevich 
Reviewed-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
  tests/qemu-iotests/qcow2_format.py | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/tests/qemu-iotests/qcow2_format.py 
b/tests/qemu-iotests/qcow2_format.py
index 0f65fd1..d4f 100644
--- a/tests/qemu-iotests/qcow2_format.py
+++ b/tests/qemu-iotests/qcow2_format.py
@@ -164,6 +164,13 @@ class QcowHeaderExtension(Qcow2Struct):
  self.data = fd.read(padded)
  assert self.data is not None
  
+data_str = self.data[:self.length]

+if all(c in string.printable.encode('ascii') for c in data_str):
+data_str = f"'{ data_str.decode('ascii') }'"
+else:
+data_str = ''
+self.data_str = data_str
+
  if self.magic == QCOW2_EXT_MAGIC_BITMAPS:
  self.obj = Qcow2BitmapExt(data=self.data)
  else:
@@ -173,12 +180,7 @@ class QcowHeaderExtension(Qcow2Struct):
  super().dump()
  
  if self.obj is None:

-data = self.data[:self.length]
-if all(c in string.printable.encode('ascii') for c in data):
-data = f"'{ data.decode('ascii') }'"
-else:
-data = ''
-print(f'{"data":<25} {data}')
+print(f'{"data":<25} {self.data_str}')
  else:
  self.obj.dump()
  




--
Best regards,
Vladimir

Re: [PATCH v3] configure: Let SLOF be initialized by ./scripts/git-submodule.sh

[Thomas Huth]

On 15/06/2020 10.28, Philippe Mathieu-Daudé wrote:
> On 6/15/20 10:13 AM, Thomas Huth wrote:
>> On 15/06/2020 09.49, Philippe Mathieu-Daudé wrote:
>>> The git-submodule.sh script is called by make and initialize the
>>> submodules listed in the GIT_SUBMODULES variable generated by
>>> ./configure.
>>>
>>> SLOF is required for building the s390-ccw firmware on s390x, since
>>> it is using the libnet code from SLOF for network booting.
>>>
>>> Add it to the GIT_SUBMODULES when buildint the s390-ccw firmware,
>>
>> s/buildint/building/
>>
>>> to fix:
>>>
>>>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
>>> path 'roms/SLOF'
>>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>>> resolve host: git.qemu.org
>>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>>   Failed to clone 'roms/SLOF'. Retry scheduled
>>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>>> resolve host: git.qemu.org
>>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>>   Failed to clone 'roms/SLOF' a second time, aborting
>>>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
>>> exited with 1.
>>
>> I still somehow doubt that this will really fix the issue that you've
>> seen here (why should it matter where the submodule is checked out?),
> 
> Yeah I still don't understand why the previous checkouts succeeded.
> 
> Is git.qemu.org cached by a CDN?

Is it still failing for you? For me it works fine:

 https://travis-ci.com/github/huth/qemu/jobs/349064333#L1531

 Thomas

[RFC PATCH] docs/devel: convert and update MTTCG design document

[Alex Bennée]

Do a light conversion to .rst and clean-up some of the language at the
start now MTTCG has been merged for a while.

Signed-off-by: Alex Bennée 
---
 docs/devel/index.rst  |  1 +
 ...ti-thread-tcg.txt => multi-thread-tcg.rst} | 52 ---
 2 files changed, 34 insertions(+), 19 deletions(-)
 rename docs/devel/{multi-thread-tcg.txt => multi-thread-tcg.rst} (90%)

diff --git a/docs/devel/index.rst b/docs/devel/index.rst
index bb8238c5d6d..4ecaea3643f 100644
--- a/docs/devel/index.rst
+++ b/docs/devel/index.rst
@@ -23,6 +23,7 @@ Contents:
decodetree
secure-coding-practices
tcg
+   multi-thread-tcg
tcg-plugins
bitops
reset
diff --git a/docs/devel/multi-thread-tcg.txt b/docs/devel/multi-thread-tcg.rst
similarity index 90%
rename from docs/devel/multi-thread-tcg.txt
rename to docs/devel/multi-thread-tcg.rst
index 3c85ac0eab9..42158b77c70 100644
--- a/docs/devel/multi-thread-tcg.txt
+++ b/docs/devel/multi-thread-tcg.rst
@@ -1,15 +1,17 @@
-Copyright (c) 2015-2016 Linaro Ltd.
+..
+  Copyright (c) 2015-2020 Linaro Ltd.
 
-This work is licensed under the terms of the GNU GPL, version 2 or
-later. See the COPYING file in the top-level directory.
+  This work is licensed under the terms of the GNU GPL, version 2 or
+  later. See the COPYING file in the top-level directory.
 
 Introduction
 
 
-This document outlines the design for multi-threaded TCG system-mode
-emulation. The current user-mode emulation mirrors the thread
-structure of the translated executable. Some of the work will be
-applicable to both system and linux-user emulation.
+This document outlines the design for multi-threaded TCG (a.k.a MTTCG)
+system-mode emulation. user-mode emulation has always mirrored the
+thread structure of the translated executable although some of the
+changes done for MTTCG system emulation have improved the stability of
+linux-user emulation.
 
 The original system-mode TCG implementation was single threaded and
 dealt with multiple CPUs with simple round-robin scheduling. This
@@ -21,9 +23,18 @@ vCPU Scheduling
 ===
 
 We introduce a new running mode where each vCPU will run on its own
-user-space thread. This will be enabled by default for all FE/BE
-combinations that have had the required work done to support this
-safely.
+user-space thread. This is enabled by default for all FE/BE
+combinations where the host memory model is able to accommodate the
+guest (TCG_GUEST_DEFAULT_MO & ~TCG_TARGET_DEFAULT_MO is zero) and the
+guest has had the required work done to support this safely
+(TARGET_SUPPORTS_MTTCG).
+
+System emulation will fall back to the original round robin approach
+if:
+
+* forced by --accel tcg,thread=single
+* enabling --icount mode
+* 64 bit guests on 32 bit hosts (TCG_OVERSIZED_GUEST)
 
 In the general case of running translated code there should be no
 inter-vCPU dependencies and all vCPUs should be able to run at full
@@ -61,7 +72,9 @@ have their block-to-block jumps patched.
 Global TCG State
 
 
-### User-mode emulation
+User-mode emulation
+~~~
+
 We need to protect the entire code generation cycle including any post
 generation patching of the translated code. This also implies a shared
 translation buffer which contains code running on all cores. Any
@@ -78,9 +91,11 @@ patching.
 
 Code generation is serialised with mmap_lock().
 
-### !User-mode emulation
+!User-mode emulation
+
+
 Each vCPU has its own TCG context and associated TCG region, thereby
-requiring no locking.
+requiring no locking during translation.
 
 Translation Blocks
 --
@@ -92,6 +107,7 @@ including:
 
   - debugging operations (breakpoint insertion/removal)
   - some CPU helper functions
+  - linux-user spawning it's first thread
 
 This is done with the async_safe_run_on_cpu() mechanism to ensure all
 vCPUs are quiescent when changes are being made to shared global
@@ -250,8 +266,10 @@ to enforce a particular ordering of memory operations from 
the point
 of view of external observers (e.g. another processor core). They can
 apply to any memory operations as well as just loads or stores.
 
-The Linux kernel has an excellent write-up on the various forms of
-memory barrier and the guarantees they can provide [1].
+The Linux kernel has an excellent `write-up
+`
+on the various forms of memory barrier and the guarantees they can
+provide.
 
 Barriers are often wrapped around synchronisation primitives to
 provide explicit memory ordering semantics. However they can be used
@@ -352,7 +370,3 @@ an exclusive lock which ensures all emulation is serialised.
 While the atomic helpers look good enough for now there may be a need
 to look at solutions that can more closely model the guest
 architectures semantics.
-
-==
-
-[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds

[PATCH v1 1/2] semihosting: defer connect_chardevs a little more to use serialx

[konrad]

From: KONRAD Frederic 

With that we can just use chardev=serial0.

Signed-off-by: KONRAD Frederic 
---
 softmmu/vl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index f669c06..9b8b48a 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -4123,8 +4123,6 @@ void qemu_init(int argc, char **argv, char **envp)
 
 qemu_opts_foreach(qemu_find_opts("chardev"),
   chardev_init_func, NULL, &error_fatal);
-/* now chardevs have been created we may have semihosting to connect */
-qemu_semihosting_connect_chardevs();
 
 #ifdef CONFIG_VIRTFS
 qemu_opts_foreach(qemu_find_opts("fsdev"),
@@ -4271,6 +4269,9 @@ void qemu_init(int argc, char **argv, char **envp)
 if (foreach_device_config(DEV_DEBUGCON, debugcon_parse) < 0)
 exit(1);
 
+/* now chardevs have been created we may have semihosting to connect */
+qemu_semihosting_connect_chardevs();
+
 /* If no default VGA is requested, the default is "none".  */
 if (default_vga) {
 vga_model = get_default_vga_model(machine_class);
-- 
1.8.3.1

[PATCH v1 2/2] semihosting: don't send the trailing '\0'

[konrad]

From: KONRAD Frederic 

Don't send the trailing 0 from the string.

Signed-off-by: KONRAD Frederic 
---
 hw/semihosting/console.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/semihosting/console.c b/hw/semihosting/console.c
index 22e7827..9b4fee9 100644
--- a/hw/semihosting/console.c
+++ b/hw/semihosting/console.c
@@ -52,7 +52,9 @@ static GString *copy_user_string(CPUArchState *env, 
target_ulong addr)
 
 do {
 if (cpu_memory_rw_debug(cpu, addr++, &c, 1, 0) == 0) {
-s = g_string_append_c(s, c);
+if (c) {
+s = g_string_append_c(s, c);
+}
 } else {
 qemu_log_mask(LOG_GUEST_ERROR,
   "%s: passed inaccessible address " TARGET_FMT_lx,
-- 
1.8.3.1

Re: [PULL v2 20/58] bios-tables-test: Add Q35/TPM-TIS test

[Philippe Mathieu-Daudé]

On Fri, Jun 12, 2020 at 5:00 PM Michael S. Tsirkin  wrote:
>
> From: Eric Auger 
>
> Test tables specific to the TPM-TIS instantiation.
> The TPM2 is added in the framework. Also the DSDT
> is updated with the TPM. The new function should be
> be usable for CRB as well, later one.
>
> Signed-off-by: Eric Auger 
>
> Message-Id: <20200609125409.24179-5-eric.au...@redhat.com>
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  tests/qtest/bios-tables-test.c | 58 ++
>  tests/qtest/Makefile.include   |  1 +
>  2 files changed, 59 insertions(+)
>
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index c9843829b3..53f104a9c5 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -57,6 +57,9 @@
>  #include "qemu/bitmap.h"
>  #include "acpi-utils.h"
>  #include "boot-sector.h"
> +#include "tpm-emu.h"
> +#include "hw/acpi/tpm.h"
> +
>
>  #define MACHINE_PC "pc"
>  #define MACHINE_Q35 "q35"
> @@ -874,6 +877,60 @@ static void test_acpi_piix4_tcg_numamem(void)
>  free_test_data(&data);
>  }
>
> +uint64_t tpm_tis_base_addr;
> +
> +static void test_acpi_tcg_tpm(const char *machine, const char *tpm_if,
> +  uint64_t base)
> +{
> +gchar *tmp_dir_name = g_strdup_printf("qemu-test_acpi_%s_tcg_%s.XX",
> +  machine, tpm_if);
> +char *tmp_path = g_dir_make_tmp(tmp_dir_name, NULL);
> +TestState test;
> +test_data data;
> +GThread *thread;
> +char *args, *variant = g_strdup_printf(".%s", tpm_if);
> +
> +tpm_tis_base_addr = base;
> +
> +module_call_init(MODULE_INIT_QOM);
> +
> +test.addr = g_new0(SocketAddress, 1);
> +test.addr->type = SOCKET_ADDRESS_TYPE_UNIX;
> +test.addr->u.q_unix.path = g_build_filename(tmp_path, "sock", NULL);
> +g_mutex_init(&test.data_mutex);
> +g_cond_init(&test.data_cond);
> +test.data_cond_signal = false;
> +
> +thread = g_thread_new(NULL, tpm_emu_ctrl_thread, &test);
> +tpm_emu_test_wait_cond(&test);
> +
> +memset(&data, 0, sizeof(data));
> +data.machine = machine;
> +data.variant = variant;
> +
> +args = g_strdup_printf(
> +" -chardev socket,id=chr,path=%s"
> +" -tpmdev emulator,id=dev,chardev=chr"

This test makes our CI fail:
https://gitlab.com/qemu-project/qemu/-/jobs/593586369#L3466

> +" -device tpm-%s,tpmdev=dev",
> +test.addr->u.q_unix.path, tpm_if);
> +
> +test_acpi_one(args, &data);
> +
> +g_thread_join(thread);
> +g_unlink(test.addr->u.q_unix.path);
> +qapi_free_SocketAddress(test.addr);
> +g_rmdir(tmp_path);
> +g_free(variant);
> +g_free(tmp_path);
> +g_free(tmp_dir_name);
> +free_test_data(&data);
> +}
> +
> +static void test_acpi_q35_tcg_tpm_tis(void)
> +{
> +test_acpi_tcg_tpm("q35", "tis", 0xFED4);
> +}
> +
>  static void test_acpi_tcg_dimm_pxm(const char *machine)
>  {
>  test_data data;
> @@ -1037,6 +1094,7 @@ int main(int argc, char *argv[])
>  return ret;
>  }
>
> +qtest_add_func("acpi/q35/tpm-tis", test_acpi_q35_tcg_tpm_tis);
>  qtest_add_func("acpi/piix4", test_acpi_piix4_tcg);
>  qtest_add_func("acpi/piix4/bridge", test_acpi_piix4_tcg_bridge);
>  qtest_add_func("acpi/q35", test_acpi_q35_tcg);
> diff --git a/tests/qtest/Makefile.include b/tests/qtest/Makefile.include
> index 9e5a51d033..5023fa413d 100644
> --- a/tests/qtest/Makefile.include
> +++ b/tests/qtest/Makefile.include
> @@ -262,6 +262,7 @@ tests/qtest/hd-geo-test$(EXESUF): 
> tests/qtest/hd-geo-test.o $(libqos-obj-y)
>  tests/qtest/boot-order-test$(EXESUF): tests/qtest/boot-order-test.o 
> $(libqos-obj-y)
>  tests/qtest/boot-serial-test$(EXESUF): tests/qtest/boot-serial-test.o 
> $(libqos-obj-y)
>  tests/qtest/bios-tables-test$(EXESUF): tests/qtest/bios-tables-test.o \
> +tests/qtest/tpm-emu.o $(test-io-obj-y) \
> tests/qtest/boot-sector.o tests/qtest/acpi-utils.o $(libqos-obj-y)
>  tests/qtest/pxe-test$(EXESUF): tests/qtest/pxe-test.o 
> tests/qtest/boot-sector.o $(libqos-obj-y)
>  tests/qtest/microbit-test$(EXESUF): tests/qtest/microbit-test.o
> --
> MST
>
>

Re: [PATCH v1 2/2] semihosting: don't send the trailing '\0'

[Philippe Mathieu-Daudé]

On 6/15/20 12:00 PM, kon...@adacore.com wrote:
> From: KONRAD Frederic 
> 
> Don't send the trailing 0 from the string.
> 

Fixes: a331c6d7741
Reviewed-by: Philippe Mathieu-Daudé 

> Signed-off-by: KONRAD Frederic 
> ---
>  hw/semihosting/console.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/semihosting/console.c b/hw/semihosting/console.c
> index 22e7827..9b4fee9 100644
> --- a/hw/semihosting/console.c
> +++ b/hw/semihosting/console.c
> @@ -52,7 +52,9 @@ static GString *copy_user_string(CPUArchState *env, 
> target_ulong addr)
>  
>  do {
>  if (cpu_memory_rw_debug(cpu, addr++, &c, 1, 0) == 0) {
> -s = g_string_append_c(s, c);
> +if (c) {
> +s = g_string_append_c(s, c);
> +}
>  } else {
>  qemu_log_mask(LOG_GUEST_ERROR,
>"%s: passed inaccessible address " TARGET_FMT_lx,
> 

Re: [PULL 082/116] target/i386: correct fix for pcmpxstrx substring search

[Philippe Mathieu-Daudé]

On 6/12/20 6:07 PM, Paolo Bonzini wrote:
> From: Joseph Myers 
> 
> This corrects a bug introduced in my previous fix for SSE4.2 pcmpestri
> / pcmpestrm / pcmpistri / pcmpistrm substring search, commit
> ae35eea7e4a9f21dd147406dfbcd0c4c6aaf2a60.
> 
> That commit fixed a bug that showed up in four GCC tests with one libc
> implementation.  The tests in question generate random inputs to the
> intrinsics and compare results to a C implementation, but they only
> test 1024 possible random inputs, and when the tests use the cases of
> those instructions that work with word rather than byte inputs, it's
> easy to have problematic cases that show up much less frequently than
> that.  Thus, testing with a different libc implementation, and so a
> different random number generator, showed up a problem with the
> previous patch.
> 
> When investigating the previous test failures, I found the description
> of these instructions in the Intel manuals (starting from computing a
> 16x16 or 8x8 set of comparison results) confusing and hard to match up
> with the more optimized implementation in QEMU, and referred to AMD
> manuals which described the instructions in a different way.  Those
> AMD descriptions are very explicit that the whole of the string being
> searched for must be found in the other operand, not running off the
> end of that operand; they say "If the prototype and the SUT are equal
> in length, the two strings must be identical for the comparison to be
> TRUE.".  However, that statement is incorrect.
> 
> In my previous commit message, I noted:
> 
>   The operation in this case is a search for a string (argument d to
>   the helper) in another string (argument s to the helper); if a copy
>   of d at a particular position would run off the end of s, the
>   resulting output bit should be 0 whether or not the strings match in
>   the region where they overlap, but the QEMU implementation was
>   wrongly comparing only up to the point where s ends and counting it
>   as a match if an initial segment of d matched a terminal segment of
>   s.  Here, "run off the end of s" means that some byte of d would
>   overlap some byte outside of s; thus, if d has zero length, it is
>   considered to match everywhere, including after the end of s.
> 
> The description "some byte of d would overlap some byte outside of s"
> is accurate only when understood to refer to overlapping some byte
> *within the 16-byte operand* but at or after the zero terminator; it
> is valid to run over the end of s if the end of s is the end of the
> 16-byte operand.  So the fix in the previous patch for the case of d
> being empty was correct, but the other part of that patch was not
> correct (as it never allowed partial matches even at the end of the
> 16-byte operand).  Nor was the code before the previous patch correct
> for the case of d nonempty, as it would always have allowed partial
> matches at the end of s.
> 
> Fix with a partial revert of my previous change, combined with
> inserting a check for the special case of s having maximum length to
> determine where it is necessary to check for matches.
> 
> In the added test, test 1 is for the case of empty strings, which
> failed before my 2017 patch, test 2 is for the bug introduced by my
> 2017 patch and test 3 deals with the case where a match of an initial
> segment at the end of the string is not valid when the string ends
> before the end of the 16-byte operand (that is, the case that would be
> broken by a simple revert of the non-empty-string part of my 2017
> patch).
> 
> Signed-off-by: Joseph Myers 
> Message-Id: 
> Signed-off-by: Paolo Bonzini 
> ---
>  target/i386/ops_sse.h|  4 ++--
>  tests/tcg/i386/Makefile.target   |  3 +++
>  tests/tcg/i386/test-i386-pcmpistri.c | 33 
>  3 files changed, 38 insertions(+), 2 deletions(-)
>  create mode 100644 tests/tcg/i386/test-i386-pcmpistri.c
> 
> diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
> index 01d6017412..14f2b16abd 100644
> --- a/target/i386/ops_sse.h
> +++ b/target/i386/ops_sse.h
> @@ -2089,10 +2089,10 @@ static inline unsigned pcmpxstrx(CPUX86State *env, 
> Reg *d, Reg *s,
>  res = (2 << upper) - 1;
>  break;
>  }
> -for (j = valids - validd; j >= 0; j--) {
> +for (j = valids == upper ? valids : valids - validd; j >= 0; j--) {
>  res <<= 1;
>  v = 1;
> -for (i = validd; i >= 0; i--) {
> +for (i = MIN(valids - j, validd); i >= 0; i--) {
>  v &= (pcmp_val(s, ctrl, i + j) == pcmp_val(d, ctrl, i));
>  }
>  res |= v;
> diff --git a/tests/tcg/i386/Makefile.target b/tests/tcg/i386/Makefile.target
> index 43ee2e181e..53efec0668 100644
> --- a/tests/tcg/i386/Makefile.target
> +++ b/tests/tcg/i386/Makefile.target
> @@ -10,6 +10,9 @@ ALL_X86_TESTS=$(I386_SRCS:.c=)
>  SKIP_I386_TESTS=test-i386-ssse3
>  X86_64_TESTS:=$(filter test-i386-ssse

RE: [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch

[Salil Mehta]

Hi Marc,
Thanks for the review.

> From: Marc Zyngier [mailto:m...@kernel.org]
> Sent: Sunday, June 14, 2020 12:55 PM
> 
> Hi Salil,
> 
> On 2020-06-13 22:36, Salil Mehta wrote:
> > This patch-set introduces the virtual cpu hotplug support for ARMv8
> > architecture in QEMU. Idea is to be able to hotplug and hot-unplug the
> > vcpus
> > while guest VM is running and no reboot is required. This does *not*
> > makes any
> > assumption of the physical cpu hotplug availability within the host
> > system but
> > rather tries to solve the problem at virtualizer/QEMU layer and by
> > introducing
> > cpu hotplug hooks and event handling within the guest kernel. No
> > changes are
> > required within the host kernel/KVM.
> >
> > Motivation:
> > This allows scaling the guest VM compute capacity on-demand which would
> > be
> > useful for the following example scenarios,
> > 1. Vertical Pod Autoscaling[3][4] in the cloud: Part of the
> > orchestration
> >framework which could adjust resource requests (CPU and Mem
> > requests) for
> >the containers in a pod, based on usage.
> > 2. Pay-as-you-grow Business Model: Infrastructure provider could
> > allocate and
> >restrict the total number of compute resources available to the
> > guest VM
> >according to the SLA(Service Level Agreement). VM owner could
> > request for
> >more compute to be hot-plugged for some cost.
> >
> > Terminology:
> >
> > (*) Present cpus: Total cpus with which guest has/will boot and are
> > available
> >   to guest for use and can be onlined. Qemu
> > parameter(-smp)
> > (*) Disabled cpus: Possible cpus which will not be available for the
> > guest to
> >use. These can be hotplugged and made present. These
> > can be
> >thought of as un-plugged vcpus. These will be included as
> >part of sizing.
> > (*) Posssible cpus: Total vcpus which could ever exist in VM. This
> > includes
> > booted cpus plus any cpus which could be later
> > plugged.
> > - Qemu parameter(-maxcpus)
> > - Possible vcpus = Present vcpus (+) Disabled vcpus
> >
> >
> > Limitations of ARMv8 Architecture:
> >
> > A. Physical Limitation to CPU Hotplug:
> > 1. ARMv8 architecture does not support the concept of the physical cpu
> > hotplug.
> >The closest thing which is recomended to achieve the cpu hotplug on
> > ARM is
> >to bring down power state of the cpu using PSCI.
> 
> It isn't so much that the ARMv8 architecture doesn't support CPU
> hotplug. It is that CPU hotplug is largely out of the scope of the ARMv8
> architecture, which is a CPU architecture and not a system architecture.
> Yes, the lack of a comprehensive system architecture is *very* annoying,
> but let's put the blame where it belongs... ;-)


Sure.

 
> > 2. Other ARM components like GIC etc. have not been designed to realize
> >physical cpu hotplug capability as of now.
> >
> > B. Limitations of GIC to Support Virtual CPU Hotplug:
> > 1. GIC requires various resources(related to GICR/redistributor,
> > GICC/cpu
> >interface etc) like memory regions to be fixed at the VM init time
> > and these
> >could not be changed later on after VM has inited.
> > 2. Associations between GICC(GIC cpu interface) and vcpu get fixed at
> > the VM
> >init time and GIC does not allows to change this association once
> > GIC has
> >initialized.
> 
> There isn't an association, really. the GIC CPU interface is part of the
> CPU itself, and not an external entity. KVM doesn't split the two
> either. It is the association between the CPU and its redistributor that
> is being done. There is no architectural way to set this up this, so KVM
> just statically configures these based on the number of vcpus and the
> number/size of redistributor ranges.


I stand corrected. Sorry for the horrible mix up and I realized that some
how I copied the same terminology at other 2 other places as well, maybe
under sleep duress :(. I will correct it in later versions.

To be frank, I actually meant association of "mp-affinity" and the
"proc number" as given by GICR_TYPER register for the vgic. I guess reading
this register using kvm_gicr_acces/KVM_DEV_ARM_VGIC_GRP_REDIST_REGS from
QEMU lands up in vgic vgic_mmio_read_v3r_typer() which forms the reg value
using "vcpu-id" and "mpidr"(fetched from MPIDR_EL1).

Also, value of the MPIDR for vcpu is set during KVM_ARM_VCPU_INIT IOCTL
from QEMU after the creation of the vcpus(using KVM_CREATE_VCPU). I guess
this is done during reset of all of the system regs  SYS_MPIDR_EL1 value
is also reset to default within function reset_mpidr() derived using below
logic:

   +++++++++
  MPIDR   |||  Res   |   Aff2  |   Aff1   |  Aff0|
   +++++++++
\  \  \   | |
 \ 

Re: [PULL v2 20/58] bios-tables-test: Add Q35/TPM-TIS test

[Thomas Huth]

On 15/06/2020 12.02, Philippe Mathieu-Daudé wrote:
> On Fri, Jun 12, 2020 at 5:00 PM Michael S. Tsirkin  wrote:
>>
>> From: Eric Auger 
>>
>> Test tables specific to the TPM-TIS instantiation.
>> The TPM2 is added in the framework. Also the DSDT
>> is updated with the TPM. The new function should be
>> be usable for CRB as well, later one.
>>
>> Signed-off-by: Eric Auger 
>>
>> Message-Id: <20200609125409.24179-5-eric.au...@redhat.com>
>> Reviewed-by: Michael S. Tsirkin 
>> Signed-off-by: Michael S. Tsirkin 
>> ---
>>  tests/qtest/bios-tables-test.c | 58 ++
>>  tests/qtest/Makefile.include   |  1 +
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>> index c9843829b3..53f104a9c5 100644
>> --- a/tests/qtest/bios-tables-test.c
>> +++ b/tests/qtest/bios-tables-test.c
>> @@ -57,6 +57,9 @@
>>  #include "qemu/bitmap.h"
>>  #include "acpi-utils.h"
>>  #include "boot-sector.h"
>> +#include "tpm-emu.h"
>> +#include "hw/acpi/tpm.h"
>> +
>>
>>  #define MACHINE_PC "pc"
>>  #define MACHINE_Q35 "q35"
>> @@ -874,6 +877,60 @@ static void test_acpi_piix4_tcg_numamem(void)
>>  free_test_data(&data);
>>  }
>>
>> +uint64_t tpm_tis_base_addr;
>> +
>> +static void test_acpi_tcg_tpm(const char *machine, const char *tpm_if,
>> +  uint64_t base)
>> +{
>> +gchar *tmp_dir_name = g_strdup_printf("qemu-test_acpi_%s_tcg_%s.XX",
>> +  machine, tpm_if);
>> +char *tmp_path = g_dir_make_tmp(tmp_dir_name, NULL);
>> +TestState test;
>> +test_data data;
>> +GThread *thread;
>> +char *args, *variant = g_strdup_printf(".%s", tpm_if);
>> +
>> +tpm_tis_base_addr = base;
>> +
>> +module_call_init(MODULE_INIT_QOM);
>> +
>> +test.addr = g_new0(SocketAddress, 1);
>> +test.addr->type = SOCKET_ADDRESS_TYPE_UNIX;
>> +test.addr->u.q_unix.path = g_build_filename(tmp_path, "sock", NULL);
>> +g_mutex_init(&test.data_mutex);
>> +g_cond_init(&test.data_cond);
>> +test.data_cond_signal = false;
>> +
>> +thread = g_thread_new(NULL, tpm_emu_ctrl_thread, &test);
>> +tpm_emu_test_wait_cond(&test);
>> +
>> +memset(&data, 0, sizeof(data));
>> +data.machine = machine;
>> +data.variant = variant;
>> +
>> +args = g_strdup_printf(
>> +" -chardev socket,id=chr,path=%s"
>> +" -tpmdev emulator,id=dev,chardev=chr"
> 
> This test makes our CI fail:
> https://gitlab.com/qemu-project/qemu/-/jobs/593586369#L3466

Right. The problem seems to occur as soon as you run "configure" with
"--disable-tpm" ... I think you need some "#ifdef CONFIG_TPM" here?

 Thomas

Re: KVM call for 2016-06-16

[Juan Quintela]

Philippe Mathieu-Daudé  wrote:
> Hi Juan,
>
> On 6/15/20 11:34 AM, Juan Quintela wrote:
>> 
>> Hi
>> 
>> Please, send any topic that you are interested in covering.
>> There is already a topic from last call:
>
> This topic was already discussed in the last call :)

Sorry.

My understanding from last call was that we wanted to discuss it with
more people from more organizations.

Later, Juan.

Re: [PATCH v8 00/14] target/mips: MSA, FPU and other cleanups and improvements

[Aleksandar Rikalo]

This series contains some patches that split heprers in msa_helper.c.
It will make easier for debugging tools to display involved source
code, and also introduces some modest performance improvements gains
for all involved MSA instructions.

v7->v8:

   - added six new demacroing patches

v6->v7:

   - excluded patches that have been already upstreamed
   - added six new demacroing patches

v5->v6:

   - excluded a patch that was included by mistake

v4->v5:

   - corrected some spelling and style mistakes in commit messages
   - added changing MAINTAINERS too while renaming files
   - added two patches on splitting helpers in msa_helper.c

v3->v4:

   - corrected some spelling and style mistakes in commit messages
   - added a patch on renaming some files in hw/mips

v2->v3:

   - changed Malta patch to perform logging
   - added change of Aleksandar Rikalo's email

v1->v2:

   - added more demacroing

Aleksandar Markovic (14):
   target/mips: msa: Split helpers for MADDV.
   target/mips: msa: Split helpers for MSUBV.
   target/mips: msa: Split helpers for DPADD_S.
   target/mips: msa: Split helpers for DPADD_U.
   target/mips: msa: Split helpers for DPSUB_S.
   target/mips: msa: Split helpers for DPSUB_U.
   target/mips: msa: Split helpers for DOTP_S.
   target/mips: msa: Split helpers for DOTP_U.
   target/mips: msa: Split helpers for SUBS_S.
   target/mips: msa: Split helpers for SUBS_U.
   target/mips: msa: Split helpers for SUBSUS_U.
   target/mips: msa: Split helpers for SUBSUU_S.
   target/mips: msa: Split helpers for SUBV.
   target/mips: msa: Split helpers for MULV.

  target/mips/helper.h |   73 ++-
  target/mips/msa_helper.c | 1296 ++
  target/mips/translate.c  |  200 +-
  3 files changed, 1271 insertions(+), 298 deletions(-)


For the whole series:
Reviewed-by: Aleksandar Rikalo 

Please run all regression tests. Thank you.

Aleksandar Rikalo

Re: [PATCH v7 4/9] qcow2_format.py: Dump bitmap directory information

[Vladimir Sementsov-Ogievskiy]

12.06.2020 03:04, Andrey Shinkevich wrote:

Read and dump entries from the bitmap directory of QCOW2 image.
It extends the output in the test case #291.

Header extension:
magic 0x23852875 (Bitmaps)
...
Bitmap name   bitmap-1
flag  auto
table size8 (bytes)
bitmap_table_offset   0x9
bitmap_table_size 1
flags 0
type  1
granularity_bits  16
name_size 8
extra_data_size   0

Suggested-by: Kevin Wolf 
Signed-off-by: Andrey Shinkevich 
Reviewed-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 


Hmm I don't remember me gave it..


---
  tests/qemu-iotests/291.out | 52 ++
  tests/qemu-iotests/qcow2_format.py | 75 ++
  2 files changed, 127 insertions(+)

diff --git a/tests/qemu-iotests/291.out b/tests/qemu-iotests/291.out
index ccfcdc5..d847419 100644
--- a/tests/qemu-iotests/291.out
+++ b/tests/qemu-iotests/291.out
@@ -33,6 +33,27 @@ reserved320
  bitmap_directory_size 0x40
  bitmap_directory_offset   0x51
  
+Bitmap name   b1

+table size8 (bytes)
+bitmap_table_offset   0x4e
+bitmap_table_size 1
+flags 0
+type  1
+granularity_bits  19
+name_size 2
+extra_data_size   0
+
+Bitmap name   b2
+flag  auto
+table size8 (bytes)
+bitmap_table_offset   0x50
+bitmap_table_size 1
+flags 2


both having flags and flag in the output looks strange.

If you want good human look of flags field, you should implement a special 
formatter-class for it, like Flags64.
Maybe, something like this:

flags  0x3 (in_use auto)



+type  1
+granularity_bits  16
+name_size 2
+extra_data_size   0
+
  
  === Bitmap preservation not possible to non-qcow2 ===
  
@@ -98,6 +119,37 @@ reserved320

  bitmap_directory_size 0x60
  bitmap_directory_offset   0x52
  
+Bitmap name   b1

+table size8 (bytes)
+bitmap_table_offset   0x47
+bitmap_table_size 1
+flags 0
+type  1
+granularity_bits  19
+name_size 2
+extra_data_size   0
+
+Bitmap name   b2
+flag  auto
+table size8 (bytes)
+bitmap_table_offset   0x49
+bitmap_table_size 1
+flags 2
+type  1
+granularity_bits  16
+name_size 2
+extra_data_size   0
+
+Bitmap name   b0
+table size8 (bytes)
+bitmap_table_offset   0x51
+bitmap_table_size 1
+flags 0
+type  1
+granularity_bits  16
+name_size 2
+extra_data_size   0
+
  
  === Check bitmap contents ===
  
diff --git a/tests/qemu-iotests/qcow2_format.py b/tests/qemu-iotests/qcow2_format.py

index d4f..90eff92 100644
--- a/tests/qemu-iotests/qcow2_format.py
+++ b/tests/qemu-iotests/qcow2_format.py
@@ -103,6 +103,10 @@ class Qcow2Struct(metaclass=Qcow2StructMeta):
  print('{:<25} {}'.format(f[2], value_str))
  
  
+# seek relative to the current position in the file

+FROM_CURRENT = 1


Firstly, I though that it's a global variable to control class behavior. Only 
than I understood that you just decided to use a named constant instead of just 
1...

So, I'd prefer to use just 1.


+
+
  class Qcow2BitmapExt(Qcow2Struct):
  
  fields = (

@@ -112,6 +116,73 @@ class Qcow2BitmapExt(Qcow2Struct):
  ('u64', '{:#x}', 'bitmap_directory_offset')
  )
  
+def read_bitmap_directory(self, fd):

+self.bitmaps = []
+fd.seek(self.bitmap_directory_offset)
+buf_size = struct.calcsize(Qcow2BitmapDirEntry.fmt)
+
+for n in range(self.nb_bitmaps):
+buf = fd.read(buf_size)
+dir_entry = Qcow2BitmapDirEntry(data=buf)


Base class of Qcow2BitmapDirEntry can load from fd. We should definitely 
utilize this possibility, instead of writing it again.


+fd.seek(dir_entry.extra_data_size, FROM_CURRENT)
+bitmap_name = fd.read(dir_entry.name_size)
+dir_entry.name = bitmap_name.decode('ascii')


You should initialize object in its constructor, not by hand here.

Actually, the code here should look like this:

self.bitmap_directory = [Qcow2BitmapDirEntry(fd) for _ in 
range(self.nb_bitmaps)]

OK, you may leave a loop, and even calculating of final alignment here, but 
real fields should be read and initialized in Qcow2BitmapDirEntry constructor
   


+self.bitmaps.append(dir_entry)
+entry_raw_size = dir_entry.bitmap_dir_entry_raw_size()
+shift = ((

[PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface

[Philippe Mathieu-Daudé]

The FW_CFG_DATA_GENERATOR allows any object to produce
blob of data consumable by the fw_cfg device.

Reviewed-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/specs/fw_cfg.txt |  9 ++-
 include/hw/nvram/fw_cfg.h | 52 +++
 hw/nvram/fw_cfg.c | 36 +++
 3 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index 8f1ebc66fa..bc16daa38a 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -219,7 +219,7 @@ To check the result, read the "control" field:
 
 = Externally Provided Items =
 
-As of v2.4, "file" fw_cfg items (i.e., items with selector keys above
+Since v2.4, "file" fw_cfg items (i.e., items with selector keys above
 FW_CFG_FILE_FIRST, and with a corresponding entry in the fw_cfg file
 directory structure) may be inserted via the QEMU command line, using
 the following syntax:
@@ -230,6 +230,13 @@ Or
 
 -fw_cfg [name=],string=
 
+Since v5.1, QEMU allows some objects to generate fw_cfg-specific content,
+the content is then associated with a "file" item using the 'gen_id' option
+in the command line, using the following syntax:
+
+-object ,id=,[generator-specific-options] \
+-fw_cfg [name=],gen_id=
+
 See QEMU man page for more documentation.
 
 Using item_name with plain ASCII characters only is recommended.
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 25d9307018..ca69666847 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -9,11 +9,43 @@
 #define TYPE_FW_CFG "fw_cfg"
 #define TYPE_FW_CFG_IO  "fw_cfg_io"
 #define TYPE_FW_CFG_MEM "fw_cfg_mem"
+#define TYPE_FW_CFG_DATA_GENERATOR_INTERFACE "fw_cfg-data-generator"
 
 #define FW_CFG(obj) OBJECT_CHECK(FWCfgState,(obj), TYPE_FW_CFG)
 #define FW_CFG_IO(obj)  OBJECT_CHECK(FWCfgIoState,  (obj), TYPE_FW_CFG_IO)
 #define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
 
+#define FW_CFG_DATA_GENERATOR_CLASS(class) \
+OBJECT_CLASS_CHECK(FWCfgDataGeneratorClass, (class), \
+   TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
+#define FW_CFG_DATA_GENERATOR_GET_CLASS(obj) \
+OBJECT_GET_CLASS(FWCfgDataGeneratorClass, (obj), \
+ TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
+
+typedef struct FWCfgDataGeneratorClass {
+/*< private >*/
+InterfaceClass parent_class;
+/*< public >*/
+
+/**
+ * get_data:
+ * @obj: the object implementing this interface
+ *
+ * Returns: pointer to start of the generated item data
+ *
+ * The returned pointer is a QObject weak reference, @obj owns
+ * the reference and may free it at any time in the future.
+ */
+const void *(*get_data)(Object *obj);
+/**
+ * get_length:
+ * @obj: the object implementing this interface
+ *
+ * Returns: the size of the generated item data in bytes
+ */
+size_t (*get_length)(Object *obj);
+} FWCfgDataGeneratorClass;
+
 typedef struct fw_cfg_file FWCfgFile;
 
 #define FW_CFG_ORDER_OVERRIDE_VGA70
@@ -263,6 +295,26 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char 
*filename,
 void *fw_cfg_modify_file(FWCfgState *s, const char *filename, void *data,
  size_t len);
 
+/**
+ * fw_cfg_add_from_generator:
+ * @s: fw_cfg device being modified
+ * @filename: name of new fw_cfg file item
+ * @gen_id: name of object implementing FW_CFG_DATA_GENERATOR interface
+ * @errp: pointer to a NULL initialized error object
+ *
+ * Add a new NAMED fw_cfg item with the content generated from the
+ * @gen_id object. The data generated by the @gen_id object is copied
+ * into the data structure of the fw_cfg device.
+ * The next available (unused) selector key starting at FW_CFG_FILE_FIRST
+ * will be used; also, a new entry will be added to the file directory
+ * structure residing at key value FW_CFG_FILE_DIR, containing the item name,
+ * data size, and assigned selector key value.
+ *
+ * Returns: the size of the generated item data on success, or 0 on errors.
+ */
+size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
+ const char *gen_id, Error **errp);
+
 FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
 AddressSpace *dma_as);
 FWCfgState *fw_cfg_init_io(uint32_t iobase);
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 8dd50c2c72..84578e83aa 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -1032,6 +1032,36 @@ void *fw_cfg_modify_file(FWCfgState *s, const char 
*filename,
 return NULL;
 }
 
+size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
+ const char *gen_id, Error **errp)
+{
+FWCfgDataGeneratorClass *klass;
+Object *obj;
+size_t size;
+
+obj = object_resolve_path_component(object_get_objects_root(), gen_id);
+if (!obj) {
+error_setg(

[PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites

[Philippe Mathieu-Daudé]

Hi,

This series has two parts:

- First we add the ability to QOM objects to produce data
  consumable by the fw_cfg device,

- Then we add the tls-cipher-suites object, and let it
  implement the FW_CFG_DATA_GENERATOR interface.

This is required by EDK2 'HTTPS Boot' feature [*] to tell
the guest which TLS ciphers it can use.

** Unresolved item: **
- Should a generated fw_cfg entry use a specific global order?
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02309.html

^ Gerd can you help?

Daniel, can you review/ack?

Since v8:
- addressed Laszlo review comments (reword/typos)
Since v7:
- addressed Laszlo review comments
Since v6:
- addressed Laszlo & Daniel review comments
Since v5:
- Complete rewrite after chatting with Daniel Berrangé
Since v4:
- Addressed Laszlo comments (see patch#1 description)
Since v3:
- Addressed Markus' comments (do not care about heap)
Since v2:
- Split of
Since v1:
- Addressed Michael and Laszlo comments.

Phil.

[*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
v8: https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02428.html
v7: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08050.html
v6: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05448.html
v5: https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04525.html
v4: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04300.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02965.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02522.html
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg01598.html

Philippe Mathieu-Daudé (5):
  hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
  softmmu/vl: Let -fw_cfg option take a 'gen_id' argument
  softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace
  crypto: Add tls-cipher-suites object
  crypto/tls-cipher-suites: Produce fw_cfg consumable blob

 docs/specs/fw_cfg.txt  |  13 ++-
 include/crypto/tls-cipher-suites.h |  38 
 include/hw/nvram/fw_cfg.h  |  52 ++
 crypto/tls-cipher-suites.c | 146 +
 hw/nvram/fw_cfg.c  |  36 +++
 softmmu/vl.c   |  33 +--
 crypto/Makefile.objs   |   1 +
 crypto/trace-events|   5 +
 qemu-options.hx|  37 
 9 files changed, 351 insertions(+), 10 deletions(-)
 create mode 100644 include/crypto/tls-cipher-suites.h
 create mode 100644 crypto/tls-cipher-suites.c

-- 
2.21.3

[PATCH v9 4/5] crypto: Add tls-cipher-suites object

[Philippe Mathieu-Daudé]

On the host OS, various aspects of TLS operation are configurable.
In particular it is possible for the sysadmin to control the TLS
cipher/protocol algorithms that applications are permitted to use.

* Any given crypto library has a built-in default priority list
  defined by the distro maintainer of the library package (or by
  upstream).

* The "crypto-policies" RPM (or equivalent host OS package)
  provides a config file such as "/etc/crypto-policies/config",
  where the sysadmin can set a high level (library-independent)
  policy.

  The "update-crypto-policies --set" command (or equivalent) is
  used to translate the global policy to individual library
  representations, producing files such as
  "/etc/crypto-policies/back-ends/*.config". The generated files,
  if present, are loaded by the various crypto libraries to
  override their own built-in defaults.

  For example, the GNUTLS library may read
  "/etc/crypto-policies/back-ends/gnutls.config".

* A management application (or the QEMU user) may overide the
  system-wide crypto-policies config via their own config, if
  they need to diverge from the former.

Thus the priority order is "QEMU user config" > "crypto-policies
system config" > "library built-in config".

Introduce the "tls-cipher-suites" object for exposing the ordered
list of permitted TLS cipher suites from the host side to the
guest firmware, via fw_cfg. The list is represented as an array
of IANA_TLS_CIPHER objects. The firmware uses the IANA_TLS_CIPHER
array for configuring guest-side TLS, for example in UEFI HTTPS
Boot.

The priority at which the host-side policy is retrieved is given
by the "priority" property of the new object type. For example,
"priority=@SYSTEM" may be used to refer to
"/etc/crypto-policies/back-ends/gnutls.config" (given that QEMU
uses GNUTLS).

[Description from Daniel P. Berrangé, edited by Laszlo Ersek.]

Example of use to dump the cipher suites:

  $ qemu-system-x86_64 -S \
-object tls-cipher-suites,id=mysuite,priority=@SYSTEM \
-trace qcrypto\*
  159066.197123:qcrypto_tls_cipher_suite_priority priority: @SYSTEM
  159066.197219:qcrypto_tls_cipher_suite_info data=[0x13,0x02] 
version=TLS1.3 name=TLS_AES_256_GCM_SHA384
  159066.197228:qcrypto_tls_cipher_suite_info data=[0x13,0x03] 
version=TLS1.3 name=TLS_CHACHA20_POLY1305_SHA256
  159066.197233:qcrypto_tls_cipher_suite_info data=[0x13,0x01] 
version=TLS1.3 name=TLS_AES_128_GCM_SHA256
  159066.197236:qcrypto_tls_cipher_suite_info data=[0x13,0x04] 
version=TLS1.3 name=TLS_AES_128_CCM_SHA256
  159066.197240:qcrypto_tls_cipher_suite_info data=[0xc0,0x30] 
version=TLS1.2 name=TLS_ECDHE_RSA_AES_256_GCM_SHA384
  159066.197245:qcrypto_tls_cipher_suite_info data=[0xcc,0xa8] 
version=TLS1.2 name=TLS_ECDHE_RSA_CHACHA20_POLY1305
  159066.197250:qcrypto_tls_cipher_suite_info data=[0xc0,0x14] 
version=TLS1.0 name=TLS_ECDHE_RSA_AES_256_CBC_SHA1
  159066.197254:qcrypto_tls_cipher_suite_info data=[0xc0,0x2f] 
version=TLS1.2 name=TLS_ECDHE_RSA_AES_128_GCM_SHA256
  159066.197258:qcrypto_tls_cipher_suite_info data=[0xc0,0x13] 
version=TLS1.0 name=TLS_ECDHE_RSA_AES_128_CBC_SHA1
  159066.197261:qcrypto_tls_cipher_suite_info data=[0xc0,0x2c] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
  159066.197266:qcrypto_tls_cipher_suite_info data=[0xcc,0xa9] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_CHACHA20_POLY1305
  159066.197270:qcrypto_tls_cipher_suite_info data=[0xc0,0xad] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_CCM
  159066.197274:qcrypto_tls_cipher_suite_info data=[0xc0,0x0a] 
version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_256_CBC_SHA1
  159066.197278:qcrypto_tls_cipher_suite_info data=[0xc0,0x2b] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
  159066.197283:qcrypto_tls_cipher_suite_info data=[0xc0,0xac] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_CCM
  159066.197287:qcrypto_tls_cipher_suite_info data=[0xc0,0x09] 
version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_128_CBC_SHA1
  159066.197291:qcrypto_tls_cipher_suite_info data=[0x00,0x9d] 
version=TLS1.2 name=TLS_RSA_AES_256_GCM_SHA384
  159066.197296:qcrypto_tls_cipher_suite_info data=[0xc0,0x9d] 
version=TLS1.2 name=TLS_RSA_AES_256_CCM
  159066.197300:qcrypto_tls_cipher_suite_info data=[0x00,0x35] 
version=TLS1.0 name=TLS_RSA_AES_256_CBC_SHA1
  159066.197304:qcrypto_tls_cipher_suite_info data=[0x00,0x9c] 
version=TLS1.2 name=TLS_RSA_AES_128_GCM_SHA256
  159066.197308:qcrypto_tls_cipher_suite_info data=[0xc0,0x9c] 
version=TLS1.2 name=TLS_RSA_AES_128_CCM
  159066.197312:qcrypto_tls_cipher_suite_info data=[0x00,0x2f] 
version=TLS1.0 name=TLS_RSA_AES_128_CBC_SHA1
  159066.197316:qcrypto_tls_cipher_suite_info data=[0x00,0x9f] 
version=TLS1.2 name=TLS_DHE_RSA_AES_256_GCM_SHA384
  159066.197320:qcrypto_tls_cipher_suite_info data=[0xcc,0xaa] 
version=TLS1.2 name=TLS_DHE_RSA_CHACHA20_POLY1305
  159066.197325:qcrypto_tls_cipher_suite_info data=[0xc0,0x9f] 
version=TLS1.2 na

[PULL 1/5] crypto: add "none" random provider

[Daniel P . Berrangé]

From: Marek Marczykowski-Górecki 

In case of not using random-number needing feature, it makes sense to
skip RNG init too. This is especially helpful when QEMU is sandboxed in
Stubdomain under Xen, where there is very little entropy so initial
getrandom() call delays the startup several seconds. In that setup, no
random bytes are needed at all.

Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: Daniel P. Berrangé 
---
 configure| 11 +++
 crypto/Makefile.objs |  3 ++-
 crypto/random-none.c | 38 ++
 3 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 crypto/random-none.c

diff --git a/configure b/configure
index bb7fd12612..997284e094 100755
--- a/configure
+++ b/configure
@@ -509,6 +509,7 @@ libpmem=""
 default_devices="yes"
 plugins="no"
 fuzzing="no"
+rng_none="no"
 
 supported_cpu="no"
 supported_os="no"
@@ -1601,6 +1602,10 @@ for opt do
   ;;
   --gdb=*) gdb_bin="$optarg"
   ;;
+  --enable-rng-none) rng_none=yes
+  ;;
+  --disable-rng-none) rng_none=no
+  ;;
   *)
   echo "ERROR: unknown option $opt"
   echo "Try '$0 --help' for more information"
@@ -1898,6 +1903,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   debug-mutex mutex debugging support
   libpmem libpmem support
   xkbcommon   xkbcommon support
+  rng-nonedummy RNG, avoid using /dev/(u)random and getrandom()
 
 NOTE: The object files are built at the place where configure is launched
 EOF
@@ -6767,6 +6773,7 @@ echo "default devices   $default_devices"
 echo "plugin support$plugins"
 echo "fuzzing support   $fuzzing"
 echo "gdb   $gdb_bin"
+echo "rng-none  $rng_none"
 
 if test "$supported_cpu" = "no"; then
 echo
@@ -7744,6 +7751,10 @@ if test "$edk2_blobs" = "yes" ; then
   echo "DECOMPRESS_EDK2_BLOBS=y" >> $config_host_mak
 fi
 
+if test "$rng_none" = "yes"; then
+  echo "CONFIG_RNG_NONE=y" >> $config_host_mak
+fi
+
 # use included Linux headers
 if test "$linux" = "yes" ; then
   mkdir -p linux-headers
diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index c2a371b0b4..cdee92b4e5 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -35,5 +35,6 @@ crypto-obj-y += block-luks.o
 
 util-obj-$(CONFIG_GCRYPT) += random-gcrypt.o
 util-obj-$(if $(CONFIG_GCRYPT),n,$(CONFIG_GNUTLS)) += random-gnutls.o
-util-obj-$(if $(CONFIG_GCRYPT),n,$(if $(CONFIG_GNUTLS),n,y)) += 
random-platform.o
+util-obj-$(if $(CONFIG_GCRYPT),n,$(if $(CONFIG_GNUTLS),n,$(CONFIG_RNG_NONE))) 
+= random-none.o
+util-obj-$(if $(CONFIG_GCRYPT),n,$(if $(CONFIG_GNUTLS),n,$(if 
$(CONFIG_RNG_NONE),n,y))) += random-platform.o
 util-obj-y += aes.o init.o
diff --git a/crypto/random-none.c b/crypto/random-none.c
new file mode 100644
index 00..102f8a4dce
--- /dev/null
+++ b/crypto/random-none.c
@@ -0,0 +1,38 @@
+/*
+ * QEMU Crypto "none" random number provider
+ *
+ * Copyright (c) 2020 Marek Marczykowski-Górecki
+ *  
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "crypto/random.h"
+#include "qapi/error.h"
+
+int qcrypto_random_init(Error **errp)
+{
+return 0;
+}
+
+int qcrypto_random_bytes(void *buf,
+ size_t buflen,
+ Error **errp)
+{
+error_setg(errp, "Random bytes not available with \"none\" rng");
+return -1;
+}
-- 
2.26.2

[PATCH v9 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob

[Philippe Mathieu-Daudé]

Since our format is consumable by the fw_cfg device,
we can implement the FW_CFG_DATA_GENERATOR interface.

Acked-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
v9: Fixed typos in qemu-options.hx (lersek)
---
 crypto/tls-cipher-suites.c | 19 +++
 qemu-options.hx| 18 ++
 2 files changed, 37 insertions(+)

diff --git a/crypto/tls-cipher-suites.c b/crypto/tls-cipher-suites.c
index f02a041f9a..d6ea0ed190 100644
--- a/crypto/tls-cipher-suites.c
+++ b/crypto/tls-cipher-suites.c
@@ -14,6 +14,7 @@
 #include "qemu/error-report.h"
 #include "crypto/tlscreds.h"
 #include "crypto/tls-cipher-suites.h"
+#include "hw/nvram/fw_cfg.h"
 #include "trace.h"
 
 static void parse_cipher_suites(QCryptoTLSCipherSuites *s,
@@ -99,11 +100,28 @@ static void qcrypto_tls_cipher_suites_finalize(Object *obj)
 g_free(s->cipher_list);
 }
 
+static const void *qcrypto_tls_cipher_suites_get_data(Object *obj)
+{
+QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
+
+return s->cipher_list;
+}
+
+static size_t qcrypto_tls_cipher_suites_get_length(Object *obj)
+{
+QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
+
+return s->cipher_count * sizeof(IANA_TLS_CIPHER);
+}
+
 static void qcrypto_tls_cipher_suites_class_init(ObjectClass *oc, void *data)
 {
 UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
+FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(oc);
 
 ucc->complete = qcrypto_tls_cipher_suites_complete;
+fwgc->get_data = qcrypto_tls_cipher_suites_get_data;
+fwgc->get_length = qcrypto_tls_cipher_suites_get_length;
 }
 
 static const TypeInfo qcrypto_tls_cipher_suites_info = {
@@ -115,6 +133,7 @@ static const TypeInfo qcrypto_tls_cipher_suites_info = {
 .class_init = qcrypto_tls_cipher_suites_class_init,
 .interfaces = (InterfaceInfo[]) {
 { TYPE_USER_CREATABLE },
+{ TYPE_FW_CFG_DATA_GENERATOR_INTERFACE },
 { }
 }
 };
diff --git a/qemu-options.hx b/qemu-options.hx
index 4f519f35fd..ce54c7359c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4585,6 +4585,24 @@ SRST
 string as described at
 https://gnutls.org/manual/html_node/Priority-Strings.html.
 
+An example of use of this object is to control UEFI HTTPS Boot.
+The tls-cipher-suites object exposes the ordered list of permitted
+TLS cipher suites from the host side to the guest firmware, via
+fw_cfg. The list is represented as an array of IANA_TLS_CIPHER
+objects. The firmware uses the IANA_TLS_CIPHER array for configuring
+guest-side TLS.
+
+In the following example, the priority at which the host-side policy
+is retrieved is given by the ``priority`` property.
+Given that QEMU uses GNUTLS, ``priority=@SYSTEM`` may be used to
+refer to /etc/crypto-policies/back-ends/gnutls.config.
+
+.. parsed-literal::
+
+ # |qemu_system| \
+ -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
+ -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
+
 ``-object 
filter-buffer,id=id,netdev=netdevid,interval=t[,queue=all|rx|tx][,status=on|off][,position=head|tail|id=][,insert=behind|before]``
 Interval t can't be 0, this filter batches the packet delivery:
 all packets arriving in a given interval on netdev netdevid are
-- 
2.21.3

[PATCH v9 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument

[Philippe Mathieu-Daudé]

The 'gen_id' argument refers to a QOM object able to produce
data consumable by the fw_cfg device. The producer object must
implement the FW_CFG_DATA_GENERATOR interface.

Reviewed-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
 softmmu/vl.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index f669c06ede..a46fe5c6c9 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -489,6 +489,11 @@ static QemuOptsList qemu_fw_cfg_opts = {
 .name = "string",
 .type = QEMU_OPT_STRING,
 .help = "Sets content of the blob to be inserted from a string",
+}, {
+.name = "gen_id",
+.type = QEMU_OPT_STRING,
+.help = "Sets id of the object generating the fw_cfg blob "
+"to be inserted",
 },
 { /* end of list */ }
 },
@@ -2020,7 +2025,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
Error **errp)
 {
 gchar *buf;
 size_t size;
-const char *name, *file, *str;
+const char *name, *file, *str, *gen_id;
 FWCfgState *fw_cfg = (FWCfgState *) opaque;
 
 if (fw_cfg == NULL) {
@@ -2030,14 +2035,13 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
Error **errp)
 name = qemu_opt_get(opts, "name");
 file = qemu_opt_get(opts, "file");
 str = qemu_opt_get(opts, "string");
+gen_id = qemu_opt_get(opts, "gen_id");
 
-/* we need name and either a file or the content string */
-if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str {
-error_setg(errp, "invalid argument(s)");
-return -1;
-}
-if (nonempty_str(file) && nonempty_str(str)) {
-error_setg(errp, "file and string are mutually exclusive");
+/* we need the name, and exactly one of: file, content string, gen_id */
+if (!nonempty_str(name) ||
+nonempty_str(file) + nonempty_str(str) + nonempty_str(gen_id) != 1) {
+error_setg(errp, "name, plus exactly one of file,"
+ " string and gen_id, are needed");
 return -1;
 }
 if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
@@ -2052,6 +2056,11 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
Error **errp)
 if (nonempty_str(str)) {
 size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
 buf = g_memdup(str, size);
+} else if (nonempty_str(gen_id)) {
+size_t fw_cfg_size;
+
+fw_cfg_size = fw_cfg_add_from_generator(fw_cfg, name, gen_id, errp);
+return (fw_cfg_size > 0) ? 0 : -1;
 } else {
 GError *err = NULL;
 if (!g_file_get_contents(file, &buf, &size, &err)) {
-- 
2.21.3

[PATCH v9 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace

[Philippe Mathieu-Daudé]

Names of user-provided fw_cfg items are supposed to start
with "opt/". However FW_CFG_DATA_GENERATOR items are generated
by QEMU, so allow the "etc/" namespace in this specific case.

Reviewed-by: Laszlo Ersek 
Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/specs/fw_cfg.txt | 4 
 softmmu/vl.c  | 8 +++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index bc16daa38a..3e6d586f66 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -258,4 +258,8 @@ Prefix "opt/org.qemu/" is reserved for QEMU itself.
 Use of names not beginning with "opt/" is potentially dangerous and
 entirely unsupported.  QEMU will warn if you try.
 
+Use of names not beginning with "opt/" is tolerated with 'gen_id' (that
+is, the warning is suppressed), but you must know exactly what you're
+doing.
+
 All externally provided fw_cfg items are read-only to the guest.
diff --git a/softmmu/vl.c b/softmmu/vl.c
index a46fe5c6c9..535f9d4f24 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2049,7 +2049,13 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
Error **errp)
FW_CFG_MAX_FILE_PATH - 1);
 return -1;
 }
-if (strncmp(name, "opt/", 4) != 0) {
+if (nonempty_str(gen_id)) {
+/*
+ * In this particular case where the content is populated
+ * internally, the "etc/" namespace protection is relaxed,
+ * so do not emit a warning.
+ */
+} else if (strncmp(name, "opt/", 4) != 0) {
 warn_report("externally provided fw_cfg item names "
 "should be prefixed with \"opt/\"");
 }
-- 
2.21.3

[PULL v2 0/5] Qcrypto next patches

[Daniel P . Berrangé]

The following changes since commit 7d3660e79830a069f1848bb4fa1cdf8f666424fb:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagi=
ng (2020-06-12 23:06:22 +0100)

are available in the Git repository at:

  https://github.com/berrange/qemu tags/qcrypto-next-pull-request

for you to fetch changes up to d6cca8e111696fbbd7c233dc53f9c80b6a43359d:

  crypto: Remove use of GCRYPT_VERSION macro. (2020-06-15 11:33:51 +0100)


Misc crypto subsystem fixes

* Improve error message for large files when creating LUKS volumes
* Expand crypto hash benchmark coverage
* Misc code refactoring with no functional change



Alexey Krasikov (3):
  crypto/secret: move main logic from 'secret' to 'secret_common'.
  crypto/linux_keyring: add 'secret_keyring' secret object.
  test-crypto-secret: add 'secret_keyring' object tests.

Marek Marczykowski-G=C3=B3recki (1):
  crypto: add "none" random provider

Richard W.M. Jones (1):
  crypto: Remove use of GCRYPT_VERSION macro.

 configure   |  80 +++
 crypto/Makefile.objs|   5 +-
 crypto/init.c   |   2 +-
 crypto/random-none.c|  38 +++
 crypto/secret.c | 347 +--
 crypto/secret_common.c  | 403 
 crypto/secret_keyring.c | 148 
 include/crypto/secret.h |  20 +-
 include/crypto/secret_common.h  |  68 ++
 include/crypto/secret_keyring.h |  52 +
 tests/Makefile.include  |   4 +
 tests/test-crypto-secret.c  | 158 +
 12 files changed, 966 insertions(+), 359 deletions(-)
 create mode 100644 crypto/random-none.c
 create mode 100644 crypto/secret_common.c
 create mode 100644 crypto/secret_keyring.c
 create mode 100644 include/crypto/secret_common.h
 create mode 100644 include/crypto/secret_keyring.h

--=20
2.26.2

[PULL 5/5] crypto: Remove use of GCRYPT_VERSION macro.

[Daniel P . Berrangé]

From: "Richard W.M. Jones" 

According to the gcrypt documentation it's intended that
gcry_check_version() is called with the minimum version of gcrypt
needed by the program, not the version from the  header file
that happened to be installed when qemu was compiled.  Indeed the
gcrypt.h header says that you shouldn't use the GCRYPT_VERSION macro.

This causes the following failure:

  qemu-img: Unable to initialize gcrypt

if a slightly older version of libgcrypt is installed with a newer
qemu, even though the slightly older version works fine.  This can
happen with RPM packaging which uses symbol versioning to determine
automatically which libgcrypt is required by qemu, which caused the
following bug in RHEL 8:

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

qemu actually requires libgcrypt >= 1.5.0, so we might put the string
"1.5.0" here.  However since 1.5.0 was released in 2011, it hardly
seems we need to check that.  So I replaced GCRYPT_VERSION with NULL.
Perhaps in future if we move to requiring a newer version of gcrypt we
could put a literal string here.

Signed-off-by: Richard W.M. Jones 
Signed-off-by: Daniel P. Berrangé 
---
 crypto/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/init.c b/crypto/init.c
index b305381ec5..ea233b9192 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -122,7 +122,7 @@ int qcrypto_init(Error **errp)
 #endif
 
 #ifdef CONFIG_GCRYPT
-if (!gcry_check_version(GCRYPT_VERSION)) {
+if (!gcry_check_version(NULL)) {
 error_setg(errp, "Unable to initialize gcrypt");
 return -1;
 }
-- 
2.26.2

[PULL 4/5] test-crypto-secret: add 'secret_keyring' object tests.

[Daniel P . Berrangé]

From: Alexey Krasikov 

Add tests:
  test_secret_keyring_good;
  test_secret_keyring_revoked_key;
  test_secret_keyring_expired_key;
  test_secret_keyring_bad_serial_key;
  test_secret_keyring_bad_key_access_right;

Added tests require libkeyutils. The absence of this library is not
critical, because these tests will be skipped in this case.

Signed-off-by: Alexey Krasikov 
Signed-off-by: Daniel P. Berrangé 
---
 configure  |  24 ++
 tests/Makefile.include |   4 +
 tests/test-crypto-secret.c | 158 +
 3 files changed, 186 insertions(+)

diff --git a/configure b/configure
index 3fbb61905a..07202acb9e 100755
--- a/configure
+++ b/configure
@@ -6330,6 +6330,27 @@ but not implemented on your system"
 fi
 fi
 
+##
+# check for usable keyutils.h
+
+if test "$linux" = "yes" ; then
+
+have_keyutils=no
+cat > $TMPC << EOF
+#include 
+#include 
+#include 
+#include 
+#include 
+int main(void) {
+return request_key("user", NULL, NULL, 0);
+}
+EOF
+if compile_prog "" "-lkeyutils"; then
+have_keyutils=yes
+fi
+fi
+
 
 ##
 # End of CC checks
@@ -7702,6 +7723,9 @@ fi
 
 if test "$secret_keyring" = "yes" ; then
   echo "CONFIG_SECRET_KEYRING=y" >> $config_host_mak
+  if test "$have_keyutils" = "yes" ; then
+echo "CONFIG_TEST_SECRET_KEYRING=y" >> $config_host_mak
+  fi
 fi
 
 if test "$tcg_interpreter" = "yes"; then
diff --git a/tests/Makefile.include b/tests/Makefile.include
index c2397de8ed..5607c7290d 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -540,6 +540,10 @@ tests/benchmark-crypto-cipher$(EXESUF): 
tests/benchmark-crypto-cipher.o $(test-c
 tests/test-crypto-secret$(EXESUF): tests/test-crypto-secret.o 
$(test-crypto-obj-y)
 tests/test-crypto-xts$(EXESUF): tests/test-crypto-xts.o $(test-crypto-obj-y)
 
+ifeq ($(CONFIG_TEST_SECRET_KEYRING),y)
+tests/test-crypto-secret.o-libs := -lkeyutils
+endif
+
 tests/crypto-tls-x509-helpers.o-cflags := $(TASN1_CFLAGS)
 tests/crypto-tls-x509-helpers.o-libs := $(TASN1_LIBS)
 tests/pkix_asn1_tab.o-cflags := $(TASN1_CFLAGS)
diff --git a/tests/test-crypto-secret.c b/tests/test-crypto-secret.c
index 13fc6c4c75..603a093f10 100644
--- a/tests/test-crypto-secret.c
+++ b/tests/test-crypto-secret.c
@@ -24,6 +24,10 @@
 #include "crypto/secret.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
+#ifdef CONFIG_TEST_SECRET_KEYRING
+#include "crypto/secret_keyring.h"
+#include 
+#endif
 
 static void test_secret_direct(void)
 {
@@ -124,6 +128,147 @@ static void test_secret_indirect_emptyfile(void)
 g_free(fname);
 }
 
+#ifdef CONFIG_TEST_SECRET_KEYRING
+
+#define DESCRIPTION "qemu_test_secret"
+#define PAYLOAD "Test Payload"
+
+
+static void test_secret_keyring_good(void)
+{
+char key_str[16];
+Object *sec;
+int32_t key = add_key("user", DESCRIPTION, PAYLOAD,
+  strlen(PAYLOAD), KEY_SPEC_PROCESS_KEYRING);
+
+g_assert(key >= 0);
+
+snprintf(key_str, sizeof(key_str), "0x%08x", key);
+sec = object_new_with_props(
+TYPE_QCRYPTO_SECRET_KEYRING,
+object_get_objects_root(),
+"sec0",
+&error_abort,
+"serial", key_str,
+NULL);
+
+assert(0 <= keyctl_unlink(key, KEY_SPEC_PROCESS_KEYRING));
+char *pw = qcrypto_secret_lookup_as_utf8("sec0",
+ &error_abort);
+g_assert_cmpstr(pw, ==, PAYLOAD);
+
+object_unparent(sec);
+g_free(pw);
+}
+
+
+static void test_secret_keyring_revoked_key(void)
+{
+char key_str[16];
+Object *sec;
+int32_t key = add_key("user", DESCRIPTION, PAYLOAD,
+  strlen(PAYLOAD), KEY_SPEC_PROCESS_KEYRING);
+g_assert(key >= 0);
+g_assert_false(keyctl_revoke(key));
+
+snprintf(key_str, sizeof(key_str), "0x%08x", key);
+sec = object_new_with_props(
+TYPE_QCRYPTO_SECRET_KEYRING,
+object_get_objects_root(),
+"sec0",
+NULL,
+"serial", key_str,
+NULL);
+
+g_assert(errno == EKEYREVOKED);
+g_assert(sec == NULL);
+
+keyctl_unlink(key, KEY_SPEC_PROCESS_KEYRING);
+}
+
+
+static void test_secret_keyring_expired_key(void)
+{
+char key_str[16];
+Object *sec;
+int32_t key = add_key("user", DESCRIPTION, PAYLOAD,
+  strlen(PAYLOAD), KEY_SPEC_PROCESS_KEYRING);
+g_assert(key >= 0);
+g_assert_false(keyctl_set_timeout(key, 1));
+sleep(1);
+
+snprintf(key_str, sizeof(key_str), "0x%08x", key);
+sec = object_new_with_props(
+TYPE_QCRYPTO_SECRET_KEYRING,
+object_get_objects_root(),
+"sec0",
+NULL,
+"serial", key_str,
+NULL);
+
+g_assert(errno == EKEYEXPIRED);
+g_assert(sec == NULL);
+
+keyctl_unlink(key, KEY_SPEC_PROCESS_KEYRING);
+}
+
+
+static void test_secret_keyring_bad_serial_key(void)
+{
+Object *sec;
+
+sec = object_new_with_p

[PULL 2/5] crypto/secret: move main logic from 'secret' to 'secret_common'.

[Daniel P . Berrangé]

From: Alexey Krasikov 

Create base class 'common secret'. Move common data and logic from
'secret' to 'common_secret' class. This allowed adding abstraction layer
for easier adding new 'secret' objects in future.
Convert 'secret' class to child from basic 'secret_common' with 'data'
and 'file' properties.

Signed-off-by: Alexey Krasikov 
Signed-off-by: Daniel P. Berrangé 
---
 crypto/Makefile.objs   |   1 +
 crypto/secret.c| 347 +---
 crypto/secret_common.c | 403 +
 include/crypto/secret.h|  20 +-
 include/crypto/secret_common.h |  68 ++
 5 files changed, 482 insertions(+), 357 deletions(-)
 create mode 100644 crypto/secret_common.c
 create mode 100644 include/crypto/secret_common.h

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index cdee92b4e5..110dec1b87 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -18,6 +18,7 @@ crypto-obj-y += tlscredsanon.o
 crypto-obj-y += tlscredspsk.o
 crypto-obj-y += tlscredsx509.o
 crypto-obj-y += tlssession.o
+crypto-obj-y += secret_common.o
 crypto-obj-y += secret.o
 crypto-obj-y += pbkdf.o
 crypto-obj-$(CONFIG_NETTLE) += pbkdf-nettle.o
diff --git a/crypto/secret.c b/crypto/secret.c
index 3107aecb47..3447e2f64b 100644
--- a/crypto/secret.c
+++ b/crypto/secret.c
@@ -20,16 +20,14 @@
 
 #include "qemu/osdep.h"
 #include "crypto/secret.h"
-#include "crypto/cipher.h"
 #include "qapi/error.h"
 #include "qom/object_interfaces.h"
-#include "qemu/base64.h"
 #include "qemu/module.h"
 #include "trace.h"
 
 
 static void
-qcrypto_secret_load_data(QCryptoSecret *secret,
+qcrypto_secret_load_data(QCryptoSecretCommon *sec_common,
  uint8_t **output,
  size_t *outputlen,
  Error **errp)
@@ -38,6 +36,8 @@ qcrypto_secret_load_data(QCryptoSecret *secret,
 size_t length = 0;
 GError *gerr = NULL;
 
+QCryptoSecret *secret = QCRYPTO_SECRET(sec_common);
+
 *output = NULL;
 *outputlen = 0;
 
@@ -65,198 +65,6 @@ qcrypto_secret_load_data(QCryptoSecret *secret,
 }
 
 
-static void qcrypto_secret_decrypt(QCryptoSecret *secret,
-   const uint8_t *input,
-   size_t inputlen,
-   uint8_t **output,
-   size_t *outputlen,
-   Error **errp)
-{
-g_autofree uint8_t *key = NULL;
-g_autofree uint8_t *ciphertext = NULL;
-g_autofree uint8_t *iv = NULL;
-size_t keylen, ciphertextlen, ivlen;
-g_autoptr(QCryptoCipher) aes = NULL;
-g_autofree uint8_t *plaintext = NULL;
-
-*output = NULL;
-*outputlen = 0;
-
-if (qcrypto_secret_lookup(secret->keyid,
-  &key, &keylen,
-  errp) < 0) {
-return;
-}
-
-if (keylen != 32) {
-error_setg(errp, "Key should be 32 bytes in length");
-return;
-}
-
-if (!secret->iv) {
-error_setg(errp, "IV is required to decrypt secret");
-return;
-}
-
-iv = qbase64_decode(secret->iv, -1, &ivlen, errp);
-if (!iv) {
-return;
-}
-if (ivlen != 16) {
-error_setg(errp, "IV should be 16 bytes in length not %zu",
-   ivlen);
-return;
-}
-
-aes = qcrypto_cipher_new(QCRYPTO_CIPHER_ALG_AES_256,
- QCRYPTO_CIPHER_MODE_CBC,
- key, keylen,
- errp);
-if (!aes) {
-return;
-}
-
-if (qcrypto_cipher_setiv(aes, iv, ivlen, errp) < 0) {
-return;
-}
-
-if (secret->format == QCRYPTO_SECRET_FORMAT_BASE64) {
-ciphertext = qbase64_decode((const gchar*)input,
-inputlen,
-&ciphertextlen,
-errp);
-if (!ciphertext) {
-return;
-}
-plaintext = g_new0(uint8_t, ciphertextlen + 1);
-} else {
-ciphertextlen = inputlen;
-plaintext = g_new0(uint8_t, inputlen + 1);
-}
-if (qcrypto_cipher_decrypt(aes,
-   ciphertext ? ciphertext : input,
-   plaintext,
-   ciphertextlen,
-   errp) < 0) {
-return;
-}
-
-if (plaintext[ciphertextlen - 1] > 16 ||
-plaintext[ciphertextlen - 1] > ciphertextlen) {
-error_setg(errp, "Incorrect number of padding bytes (%d) "
-   "found on decrypted data",
-   (int)plaintext[ciphertextlen - 1]);
-return;
-}
-
-/* Even though plaintext may contain arbitrary NUL
- * ensure it is explicitly NUL terminated.
- */
-ciphertextlen -= plaintext[ciphertextlen - 1];
-plaintext[ciphertextlen] = '\0';
-
-*output = g_steal_pointer(&plaintext);

[PULL 3/5] crypto/linux_keyring: add 'secret_keyring' secret object.

[Daniel P . Berrangé]

From: Alexey Krasikov 

Add the ability for the secret object to obtain secret data from the
Linux in-kernel key managment and retention facility, as an extra option
to the existing ones: reading from a file or passing directly as a
string.

The secret is identified by the key serial number. The upper layers
need to instantiate the key and make sure the QEMU process has access
permissions to read it.

Signed-off-by: Alexey Krasikov 

 - Fixed up detection logic default behaviour in configure

Signed-off-by: Daniel P. Berrangé 
---
 configure   |  45 ++
 crypto/Makefile.objs|   1 +
 crypto/secret_keyring.c | 148 
 include/crypto/secret_keyring.h |  52 +++
 4 files changed, 246 insertions(+)
 create mode 100644 crypto/secret_keyring.c
 create mode 100644 include/crypto/secret_keyring.h

diff --git a/configure b/configure
index 997284e094..3fbb61905a 100755
--- a/configure
+++ b/configure
@@ -510,6 +510,7 @@ default_devices="yes"
 plugins="no"
 fuzzing="no"
 rng_none="no"
+secret_keyring=""
 
 supported_cpu="no"
 supported_os="no"
@@ -1606,6 +1607,10 @@ for opt do
   ;;
   --disable-rng-none) rng_none=no
   ;;
+  --enable-keyring) secret_keyring="yes"
+  ;;
+  --disable-keyring) secret_keyring="no"
+  ;;
   *)
   echo "ERROR: unknown option $opt"
   echo "Try '$0 --help' for more information"
@@ -6290,6 +6295,41 @@ case "$slirp" in
 ;;
 esac
 
+##
+# check for usable __NR_keyctl syscall
+
+if test "$linux" = "yes" ; then
+
+have_keyring=no
+cat > $TMPC << EOF
+#include 
+#include 
+#include 
+#include 
+int main(void) {
+return syscall(__NR_keyctl, KEYCTL_READ, 0, NULL, NULL, 0);
+}
+EOF
+if compile_prog "" "" ; then
+have_keyring=yes
+fi
+fi
+if test "$secret_keyring" != "no"
+then
+if test "$have_keyring" == "yes"
+then
+   secret_keyring=yes
+else
+   if test "$secret_keyring" = "yes"
+   then
+   error_exit "syscall __NR_keyctl requested, \
+but not implemented on your system"
+   else
+   secret_keyring=no
+   fi
+fi
+fi
+
 
 ##
 # End of CC checks
@@ -6774,6 +6814,7 @@ echo "plugin support$plugins"
 echo "fuzzing support   $fuzzing"
 echo "gdb   $gdb_bin"
 echo "rng-none  $rng_none"
+echo "Linux keyring $secret_keyring"
 
 if test "$supported_cpu" = "no"; then
 echo
@@ -7659,6 +7700,10 @@ if test -n "$gdb_bin" ; then
 echo "HAVE_GDB_BIN=$gdb_bin" >> $config_host_mak
 fi
 
+if test "$secret_keyring" = "yes" ; then
+  echo "CONFIG_SECRET_KEYRING=y" >> $config_host_mak
+fi
+
 if test "$tcg_interpreter" = "yes"; then
   QEMU_INCLUDES="-iquote \$(SRC_PATH)/tcg/tci $QEMU_INCLUDES"
 elif test "$ARCH" = "sparc64" ; then
diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index 110dec1b87..707c02ad37 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -20,6 +20,7 @@ crypto-obj-y += tlscredsx509.o
 crypto-obj-y += tlssession.o
 crypto-obj-y += secret_common.o
 crypto-obj-y += secret.o
+crypto-obj-$(CONFIG_SECRET_KEYRING) += secret_keyring.o
 crypto-obj-y += pbkdf.o
 crypto-obj-$(CONFIG_NETTLE) += pbkdf-nettle.o
 crypto-obj-$(if $(CONFIG_NETTLE),n,$(CONFIG_GCRYPT)) += pbkdf-gcrypt.o
diff --git a/crypto/secret_keyring.c b/crypto/secret_keyring.c
new file mode 100644
index 00..4f132d6370
--- /dev/null
+++ b/crypto/secret_keyring.c
@@ -0,0 +1,148 @@
+/*
+ * QEMU crypto secret support
+ *
+ * Copyright 2020 Yandex N.V.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include 
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "trace.h"
+#include "crypto/secret_keyring.h"
+
+
+static inline
+long keyctl_read(int32_t key, uint8_t *buffer, size_t buflen)
+{
+return syscall(__NR_keyctl, KEYCTL_READ, key, buffer, buflen, 0);
+}
+
+
+static void
+qcrypto_secret_keyring_load_data(QCryptoSecretCommon *sec_common,
+ uint8_t **output,
+ size_t *outputlen,
+ Error **errp)
+{
+QCryptoSecretKeyring *secret = QCRYPTO_SECRET_KEYRING(sec_common);
+uint8_t *buffer = NULL;
+long retcode;
+
+*output = NULL;
+*outp

Re: RFC: use VFIO over a UNIX domain socket to implement device offloading

[Stefan Hajnoczi]

On Tue, Jun 09, 2020 at 11:25:41PM -0700, John G Johnson wrote:
> > On Jun 2, 2020, at 8:06 AM, Alex Williamson  
> > wrote:
> > 
> > On Wed, 20 May 2020 17:45:13 -0700
> > John G Johnson  wrote:
> > 
> >>> I'm confused by VFIO_USER_ADD_MEMORY_REGION vs VFIO_USER_IOMMU_MAP_DMA.
> >>> The former seems intended to provide the server with access to the
> >>> entire GPA space, while the latter indicates an IOVA to GPA mapping of
> >>> those regions.  Doesn't this break the basic isolation of a vIOMMU?
> >>> This essentially says to me "here's all the guest memory, but please
> >>> only access these regions for which we're providing DMA mappings".
> >>> That invites abuse.
> >>> 
> >> 
> >>The purpose behind separating QEMU into multiple processes is
> >> to provide an additional layer protection for the infrastructure against
> >> a malign guest, not for the guest against itself, so preventing a server
> >> that has been compromised by a guest from accessing all of guest memory
> >> adds no additional benefit.  We don’t even have an IOMMU in our current
> >> guest model for this reason.
> > 
> > One of the use cases we see a lot with vfio is nested assignment, ie.
> > we assign a device to a VM where the VM includes a vIOMMU, such that
> > the guest OS can then assign the device to userspace within the guest.
> > This is safe to do AND provides isolation within the guest exactly
> > because the device only has access to memory mapped to the device, not
> > the entire guest address space.  I don't think it's just the hypervisor
> > you're trying to protect, we can't assume there are always trusted
> > drivers managing the device.
> > 
> 
>   We intend to support an IOMMU.  The question seems to be whether
> it’s implemented in the server or client.  The current proposal has it
> in the server, ala vhost-user, but we are fine with moving it.

It's challenging to implement a fast and secure IOMMU. The simplest
approach is secure but not fast: add protocol messages for
DMA_READ(iova, length) and DMA_WRITE(iova, buffer, length).

An issue with file descriptor passing is that it's hard to revoke access
once the file descriptor has been passed. memfd supports sealing with
fnctl(F_ADD_SEALS) it doesn't revoke mmap(MAP_WRITE) on other processes.

Memory Protection Keys don't seem to be useful here either and their
availability is limited (see pkeys(7)).

One crazy idea is to use KVM as a sandbox for running the device and let
the vIOMMU control the page tables instead of the device (guest). That
way the hardware MMU provides memory translation, but I think this is
impractical because the guest environment is too different from the
Linux userspace environment.

As a starting point adding DMA_READ/DMA_WRITE messages would provide the
functionality and security. Unfortunately it makes DMA expensive and
performance will suffer.

Stefan


signature.asc
Description: PGP signature

Re: [RFC PATCH v2 1/5] hw/misc: Add a LED device

[Dr. David Alan Gilbert]

* Philippe Mathieu-Daudé (f4...@amsat.org) wrote:
> A LED device can be connected to a GPIO output.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/misc/led.h | 30 
>  hw/misc/led.c | 84 +++
>  MAINTAINERS   |  6 
>  hw/misc/Kconfig   |  3 ++
>  hw/misc/Makefile.objs |  1 +
>  hw/misc/trace-events  |  3 ++
>  6 files changed, 127 insertions(+)
>  create mode 100644 include/hw/misc/led.h
>  create mode 100644 hw/misc/led.c
> 
> diff --git a/include/hw/misc/led.h b/include/hw/misc/led.h
> new file mode 100644
> index 00..427ca1418e
> --- /dev/null
> +++ b/include/hw/misc/led.h
> @@ -0,0 +1,30 @@
> +/*
> + * QEMU single LED device
> + *
> + * Copyright (C) 2020 Philippe Mathieu-Daudé 
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +#ifndef HW_MISC_LED_H
> +#define HW_MISC_LED_H
> +
> +#include "hw/qdev-core.h"
> +#include "hw/sysbus.h" /* FIXME remove */
> +
> +#define TYPE_LED "led"
> +#define LED(obj) OBJECT_CHECK(LEDState, (obj), TYPE_LED)
> +
> +typedef struct LEDState {
> +/* Private */
> +SysBusDevice parent_obj; /* FIXME DeviceState */
> +/* Public */
> +
> +qemu_irq irq;

Why an irq?

> +uint8_t current_state;

Is the state of this device boolean or is it a 0..255 0=off, 255=full
on, analog thing?
Can an LED device be connected to a PWM device driving a GPIO - what
happens?

Dave


> +/* Properties */
> +char *name;
> +uint8_t reset_state; /* TODO [GPIO_ACTIVE_LOW, GPIO_ACTIVE_HIGH] */
> +} LEDState;
> +
> +#endif /* HW_MISC_LED_H */
> diff --git a/hw/misc/led.c b/hw/misc/led.c
> new file mode 100644
> index 00..1bae1a34c0
> --- /dev/null
> +++ b/hw/misc/led.c
> @@ -0,0 +1,84 @@
> +/*
> + * QEMU single LED device
> + *
> + * Copyright (C) 2020 Philippe Mathieu-Daudé 
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "migration/vmstate.h"
> +#include "hw/qdev-properties.h"
> +#include "hw/misc/led.h"
> +#include "hw/irq.h"
> +#include "trace.h"
> +
> +static void led_set(void *opaque, int line, int new_state)
> +{
> +LEDState *s = LED(opaque);
> +
> +trace_led_set(s->name, s->current_state, new_state);
> +
> +s->current_state = new_state;
> +}
> +
> +static void led_reset(DeviceState *dev)
> +{
> +LEDState *s = LED(dev);
> +
> +led_set(dev, 0, s->reset_state);
> +}
> +
> +static const VMStateDescription vmstate_led = {
> +.name = TYPE_LED,
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT8(reset_state, LEDState),

I'm not sure you need to migrate this - this is a property that's set on
the device, not a dynamic state of the device
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> +static void led_realize(DeviceState *dev, Error **errp)
> +{
> +LEDState *s = LED(dev);
> +
> +if (s->name == NULL) {
> +error_setg(errp, "property 'name' not specified");
> +return;
> +}
> +
> +qdev_init_gpio_in(DEVICE(s), led_set, 1);
> +}
> +
> +static Property led_properties[] = {
> +DEFINE_PROP_STRING("name", LEDState, name),
> +DEFINE_PROP_UINT8("reset_state", LEDState, reset_state, 0),

I suggest you add a property for the notional colour; that way any UIs
that are built can use that as a hint.

Dave

> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void led_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +dc->desc = "LED";
> +dc->vmsd = &vmstate_led;
> +dc->reset = led_reset;
> +dc->realize = led_realize;
> +set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
> +device_class_set_props(dc, led_properties);
> +}
> +
> +static const TypeInfo led_info = {
> +.name = TYPE_LED,
> +.parent = TYPE_SYS_BUS_DEVICE, /* FIXME TYPE_DEVICE */
> +.instance_size = sizeof(LEDState),
> +.class_init = led_class_init
> +};
> +
> +static void led_register_types(void)
> +{
> +type_register_static(&led_info);
> +}
> +
> +type_init(led_register_types)
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3abe3faa4e..10593863dc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1857,6 +1857,12 @@ F: docs/specs/vmgenid.txt
>  F: tests/qtest/vmgenid-test.c
>  F: stubs/vmgenid.c
>  
> +LED
> +M: Philippe Mathieu-Daudé 
> +S: Maintained
> +F: include/hw/misc/led.h
> +F: hw/misc/led.c
> +
>  Unimplemented device
>  M: Peter Maydell 
>  R: Philippe Mathieu-Daudé 
> diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
> index bdd77d8020..f60dce694d 100644
> --- a/hw/misc/Kconfig
> +++ b/hw/misc/Kconfig
> @@ -126,6 +126,9 @@ config AUX
>  config UNIMP
>  bool
>  
> +config LED
> +bool
> +
>  config MAC_VIA
>  bool
>  select MOS6522
> diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
> index 5aaca8a039..9efa3c941c 100644
> --- a/hw/misc/Makefile.objs
> +++ b/hw/misc/Ma

Re: [PULL 082/116] target/i386: correct fix for pcmpxstrx substring search

[Philippe Mathieu-Daudé]

On 6/15/20 12:18 PM, Philippe Mathieu-Daudé wrote:
> On 6/12/20 6:07 PM, Paolo Bonzini wrote:
>> From: Joseph Myers 
>>
>> This corrects a bug introduced in my previous fix for SSE4.2 pcmpestri
>> / pcmpestrm / pcmpistri / pcmpistrm substring search, commit
>> ae35eea7e4a9f21dd147406dfbcd0c4c6aaf2a60.
>>
>> That commit fixed a bug that showed up in four GCC tests with one libc
>> implementation.  The tests in question generate random inputs to the
>> intrinsics and compare results to a C implementation, but they only
>> test 1024 possible random inputs, and when the tests use the cases of
>> those instructions that work with word rather than byte inputs, it's
>> easy to have problematic cases that show up much less frequently than
>> that.  Thus, testing with a different libc implementation, and so a
>> different random number generator, showed up a problem with the
>> previous patch.
>>
>> When investigating the previous test failures, I found the description
>> of these instructions in the Intel manuals (starting from computing a
>> 16x16 or 8x8 set of comparison results) confusing and hard to match up
>> with the more optimized implementation in QEMU, and referred to AMD
>> manuals which described the instructions in a different way.  Those
>> AMD descriptions are very explicit that the whole of the string being
>> searched for must be found in the other operand, not running off the
>> end of that operand; they say "If the prototype and the SUT are equal
>> in length, the two strings must be identical for the comparison to be
>> TRUE.".  However, that statement is incorrect.
>>
>> In my previous commit message, I noted:
>>
>>   The operation in this case is a search for a string (argument d to
>>   the helper) in another string (argument s to the helper); if a copy
>>   of d at a particular position would run off the end of s, the
>>   resulting output bit should be 0 whether or not the strings match in
>>   the region where they overlap, but the QEMU implementation was
>>   wrongly comparing only up to the point where s ends and counting it
>>   as a match if an initial segment of d matched a terminal segment of
>>   s.  Here, "run off the end of s" means that some byte of d would
>>   overlap some byte outside of s; thus, if d has zero length, it is
>>   considered to match everywhere, including after the end of s.
>>
>> The description "some byte of d would overlap some byte outside of s"
>> is accurate only when understood to refer to overlapping some byte
>> *within the 16-byte operand* but at or after the zero terminator; it
>> is valid to run over the end of s if the end of s is the end of the
>> 16-byte operand.  So the fix in the previous patch for the case of d
>> being empty was correct, but the other part of that patch was not
>> correct (as it never allowed partial matches even at the end of the
>> 16-byte operand).  Nor was the code before the previous patch correct
>> for the case of d nonempty, as it would always have allowed partial
>> matches at the end of s.
>>
>> Fix with a partial revert of my previous change, combined with
>> inserting a check for the special case of s having maximum length to
>> determine where it is necessary to check for matches.
>>
>> In the added test, test 1 is for the case of empty strings, which
>> failed before my 2017 patch, test 2 is for the bug introduced by my
>> 2017 patch and test 3 deals with the case where a match of an initial
>> segment at the end of the string is not valid when the string ends
>> before the end of the 16-byte operand (that is, the case that would be
>> broken by a simple revert of the non-empty-string part of my 2017
>> patch).
>>
>> Signed-off-by: Joseph Myers 
>> Message-Id: 
>> Signed-off-by: Paolo Bonzini 
>> ---
>>  target/i386/ops_sse.h|  4 ++--
>>  tests/tcg/i386/Makefile.target   |  3 +++
>>  tests/tcg/i386/test-i386-pcmpistri.c | 33 
>>  3 files changed, 38 insertions(+), 2 deletions(-)
>>  create mode 100644 tests/tcg/i386/test-i386-pcmpistri.c
>>
>> diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
>> index 01d6017412..14f2b16abd 100644
>> --- a/target/i386/ops_sse.h
>> +++ b/target/i386/ops_sse.h
>> @@ -2089,10 +2089,10 @@ static inline unsigned pcmpxstrx(CPUX86State *env, 
>> Reg *d, Reg *s,
>>  res = (2 << upper) - 1;
>>  break;
>>  }
>> -for (j = valids - validd; j >= 0; j--) {
>> +for (j = valids == upper ? valids : valids - validd; j >= 0; j--) {
>>  res <<= 1;
>>  v = 1;
>> -for (i = validd; i >= 0; i--) {
>> +for (i = MIN(valids - j, validd); i >= 0; i--) {
>>  v &= (pcmp_val(s, ctrl, i + j) == pcmp_val(d, ctrl, i));
>>  }
>>  res |= v;
>> diff --git a/tests/tcg/i386/Makefile.target b/tests/tcg/i386/Makefile.target
>> index 43ee2e181e..53efec0668 100644
>> --- a/tests/tcg/i386/Makefile.target
>> +++ b/tests/tcg/i386/Make

Re: [PATCH] hw/timer/a9gtimer: Clear pending interrupt, after the clear of Event flag

[Peter Maydell]

On Wed, 10 Jun 2020 at 09:47, Vaclav Vanc  wrote:
>
> A9 Global Timer is used with Edge triggered interrupts (This is true
> at least for Zynq and i.MX6 processors).
> When Event Flag is cleared in Interrupt Status Register and new interrupt
> was supposed to be scheduled, interrupt request is never cleared.
> Since interrupt in GIC is configured as Edge triggered, new interrupts
> are not registered (because interrupt is stuck at pending and GIC thinks
> it was already serviced). As a result interrupts from timer does not work
> anymore.
>
> Note: This happens only when interrupt was not serviced before the next
> interrupt is suppose to be scheduled. This happens for example during
> the increased load of the host system.
>
> Interrupt is now always cleared when Event Flag is cleared.
> This is in accordance to A9 Global Timer documentation.
>
> Signed-off-by: Vaclav Vanc 
> ---
>  hw/timer/a9gtimer.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/hw/timer/a9gtimer.c b/hw/timer/a9gtimer.c
> index 7233068a37..732889105e 100644
> --- a/hw/timer/a9gtimer.c
> +++ b/hw/timer/a9gtimer.c
> @@ -206,6 +206,9 @@ static void a9_gtimer_write(void *opaque, hwaddr addr, 
> uint64_t value,
>  case R_INTERRUPT_STATUS:
>  a9_gtimer_update(s, false);
>  gtb->status &= ~value;
> +if (gtb->status == 0) {
> +qemu_set_irq(gtb->irq, 0);
> +}
>  break;

Hi; thanks for this patch. I can see the situation you're trying to address,
but I can't find anything in the docs that convinces me that this change
is the right way to fix it.

The problem we have is that the a9_gtimer_update() function (which is
going to get called after this code at the end of the a9_gtimer_write()
function) updates the gtb->status bit based on whether the timer has
currently passed the compare value. So effectively we do the "has the
count gone past the compare value" check not only when the timer expires
but also at every register write. My best guess is that the real hardware
only does an expiry-check when it does a counter value update. If that's
the case then in the situation you outline the guest clearing the event
flag should mean that the interrupt is not re-asserted until the counter
next increments past the compare value (ie not for a little while) whereas
with your patch it will be instantly re-asserted.

(Unfortunately the A9 TRM is not clear on the behaviour here. It would
probably be possible to write some test code to check the real h/w
behaviour.)

thanks
-- PMM

Re: [PATCH v2] hw/misc/imx6ul_ccm: Implement non writable bits in CCM registers

[Peter Maydell]

On Mon, 8 Jun 2020 at 14:35, Jean-Christophe Dubois  
wrote:
>
> Some bits of the CCM registers are non writable.
>
> This was left undone in the initial commit (all bits of registers were
> writable).
>
> This patch adds the required code to protect the non writable bits.
>
> Signed-off-by: Jean-Christophe Dubois 
> ---
>
>  v2: simplify code after feedback on the first patch.



Applied to target-arm.next, thanks.

-- PMM

Re: [RFC PATCH v2 1/5] hw/misc: Add a LED device

[Philippe Mathieu-Daudé]

On 6/15/20 12:55 PM, Dr. David Alan Gilbert wrote:
> * Philippe Mathieu-Daudé (f4...@amsat.org) wrote:
>> A LED device can be connected to a GPIO output.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  include/hw/misc/led.h | 30 
>>  hw/misc/led.c | 84 +++
>>  MAINTAINERS   |  6 
>>  hw/misc/Kconfig   |  3 ++
>>  hw/misc/Makefile.objs |  1 +
>>  hw/misc/trace-events  |  3 ++
>>  6 files changed, 127 insertions(+)
>>  create mode 100644 include/hw/misc/led.h
>>  create mode 100644 hw/misc/led.c
>>
>> diff --git a/include/hw/misc/led.h b/include/hw/misc/led.h
>> new file mode 100644
>> index 00..427ca1418e
>> --- /dev/null
>> +++ b/include/hw/misc/led.h
>> @@ -0,0 +1,30 @@
>> +/*
>> + * QEMU single LED device
>> + *
>> + * Copyright (C) 2020 Philippe Mathieu-Daudé 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +#ifndef HW_MISC_LED_H
>> +#define HW_MISC_LED_H
>> +
>> +#include "hw/qdev-core.h"
>> +#include "hw/sysbus.h" /* FIXME remove */
>> +
>> +#define TYPE_LED "led"
>> +#define LED(obj) OBJECT_CHECK(LEDState, (obj), TYPE_LED)
>> +
>> +typedef struct LEDState {
>> +/* Private */
>> +SysBusDevice parent_obj; /* FIXME DeviceState */
>> +/* Public */
>> +
>> +qemu_irq irq;
> 
> Why an irq?

We model GPIO/IRQ the same way, this is simply a GPIO, right?

It makes modeling easier IMO. This is for visualization purpose.

> 
>> +uint8_t current_state;
> 
> Is the state of this device boolean or is it a 0..255 0=off, 255=full
> on, analog thing?
> Can an LED device be connected to a PWM device driving a GPIO - what
> happens?

Well I simply wanted to use a boolean, but I need to consider
if we can model intensity here in case of PWM. This is interesting.

> 
> Dave
> 
> 
>> +/* Properties */
>> +char *name;
>> +uint8_t reset_state; /* TODO [GPIO_ACTIVE_LOW, GPIO_ACTIVE_HIGH] */
>> +} LEDState;
>> +
>> +#endif /* HW_MISC_LED_H */
>> diff --git a/hw/misc/led.c b/hw/misc/led.c
>> new file mode 100644
>> index 00..1bae1a34c0
>> --- /dev/null
>> +++ b/hw/misc/led.c
>> @@ -0,0 +1,84 @@
>> +/*
>> + * QEMU single LED device
>> + *
>> + * Copyright (C) 2020 Philippe Mathieu-Daudé 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +#include "qemu/osdep.h"
>> +#include "qapi/error.h"
>> +#include "migration/vmstate.h"
>> +#include "hw/qdev-properties.h"
>> +#include "hw/misc/led.h"
>> +#include "hw/irq.h"
>> +#include "trace.h"
>> +
>> +static void led_set(void *opaque, int line, int new_state)
>> +{
>> +LEDState *s = LED(opaque);
>> +
>> +trace_led_set(s->name, s->current_state, new_state);
>> +
>> +s->current_state = new_state;
>> +}
>> +
>> +static void led_reset(DeviceState *dev)
>> +{
>> +LEDState *s = LED(dev);
>> +
>> +led_set(dev, 0, s->reset_state);
>> +}
>> +
>> +static const VMStateDescription vmstate_led = {
>> +.name = TYPE_LED,
>> +.version_id = 1,
>> +.minimum_version_id = 1,
>> +.fields = (VMStateField[]) {
>> +VMSTATE_UINT8(reset_state, LEDState),
> 
> I'm not sure you need to migrate this - this is a property that's set on
> the device, not a dynamic state of the device

Yes you are right.

>> +VMSTATE_END_OF_LIST()
>> +}
>> +};
>> +
>> +static void led_realize(DeviceState *dev, Error **errp)
>> +{
>> +LEDState *s = LED(dev);
>> +
>> +if (s->name == NULL) {
>> +error_setg(errp, "property 'name' not specified");
>> +return;
>> +}
>> +
>> +qdev_init_gpio_in(DEVICE(s), led_set, 1);
>> +}
>> +
>> +static Property led_properties[] = {
>> +DEFINE_PROP_STRING("name", LEDState, name),
>> +DEFINE_PROP_UINT8("reset_state", LEDState, reset_state, 0),
> 
> I suggest you add a property for the notional colour; that way any UIs
> that are built can use that as a hint.

Great idea, thanks!

> 
> Dave
> 
>> +DEFINE_PROP_END_OF_LIST(),
>> +};
>> +
>> +static void led_class_init(ObjectClass *klass, void *data)
>> +{
>> +DeviceClass *dc = DEVICE_CLASS(klass);
>> +
>> +dc->desc = "LED";
>> +dc->vmsd = &vmstate_led;
>> +dc->reset = led_reset;
>> +dc->realize = led_realize;
>> +set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
>> +device_class_set_props(dc, led_properties);
>> +}
>> +
>> +static const TypeInfo led_info = {
>> +.name = TYPE_LED,
>> +.parent = TYPE_SYS_BUS_DEVICE, /* FIXME TYPE_DEVICE */
>> +.instance_size = sizeof(LEDState),
>> +.class_init = led_class_init
>> +};
>> +
>> +static void led_register_types(void)
>> +{
>> +type_register_static(&led_info);
>> +}
>> +
>> +type_init(led_register_types)
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 3abe3faa4e..10593863dc 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1857,6 +1857,12 @@ F: docs/specs/vmgenid.txt
>>  F: tests/qtest/vmgenid-test.c
>>  F: stubs/vmgenid.c
>>  
>> +LED
>> +M: Philippe Mathieu-Daudé 
>> +S: Maintained
>> +F: in

Re: [PATCH v2] Implement configurable descriptor size in ftgmac100

[Peter Maydell]

On Sat, 6 Jun 2020 at 10:03, Erik Smit  wrote:
>
> The hardware supports configurable descriptor sizes, configured in the DBLAC
> register.
>
> Most drivers use the default 4 word descriptor, which is currently hardcoded,
> but Aspeed SDK configures 8 words to store extra data.

Hi; I've applied this to target-arm.next, with the parenthesis
change that Cédric suggested; thanks for your contribution.

A couple of minor patch format notes, which are only worth worrying
about if you plan to submit more QEMU patches in future:

> ---

The Signed-off-by: line should go above this '---' divider, because
it wants to go into the commit message in git; anything below '---'
is discarded when the patch is applied.

>  /*
>   * PHY control register
>   */
> @@ -553,7 +563,7 @@ static void ftgmac100_do_tx(FTGMAC100State *s,
> uint32_t tx_ring,

Your email client is wrapping long lines, which corrupts patches.
(You can see that patchew was unable to apply and CI-test it:
https://patchew.org/QEMU/CA+MHfovYq1UAQQ341MnyGas7ScskWyjR=qe0d-rs7+zxf2m...@mail.gmail.com/
)

I fixed this patch up by hand, but if you're planning on sending
more patches in future it would be worth sorting out how to send them
in a way that doesn't wrap them. (Most long-term devs use some form
of the 'git send-email' client.)

thanks
-- PMM

Re: [PATCH v3 1/6] linux-user: Extend strace support to enable argument printing after syscall execution

[Laurent Vivier]

Le 11/06/2020 à 17:51, Filip Bozuta a écrit :
> From: Filip Bozuta 
> 
> Structure "struct syscallname" in file "strace.c" is used for "-strace"
> to print arguments and return values of syscalls. The last field of
> this structure "result" represents the calling function that prints the
> return values. This field was extended in this patch so that this 
> functions
> takes all syscalls arguments beside the return value. In this way, it 
> enables
> "-strace" to print arguments of syscalls that have changed after the 
> syscall
> execution. This extension will be useful as there are many syscalls that
> return values inside their arguments (i.e. listxattr() that returns the 
> list
> of extended attributes inside the "list" argument).
> 
> Implementation notes:
> 
> Since there are already three existing "print_syscall_ret*" functions 
> inside
> "strace.c" ("print_syscall_ret_addr()", "print_syscall_ret_adjtimex()",
> "print_syscall_ret_newselect()"), they were changed to have all syscall 
> arguments
> beside the return value. This was done so that these functions don't 
> cause build
> errors (even though syscall arguments are not used in these functions).
> There is code repetition in these functions for checking the return value
> and printing the approppriate error message (this code is also located in
> print_syscall_ret() at the end of "strace.c"). That is the reason why a 
> generic
> function SYSCALL_RET_ERR() was added for this code and put inside these
> functions.
> 
> Signed-off-by: Filip Bozuta 
> ---
>  linux-user/qemu.h|  4 ++-
>  linux-user/strace.c  | 71 ++--
>  linux-user/syscall.c |  2 +-
>  3 files changed, 46 insertions(+), 31 deletions(-)
> 
> diff --git a/linux-user/qemu.h b/linux-user/qemu.h
> index ce902f5132..8f938b8105 100644
> --- a/linux-user/qemu.h
> +++ b/linux-user/qemu.h
> @@ -383,7 +383,9 @@ int host_to_target_waitstatus(int status);
>  void print_syscall(int num,
> abi_long arg1, abi_long arg2, abi_long arg3,
> abi_long arg4, abi_long arg5, abi_long arg6);
> -void print_syscall_ret(int num, abi_long arg1);
> +void print_syscall_ret(int num, abi_long ret,
> +   abi_long arg1, abi_long arg2, abi_long arg3,
> +   abi_long arg4, abi_long arg5, abi_long arg6);
>  /**
>   * print_taken_signal:
>   * @target_signum: target signal being taken
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index 0d9095c674..8678a2aeac 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -19,7 +19,9 @@ struct syscallname {
>  void (*call)(const struct syscallname *,
>   abi_long, abi_long, abi_long,
>   abi_long, abi_long, abi_long);
> -void (*result)(const struct syscallname *, abi_long);
> +void (*result)(const struct syscallname *, abi_long,
> +   abi_long, abi_long, abi_long,
> +   abi_long, abi_long, abi_long);
>  };
>  
>  #ifdef __GNUC__
> @@ -735,18 +737,29 @@ print_ipc(const struct syscallname *name,
>   * Variants for the return value output function
>   */
>  
> +#define SYSCALL_RET_ERR(ret, errstr)\
> +{   \
> +qemu_log(" = ");\
> +if (ret < 0) {  \
> +qemu_log("-1 errno=%d", errno); \
> +errstr = target_strerror(-ret); \
> +if (errstr) {   \
> +qemu_log(" (%s)", errstr);  \
> +}   \
> +}   \
> +}

You should move the declaration of errstr into this block, and then I
think it would be better to have function rather than a macro.

Thanks,
Laurent

Re: [PATCH v7 07/13] hw/386: Add EPYC mode topology decoding functions

[Dr. David Alan Gilbert]

* Babu Moger (babu.mo...@amd.com) wrote:
> 
> 
> > -Original Message-
> > From: Eduardo Habkost 
> > Sent: Wednesday, June 3, 2020 10:46 AM
> > To: Moger, Babu 
> > Cc: marcel.apfelb...@gmail.com; pbonz...@redhat.com; r...@twiddle.net;
> > m...@redhat.com; imamm...@redhat.com; qemu-devel@nongnu.org
> > Subject: Re: [PATCH v7 07/13] hw/386: Add EPYC mode topology decoding
> > functions
> > 
> > On Wed, Jun 03, 2020 at 10:38:46AM -0500, Babu Moger wrote:
> > >
> > >
> > > On 6/3/20 10:31 AM, Eduardo Habkost wrote:
> > > > On Wed, Jun 03, 2020 at 10:22:10AM -0500, Babu Moger wrote:
> > > >>
> > > >>
> > > >>> -Original Message-
> > > >>> From: Eduardo Habkost 
> > > >>> Sent: Tuesday, June 2, 2020 6:01 PM
> > > >>> To: Moger, Babu 
> > > >>> Cc: marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> > r...@twiddle.net;
> > > >>> m...@redhat.com; imamm...@redhat.com; qemu-devel@nongnu.org
> > > >>> Subject: Re: [PATCH v7 07/13] hw/386: Add EPYC mode topology decoding
> > > >>> functions
> > > >>>
> > > >>> On Tue, Jun 02, 2020 at 04:59:19PM -0500, Babu Moger wrote:
> > > 
> > > 
> > > > -Original Message-
> > > > From: Eduardo Habkost 
> > > > Sent: Tuesday, June 2, 2020 12:19 PM
> > > > To: Moger, Babu 
> > > > Cc: marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> > r...@twiddle.net;
> > > > m...@redhat.com; imamm...@redhat.com; qemu-devel@nongnu.org
> > > > Subject: Re: [PATCH v7 07/13] hw/386: Add EPYC mode topology
> > decoding
> > > > functions
> > > >
> > > > Hi,
> > > >
> > > > It looks like this series breaks -device and CPU hotplug:
> > > >
> > > > On Wed, Mar 11, 2020 at 05:53:34PM -0500, Babu Moger wrote:
> > > >> These functions add support for building EPYC mode topology given
> > the
> > > >>> smp
> > > >> details like numa nodes, cores, threads and sockets.
> > > >>
> > > >> The new apic id decoding is mostly similar to current apic id 
> > > >> decoding
> > > >> except that it adds a new field node_id when numa configured.
> > Removes
> > > >>> all
> > > >> the hardcoded values. Subsequent patches will use these functions 
> > > >> to
> > build
> > > >> the topology.
> > > >>
> > > >> Following functions are added.
> > > >> apicid_llc_width_epyc
> > > >> apicid_llc_offset_epyc
> > > >> apicid_pkg_offset_epyc
> > > >> apicid_from_topo_ids_epyc
> > > >> x86_topo_ids_from_idx_epyc
> > > >> x86_topo_ids_from_apicid_epyc
> > > >> x86_apicid_from_cpu_idx_epyc
> > > >>
> > > >> The topology details are available in Processor Programming
> > Reference
> > > >>> (PPR)
> > > >> for AMD Family 17h Model 01h, Revision B1 Processors. The revision
> > > >>> guides
> > > > are
> > > >> available from the bugzilla Link below.
> > > >> Link:
> > > >
> > > >>>
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.
> > > >
> > > >>>
> > kernel.org%2Fshow_bug.cgi%3Fid%3D206537&data=02%7C01%7Cbabu.m
> > > >
> > > >>>
> > oger%40amd.com%7C3487f40d37df4d59097d08d807190248%7C3dd8961fe488
> > > >
> > > >>>
> > 4e608e11a82d994e183d%7C0%7C0%7C637267151289763739&sdata=wE0
> > > > ukXIVh0l5eNQWsv6VDE9UZEVJmisofaW192gcZAI%3D&reserved=0
> > > >>
> > > >> Signed-off-by: Babu Moger 
> > > >> Acked-by: Igor Mammedov 
> > > >> Acked-by: Michael S. Tsirkin 
> > > >> ---
> > > > [...]
> > > >>  typedef struct X86CPUTopoIDs {
> > > >>  unsigned pkg_id;
> > > >> +unsigned node_id;
> > > >
> > > > You have added a new field here.
> > > >
> > > >>  unsigned die_id;
> > > >>  unsigned core_id;
> > > >>  unsigned smt_id;
> > > > [...]
> > > >> +static inline apic_id_t
> > > >> +x86_apicid_from_topo_ids_epyc(X86CPUTopoInfo *topo_info,
> > > >> +  const X86CPUTopoIDs *topo_ids)
> > > >> +{
> > > >> +return (topo_ids->pkg_id  << 
> > > >> apicid_pkg_offset_epyc(topo_info)) |
> > > >> +   (topo_ids->node_id << 
> > > >> apicid_node_offset_epyc(topo_info)) |
> > > >
> > > > You are using the new field here.
> > > >
> > > >> +   (topo_ids->die_id  << apicid_die_offset(topo_info)) |
> > > >> +   (topo_ids->core_id << apicid_core_offset(topo_info)) |
> > > >> +   topo_ids->smt_id;
> > > >> +}
> > > >
> > > > But you are not initializing node_id in one caller of
> > apicid_from_topo_ids():
> > > >
> > > > static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
> > > > DeviceState *dev, Error **errp)
> > > > {
> > > > [...]
> > > > X86CPUTopoIDs topo_ids;
> > > > [...]
> > > > if (cpu->apic_id == UNASSIGNED_APIC_ID) {
> > > > [...]
> > > > topo_ids.pkg_id = cpu->socket_id;
> > > > topo_ids.die_id = cpu

Re: [RFC PATCH v2 1/5] hw/misc: Add a LED device

[Dr. David Alan Gilbert]

* Philippe Mathieu-Daudé (f4...@amsat.org) wrote:
> On 6/15/20 12:55 PM, Dr. David Alan Gilbert wrote:
> > * Philippe Mathieu-Daudé (f4...@amsat.org) wrote:
> >> A LED device can be connected to a GPIO output.
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >> ---
> >>  include/hw/misc/led.h | 30 
> >>  hw/misc/led.c | 84 +++
> >>  MAINTAINERS   |  6 
> >>  hw/misc/Kconfig   |  3 ++
> >>  hw/misc/Makefile.objs |  1 +
> >>  hw/misc/trace-events  |  3 ++
> >>  6 files changed, 127 insertions(+)
> >>  create mode 100644 include/hw/misc/led.h
> >>  create mode 100644 hw/misc/led.c
> >>
> >> diff --git a/include/hw/misc/led.h b/include/hw/misc/led.h
> >> new file mode 100644
> >> index 00..427ca1418e
> >> --- /dev/null
> >> +++ b/include/hw/misc/led.h
> >> @@ -0,0 +1,30 @@
> >> +/*
> >> + * QEMU single LED device
> >> + *
> >> + * Copyright (C) 2020 Philippe Mathieu-Daudé 
> >> + *
> >> + * SPDX-License-Identifier: GPL-2.0-or-later
> >> + */
> >> +#ifndef HW_MISC_LED_H
> >> +#define HW_MISC_LED_H
> >> +
> >> +#include "hw/qdev-core.h"
> >> +#include "hw/sysbus.h" /* FIXME remove */
> >> +
> >> +#define TYPE_LED "led"
> >> +#define LED(obj) OBJECT_CHECK(LEDState, (obj), TYPE_LED)
> >> +
> >> +typedef struct LEDState {
> >> +/* Private */
> >> +SysBusDevice parent_obj; /* FIXME DeviceState */
> >> +/* Public */
> >> +
> >> +qemu_irq irq;
> > 
> > Why an irq?
> 
> We model GPIO/IRQ the same way, this is simply a GPIO, right?
> 
> It makes modeling easier IMO. This is for visualization purpose.
> 
> > 
> >> +uint8_t current_state;
> > 
> > Is the state of this device boolean or is it a 0..255 0=off, 255=full
> > on, analog thing?
> > Can an LED device be connected to a PWM device driving a GPIO - what
> > happens?
> 
> Well I simply wanted to use a boolean, but I need to consider
> if we can model intensity here in case of PWM. This is interesting.

Which then leads to an interesting question about your events in the
next mail;  if I was to connect an LED to a PWM driven GPIO I'd get
zillions of events which may not be what I want.

Dave

> > 
> > Dave
> > 
> > 
> >> +/* Properties */
> >> +char *name;
> >> +uint8_t reset_state; /* TODO [GPIO_ACTIVE_LOW, GPIO_ACTIVE_HIGH] */
> >> +} LEDState;
> >> +
> >> +#endif /* HW_MISC_LED_H */
> >> diff --git a/hw/misc/led.c b/hw/misc/led.c
> >> new file mode 100644
> >> index 00..1bae1a34c0
> >> --- /dev/null
> >> +++ b/hw/misc/led.c
> >> @@ -0,0 +1,84 @@
> >> +/*
> >> + * QEMU single LED device
> >> + *
> >> + * Copyright (C) 2020 Philippe Mathieu-Daudé 
> >> + *
> >> + * SPDX-License-Identifier: GPL-2.0-or-later
> >> + */
> >> +#include "qemu/osdep.h"
> >> +#include "qapi/error.h"
> >> +#include "migration/vmstate.h"
> >> +#include "hw/qdev-properties.h"
> >> +#include "hw/misc/led.h"
> >> +#include "hw/irq.h"
> >> +#include "trace.h"
> >> +
> >> +static void led_set(void *opaque, int line, int new_state)
> >> +{
> >> +LEDState *s = LED(opaque);
> >> +
> >> +trace_led_set(s->name, s->current_state, new_state);
> >> +
> >> +s->current_state = new_state;
> >> +}
> >> +
> >> +static void led_reset(DeviceState *dev)
> >> +{
> >> +LEDState *s = LED(dev);
> >> +
> >> +led_set(dev, 0, s->reset_state);
> >> +}
> >> +
> >> +static const VMStateDescription vmstate_led = {
> >> +.name = TYPE_LED,
> >> +.version_id = 1,
> >> +.minimum_version_id = 1,
> >> +.fields = (VMStateField[]) {
> >> +VMSTATE_UINT8(reset_state, LEDState),
> > 
> > I'm not sure you need to migrate this - this is a property that's set on
> > the device, not a dynamic state of the device
> 
> Yes you are right.
> 
> >> +VMSTATE_END_OF_LIST()
> >> +}
> >> +};
> >> +
> >> +static void led_realize(DeviceState *dev, Error **errp)
> >> +{
> >> +LEDState *s = LED(dev);
> >> +
> >> +if (s->name == NULL) {
> >> +error_setg(errp, "property 'name' not specified");
> >> +return;
> >> +}
> >> +
> >> +qdev_init_gpio_in(DEVICE(s), led_set, 1);
> >> +}
> >> +
> >> +static Property led_properties[] = {
> >> +DEFINE_PROP_STRING("name", LEDState, name),
> >> +DEFINE_PROP_UINT8("reset_state", LEDState, reset_state, 0),
> > 
> > I suggest you add a property for the notional colour; that way any UIs
> > that are built can use that as a hint.
> 
> Great idea, thanks!
> 
> > 
> > Dave
> > 
> >> +DEFINE_PROP_END_OF_LIST(),
> >> +};
> >> +
> >> +static void led_class_init(ObjectClass *klass, void *data)
> >> +{
> >> +DeviceClass *dc = DEVICE_CLASS(klass);
> >> +
> >> +dc->desc = "LED";
> >> +dc->vmsd = &vmstate_led;
> >> +dc->reset = led_reset;
> >> +dc->realize = led_realize;
> >> +set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
> >> +device_class_set_props(dc, led_properties);
> >> +}
> >> +
> >> +static const TypeInfo led_info = {
> >> +.name = TYPE_LED,
> >> +

[Bug 1882784] Re: Legacy IGD passthrough in QEMU 5 disabled

[Thomas Huth]

Patch has been included:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=643a4eacef87a318c

** Changed in: qemu
   Status: Confirmed => Fix Committed

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

Title:
  Legacy IGD passthrough in QEMU 5 disabled

Status in QEMU:
  Fix Committed

Bug description:
  Bug with tag v5.0.0, or commit
  fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6

  As of QEMU 5 Legacy IGD PT is no longer working.

  Host is a Xeon E3-1226 v3 and my method to test is to run the
  following:

  ./qemu-system-x86_64 \
-device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1f' \
-device 'vfio-pci,host=00:02.0,addr=02.0' \
-L '/usr/share/kvm' \
-nographic \
-vga none \
-nodefaults

  in the hope of seeing a "IGD device :00:02.0 cannot support legacy
  mode due to existing devices at address 1f.0" error.

  The culprit appears to be this commit:

  https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19

  Specifically the following block in pci-quirks.c:

  #ifdef CONFIG_VFIO_IGD
  vfio_probe_igd_bar4_quirk(vdev, nr);
  #endif

  as the kconfig variable CONFIG_VFIO_IGD doesn't appear to be available
  outside of makefiles as described here:
  https://qemu.weilnetz.de/doc/devel/kconfig.html. I can confirm that
  the igd code is being pulled in as removing this check, as would
  defining the variable I presume, makes Legacy IGD PT work again (ie I
  see the expected "existing devices" error).

  I first spotted this in Proxmox, but have confirmed the bug by
  building QEMU sources.

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

RE: [PATCH] migration: Count new_dirty instead of real_dirty

[Zhoujian (jay)]

Hi Keqian,

> -Original Message-
> From: zhukeqian
> Sent: Monday, June 15, 2020 11:19 AM
> To: qemu-devel@nongnu.org; qemu-...@nongnu.org; Paolo Bonzini
> ; Zhoujian (jay) 
> Cc: Juan Quintela ; Chao Fan ;
> Wanghaibin (D) 
> Subject: Re: [PATCH] migration: Count new_dirty instead of real_dirty
> 
> Hi Paolo and Jian Zhou,
> 
> Do you have any suggestion on this patch?
> 
> Thanks,
> Keqian
> 
> On 2020/6/1 12:02, Keqian Zhu wrote:
> > DIRTY_LOG_INITIALLY_ALL_SET feature is on the queue. This fixs the

s/fixs/fixes

> > dirty rate calculation for this feature. After introducing this
> > feature, real_dirty_pages is equal to total memory size at begining.
> > This causing wrong dirty rate and false positive throttling.

I think it should be tested whether DIRTY_LOG_INITIALLY_ALL_SET is enabled
in ram_init_bitmaps(maybe?) in order to be compatible with the old path.

Thanks,
Jay Zhou

> >
> > BTW, real dirty rate is not suitable and not very accurate.
> >
> > 1. For not suitable: We mainly concern on the relationship between
> >dirty rate and network bandwidth. Net increasement of dirty pages
> >makes more sense.
> > 2. For not very accurate: With manual dirty log clear, some dirty pages
> >will be cleared during each peroid, our "real dirty rate" is less
> >than real "real dirty rate".



> >
> > Signed-off-by: Keqian Zhu 
> > ---
> >  include/exec/ram_addr.h | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index
> > 5e59a3d8d7..af9677e291 100644
> > --- a/include/exec/ram_addr.h
> > +++ b/include/exec/ram_addr.h
> > @@ -443,7 +443,7 @@ static inline
> >  uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
> > ram_addr_t start,
> > ram_addr_t length,
> > -   uint64_t
> *real_dirty_pages)
> > +   uint64_t
> > + *accu_dirty_pages)
> >  {
> >  ram_addr_t addr;
> >  unsigned long word = BIT_WORD((start + rb->offset) >>
> > TARGET_PAGE_BITS); @@ -469,7 +469,6 @@ uint64_t
> cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
> >  if (src[idx][offset]) {
> >  unsigned long bits = atomic_xchg(&src[idx][offset], 0);
> >  unsigned long new_dirty;
> > -*real_dirty_pages += ctpopl(bits);
> >  new_dirty = ~dest[k];
> >  dest[k] |= bits;
> >  new_dirty &= bits;
> > @@ -502,7 +501,6 @@ uint64_t
> cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
> >  start + addr + offset,
> >  TARGET_PAGE_SIZE,
> >  DIRTY_MEMORY_MIGRATION)) {
> > -*real_dirty_pages += 1;
> >  long k = (start + addr) >> TARGET_PAGE_BITS;
> >  if (!test_and_set_bit(k, dest)) {
> >  num_dirty++;
> > @@ -511,6 +509,7 @@ uint64_t
> cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
> >  }
> >  }
> >
> > +*accu_dirty_pages += num_dirty;
> >  return num_dirty;
> >  }
> >  #endif
> >

Re: [PATCH v3 3/6] linux-user: Add strace support for printing argument of syscalls used for extended attributes

[Laurent Vivier]

Le 11/06/2020 à 17:51, Filip Bozuta a écrit :
> From: Filip Bozuta 
> 
> This patch implements strace argument printing functionality for following 
> syscalls:
> 
> *getxattr, lgetxattr, fgetxattr - retrieve an extended attribute value
> 
> ssize_t getxattr(const char *path, const char *name, void *value, 
> size_t size)
> ssize_t lgetxattr(const char *path, const char *name, void *value, 
> size_t size)
> ssize_t fgetxattr(int fd, const char *name, void *value, size_t size)
> man page: https://www.man7.org/linux/man-pages/man2/getxattr.2.html
> 
> *listxattr, llistxattr, flistxattr - list extended attribute names
> 
> ssize_t listxattr(const char *path, char *list, size_t size)
> ssize_t llistxattr(const char *path, char *list, size_t size)
> ssize_t flistxattr(int fd, char *list, size_t size)
> man page: https://www.man7.org/linux/man-pages/man2/listxattr.2.html
> 
> *removexattr, lremovexattr, fremovexattr - remove an extended attribute
> 
>  int removexattr(const char *path, const char *name)
>  int lremovexattr(const char *path, const char *name)
>  int fremovexattr(int fd, const char *name)
>  man page: 
> https://www.man7.org/linux/man-pages/man2/removexattr.2.html

Compared to v2, fremovexattr, removexattr and lremovexattr are missing.

> 
> Implementation notes:
> 
> All of the syscalls have strings as argument types and thus a separate
> printing function was stated in file "strace.list" for every one of them.
> All of these printing functions were defined in "strace.c" using existing
> printing functions for appropriate argument types:
>"print_string()" - for (const char*) type
>"print_pointer()" - for (char*) and (void *) type
>"print_raw_param()" for (int) and (size_t) type
> Syscalls "getxattr()" and "lgetxattr()" have the same number and type of
> arguments and thus their print functions ("print_getxattr", 
> "print_lgetxattr")
> share a same definition. The same statement applies to syscalls 
> "listxattr()"
> and "llistxattr()".
> Function "print_syscall_ret_listxattr()" was added to print the returned 
> list
> of extended attributes for syscalls "print_listxattr(), 
> print_llistxattr() and
> print_flistxattr()".
> 
> Signed-off-by: Filip Bozuta 
> ---
>  linux-user/strace.c| 95 ++
>  linux-user/strace.list | 15 ---
>  2 files changed, 104 insertions(+), 6 deletions(-)
> 
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index 4f85606c19..a7c3ea8df3 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -834,6 +834,41 @@ print_syscall_ret_adjtimex(const struct syscallname 
> *name, abi_long ret,
>  }
>  #endif
>  
> +#if defined(TARGET_NR_listxattr) || defined(TARGET_NR_llistxattr) \
> + || defined(TARGGET_NR_flistxattr)
> +static void
> +print_syscall_ret_listxattr(const struct syscallname *name, abi_long ret,
> +abi_long arg0, abi_long arg1, abi_long arg2,
> +abi_long arg3, abi_long arg4, abi_long arg5)
> +{
> +const char *errstr = NULL;
> +
> +SYSCALL_RET_ERR(ret, errstr);
> +
> +if (ret >= 0) {
> +qemu_log(TARGET_ABI_FMT_ld, ret);
> +qemu_log(" (list = ");
> +if (arg1 != 0) {
> +abi_long attr = arg1;
> +while (target_strlen(attr) != 0) {

You can't rely on target_strlen(), you should rely on the value returned
by the ioctl() (ret) that is defined as the length of the returned data.

Thanks,
Laurent

Re: [PATCH v3 6/6] linux-user: Add strace support for printing arguments of fallocate()

[Laurent Vivier]

Le 11/06/2020 à 17:51, Filip Bozuta a écrit :
> From: Filip Bozuta 
> 
> This patch implements strace argument printing functionality for following 
> syscall:
> 
> *fallocate - manipulate file space
> 
> int fallocate(int fd, int mode, off_t offset, off_t len)
> man page: https://www.man7.org/linux/man-pages/man2/fallocate.2.html
> 
> Implementation notes:
> 
> This syscall's second argument "mode" is composed of predefined values
> which represent flags that determine the type of operation that is
> to be performed on the file space. For that reason, a printing
> function "print_fallocate" was stated in file "strace.list". This printing
> function uses an already existing function "print_flags()" to print flags 
> of
> the "mode" argument. These flags are stated inside an array "falloc_flags"
> that contains values of type "struct flags". These values are instantiated
> using an existing macro "FLAG_GENERIC()". Most of these flags are defined
> after kernel version 3.0 which is why they are enwrapped in an #ifdef
> directive.
> The syscall's third ant fourth argument are of type "off_t" which can
> cause variations between 32/64-bit architectures. To handle this 
> variation,
> function "target_offset64()" was copied from file "strace.c" and used in
> "print_fallocate" to print "off_t" arguments for 32-bit architectures.
> 
> Signed-off-by: Filip Bozuta 
> Reviewed-by: Laurent Vivier 
> ---
>  linux-user/qemu.h  | 16 
>  linux-user/strace.c| 40 
>  linux-user/strace.list |  2 +-
>  linux-user/syscall.c   | 16 
>  4 files changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git a/linux-user/qemu.h b/linux-user/qemu.h
> index 8f938b8105..be67391ba4 100644
> --- a/linux-user/qemu.h
> +++ b/linux-user/qemu.h
> @@ -670,6 +670,22 @@ static inline int is_error(abi_long ret)
>  return (abi_ulong)ret >= (abi_ulong)(-4096);
>  }
>  
> +#if TARGET_ABI_BITS == 32
> +static inline uint64_t target_offset64(uint32_t word0, uint32_t word1)
> +{
> +#ifdef TARGET_WORDS_BIGENDIAN
> +return ((uint64_t)word0 << 32) | word1;
> +#else
> +return ((uint64_t)word1 << 32) | word0;
> +#endif
> +}
> +#else /* TARGET_ABI_BITS == 32 */
> +static inline uint64_t target_offset64(uint64_t word0, uint64_t word1)
> +{
> +return word0;
> +}
> +#endif /* TARGET_ABI_BITS != 32 */
> +
>  /**
>   * preexit_cleanup: housekeeping before the guest exits
>   *
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index 40c17f7abe..5f370256e3 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -1144,6 +1144,26 @@ UNUSED static struct flags statx_mask[] = {
>  FLAG_END,
>  };
>  
> +UNUSED static struct flags falloc_flags[] = {
> +FLAG_GENERIC(FALLOC_FL_KEEP_SIZE),
> +FLAG_GENERIC(FALLOC_FL_PUNCH_HOLE),
> +#ifdef FALLOC_FL_NO_HIDE_STALE
> +FLAG_GENERIC(FALLOC_FL_NO_HIDE_STALE),
> +#endif
> +#ifdef FALLOC_FL_COLLAPSE_RANGE
> +FLAG_GENERIC(FALLOC_FL_COLLAPSE_RANGE),
> +#endif
> +#ifdef FALLOC_FL_ZERO_RANGE
> +FLAG_GENERIC(FALLOC_FL_ZERO_RANGE),
> +#endif
> +#ifdef FALLOC_FL_INSERT_RANGE
> +FLAG_GENERIC(FALLOC_FL_INSERT_RANGE),
> +#endif
> +#ifdef FALLOC_FL_UNSHARE_RANGE
> +FLAG_GENERIC(FALLOC_FL_UNSHARE_RANGE),
> +#endif
> +};
> +
>  /*
>   * print_xxx utility functions.  These are used to print syscall
>   * parameters in certain format.  All of these have parameter
> @@ -1561,6 +1581,26 @@ print_faccessat(const struct syscallname *name,
>  }
>  #endif
>  
> +#ifdef TARGET_NR_fallocate
> +static void
> +print_fallocate(const struct syscallname *name,
> +abi_long arg0, abi_long arg1, abi_long arg2,
> +abi_long arg3, abi_long arg4, abi_long arg5)
> +{
> +print_syscall_prologue(name);
> +print_raw_param("%d", arg0, 0);
> +print_flags(falloc_flags, arg1, 0);
> +#if TARGET_ABI_BITS == 32
> +print_raw_param("%ld", target_offset64(arg2, arg3), 0);
> +print_raw_param("%ld", target_offset64(arg4, arg5), 1);
> +#else
> +print_raw_param("%ld", arg2, 0);
> +print_raw_param("%ld", arg3, 1);
> +#endif
>

You have removed the PRIu64 and TARGET_ABI_FMT_ld from the v2. So my
Reviewed-by is not relevant for the v3.

Thanks,
Laurent

Re: [PATCH 1/4] migration/savevm: respect qemu_fclose() error code in save_snapshot()

[Dr. David Alan Gilbert]

* Denis V. Lunev (d...@openvz.org) wrote:
> qemu_fclose() could return error, f.e. if bdrv_co_flush() will return
> the error.
> 
> This validation will become more important once we will start waiting of
> asynchronous IO operations, started from bdrv_write_vmstate(), which are
> coming soon.
> 
> Signed-off-by: Denis V. Lunev 
> CC: Kevin Wolf 
> CC: Max Reitz 
> CC: Stefan Hajnoczi 
> CC: Fam Zheng 
> CC: Juan Quintela 
> CC: "Dr. David Alan Gilbert" 
> CC: Vladimir Sementsov-Ogievskiy 
> CC: Denis Plotnikov 

We check the return value in very few other places; I think in the
migration case we do flushes and assume that if the flushes work we
were OK; then most of the closes happen on error paths or after points
we think we're done.

Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/savevm.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/savevm.c b/migration/savevm.c
> index c00a6807d9..0ff5bb40ed 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -2628,7 +2628,7 @@ int save_snapshot(const char *name, Error **errp)
>  {
>  BlockDriverState *bs, *bs1;
>  QEMUSnapshotInfo sn1, *sn = &sn1, old_sn1, *old_sn = &old_sn1;
> -int ret = -1;
> +int ret = -1, ret2;
>  QEMUFile *f;
>  int saved_vm_running;
>  uint64_t vm_state_size;
> @@ -2712,10 +2712,14 @@ int save_snapshot(const char *name, Error **errp)
>  }
>  ret = qemu_savevm_state(f, errp);
>  vm_state_size = qemu_ftell(f);
> -qemu_fclose(f);
> +ret2 = qemu_fclose(f);
>  if (ret < 0) {
>  goto the_end;
>  }
> +if (ret2 < 0) {
> +ret = ret2;
> +goto the_end;
> +}
>  
>  /* The bdrv_all_create_snapshot() call that follows acquires the 
> AioContext
>   * for itself.  BDRV_POLL_WHILE() does not support nested locking because
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v3 0/2] net: Drop legacy "name" from -net and remove NetLegacy

[Thomas Huth]

On 18/05/2020 20.01, Thomas Huth wrote:
> Since commit b4983c570c7a ("net: Remove deprecated [hub_id name] tuple of
> 'hostfwd_add' / 'hostfwd_remove'"), the "name" parameter is not used
> internally anymore. And it's been marked as deprecated since QEMU v3.1,
> so it is time to remove the "name" parameter from -net now. Once this
> has been done, we can also drop the obsolete NetLegacy structure since
> there is no major difference between Netdev and NetLegacy anymore.
> 
> v3:
>  - Do not make "id" in Netdev optional, but rather assign a temporary
>"id" for -net before we call the options visitor function.
>  - Changed some "void *" to "Netdev *" now
> 
> v2:
>  - Rebased to master (use the deprecated.rst instead of qemu-deprecated.texi)
> 
> Thomas Huth (2):
>   net: Drop the legacy "name" parameter from the -net option
>   net: Drop the NetLegacy structure, always use Netdev instead

Ping!

Jason, do you think these patches are OK now, and if so, could you
please queue them for your next net pull request?

 Thanks,
  Thomas

[PATCH] kvm: i386: allow TSC to differ by NTP correction bounds without TSC scaling

[Marcelo Tosatti]

The Linux TSC calibration procedure is subject to small variations
(its common to see +-1 kHz difference between reboots on a given CPU, for 
example).

So migrating a guest between two hosts with identical processor can fail, in 
case 
of a small variation in calibrated TSC between them.

Allow a conservative 250ppm error between host TSC and VM TSC frequencies,
rather than requiring an exact match. NTP daemon in the guest can
correct this difference.

Also change migration to accept this bound.

Signed-off-by: Marcelo Tosatti 

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 34f8387..257fee4 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -739,23 +739,44 @@ static int kvm_arch_set_tsc_khz(CPUState *cs)
 {
 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *env = &cpu->env;
-int r;
+int r, cur_freq;
+bool set_ioctl = false;
 
 if (!env->tsc_khz) {
 return 0;
 }
 
-r = kvm_check_extension(cs->kvm_state, KVM_CAP_TSC_CONTROL) ?
+cur_freq = kvm_check_extension(cs->kvm_state, KVM_CAP_GET_TSC_KHZ) ?
+   kvm_vcpu_ioctl(cs, KVM_GET_TSC_KHZ) : -ENOTSUP;
+
+/*
+ * If TSC scaling is supported, attempt to set TSC frequency.
+ */
+if (kvm_check_extension(cs->kvm_state, KVM_CAP_TSC_CONTROL)) {
+set_ioctl = true;
+}
+
+/*
+ * If desired TSC frequency is within bounds of NTP correction,
+ * attempt to set TSC frequency.
+ */
+if (cur_freq != -ENOTSUP && freq_within_bounds(cur_freq, env->tsc_khz)) {
+set_ioctl = true;
+}
+
+r = set_ioctl ?
 kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz) :
 -ENOTSUP;
+
 if (r < 0) {
 /* When KVM_SET_TSC_KHZ fails, it's an error only if the current
  * TSC frequency doesn't match the one we want.
  */
-int cur_freq = kvm_check_extension(cs->kvm_state, KVM_CAP_GET_TSC_KHZ) 
?
-   kvm_vcpu_ioctl(cs, KVM_GET_TSC_KHZ) :
-   -ENOTSUP;
-if (cur_freq <= 0 || cur_freq != env->tsc_khz) {
+cur_freq = kvm_check_extension(cs->kvm_state, KVM_CAP_GET_TSC_KHZ) ?
+   kvm_vcpu_ioctl(cs, KVM_GET_TSC_KHZ) :
+   -ENOTSUP;
+if (cur_freq <= 0 || (cur_freq != env->tsc_khz &&
+  !freq_within_bounds(cur_freq, env->tsc_khz))) {
 warn_report("TSC frequency mismatch between "
 "VM (%" PRId64 " kHz) and host (%d kHz), "
 "and TSC scaling unavailable",
diff --git a/target/i386/kvm_i386.h b/target/i386/kvm_i386.h
index 00bde7a..ebf9a64 100644
--- a/target/i386/kvm_i386.h
+++ b/target/i386/kvm_i386.h
@@ -47,4 +47,20 @@ bool kvm_has_x2apic_api(void);
 
 bool kvm_hv_vpindex_settable(void);
 
+/*
+ * Check whether target_freq is within conservative
+ * ntp correctable bounds (250ppm) of freq
+ */
+static inline bool freq_within_bounds(int freq, int target_freq)
+{
+int max_freq = freq + (freq * 250 / 100);
+int min_freq = freq - (freq * 250 / 100);
+
+if (target_freq >= min_freq && target_freq <= max_freq) {
+return true;
+}
+
+return false;
+}
+
 #endif
diff --git a/target/i386/machine.c b/target/i386/machine.c
index 0c96531..b052654 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -300,7 +300,7 @@ static int cpu_post_load(void *opaque, int version_id)
 int i;
 
 if (env->tsc_khz && env->user_tsc_khz &&
-env->tsc_khz != env->user_tsc_khz) {
+!freq_within_bounds(env->tsc_khz, env->user_tsc_khz)) {
 error_report("Mismatch between user-specified TSC frequency and "
  "migrated TSC frequency");
 return -EINVAL;

Re: [PATCH v3] target/arm/cpu: adjust virtual time for arm cpu

[Peter Maydell]

On Mon, 8 Jun 2020 at 13:12, Ying Fang  wrote:
>
> From: fangying 
>
> Virtual time adjustment was implemented for virt-5.0 machine type,
> but the cpu property was enabled only for host-passthrough and
> max cpu model. Let's add it for arm cpu which has the generic timer
> feature enabled.
>
> Suggested-by: Andrew Jones 
> Signed-off-by: Ying Fang 



Applied to target-arm.next, thanks (with a minor commit message
wording tweak, and the suggested-by tag removed).

-- PMM

Re: [PATCH v3 0/4] block: seriously improve savevm performance

[Dr. David Alan Gilbert]

* Denis V. Lunev (d...@openvz.org) wrote:
> This series do standard basic things:
> - it creates intermediate buffer for all writes from QEMU migration code
>   to QCOW2 image,
> - this buffer is sent to disk asynchronously, allowing several writes to
>   run in parallel.
> 
> In general, migration code is fantastically inefficent (by observation),
> buffers are not aligned and sent with arbitrary pieces, a lot of time
> less than 100 bytes at a chunk, which results in read-modify-write
> operations with non-cached operations. It should also be noted that all
> operations are performed into unallocated image blocks, which also suffer
> due to partial writes to such new clusters.

It surprises me a little that you're not benefiting from the buffer
internal to qemu-file.c

Dave

> This patch series is an implementation of idea discussed in the RFC
> posted by Denis Plotnikov
> https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg01925.html
> Results with this series over NVME are better than original code
> original rfcthis
> cached:  1.79s  2.38s   1.27s
> non-cached:  3.29s  1.31s   0.81s
> 
> Changes from v2:
> - code moved from QCOW2 level to generic block level
> - created bdrv_flush_vmstate helper to fix 022, 029 tests
> - added recursive for bs->file in bdrv_co_flush_vmstate (fix 267)
> - fixed blk_save_vmstate helper
> - fixed coroutine wait as Vladimir suggested with waiting fixes from me
> 
> Changes from v1:
> - patchew warning fixed
> - fixed validation that only 1 waiter is allowed in patch 1
> 
> Signed-off-by: Denis V. Lunev 
> CC: Kevin Wolf 
> CC: Max Reitz 
> CC: Stefan Hajnoczi 
> CC: Fam Zheng 
> CC: Juan Quintela 
> CC: "Dr. David Alan Gilbert" 
> CC: Vladimir Sementsov-Ogievskiy 
> CC: Denis Plotnikov 
> 
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v5 2/3] hw/net/imx_fec: Allow phy not to be the first device on the mii bus.

[Peter Maydell]

On Thu, 4 Jun 2020 at 13:39, Jean-Christophe Dubois  
wrote:
>
> Up to now we were allowing only one PHY device and it had to be the
> first device on the bus.
>
> The i.MX6UL has 2 Ethernet devices and can therefore have several
> PHY devices on the bus (and not necessarilly as device 0).
>
> This patch allows for PHY devices on 2nd, 3rd or any position.
>
> Signed-off-by: Jean-Christophe Dubois 

> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> index eefedc252de..29e613699ee 100644
> --- a/hw/net/imx_fec.c
> +++ b/hw/net/imx_fec.c
> @@ -280,11 +280,9 @@ static void imx_phy_reset(IMXFECState *s)
>  static uint32_t imx_phy_read(IMXFECState *s, int reg)
>  {
>  uint32_t val;
> +uint32_t phy = reg / 32;
>
> -if (reg > 31) {
> -/* we only advertise one phy */
> -return 0;
> -}
> +reg %= 32;

This change means we now support multiple PHYs...

>
>  switch (reg) {
>  case 0: /* Basic Control */
> @@ -331,19 +329,18 @@ static uint32_t imx_phy_read(IMXFECState *s, int reg)
>  break;
>  }
>
> -trace_imx_phy_read(val, reg);
> +trace_imx_phy_read(val, phy, reg);

...but the only change we actually make is to trace the phy number.
Surely if there is more than one phy then each phy needs to have
its own state (phy_control/phy_status/phy_advertise/etc), rather
than all these PHYs all sharing the same state under the hood?

It also sounds from your commit message as if there isn't a
large number of PHYs, but only perhaps two. In that case
don't we need to fail attempts to access non-existent PHYs
and only work with the ones which actually exist on any
given board?

thanks
-- PMM

Re: [PATCH 2/2] linux-user: Add strace support for printing arguments of ioctl()

[Laurent Vivier]

Le 12/06/2020 à 18:40, Filip Bozuta a écrit :
> From: Filip Bozuta 
> 
> This patch implements functionality for strace argument printing for ioctls.
> When running ioctls through qemu with "-strace", they get printed in format:
> 
> "ioctl(fd_num,0x*,0x*) = ret_value"
> 
> where the request code an the ioctl's third argument get printed in a 
> hexadicemal
> format. This patch changes that by enabling strace to print both the request 
> code
> name and the contents of the third argument. For example, when running ioctl
> RTC_SET_TIME with "-strace", with changes from this patch, it gets printed in
> this way:
> 
> "ioctl(3,RTC_SET_TIME,{12,13,15,20,10,119,0,0,0}) = 0"
> 
> In case of IOC_R type ioctls, the contents of the third argument get printed
> after the return value, and the argument inside the ioctl call gets printed
> as pointer in hexadecimal format. For example, when running RTC_RD_TIME with
> "-strace", with changes from this patch, it gets printed in this way:
> 
> "ioctl(3,RTC_RD_TIME,0x40800374) = 0 ({22,9,13,11,5,120,0,0,0})"
> 
> In case of IOC_RW type ioctls, the contents of the third argument get printed
> both inside the ioctl call and after the return value.
> 
> Implementation notes:
> 
> Functions "print_ioctl()" and "print_syscall_ret_ioctl()", that are 
> defined
> in "strace.c", are listed in file "strace.list" as "call" and "result"
> value for ioctl. Structure definition "IOCTLEntry" as well as predefined
> values for IOC_R, IOC_W and IOC_RW were cut and pasted from file 
> "syscall.c"
> to file "qemu.h" so that they can be used by these functions to print the
> contents of the third ioctl argument. Also, the "static" identifier for 
> array
> "ioctl_entries[]" was removed and this array was declared as "extern" in 
> "qemu.h"
> so that it can also be used by these functions. To decode the structure 
> type
> of the ioctl third argument, function "thunk_print()" was defined in file
> "thunk.c" and its definition is somewhat simillar to that of function
> "thunk_convert()".
> 
> Signed-off-by: Filip Bozuta 
> ---
>  include/exec/user/thunk.h |   1 +
>  linux-user/qemu.h |  20 +
>  linux-user/strace.c   | 120 +
>  linux-user/strace.list|   3 +-
>  linux-user/syscall.c  |  20 +
>  thunk.c   | 154 ++
>  6 files changed, 298 insertions(+), 20 deletions(-)
> 
> diff --git a/include/exec/user/thunk.h b/include/exec/user/thunk.h
> index eae2c27f99..7992475c9f 100644
> --- a/include/exec/user/thunk.h
> +++ b/include/exec/user/thunk.h
> @@ -73,6 +73,7 @@ void thunk_register_struct_direct(int id, const char *name,
>const StructEntry *se1);
>  const argtype *thunk_convert(void *dst, const void *src,
>   const argtype *type_ptr, int to_host);
> +const argtype *thunk_print(void *arg, const argtype *type_ptr);
>  
>  extern StructEntry *struct_entries;
>  
> diff --git a/linux-user/qemu.h b/linux-user/qemu.h
> index be67391ba4..5c964389c1 100644
> --- a/linux-user/qemu.h
> +++ b/linux-user/qemu.h
> @@ -184,6 +184,26 @@ struct linux_binprm {
>  int (*core_dump)(int, const CPUArchState *); /* coredump routine */
>  };
>  
> +typedef struct IOCTLEntry IOCTLEntry;
> +
> +typedef abi_long do_ioctl_fn(const IOCTLEntry *ie, uint8_t *buf_temp,
> + int fd, int cmd, abi_long arg);
> +
> +struct IOCTLEntry {
> +int target_cmd;
> +unsigned int host_cmd;
> +const char *name;
> +int access;
> +do_ioctl_fn *do_ioctl;
> +const argtype arg_type[5];
> +};
> +
> +extern IOCTLEntry ioctl_entries[];
> +
> +#define IOC_R 0x0001
> +#define IOC_W 0x0002
> +#define IOC_RW (IOC_R | IOC_W)
> +
>  void do_init_thread(struct target_pt_regs *regs, struct image_info *infop);
>  abi_ulong loader_build_argptr(int envc, int argc, abi_ulong sp,
>abi_ulong stringp, int push_ptr);
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index 5f370256e3..8de8f242ae 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -869,6 +869,51 @@ print_syscall_ret_listxattr(const struct syscallname 
> *name, abi_long ret,
>  #define print_syscall_ret_flistxattr print_syscall_ret_listxattr
>  #endif
>  
> +#ifdef TARGET_NR_ioctl
> +static void
> +print_syscall_ret_ioctl(const struct syscallname *name, abi_long ret,
> +abi_long arg0, abi_long arg1, abi_long arg2,
> +abi_long arg3, abi_long arg4, abi_long arg5)
> +{
> +const char *errstr = NULL;
> +
> +qemu_log(" = ");
> +if (ret < 0) {
> +qemu_log("-1 errno=%d", errno);
> +errstr = target_strerror(-ret);
> +if (errstr) {
> +qemu_log(" (%s)", errstr);
> +}

You should use the error function you used in your provious series.
You can explain it is based on it

Re: [PULL v2 20/58] bios-tables-test: Add Q35/TPM-TIS test

[Auger Eric]

Hi Philippe, Thomas,

On 6/15/20 12:22 PM, Thomas Huth wrote:
> On 15/06/2020 12.02, Philippe Mathieu-Daudé wrote:
>> On Fri, Jun 12, 2020 at 5:00 PM Michael S. Tsirkin  wrote:
>>>
>>> From: Eric Auger 
>>>
>>> Test tables specific to the TPM-TIS instantiation.
>>> The TPM2 is added in the framework. Also the DSDT
>>> is updated with the TPM. The new function should be
>>> be usable for CRB as well, later one.
>>>
>>> Signed-off-by: Eric Auger 
>>>
>>> Message-Id: <20200609125409.24179-5-eric.au...@redhat.com>
>>> Reviewed-by: Michael S. Tsirkin 
>>> Signed-off-by: Michael S. Tsirkin 
>>> ---
>>>  tests/qtest/bios-tables-test.c | 58 ++
>>>  tests/qtest/Makefile.include   |  1 +
>>>  2 files changed, 59 insertions(+)
>>>
>>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>>> index c9843829b3..53f104a9c5 100644
>>> --- a/tests/qtest/bios-tables-test.c
>>> +++ b/tests/qtest/bios-tables-test.c
>>> @@ -57,6 +57,9 @@
>>>  #include "qemu/bitmap.h"
>>>  #include "acpi-utils.h"
>>>  #include "boot-sector.h"
>>> +#include "tpm-emu.h"
>>> +#include "hw/acpi/tpm.h"
>>> +
>>>
>>>  #define MACHINE_PC "pc"
>>>  #define MACHINE_Q35 "q35"
>>> @@ -874,6 +877,60 @@ static void test_acpi_piix4_tcg_numamem(void)
>>>  free_test_data(&data);
>>>  }
>>>
>>> +uint64_t tpm_tis_base_addr;
>>> +
>>> +static void test_acpi_tcg_tpm(const char *machine, const char *tpm_if,
>>> +  uint64_t base)
>>> +{
>>> +gchar *tmp_dir_name = 
>>> g_strdup_printf("qemu-test_acpi_%s_tcg_%s.XX",
>>> +  machine, tpm_if);
>>> +char *tmp_path = g_dir_make_tmp(tmp_dir_name, NULL);
>>> +TestState test;
>>> +test_data data;
>>> +GThread *thread;
>>> +char *args, *variant = g_strdup_printf(".%s", tpm_if);
>>> +
>>> +tpm_tis_base_addr = base;
>>> +
>>> +module_call_init(MODULE_INIT_QOM);
>>> +
>>> +test.addr = g_new0(SocketAddress, 1);
>>> +test.addr->type = SOCKET_ADDRESS_TYPE_UNIX;
>>> +test.addr->u.q_unix.path = g_build_filename(tmp_path, "sock", NULL);
>>> +g_mutex_init(&test.data_mutex);
>>> +g_cond_init(&test.data_cond);
>>> +test.data_cond_signal = false;
>>> +
>>> +thread = g_thread_new(NULL, tpm_emu_ctrl_thread, &test);
>>> +tpm_emu_test_wait_cond(&test);
>>> +
>>> +memset(&data, 0, sizeof(data));
>>> +data.machine = machine;
>>> +data.variant = variant;
>>> +
>>> +args = g_strdup_printf(
>>> +" -chardev socket,id=chr,path=%s"
>>> +" -tpmdev emulator,id=dev,chardev=chr"
>>
>> This test makes our CI fail:
>> https://gitlab.com/qemu-project/qemu/-/jobs/593586369#L3466
> 
> Right. The problem seems to occur as soon as you run "configure" with
> "--disable-tpm" ... I think you need some "#ifdef CONFIG_TPM" here?
Thank you. I will respin asap.

Eric
> 
>  Thomas
> 
> 

[PATCH 3/3] acpi: Enable TPM IRQ

[Stefan Berger]

From: Stefan Berger 

Move the TPM TIS IRQ to unused IRQ 13, which is also accepted by Windows.
Query for the TPM's irq number and enable the TPM IRQ if not zero.

Signed-off-by: Stefan Berger 
CC: Michael S. Tsirkin 
---
 hw/i386/acpi-build.c  | 11 +--
 include/hw/acpi/tpm.h |  2 +-
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 23c77eeb95..919cab1702 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2199,6 +2199,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
 
 if (TPM_IS_TIS_ISA(tpm)) {
+uint8_t irq = tpm_get_irqnum(tpm);
 if (misc->tpm_version == TPM_VERSION_2_0) {
 dev = aml_device("TPM");
 aml_append(dev, aml_name_decl("_HID",
@@ -2213,12 +2214,10 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 crs = aml_resource_template();
 aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
-/*
-FIXME: TPM_TIS_IRQ=5 conflicts with PNP0C0F irqs,
-Rewrite to take IRQ from TPM device model and
-fix default IRQ value there to use some unused IRQ
- */
-/* aml_append(crs, aml_irq_no_flags(TPM_TIS_IRQ)); */
+
+if (irq) {
+aml_append(crs, aml_irq_no_flags(irq));
+}
 aml_append(dev, aml_name_decl("_CRS", crs));
 
 tpm_build_ppi_acpi(tpm, dev);
diff --git a/include/hw/acpi/tpm.h b/include/hw/acpi/tpm.h
index 1a2a57a21f..063a9eb42a 100644
--- a/include/hw/acpi/tpm.h
+++ b/include/hw/acpi/tpm.h
@@ -24,7 +24,7 @@
 #define TPM_TIS_ADDR_BASE   0xFED4
 #define TPM_TIS_ADDR_SIZE   0x5000
 
-#define TPM_TIS_IRQ 5
+#define TPM_TIS_IRQ 13
 
 #define TPM_TIS_NUM_LOCALITIES  5 /* per spec */
 #define TPM_TIS_LOCALITY_SHIFT  12
-- 
2.24.1

[PATCH 1/3] tpm_tis: Allow lowering of IRQ also when locality is not active

[Stefan Berger]

From: Stefan Berger 

This patch fixes a bug that occurs when using interrupts. It
allows to lower the IRQ also when a locality is not active.

Signed-off-by: Stefan Berger 
---
 hw/tpm/tpm_tis_common.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/tpm/tpm_tis_common.c b/hw/tpm/tpm_tis_common.c
index 9ce64d4836..695a10a791 100644
--- a/hw/tpm/tpm_tis_common.c
+++ b/hw/tpm/tpm_tis_common.c
@@ -601,10 +601,6 @@ static void tpm_tis_mmio_write(void *opaque, hwaddr addr,
 /* hard wired -- ignore */
 break;
 case TPM_TIS_REG_INT_STATUS:
-if (s->active_locty != locty) {
-break;
-}
-
 /* clearing of interrupt flags */
 if (((val & TPM_TIS_INTERRUPTS_SUPPORTED)) &&
 (s->loc[locty].ints & TPM_TIS_INTERRUPTS_SUPPORTED)) {
-- 
2.24.1

Re: [PATCH v3 0/4] block: seriously improve savevm performance

[Denis V. Lunev]

On 6/15/20 3:17 PM, Dr. David Alan Gilbert wrote:
> * Denis V. Lunev (d...@openvz.org) wrote:
>> This series do standard basic things:
>> - it creates intermediate buffer for all writes from QEMU migration code
>>   to QCOW2 image,
>> - this buffer is sent to disk asynchronously, allowing several writes to
>>   run in parallel.
>>
>> In general, migration code is fantastically inefficent (by observation),
>> buffers are not aligned and sent with arbitrary pieces, a lot of time
>> less than 100 bytes at a chunk, which results in read-modify-write
>> operations with non-cached operations. It should also be noted that all
>> operations are performed into unallocated image blocks, which also suffer
>> due to partial writes to such new clusters.
> It surprises me a little that you're not benefiting from the buffer
> internal to qemu-file.c
>
> Dave
There are a lot of problems with this buffer:

Flushes to block driver state are performed in the abstract places,
pushing
  a) small IO
  b) non-aligned IO both to
   1) page size
   2) cluster size
It should also be noted that buffer in QEMU file is quite small and
all IO operations with it are synchronous. IO, like ethernet, wants
good queues.

The difference is on the table.

Den

[PATCH 0/3] tpm: Enable usage of TPM TIS with interrupts

[Stefan Berger]

This series of patches enables the usage of the TPM TIS with interrupts.
We use the unused IRQ 13, which is also accepted by Windows.

Stefan

Stefan Berger (3):
  tpm_tis: Allow lowering of IRQ also when locality is not active
  tpm: Extend TPMIfClass with get_irqnum() function
  acpi: Enable TPM IRQ

 hw/i386/acpi-build.c| 11 +--
 hw/tpm/tpm_tis_common.c |  4 
 hw/tpm/tpm_tis_isa.c|  9 +
 hw/tpm/tpm_tis_sysbus.c |  9 +
 include/hw/acpi/tpm.h   |  2 +-
 include/sysemu/tpm.h| 10 ++
 6 files changed, 34 insertions(+), 11 deletions(-)

-- 
2.24.1

[PATCH 2/3] tpm: Extend TPMIfClass with get_irqnum() function

[Stefan Berger]

From: Stefan Berger 

Implement get_ireqnum() as part of the TPMIfClass to be get the assigned
IRQ number.

Signed-off-by: Stefan Berger 
---
 hw/tpm/tpm_tis_isa.c|  9 +
 hw/tpm/tpm_tis_sysbus.c |  9 +
 include/sysemu/tpm.h| 10 ++
 3 files changed, 28 insertions(+)

diff --git a/hw/tpm/tpm_tis_isa.c b/hw/tpm/tpm_tis_isa.c
index 30ba37079d..63b62f4c21 100644
--- a/hw/tpm/tpm_tis_isa.c
+++ b/hw/tpm/tpm_tis_isa.c
@@ -80,6 +80,14 @@ static enum TPMVersion tpm_tis_isa_get_tpm_version(TPMIf *ti)
 return tpm_tis_get_tpm_version(s);
 }
 
+static uint8_t tpm_tis_isa_get_irqnum(TPMIf *ti)
+{
+TPMStateISA *isadev = TPM_TIS_ISA(ti);
+TPMState *s = &isadev->state;
+
+return s->irq_num;
+}
+
 static void tpm_tis_isa_reset(DeviceState *dev)
 {
 TPMStateISA *isadev = TPM_TIS_ISA(dev);
@@ -148,6 +156,7 @@ static void tpm_tis_isa_class_init(ObjectClass *klass, void 
*data)
 dc->reset = tpm_tis_isa_reset;
 tc->request_completed = tpm_tis_isa_request_completed;
 tc->get_version = tpm_tis_isa_get_tpm_version;
+tc->get_irqnum = tpm_tis_isa_get_irqnum;
 }
 
 static const TypeInfo tpm_tis_isa_info = {
diff --git a/hw/tpm/tpm_tis_sysbus.c b/hw/tpm/tpm_tis_sysbus.c
index 18c02aed67..980c07fd82 100644
--- a/hw/tpm/tpm_tis_sysbus.c
+++ b/hw/tpm/tpm_tis_sysbus.c
@@ -80,6 +80,14 @@ static enum TPMVersion tpm_tis_sysbus_get_tpm_version(TPMIf 
*ti)
 return tpm_tis_get_tpm_version(s);
 }
 
+static uint8_t tpm_tis_sysbus_get_irqnum(TPMIf *ti)
+{
+TPMStateSysBus *sbdev = TPM_TIS_SYSBUS(ti);
+TPMState *s = &sbdev->state;
+
+return s->irq_num;
+}
+
 static void tpm_tis_sysbus_reset(DeviceState *dev)
 {
 TPMStateSysBus *sbdev = TPM_TIS_SYSBUS(dev);
@@ -137,6 +145,7 @@ static void tpm_tis_sysbus_class_init(ObjectClass *klass, 
void *data)
 dc->reset = tpm_tis_sysbus_reset;
 tc->request_completed = tpm_tis_sysbus_request_completed;
 tc->get_version = tpm_tis_sysbus_get_tpm_version;
+tc->get_irqnum = tpm_tis_sysbus_get_irqnum;
 }
 
 static const TypeInfo tpm_tis_sysbus_info = {
diff --git a/include/sysemu/tpm.h b/include/sysemu/tpm.h
index f37851b1aa..1213cc95e6 100644
--- a/include/sysemu/tpm.h
+++ b/include/sysemu/tpm.h
@@ -41,6 +41,7 @@ typedef struct TPMIfClass {
 enum TpmModel model;
 void (*request_completed)(TPMIf *obj, int ret);
 enum TPMVersion (*get_version)(TPMIf *obj);
+uint8_t (*get_irqnum)(TPMIf *obj);
 } TPMIfClass;
 
 #define TYPE_TPM_TIS_ISA"tpm-tis"
@@ -72,4 +73,13 @@ static inline TPMVersion tpm_get_version(TPMIf *ti)
 return TPM_IF_GET_CLASS(ti)->get_version(ti);
 }
 
+static inline uint8_t tpm_get_irqnum(TPMIf *ti)
+{
+if (!ti || !TPM_IF_GET_CLASS(ti)->get_irqnum) {
+return 0;
+}
+
+return TPM_IF_GET_CLASS(ti)->get_irqnum(ti);
+}
+
 #endif /* QEMU_TPM_H */
-- 
2.24.1

Re: [PATCH v3] target/arm/cpu: adjust virtual time for arm cpu

[Ying Fang]

On 6/10/2020 3:40 PM, Andrew Jones wrote:

On Wed, Jun 10, 2020 at 09:32:06AM +0800, Ying Fang wrote:



On 6/8/2020 8:49 PM, Andrew Jones wrote:

On Mon, Jun 08, 2020 at 08:12:43PM +0800, Ying Fang wrote:

From: fangying 

Virtual time adjustment was implemented for virt-5.0 machine type,
but the cpu property was enabled only for host-passthrough and
max cpu model. Let's add it for arm cpu which has the generic timer
feature enabled.

Suggested-by: Andrew Jones 


This isn't true. I did suggest the way to arrange the code, after
Peter suggested to move the kvm_arm_add_vcpu_properties() call to
arm_cpu_post_init(), but I didn't suggest making this change in general,
which is what this tag means. In fact, I've argued that it's pretty

I'm quite sorry for adding it here.


No problem.


pointless to do this, since KVM users should be using '-cpu host' or
'-cpu max' anyway. Since I don't need credit for the code arranging,

As discussed in thread [1], there is a situation where a 'custom' cpu mode
is needed for us to keep instruction set compatibility so that migration can
be done, just like x86 does.


I understand the motivation. But, as I've said, KVM doesn't work that way.


And we are planning to add support for it if
nobody is currently doing that.


Great! I'm looking forward to seeing the KVM patches. Especially since,
without the KVM patches, the 'custom' CPU model isn't a custom CPU model,
it's just a misleading way to use host passthrough. Indeed, I'm a bit
opposed to allowing anything other than '-cpu host' and '-cpu max' (with
features explicitly enabled/disabled, e.g. -cpu host,pmu=off) to work
until KVM actually works with CPU models. Otherwise, how do we know the
difference between a model that actually works and one that is just
misleadingly named?

Yes you are right here.
My colleague zhanghailiang and me are now working on it. We will post 
the patch set soon.


Thanks,
drew



Thanks.
Ying

[1]: https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00022.html

please just drop the tag. Peter can maybe do that on merge though. Also,
despite not agreeing that we need this change today, as there's nothing
wrong with it and it looks good to me

Reviewed-by: Andrew Jones 

Thanks,
drew


Signed-off-by: Ying Fang 

---
v3:
- set kvm-no-adjvtime property in kvm_arm_add_vcpu_properties

v2:
- move kvm_arm_add_vcpu_properties into arm_cpu_post_init

v1:
- initial commit
- https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08518.html

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 32bec156f2..5b7a36b5d7 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1245,6 +1245,10 @@ void arm_cpu_post_init(Object *obj)
   if (arm_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER)) {
   qdev_property_add_static(DEVICE(cpu), &arm_cpu_gt_cntfrq_property);
   }
+
+if (kvm_enabled()) {
+kvm_arm_add_vcpu_properties(obj);
+}
   }
   static void arm_cpu_finalizefn(Object *obj)
@@ -2029,7 +2033,6 @@ static void arm_max_initfn(Object *obj)
   if (kvm_enabled()) {
   kvm_arm_set_cpu_features_from_host(cpu);
-kvm_arm_add_vcpu_properties(obj);
   } else {
   cortex_a15_initfn(obj);
@@ -2183,7 +2186,6 @@ static void arm_host_initfn(Object *obj)
   if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
   aarch64_add_sve_properties(obj);
   }
-kvm_arm_add_vcpu_properties(obj);
   arm_cpu_post_init(obj);
   }
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index cbc5c3868f..778cecc2e6 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -592,7 +592,6 @@ static void aarch64_max_initfn(Object *obj)
   if (kvm_enabled()) {
   kvm_arm_set_cpu_features_from_host(cpu);
-kvm_arm_add_vcpu_properties(obj);
   } else {
   uint64_t t;
   uint32_t u;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 4bdbe6dcac..eef3bbd1cc 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -194,17 +194,18 @@ static void kvm_no_adjvtime_set(Object *obj, bool value, 
Error **errp)
   /* KVM VCPU properties should be prefixed with "kvm-". */
   void kvm_arm_add_vcpu_properties(Object *obj)
   {
-if (!kvm_enabled()) {
-return;
-}
+ARMCPU *cpu = ARM_CPU(obj);
+CPUARMState *env = &cpu->env;
-ARM_CPU(obj)->kvm_adjvtime = true;
-object_property_add_bool(obj, "kvm-no-adjvtime", kvm_no_adjvtime_get,
- kvm_no_adjvtime_set);
-object_property_set_description(obj, "kvm-no-adjvtime",
-"Set on to disable the adjustment of "
-"the virtual counter. VM stopped time "
-"will be counted.");
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+cpu->kvm_adjvtime = true;
+object_property_add_bool(obj, "kvm-no-adjvtime", kvm_no_adjvtime_get,
+ kvm_no_adjvtime_set);
+object_property_set_de

Re: [PATCH] hw/xen_pt: Don't grant opregion permissions

[Roger Pau Monné]

On Sun, Jun 14, 2020 at 11:21:09PM +, Grzegorz Uriasz wrote:
> With the upstreaming of linux based stubdomains to xen, qemu can't
> assume it runs inside dom0 - permission assignment must be moved to
> libxl running in dom0. This xen patch:
> https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html
> implements granting the required permissions to the stubdomain running
> qemu. This patch removes granting opregion permissions in qemu - this
> should be fine as when qemu is running inside dom0 the memory mapping will
> be successfully created without first explicitly granting the permission.

In order to avoid breaking certain libxl - QEMU combinations, could
you make the check below non-fatal?

So that the current code can be kept for dom0 while not throwing an
error when used inside of a stub domain?

Thanks, Roger.

Re: [PATCH v3 0/4] block: seriously improve savevm performance

[Dr. David Alan Gilbert]

* Denis V. Lunev (d...@openvz.org) wrote:
> On 6/15/20 3:17 PM, Dr. David Alan Gilbert wrote:
> > * Denis V. Lunev (d...@openvz.org) wrote:
> >> This series do standard basic things:
> >> - it creates intermediate buffer for all writes from QEMU migration code
> >>   to QCOW2 image,
> >> - this buffer is sent to disk asynchronously, allowing several writes to
> >>   run in parallel.
> >>
> >> In general, migration code is fantastically inefficent (by observation),
> >> buffers are not aligned and sent with arbitrary pieces, a lot of time
> >> less than 100 bytes at a chunk, which results in read-modify-write
> >> operations with non-cached operations. It should also be noted that all
> >> operations are performed into unallocated image blocks, which also suffer
> >> due to partial writes to such new clusters.
> > It surprises me a little that you're not benefiting from the buffer
> > internal to qemu-file.c
> >
> > Dave
> There are a lot of problems with this buffer:
> 
> Flushes to block driver state are performed in the abstract places,
> pushing
>   a) small IO
>   b) non-aligned IO both to
>        1) page size
>        2) cluster size
> It should also be noted that buffer in QEMU file is quite small and
> all IO operations with it are synchronous. IO, like ethernet, wants
> good queues.

Yeh, for ethernet we immediately get the kernels buffer so it's not too
bad; and I guess the async page writes are easier as well.

Dave

> The difference is on the table.
> 
> Den
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[PATCH] tests/qtest/bios-tables: Only run the TPM test with CONFIG_TPM enabled

[Thomas Huth]

"make check-qtest" currently fails if configure has been run with
"--disable-tpm" - the TPM-related tests can only work if the TPM is
enabled in the build. So let's use the CONFIG_TPM switch to disable
the test if TPM is not available.

Signed-off-by: Thomas Huth 
---
 tests/qtest/bios-tables-test.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 53f104a9c5..d170a617d8 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -877,6 +877,8 @@ static void test_acpi_piix4_tcg_numamem(void)
 free_test_data(&data);
 }
 
+#ifdef CONFIG_TPM
+
 uint64_t tpm_tis_base_addr;
 
 static void test_acpi_tcg_tpm(const char *machine, const char *tpm_if,
@@ -931,6 +933,8 @@ static void test_acpi_q35_tcg_tpm_tis(void)
 test_acpi_tcg_tpm("q35", "tis", 0xFED4);
 }
 
+#endif /* CONFIG_TPM */
+
 static void test_acpi_tcg_dimm_pxm(const char *machine)
 {
 test_data data;
@@ -1094,7 +1098,9 @@ int main(int argc, char *argv[])
 return ret;
 }
 
+#ifdef CONFIG_TPM
 qtest_add_func("acpi/q35/tpm-tis", test_acpi_q35_tcg_tpm_tis);
+#endif
 qtest_add_func("acpi/piix4", test_acpi_piix4_tcg);
 qtest_add_func("acpi/piix4/bridge", test_acpi_piix4_tcg_bridge);
 qtest_add_func("acpi/q35", test_acpi_q35_tcg);
-- 
2.18.1

Re: [PATCH v3 6/6] linux-user: Add strace support for printing arguments of fallocate()

[Filip Bozuta]

On 15.6.20. 13:58, Laurent Vivier wrote:
> Le 11/06/2020 à 17:51, Filip Bozuta a écrit :
>> From: Filip Bozuta 
>>
>> This patch implements strace argument printing functionality for following 
>> syscall:
>>
>>  *fallocate - manipulate file space
>>
>>  int fallocate(int fd, int mode, off_t offset, off_t len)
>>  man page: https://www.man7.org/linux/man-pages/man2/fallocate.2.html
>>
>> Implementation notes:
>>
>>  This syscall's second argument "mode" is composed of predefined values
>>  which represent flags that determine the type of operation that is
>>  to be performed on the file space. For that reason, a printing
>>  function "print_fallocate" was stated in file "strace.list". This 
>> printing
>>  function uses an already existing function "print_flags()" to print 
>> flags of
>>  the "mode" argument. These flags are stated inside an array 
>> "falloc_flags"
>>  that contains values of type "struct flags". These values are 
>> instantiated
>>  using an existing macro "FLAG_GENERIC()". Most of these flags are 
>> defined
>>  after kernel version 3.0 which is why they are enwrapped in an #ifdef
>>  directive.
>>  The syscall's third ant fourth argument are of type "off_t" which can
>>  cause variations between 32/64-bit architectures. To handle this 
>> variation,
>>  function "target_offset64()" was copied from file "strace.c" and used in
>>  "print_fallocate" to print "off_t" arguments for 32-bit architectures.
>>
>> Signed-off-by: Filip Bozuta 
>> Reviewed-by: Laurent Vivier 
>> ---
>>   linux-user/qemu.h  | 16 
>>   linux-user/strace.c| 40 
>>   linux-user/strace.list |  2 +-
>>   linux-user/syscall.c   | 16 
>>   4 files changed, 57 insertions(+), 17 deletions(-)
>>
>> diff --git a/linux-user/qemu.h b/linux-user/qemu.h
>> index 8f938b8105..be67391ba4 100644
>> --- a/linux-user/qemu.h
>> +++ b/linux-user/qemu.h
>> @@ -670,6 +670,22 @@ static inline int is_error(abi_long ret)
>>   return (abi_ulong)ret >= (abi_ulong)(-4096);
>>   }
>>   
>> +#if TARGET_ABI_BITS == 32
>> +static inline uint64_t target_offset64(uint32_t word0, uint32_t word1)
>> +{
>> +#ifdef TARGET_WORDS_BIGENDIAN
>> +return ((uint64_t)word0 << 32) | word1;
>> +#else
>> +return ((uint64_t)word1 << 32) | word0;
>> +#endif
>> +}
>> +#else /* TARGET_ABI_BITS == 32 */
>> +static inline uint64_t target_offset64(uint64_t word0, uint64_t word1)
>> +{
>> +return word0;
>> +}
>> +#endif /* TARGET_ABI_BITS != 32 */
>> +
>>   /**
>>* preexit_cleanup: housekeeping before the guest exits
>>*
>> diff --git a/linux-user/strace.c b/linux-user/strace.c
>> index 40c17f7abe..5f370256e3 100644
>> --- a/linux-user/strace.c
>> +++ b/linux-user/strace.c
>> @@ -1144,6 +1144,26 @@ UNUSED static struct flags statx_mask[] = {
>>   FLAG_END,
>>   };
>>   
>> +UNUSED static struct flags falloc_flags[] = {
>> +FLAG_GENERIC(FALLOC_FL_KEEP_SIZE),
>> +FLAG_GENERIC(FALLOC_FL_PUNCH_HOLE),
>> +#ifdef FALLOC_FL_NO_HIDE_STALE
>> +FLAG_GENERIC(FALLOC_FL_NO_HIDE_STALE),
>> +#endif
>> +#ifdef FALLOC_FL_COLLAPSE_RANGE
>> +FLAG_GENERIC(FALLOC_FL_COLLAPSE_RANGE),
>> +#endif
>> +#ifdef FALLOC_FL_ZERO_RANGE
>> +FLAG_GENERIC(FALLOC_FL_ZERO_RANGE),
>> +#endif
>> +#ifdef FALLOC_FL_INSERT_RANGE
>> +FLAG_GENERIC(FALLOC_FL_INSERT_RANGE),
>> +#endif
>> +#ifdef FALLOC_FL_UNSHARE_RANGE
>> +FLAG_GENERIC(FALLOC_FL_UNSHARE_RANGE),
>> +#endif
>> +};
>> +
>>   /*
>>* print_xxx utility functions.  These are used to print syscall
>>* parameters in certain format.  All of these have parameter
>> @@ -1561,6 +1581,26 @@ print_faccessat(const struct syscallname *name,
>>   }
>>   #endif
>>   
>> +#ifdef TARGET_NR_fallocate
>> +static void
>> +print_fallocate(const struct syscallname *name,
>> +abi_long arg0, abi_long arg1, abi_long arg2,
>> +abi_long arg3, abi_long arg4, abi_long arg5)
>> +{
>> +print_syscall_prologue(name);
>> +print_raw_param("%d", arg0, 0);
>> +print_flags(falloc_flags, arg1, 0);
>> +#if TARGET_ABI_BITS == 32
>> +print_raw_param("%ld", target_offset64(arg2, arg3), 0);
>> +print_raw_param("%ld", target_offset64(arg4, arg5), 1);
>> +#else
>> +print_raw_param("%ld", arg2, 0);
>> +print_raw_param("%ld", arg3, 1);
>> +#endif
>>
> You have removed the PRIu64 and TARGET_ABI_FMT_ld from the v2. So my
> Reviewed-by is not relevant for the v3.

I am sorry. Something wen't wrong (not sure what...) when I used git 
rebase and it removed some changes from v2

(including the ones with removexattr, lremovexattr, fremovexattr)

This was an irresponsible mistake by my part and I will of course 
correct this in v4 and make sure to thoroughly check my

patches before sending them so that this doesn't happen again.

Just wanted to let you know that I didn't do this on purpose.

>
> Thanks,
> Laurent

Re: [PULL v2 20/58] bios-tables-test: Add Q35/TPM-TIS test

[Thomas Huth]

On 15/06/2020 14.35, Auger Eric wrote:
> Hi Philippe, Thomas,
> 
> On 6/15/20 12:22 PM, Thomas Huth wrote:
>> On 15/06/2020 12.02, Philippe Mathieu-Daudé wrote:
>>> On Fri, Jun 12, 2020 at 5:00 PM Michael S. Tsirkin  wrote:

 From: Eric Auger 

 Test tables specific to the TPM-TIS instantiation.
 The TPM2 is added in the framework. Also the DSDT
 is updated with the TPM. The new function should be
 be usable for CRB as well, later one.

 Signed-off-by: Eric Auger 

 Message-Id: <20200609125409.24179-5-eric.au...@redhat.com>
 Reviewed-by: Michael S. Tsirkin 
 Signed-off-by: Michael S. Tsirkin 
 ---
  tests/qtest/bios-tables-test.c | 58 ++
  tests/qtest/Makefile.include   |  1 +
  2 files changed, 59 insertions(+)

 diff --git a/tests/qtest/bios-tables-test.c 
 b/tests/qtest/bios-tables-test.c
 index c9843829b3..53f104a9c5 100644
 --- a/tests/qtest/bios-tables-test.c
 +++ b/tests/qtest/bios-tables-test.c
 @@ -57,6 +57,9 @@
  #include "qemu/bitmap.h"
  #include "acpi-utils.h"
  #include "boot-sector.h"
 +#include "tpm-emu.h"
 +#include "hw/acpi/tpm.h"
 +

  #define MACHINE_PC "pc"
  #define MACHINE_Q35 "q35"
 @@ -874,6 +877,60 @@ static void test_acpi_piix4_tcg_numamem(void)
  free_test_data(&data);
  }

 +uint64_t tpm_tis_base_addr;
 +
 +static void test_acpi_tcg_tpm(const char *machine, const char *tpm_if,
 +  uint64_t base)
 +{
 +gchar *tmp_dir_name = 
 g_strdup_printf("qemu-test_acpi_%s_tcg_%s.XX",
 +  machine, tpm_if);
 +char *tmp_path = g_dir_make_tmp(tmp_dir_name, NULL);
 +TestState test;
 +test_data data;
 +GThread *thread;
 +char *args, *variant = g_strdup_printf(".%s", tpm_if);
 +
 +tpm_tis_base_addr = base;
 +
 +module_call_init(MODULE_INIT_QOM);
 +
 +test.addr = g_new0(SocketAddress, 1);
 +test.addr->type = SOCKET_ADDRESS_TYPE_UNIX;
 +test.addr->u.q_unix.path = g_build_filename(tmp_path, "sock", NULL);
 +g_mutex_init(&test.data_mutex);
 +g_cond_init(&test.data_cond);
 +test.data_cond_signal = false;
 +
 +thread = g_thread_new(NULL, tpm_emu_ctrl_thread, &test);
 +tpm_emu_test_wait_cond(&test);
 +
 +memset(&data, 0, sizeof(data));
 +data.machine = machine;
 +data.variant = variant;
 +
 +args = g_strdup_printf(
 +" -chardev socket,id=chr,path=%s"
 +" -tpmdev emulator,id=dev,chardev=chr"
>>>
>>> This test makes our CI fail:
>>> https://gitlab.com/qemu-project/qemu/-/jobs/593586369#L3466
>>
>> Right. The problem seems to occur as soon as you run "configure" with
>> "--disable-tpm" ... I think you need some "#ifdef CONFIG_TPM" here?
> Thank you. I will respin asap.

I just sent a fix ("Only run the TPM test with CONFIG_TPM enabled") ...
please have a look at that mail whether it looks fine to you.

 Thanks,
 Thomas

Re: [PATCH v2 0/4] Add support for SafeStack

[Daniele Buono]

Ping?

On 5/29/2020 4:51 PM, Daniele Buono wrote:

LLVM supports SafeStack instrumentation to protect against stack buffer
overflows, since version 3.7


From https://clang.llvm.org/docs/SafeStack.html:

"It works by separating the program stack into two distinct regions: the
safe stack and the unsafe stack. The safe stack stores return addresses,
register spills, and local variables that are always accessed in a safe
way, while the unsafe stack stores everything else. This separation
ensures that buffer overflows on the unsafe stack cannot be used to
overwrite anything on the safe stack."

Unfortunately, the use of two stack regions does not cope well with
QEMU's coroutines. The second stack region is not properly set up with
both ucontext and sigaltstack, so multiple coroutines end up sharing the
same memory area for the unsafe stack, causing undefined behaviors at
runtime (and most iochecks to fail).

This patch series fixes the implementation of the ucontext backend and
make sure that sigaltstack is never used if the compiler is applying
the SafeStack instrumentation. It also adds a configure flag to enable
SafeStack, and enables iotests when SafeStack is used.

Changes since v1:
  - CONFIG_SAFESTACK is now set up in configure, and not in the code
  - Added option for a --disable-safe-stack in configure
  - Configure checks if SafeStack is enabled by default in the compiler,
and set the CONFIG_SAFESTACK accordingly
  - Updated some comments in the code and the commit log

NOTE: I kept configure as Patch #3.
The reason is that the code changes will not be enabled without the
configure, making the code fully functional if only Patches #1 or #2 are
applied.
On the other hand, the configure patch will produce incorrect code if we
request SafeStack and the other patches are not applied.

Daniele Buono (4):
   coroutine: support SafeStack in ucontext backend
   coroutine: add check for SafeStack in sigaltstack
   configure: add flags to support SafeStack
   check-block: enable iotests with SafeStack

  configure| 73 
  include/qemu/coroutine_int.h |  5 +++
  tests/check-block.sh | 12 +-
  util/coroutine-sigaltstack.c |  4 ++
  util/coroutine-ucontext.c| 26 +
  5 files changed, 119 insertions(+), 1 deletion(-)

Re: [PATCH 3/3] acpi: Enable TPM IRQ

[Stefan Berger]

On 6/15/20 8:37 AM, Stefan Berger wrote:

From: Stefan Berger 

Move the TPM TIS IRQ to unused IRQ 13, which is also accepted by Windows.
Query for the TPM's irq number and enable the TPM IRQ if not zero.

Signed-off-by: Stefan Berger 
CC: Michael S. Tsirkin 


This patch is missing the reference ACPI tables for the tests. Will add 
in v2.




---
  hw/i386/acpi-build.c  | 11 +--
  include/hw/acpi/tpm.h |  2 +-
  2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 23c77eeb95..919cab1702 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2199,6 +2199,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
  build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);
  
  if (TPM_IS_TIS_ISA(tpm)) {

+uint8_t irq = tpm_get_irqnum(tpm);
  if (misc->tpm_version == TPM_VERSION_2_0) {
  dev = aml_device("TPM");
  aml_append(dev, aml_name_decl("_HID",
@@ -2213,12 +2214,10 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
  crs = aml_resource_template();
  aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
 TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
-/*
-FIXME: TPM_TIS_IRQ=5 conflicts with PNP0C0F irqs,
-Rewrite to take IRQ from TPM device model and
-fix default IRQ value there to use some unused IRQ
- */
-/* aml_append(crs, aml_irq_no_flags(TPM_TIS_IRQ)); */
+
+if (irq) {
+aml_append(crs, aml_irq_no_flags(irq));
+}
  aml_append(dev, aml_name_decl("_CRS", crs));
  
  tpm_build_ppi_acpi(tpm, dev);

diff --git a/include/hw/acpi/tpm.h b/include/hw/acpi/tpm.h
index 1a2a57a21f..063a9eb42a 100644
--- a/include/hw/acpi/tpm.h
+++ b/include/hw/acpi/tpm.h
@@ -24,7 +24,7 @@
  #define TPM_TIS_ADDR_BASE   0xFED4
  #define TPM_TIS_ADDR_SIZE   0x5000
  
-#define TPM_TIS_IRQ 5

+#define TPM_TIS_IRQ 13
  
  #define TPM_TIS_NUM_LOCALITIES  5 /* per spec */

  #define TPM_TIS_LOCALITY_SHIFT  12