Re: [Qemu-devel] [PATCH v3 3/7] hw/mips: Express dependencies of the r4k platform with Kconfig

[Thomas Huth]

On 11/03/2019 01.56, Philippe Mathieu-Daudé wrote:
> This platform use standard PC devices connected to an ISA bus.
> Networking is provided by a ne2000 chipset.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v3: remove CONFIG_NE2000_ISA (Thomas)
> add PFLASH_CFI01
> ---
>  default-configs/mips-softmmu-common.mak |  1 -
>  hw/mips/Kconfig | 11 +++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/default-configs/mips-softmmu-common.mak 
> b/default-configs/mips-softmmu-common.mak
> index caebafd416..2ca57bfee1 100644
> --- a/default-configs/mips-softmmu-common.mak
> +++ b/default-configs/mips-softmmu-common.mak
> @@ -24,7 +24,6 @@ CONFIG_I8257=y
>  CONFIG_PIIX4=y
>  CONFIG_IDE_ISA=y
>  CONFIG_IDE_PIIX=y
> -CONFIG_NE2000_ISA=y
>  CONFIG_PFLASH_CFI01=y
>  CONFIG_I8259=y
>  CONFIG_MC146818RTC=y
> diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> index ab006477c7..5678c9cf15 100644
> --- a/hw/mips/Kconfig
> +++ b/hw/mips/Kconfig
> @@ -1,5 +1,16 @@
>  config R4K
>  bool
> +select ISA_BUS
> +select SERIAL_ISA
> +select I8259
> +select I8254
> +select MC146818RTC
> +select VGA_ISA
> +select NE2000_ISA

Since Paolo now also introduced the "imply" keyword, I think you should
use "imply" instead of "select" for both, VGA_ISA and NE2000_ISA, since
the r4k machine can work without both when you specify -vga none and
-net none.

 Thomas

Re: [Qemu-devel] converting build system to Meson?

[Thomas Huth]

On 10/03/2019 17.28, Markus Armbruster wrote:
> Paolo Bonzini  writes:
> 
>> Hi all,
>>
>> lately I have been thinking of converting the QEMU build system to
>> Meson.  Meson is a relatively new build system that can replace
>> Autotools or hand-written Makefiles such as QEMU; as a die-hard
>> Autotools fan, I must say that Meson is by far better than anything else
>> that has ever tried to replace Autotools, and actually has the potential
>> to do so.
>>
>> Advantages of Meson that directly matter for QEMU include:
> [...]
>> - ease of distributing a full copy of Meson to support distros that ship
>> an older version (no dependencies apart from Python 3.5).  At 4
>> lines of Python, Meson is relatively small.
> 
> Meson is licensed under the Apache 2 license.  QEMU as a whole is
> licensed under GPLv2 (and no later versions).  From
> :
> 
> This is a free software license, compatible with version 3 of the
> GNU GPL.
> 
> Please note that this license is not compatible with GPL version 2,
> because it has some requirements that are not in that GPL version.
> These include certain patent termination and indemnification
> provisions.  The patent termination provision is a good thing, which
> is why we recommend the Apache 2.0 license for substantial programs
> over other lax permissive licenses.
> 
> Can we distribute Meson along with QEMU anyway?

Sure, as long as we make it clear that it is a separate executable (with
its own license), and do not link the meson code into the QEMU binary.

 Thomas

Re: [Qemu-devel] [PATCH v4 19/29] hw/arm: Express dependencies of the MPS2 boards with Kconfig

[Thomas Huth]

On 10/03/2019 22.33, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
> 
> On 3/7/19 3:18 PM, Thomas Huth wrote:
>> Add Kconfig dependencies for the mps2-an* machines.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  default-configs/arm-softmmu.mak | 20 +---
>>  hw/arm/Kconfig  | 18 ++
>>  2 files changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/default-configs/arm-softmmu.mak 
>> b/default-configs/arm-softmmu.mak
>> index b6f3d60..b8509fd 100644
>> --- a/default-configs/arm-softmmu.mak
>> +++ b/default-configs/arm-softmmu.mak
>> @@ -27,6 +27,7 @@ CONFIG_Z2=y
>>  CONFIG_COLLIE=y
>>  CONFIG_ASPEED_SOC=y
>>  CONFIG_NETDUINO2=y
>> +CONFIG_MPS2=y
>>  
>>  CONFIG_VGA=y
>>  CONFIG_SSI_M25P80=y
>> @@ -35,28 +36,9 @@ CONFIG_IMX_FEC=y
>>  CONFIG_FRAMEBUFFER=y
>>  
>>  CONFIG_DIGIC=y
>> -CONFIG_MPS2=y
>>  CONFIG_RASPI=y
>>  CONFIG_NRF51_SOC=y
>>  
>> -CONFIG_CMSDK_APB_TIMER=y
>> -CONFIG_CMSDK_APB_DUALTIMER=y
>> -CONFIG_CMSDK_APB_UART=y
>> -CONFIG_CMSDK_APB_WATCHDOG=y
>> -
>> -CONFIG_MPS2_FPGAIO=y
>> -CONFIG_MPS2_SCC=y
>> -
>> -CONFIG_TZ_MPC=y
>> -CONFIG_TZ_MSC=y
>> -CONFIG_TZ_PPC=y
>> -CONFIG_ARMSSE=y
>> -CONFIG_IOTKIT_SECCTL=y
>> -CONFIG_IOTKIT_SYSCTL=y
>> -CONFIG_IOTKIT_SYSINFO=y
>> -CONFIG_ARMSSE_CPUID=y
>> -CONFIG_ARMSSE_MHU=y
>> -
>>  CONFIG_FSL_IMX6=y
>>  CONFIG_FSL_IMX25=y
>>  CONFIG_FSL_IMX7=y
>> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
>> index 743c78b..32c8663 100644
>> --- a/hw/arm/Kconfig
>> +++ b/hw/arm/Kconfig
>> @@ -308,6 +308,13 @@ config ASPEED_SOC
>>  
>>  config MPS2
>>  bool
>> +select ARMSSE
>> +select LAN9118
>> +select MPS2_FPGAIO
>> +select MPS2_SCC
>> +select PL022# Serial port
>> +select PL080# DMA controller
>> +select TZ_MPC
> 
> Can we move TZ_MPC to ARMSSE?

Oh, right, armsse_init() uses TYPE_TZ_MPC, too, so it should be moved.

 Thomas

Re: [Qemu-devel] [PATCH v5-resend 2/2] mips_fulong2e: Add on-board graphics chip

[Gerd Hoffmann]

  Hi,

> > "git send-email" should send the patches with correct headers, it even
> > asks for the charset it should use in case it finds non-ascii
> > characters.  So BALATON, could you check your mail client config, or
> > switch over to "git send-email" for submitting patches?
> 
> I'm sending what git format-patch is generating and that does not add
> content type header by default. Is there a config option to enable that? I
> can't use git send-email because I'm sending from different machine than I
> use git on.

git send-email also accepts files generated by git format-patch,
so you can:

  (1) "git format-patch master..$branch", on machine A
  (2) copy over 000*.patch from machine A to machine B
  (3) "git send-email 000*.patch", on machine B

But take care that you don't have old 000*.patch files lying around on
machine B ...

HTH,
  Gerd

Re: [Qemu-devel] [PATCH v5 04/14] audio: -audiodev command line option basic implementation

[Gerd Hoffmann]

  Hi,

> And magic errors like "'vfio-pci' is not a valid device model name"
> after update.

Try a full rebuild then.  I see strange errors now and then too, that
fixed it.  Seems the qemu build fails now and then that an object file
needs a rebuild.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 2/8] hw/input: Add 8042 PS/2 Keyboard Controller to Kconfig

[Thomas Huth]

On 11/03/2019 00.53, Philippe Mathieu-Daudé wrote:
> The Intel 8042 chipset also includes some functions unrelated to
> the keyboard, such the A20-Gate.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/input/Kconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/hw/input/Kconfig b/hw/input/Kconfig
> index e2e66f0858..83e4546a28 100644
> --- a/hw/input/Kconfig
> +++ b/hw/input/Kconfig
> @@ -10,6 +10,10 @@ config PCKBD
>  default y
>  depends on ISA_BUS
>  
> +config I8042
> +bool
> +select PCKBD

I fail to see why you need this config switch. There is a "select I8042"
in a later patch, but that's it - you never use this switch to decide
anything (like including a file in the Makefiles or toggle other
switches), so this seems to be just a defunc switch to me. Or do I miss
something?

 Thomas

Re: [Qemu-devel] [PATCH v3 1/3] vfio/display: add edid support.

[Gerd Hoffmann]

  Hi,

> Liam and I both found some difficulty with the cleverness of the
> macros, so for the sake of better maintainability, I'd like to propose
> rolling in the following patch, including Liam's trace format fix.  It's
> not as compact as your version, but I think it's equivalent, it's easier
> to follow, and doesn't covertly introduce a non-curly braced block ;)
> If you agree, I'll roll this into your v3. Thanks,

>  #define pwrite_field(_fd, _reg, _ptr, _fld) \
> -if (sizeof(_ptr->_fld) !=   \
> -pwrite(_fd, &(_ptr->_fld), sizeof(_ptr->_fld),  \
> -   _reg->offset + offsetof(typeof(*_ptr), _fld)))   \
> -goto err;
> +(sizeof(_ptr->_fld) !=  \
> + pwrite(_fd, &(_ptr->_fld), sizeof(_ptr->_fld), \
> +_reg->offset + offsetof(typeof(*_ptr), _fld)))

>  dpy->edid_regs->link_state = VFIO_DEVICE_GFX_LINK_STATE_DOWN;
> -pwrite_field(fd, dpy->edid_info, dpy->edid_regs, link_state);
> +if (pwrite_field(fd, dpy->edid_info, dpy->edid_regs, link_state)) {
> +goto err;
> +}

Fine with me.

thanks,
  Gerd

[Qemu-devel] [PATCH 0/2] cleanup select_machine

[Wei Yang]

Here is two simple change related to select_machine()

[1]: make find_default_machine() local since no one outside file use it
[2]: allocate TYPE_MACHINE list only once to select machine type

Wei Yang (2):
  vl.c: make find_default_machine() local
  vl.c: allocate TYPE_MACHINE list once during bootup

 include/hw/boards.h |  1 -
 vl.c| 24 +++-
 2 files changed, 11 insertions(+), 14 deletions(-)

-- 
2.19.1

[Qemu-devel] [PATCH 1/2] vl.c: make find_default_machine() local

[Wei Yang]

Function find_default_machine() is introduced by commit 2c8cffa599b7
"vl: make find_default_machine externally visible", while it seems no
one outside use it.

This patch make it local again.

Signed-off-by: Wei Yang 
---
 include/hw/boards.h | 1 -
 vl.c| 4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 21212f0859..e911d56c28 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -57,7 +57,6 @@ void memory_region_allocate_system_memory(MemoryRegion *mr, 
Object *owner,
 #define MACHINE_CLASS(klass) \
 OBJECT_CLASS_CHECK(MachineClass, (klass), TYPE_MACHINE)
 
-MachineClass *find_default_machine(void);
 extern MachineState *current_machine;
 
 void machine_run_board_init(MachineState *machine);
diff --git a/vl.c b/vl.c
index 502857a176..3688e2bc98 100644
--- a/vl.c
+++ b/vl.c
@@ -1441,7 +1441,7 @@ static MachineClass *find_machine(const char *name)
 return mc;
 }
 
-MachineClass *find_default_machine(void)
+static MachineClass *find_default_machine(void)
 {
 GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
 MachineClass *mc = NULL;
@@ -2538,7 +2538,7 @@ static gint machine_class_cmp(gconstpointer a, 
gconstpointer b)
   object_class_get_name(OBJECT_CLASS(mc1)));
 }
 
- static MachineClass *machine_parse(const char *name)
+static MachineClass *machine_parse(const char *name)
 {
 MachineClass *mc = NULL;
 GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
-- 
2.19.1

[Qemu-devel] [PATCH 2/2] vl.c: allocate TYPE_MACHINE list once during bootup

[Wei Yang]

Now all the functions used to select machine is local and the call flow
looks like below:

select_machine()
find_default_machine()
machine_parse()
find_machine()

All these related function will need a GSList for TYPE_MACHINE.
Currently we allocate this list each time we use it, while this is not
necessary to do so because we don't need to modify this.

This patch make the TYPE_MACHINE list allocation in select_machine and
pass this to its child for use.

Signed-off-by: Wei Yang 
---
 vl.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/vl.c b/vl.c
index 3688e2bc98..cf08d96ce4 100644
--- a/vl.c
+++ b/vl.c
@@ -1418,9 +1418,9 @@ static int usb_parse(const char *cmdline)
 
 MachineState *current_machine;
 
-static MachineClass *find_machine(const char *name)
+static MachineClass *find_machine(const char *name, GSList *machines)
 {
-GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
+GSList *el;
 MachineClass *mc = NULL;
 
 for (el = machines; el; el = el->next) {
@@ -1437,13 +1437,12 @@ static MachineClass *find_machine(const char *name)
 }
 }
 
-g_slist_free(machines);
 return mc;
 }
 
-static MachineClass *find_default_machine(void)
+static MachineClass *find_default_machine(GSList *machines)
 {
-GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
+GSList *el;
 MachineClass *mc = NULL;
 
 for (el = machines; el; el = el->next) {
@@ -1455,7 +1454,6 @@ static MachineClass *find_default_machine(void)
 }
 }
 
-g_slist_free(machines);
 return mc;
 }
 
@@ -2538,16 +2536,15 @@ static gint machine_class_cmp(gconstpointer a, 
gconstpointer b)
   object_class_get_name(OBJECT_CLASS(mc1)));
 }
 
-static MachineClass *machine_parse(const char *name)
+static MachineClass *machine_parse(const char *name, GSList *machines)
 {
 MachineClass *mc = NULL;
-GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
+GSList *el;
 
 if (name) {
-mc = find_machine(name);
+mc = find_machine(name, machines);
 }
 if (mc) {
-g_slist_free(machines);
 return mc;
 }
 if (name && !is_help_option(name)) {
@@ -2567,7 +2564,6 @@ static MachineClass *machine_parse(const char *name)
 }
 }
 
-g_slist_free(machines);
 exit(!name || !is_help_option(name));
 }
 
@@ -2659,7 +2655,8 @@ static const QEMUOption *lookup_opt(int argc, char **argv,
 
 static MachineClass *select_machine(void)
 {
-MachineClass *machine_class = find_default_machine();
+GSList *machines = object_class_get_list(TYPE_MACHINE, false);
+MachineClass *machine_class = find_default_machine(machines);
 const char *optarg;
 QemuOpts *opts;
 Location loc;
@@ -2671,7 +2668,7 @@ static MachineClass *select_machine(void)
 
 optarg = qemu_opt_get(opts, "type");
 if (optarg) {
-machine_class = machine_parse(optarg);
+machine_class = machine_parse(optarg, machines);
 }
 
 if (!machine_class) {
@@ -2681,6 +2678,7 @@ static MachineClass *select_machine(void)
 }
 
 loc_pop(&loc);
+g_slist_free(machines);
 return machine_class;
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH v3] exec.c: refactor function flatview_add_to_dispatch()

[Wei Yang]

flatview_add_to_dispatch() registers page based on the condition of
*section*, which may looks like this:

|s|PPP|s|

where s stands for subpage and P for page.

The procedure of this function could be described as:

- register first subpage
- register page
- register last subpage

This means the procedure could be simplified into these three steps
instead of a loop iteration.

This patch refactors the function into three corresponding steps and
adds some comment to clarify it.

Signed-off-by: Wei Yang 

---
v3:
  * pass int128_make64() instead of 0 to int128_gt()
v2:
  * removes the loop iteration as suggested by Paolo
---
 exec.c | 50 +-
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/exec.c b/exec.c
index 0959b00c06..79cd561b3b 100644
--- a/exec.c
+++ b/exec.c
@@ -1598,34 +1598,50 @@ static void register_multipage(FlatView *fv,
 phys_page_set(d, start_addr >> TARGET_PAGE_BITS, num_pages, section_index);
 }
 
+/*
+ * The range in *section* may look like this:
+ *
+ *  |s|PPP|s|
+ *
+ * where s stands for subpage and P for page.
+ *
+ * The procedure in following function could be described as:
+ *
+ * - register first subpage
+ * - register page
+ * - register last subpage
+ */
 void flatview_add_to_dispatch(FlatView *fv, MemoryRegionSection *section)
 {
-MemoryRegionSection now = *section, remain = *section;
+MemoryRegionSection now, remain = *section;
 Int128 page_size = int128_make64(TARGET_PAGE_SIZE);
 
-if (now.offset_within_address_space & ~TARGET_PAGE_MASK) {
-uint64_t left = TARGET_PAGE_ALIGN(now.offset_within_address_space)
-   - now.offset_within_address_space;
+/* register first subpage */
+if (remain.offset_within_address_space & ~TARGET_PAGE_MASK) {
+uint64_t left = TARGET_PAGE_ALIGN(remain.offset_within_address_space)
+- remain.offset_within_address_space;
 
+now = remain;
 now.size = int128_min(int128_make64(left), now.size);
+remain.size = int128_sub(remain.size, now.size);
+remain.offset_within_address_space += int128_get64(now.size);
+remain.offset_within_region += int128_get64(now.size);
 register_subpage(fv, &now);
-} else {
-now.size = int128_zero();
 }
-while (int128_ne(remain.size, now.size)) {
+
+/* register page */
+if (int128_ge(remain.size, page_size)) {
+now = remain;
+now.size = int128_and(now.size, int128_neg(page_size));
 remain.size = int128_sub(remain.size, now.size);
 remain.offset_within_address_space += int128_get64(now.size);
 remain.offset_within_region += int128_get64(now.size);
-now = remain;
-if (int128_lt(remain.size, page_size)) {
-register_subpage(fv, &now);
-} else if (remain.offset_within_address_space & ~TARGET_PAGE_MASK) {
-now.size = page_size;
-register_subpage(fv, &now);
-} else {
-now.size = int128_and(now.size, int128_neg(page_size));
-register_multipage(fv, &now);
-}
+register_multipage(fv, &now);
+}
+
+/* register last subpage */
+if (int128_gt(remain.size, int128_make64(0))) {
+register_subpage(fv, &remain);
 }
 }
 
-- 
2.19.1

Re: [Qemu-devel] [PATCH v2] exec.c: refactor function flatview_add_to_dispatch()

[Wei Yang]

On Sun, Mar 10, 2019 at 09:54:54PM -0700, no-re...@patchew.org wrote:
>Patchew URL: 
>https://patchew.org/QEMU/20190311013016.14411-1-richardw.y...@linux.intel.com/
>
>
>
>Hi,
>
>This series failed the docker-mingw@fedora build test. Please find the testing 
>commands and
>their output below. If you have Docker installed, you can probably reproduce it
>locally.
>
>=== TEST SCRIPT BEGIN ===
>#!/bin/bash
>time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
>=== TEST SCRIPT END ===
>
>  CC  x86_64-softmmu/accel/tcg/tcg-runtime.o
>  CC  aarch64-softmmu/hw/cpu/realview_mpcore.o
>/tmp/qemu-test/src/exec.c: In function 'flatview_add_to_dispatch':
>/tmp/qemu-test/src/exec.c:1644:32: error: incompatible type for argument 2 of 
>'int128_gt'
> if (int128_gt(remain.size, 0)) {
>^
>In file included from /tmp/qemu-test/src/include/exec/memory.h:24,
>---
>  CC  aarch64-softmmu/hw/display/vga.o
>  CC  aarch64-softmmu/hw/display/bcm2835_fb.o
>/tmp/qemu-test/src/exec.c: In function 'flatview_add_to_dispatch':
>/tmp/qemu-test/src/exec.c:1644:32: error: incompatible type for argument 2 of 
>'int128_gt'
> if (int128_gt(remain.size, 0)) {
>^

Not sure why this works at my side.

Fixed this with 

  if (int128_gt(remain.size, int128_make64(0))) {

>In file included from /tmp/qemu-test/src/include/exec/memory.h:24,
>
>
>The full log is available at
>http://patchew.org/logs/20190311013016.14411-1-richardw.y...@linux.intel.com/testing.docker-mingw@fedora/?type=message.
>---
>Email generated automatically by Patchew [http://patchew.org/].
>Please send your feedback to patchew-de...@redhat.com

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] [PATCH v3 7/10] qemu-binfmt-conf.sh: add option --reset

[Unai Martinez Corral]

2019/3/10 18:15, Laurent Vivier:
> On 06/03/2019 05:52, Unai Martinez-Corral wrote:
> > Allows to remove a single or a list of already registered binfmt
> > interpreters. If  is a list, it must be comma-separated.
>
> I think ARCHS and CPUS are the same thing, so use the same word.

They are similar, but the syntax is not the same. ARCHS supports a
single word or a comma separated list. CPUS supports also using
spaces, tabs, etc. as separators.

> > -Usage: qemu-binfmt-conf.sh [--path PATH][--debian][--systemd]
> > -   [--help][--credential][--exportdir PATH]
> > +Usage: qemu-binfmt-conf.sh [--help][--path PATH][--debian][--systemd]
> > +   [--reset ARCHS][--credential][--exportdir PATH]
> > [--persistent][--suffix SUFFIX][CPUS]
>
> I don't like the idea of being able to set and reset different
> interpretes with same command line call.

> Make "--reset" exclusive without parameter to be able to use the common
> cpu list at the end of the command line

It is useful in order to replace a single interpreter or a few of them
in a single call to the script. Anyway, I think that your comment
makes sense. It is enough if we support to reset a subset. Any user
can then wrap two consecutive calls in a helper function.

So, in the next version '--reset' will be 'exclusive', i.e., it will
prevent registration.

> (this way, I think you would be
> able to share more common code between setting an resetting).

The shared code is the same, because 'qemu_check_target_list' was
already being used in both. The simplification comes from the fact
that we do not support commas anymore, since ARCHS and CPUS are now
only positional.

> You could have a look to Alex Bennée's patch:
>
>   https://patchwork.ozlabs.org/patch/938796/
>
> I think this is the good way to do this and it should merge easily with
> your series.

Thanks for the reference; I had skipped it. Upon further inspection, I
think that the features proposed by Alex are already implemented in
this patch, or they will be in the next version:

- I am already checking with '$CHECK', which will use the
corresponding procedure depending on 'systemd' or 'debian'.
- I am using printf instead of 'echo -1', as suggested by Eric Blake
in v1 of the patch.
- I will rename the option from '--reset' to '--clear', as I find it
to be more descriptive.
- None of us support neither '--debian' nor '--systemd'. See comments below.
- I support providing a subset of targets, while Alex' approach
targeted all of them.
- Overall, I think that 'BINFMT_SET=qemu_clear_interpreter' is ok for
a proof of concept, but it is not as clean as it could be. Precisely,
all the magic, mask, family values are computed in the loop inside
qemu_set_binfmts. That should be avoided if we only want to remove
them. Nonetheless, I will try to integrate both approaches.

Regarding this comment:

> I think it would be also useful to remove the files from $EXPORTDIR.
> So could you also manage something like "--debian --clear" and "--systemd CPU 
> --clear"?

ATM, this patchset supports '--reset --debian' or '--reset --systemd',
but it will proceed by updating /proc directly, which might not be
effective at all.
Furthermore, when '--debian --reset' or '--systemd --reset' are used,
a error message is shown: 'ERROR: option reset not implemented for
this mode yet'.

On the one hand, I can make '--reset --debian|systemd' and
'--debian|systemd --reset' consistent, by delaying the execution of
the reset/clear function after all the options are parsed.

On the other hand, I'd really like to have patches 6 and 7 available
in QEMU 4.0, if possible. So, I'd like to know if the partial
implementation of this feature is a stopper. If so, I'd be so glad to
have some help. These are the prototypes that I have not added to the
patchset because I am not sure about them:

For the debian case, after the comments in 'usage()', I think that the
procedure should be:

for t in $qemu_check_target_list ; do
  sudo update-binfmts --package "qemu-$t" --remove "qemu-$t" "$QEMU_PATH"
  rm "$EXPORTDIR/qemu-$t"
done

And for systemd:

sudo systemctl stop systemd-binfmt.service
for t in $qemu_check_target_list ; do
   rm -rf $EXPORTDIR/qemu-$t.conf"
do
sudo systemctl start systemd-binfmt.service

Thanks,
Unai

Re: [Qemu-devel] [PATCH v2] exec.c: refactor function flatview_add_to_dispatch()

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190311013016.14411-1-richardw.y...@linux.intel.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  x86_64-softmmu/accel/tcg/tcg-runtime.o
  CC  aarch64-softmmu/hw/cpu/realview_mpcore.o
/tmp/qemu-test/src/exec.c: In function 'flatview_add_to_dispatch':
/tmp/qemu-test/src/exec.c:1644:32: error: incompatible type for argument 2 of 
'int128_gt'
 if (int128_gt(remain.size, 0)) {
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:24,
---
  CC  aarch64-softmmu/hw/display/vga.o
  CC  aarch64-softmmu/hw/display/bcm2835_fb.o
/tmp/qemu-test/src/exec.c: In function 'flatview_add_to_dispatch':
/tmp/qemu-test/src/exec.c:1644:32: error: incompatible type for argument 2 of 
'int128_gt'
 if (int128_gt(remain.size, 0)) {
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:24,


The full log is available at
http://patchew.org/logs/20190311013016.14411-1-richardw.y...@linux.intel.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v3 6/10] qemu-binfmt-conf.sh: generalize to positional

[Unai Martinez Corral]

2019/3/10 18:02, Laurent Vivier:
> On 06/03/2019 05:50, Unai Martinez-Corral wrote:
> > The list can be separated by spaces, tabs, newlines or commas. If no
>
> I think it would be simpler to not manage commas, and to use the default
> field separator.

Commas were supported because the same function is used to parse CPUS
here and ARCHS in patch 7/10. ARCHS must be separated by commas.
Nonetheless, if we do not support CPUS and ARCHS in a single command,
we can avoid managing commas.

Agree and thanks for all of the remaining comments. I will apply them:

> Why do you need to introduce a new variable "all", you can use directly
> "qemu_target_list".

> No need to introduce a new variable, you can use directly
> checked_target_list

> Use directly "qemu_target_list"
> You don't need a new variable, you can check "x$cpu" = "x$target" to
> know if you have found the target.

> I think you don't need to add the ":" at the beginning of the list.

Regards,
Unai

Re: [Qemu-devel] [PATCH 0/8] Kconfig: Clean up the PIIX southbridge devices

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190310235351.1863-1-phi...@redhat.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===




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

Re: [Qemu-devel] [PATCH] migration/postcopy: Update the bandwidth during postcopy

[Peter Xu]

On Fri, Mar 08, 2019 at 10:12:10AM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> The recently added max-postcopy-bandwidth parameter is only read
> at the transition from precopy->postcopy where as the older
> max-bandwidth parameter updates the migration bandwidth when changed
> even if the migration is already running.
> 
> Fix this discrepency so that:
>   a) You can change the bandwidth during postcopy by setting
>  max-postcopy-bandwidth
> 
>   b) Changing max-bandwidth during postcopy has no effect
>  (it currently changes the postcopy bandwidth which isn't
>  expected).
> 
> Fixes: 7e555c6c
> bz: https://bugzilla.redhat.com/show_bug.cgi?id=1686321
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Peter Xu 

Now in qapi/migration.json it's not mentioning precopy in the
max-bandwidth entry which seems to work even for postcopy but it'll
not:

# @max-bandwidth: to set maximum speed for migration. maximum speed in
# bytes per second. (Since 2.8)

Should we consider to touch that up too to match everything?

-- 
Peter Xu

Re: [Qemu-devel] [PATCH] migration/rdma: Check qemu_rdma_init_one_block

[Peter Xu]

On Fri, Mar 08, 2019 at 06:51:24PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Actually it can't fail at the moment, but Coverity moans that
> it's the only place it's not checked, and it's an easy check.
> 
> Reported-by: Coverity (CID 1399413)
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [Qemu-devel] [PATCH] migration: fix small leak

[Peter Xu]

On Fri, Mar 08, 2019 at 05:07:31PM +0100, Marc-André Lureau wrote:

[...]

> diff --git a/migration/socket.c b/migration/socket.c
> index 239527fb1f..49bacf78fd 100644
> --- a/migration/socket.c
> +++ b/migration/socket.c
> @@ -199,6 +199,7 @@ static void socket_start_incoming_migration(SocketAddress 
> *saddr,
>  return;
>  }
>  migrate_add_address(address);
> +qapi_free_SocketAddress(address);

Or just don't clone in migrate_add_address()?  Either way:

Reviewed-by: Peter Xu 

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH 0/5] QEMU VFIO live migration

[Tian, Kevin]

> From: Alex Williamson
> Sent: Saturday, March 9, 2019 6:03 AM
> 
> On Fri, 8 Mar 2019 16:21:46 +
> "Dr. David Alan Gilbert"  wrote:
> 
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > On Thu, 7 Mar 2019 23:20:36 +
> > > "Tian, Kevin"  wrote:
> > >
> > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > Sent: Friday, March 8, 2019 1:44 AM
> > > > > > >
> > > > > > > > This kind of data needs to be saved / loaded in 
> > > > > > > > pre-copy and
> > > > > > > > stop-and-copy phase.
> > > > > > > > The data of device memory is held in device memory 
> > > > > > > > region.
> > > > > > > > Size of devie memory is usually larger than that of 
> > > > > > > > device
> > > > > > > > memory region. qemu needs to save/load it in chunks of 
> > > > > > > > size
> of
> > > > > > > > device memory region.
> > > > > > > > Not all device has device memory. Like IGD only uses 
> > > > > > > > system
> > > > > memory.
> > > > > > >
> > > > > > > It seems a little gratuitous to me that this is a separate region 
> > > > > > > or
> > > > > > > that this data is handled separately.  All of this data is opaque 
> > > > > > > to
> > > > > > > QEMU, so why do we need to separate it?
> > > > > > hi Alex,
> > > > > > as the device state interfaces are provided by kernel, it is 
> > > > > > expected to
> > > > > > meet as general needs as possible. So, do you think there are such
> use
> > > > > > cases from user space that user space knows well of the device, and
> > > > > > it wants kernel to return desired data back to it.
> > > > > > E.g. It just wants to get whole device config data including all 
> > > > > > mmios,
> > > > > > page tables, pci config data...
> > > > > > or, It just wants to get current device memory snapshot, not
> including any
> > > > > > dirty data.
> > > > > > Or, It just needs the dirty pages in device memory or system memory.
> > > > > > With all this accurate query, quite a lot of useful features can be
> > > > > > developped in user space.
> > > > > >
> > > > > > If all of this data is opaque to user app, seems the only use case 
> > > > > > is
> > > > > > for live migration.
> > > > >
> > > > > I can certainly appreciate a more versatile interface, but I think
> > > > > we're also trying to create the most simple interface we can, with the
> > > > > primary target being live migration.  As soon as we start defining 
> > > > > this
> > > > > type of device memory and that type of device memory, we're going to
> > > > > have another device come along that needs yet another because they
> have
> > > > > a slightly different requirement.  Even without that, we're going to
> > > > > have vendor drivers implement it differently, so what works for one
> > > > > device for a more targeted approach may not work for all devices.  Can
> > > > > you enumerate some specific examples of the use cases you imagine
> your
> > > > > design to enable?
> > > > >
> > > >
> > > > Do we want to consider an use case where user space would like to
> > > > selectively introspect a portion of the device state (including implicit
> > > > state which are not available through PCI regions), and may ask for
> > > > capability of direct mapping of selected portion for scanning (e.g.
> > > > device memory) instead of always turning on dirty logging on all
> > > > device state?
> > >
> > > I don't see that a migration interface necessarily lends itself to this
> > > use case.  A migration data stream has no requirement to be user
> > > consumable as anything other than opaque data, there's also no
> > > requirement that it expose state in a form that directly represents the
> > > internal state of the device.  In fact I'm not sure we want to encourage
> > > introspection via this data stream.  If a user knows how to interpret
> > > the data, what prevents them from modifying the data in-flight?  I've
> > > raised the question previously regarding how the vendor driver can
> > > validate the integrity of the migration data stream.  Using the
> > > migration interface to introspect the device certainly suggests an
> > > interface ripe for exploiting any potential weakness in the vendor
> > > driver reassembling that migration stream.  If the user has an mmap to
> > > the actual live working state of the vendor driver, protection in the
> > > hardware seems like the only way you could protect against a malicious
> > > user.  Please be defensive in what is directly exposed to the user and
> > > what safeguards are in place within the vendor driver for validating
> > > incoming data.  Thanks,
> >
> > Hmm; that sounds like a security-by-obscurity answer!
> 
> Yup, that's fair.  I won't deny that in-kernel vendor driver state
> passing through userspace from source to target systems scares me quite
> a bit, but defining device introspection as a use case for the
> migration interface imposes requirements on the vendor drivers that
> don't

Re: [Qemu-devel] [PATCH v7 2/2] mips_fulong2e: Add on-board graphics chip

[BALATON Zoltan]

On Mon, 11 Mar 2019, Philippe Mathieu-Daudé wrote:

On 3/9/19 6:21 PM, BALATON Zoltan wrote:

Add (partial) emulation of the on-board GPU of the machine. This
allows the PMON2000 firmware to run and should also work with Linux
console but probably not with X yet.

Signed-off-by: BALATON Zoltan 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 


Mojibaked again :(

I guess this is the last respin and this series will be applied,
so to the maintainer: Can you fix using:


Don't worry, Gerd said before it came out OK as he also uses UTF8 so 
maybe it only shows up wrong in your email client.



Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

Zoltan if you have to respin, please simply use:


I've tried adding some headers to specify encoding which I'll use next but 
I did not bother for this resend as it worked before.


Regards,
BALATON Zoltan

[Qemu-devel] [PATCH v2] exec.c: refactor function flatview_add_to_dispatch()

[Wei Yang]

flatview_add_to_dispatch() registers page based on the condition of
*section*, which may looks like this:

|s|PPP|s|

where s stands for subpage and P for page.

The procedure of this function could be described as:

- register first subpage
- register page
- register last subpage

This means the procedure could be simplified into these three steps
instead of a loop iteration.

This patch refactors the function into three corresponding steps and
adds some comment to clarify it.

Signed-off-by: Wei Yang 

---
v2:
  * removes the loop iteration as suggested by Paolo
---
 exec.c | 50 +-
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/exec.c b/exec.c
index 0959b00c06..160b8587d4 100644
--- a/exec.c
+++ b/exec.c
@@ -1598,34 +1598,50 @@ static void register_multipage(FlatView *fv,
 phys_page_set(d, start_addr >> TARGET_PAGE_BITS, num_pages, section_index);
 }
 
+/*
+ * The range in *section* may look like this:
+ *
+ *  |s|PPP|s|
+ *
+ * where s stands for subpage and P for page.
+ *
+ * The procedure in following function could be described as:
+ *
+ * - register first subpage
+ * - register page
+ * - register last subpage
+ */
 void flatview_add_to_dispatch(FlatView *fv, MemoryRegionSection *section)
 {
-MemoryRegionSection now = *section, remain = *section;
+MemoryRegionSection now, remain = *section;
 Int128 page_size = int128_make64(TARGET_PAGE_SIZE);
 
-if (now.offset_within_address_space & ~TARGET_PAGE_MASK) {
-uint64_t left = TARGET_PAGE_ALIGN(now.offset_within_address_space)
-   - now.offset_within_address_space;
+/* register first subpage */
+if (remain.offset_within_address_space & ~TARGET_PAGE_MASK) {
+uint64_t left = TARGET_PAGE_ALIGN(remain.offset_within_address_space)
+- remain.offset_within_address_space;
 
+now = remain;
 now.size = int128_min(int128_make64(left), now.size);
+remain.size = int128_sub(remain.size, now.size);
+remain.offset_within_address_space += int128_get64(now.size);
+remain.offset_within_region += int128_get64(now.size);
 register_subpage(fv, &now);
-} else {
-now.size = int128_zero();
 }
-while (int128_ne(remain.size, now.size)) {
+
+/* register page */
+if (int128_ge(remain.size, page_size)) {
+now = remain;
+now.size = int128_and(now.size, int128_neg(page_size));
 remain.size = int128_sub(remain.size, now.size);
 remain.offset_within_address_space += int128_get64(now.size);
 remain.offset_within_region += int128_get64(now.size);
-now = remain;
-if (int128_lt(remain.size, page_size)) {
-register_subpage(fv, &now);
-} else if (remain.offset_within_address_space & ~TARGET_PAGE_MASK) {
-now.size = page_size;
-register_subpage(fv, &now);
-} else {
-now.size = int128_and(now.size, int128_neg(page_size));
-register_multipage(fv, &now);
-}
+register_multipage(fv, &now);
+}
+
+/* register last subpage */
+if (int128_gt(remain.size, 0)) {
+register_subpage(fv, &remain);
 }
 }
 
-- 
2.19.1

Re: [Qemu-devel] converting build system to Meson?

[Neal Gompa]

On Thu, Mar 7, 2019 at 1:44 PM Paolo Bonzini  wrote:
>
> On 07/03/19 14:09, Peter Maydell wrote:
> > On Thu, 7 Mar 2019 at 12:56, Paolo Bonzini  wrote:
> >> In any case, this wouldn't change; as you suggest below, configure could
> >> remain as a front-end (well, in-srcdir builds are not supported by
> >> Meson, so "../configure && ninja" perhaps).
> >
> > As an aside, it might be a nice idea to drop the in-srcdir
> > build altogether for QEMU anyway -- it's not really a very
> > good idea and it means our build system has to cope with two
> > different ways of working to no particularly useful end.
>
> I was actually going to propose that, but I was afraid of throwing two
> bombs in the same day. :)
>
> > Of the various hosts I do builds on:
> >  * OSX is 2.7 only
> >  * the ppc64 box in the gcc compile farm is 2.7 and 3.4
> >("Centos 7.5.1804")
> >  * the aarch64 box in the gcc compile farm is 2.7 and 3.4
> >("Ubuntu 14.04.5 LTS", aka trusty)
>
> OS X will need to get Python 3 from Homebrew sooner or later anyway.
>
> Trusty does have a python3.5 package, perhaps you could ask the
> maintainers to install it.
>
> CentOS 7 doesn't have "native" Python 3 (even the 3.4 version you have
> there is probably coming from Fedora) but it has software collections,
> where you have to do "scl enable rh-python35 './configure && make'".
> You can check if scl and the rh-python35 software collections are
> already installed.
>

Most normal users of CentOS use it with EPEL. In this case, EPEL 7 is
transitioning to Python 3.6 (both are available in EPEL 7 today, and
Meson is built there against 3.6).

macOS already has Python 3 in Homebrew, as well as Meson itself.
Eventually Apple will change the native Python runtime to 3.x as well.

Ubuntu 14.04 LTS is EOL next month, and Ubuntu 16.04 LTS ships Python
3.5 and offers a recent Meson in backports.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Qemu-devel] [PATCH v3 6/7] hw/pci-host: Use CONFIG_PCI_BONITO to select the Bonito North Bridge

[Philippe Mathieu-Daudé]

Ease the kconfig selection by introducing CONFIG_PCI_BONITO to select
the Bonito North Bridge.

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/mips64el-softmmu.mak | 1 +
 hw/pci-host/Kconfig  | 4 
 hw/pci-host/Makefile.objs| 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index c7409d23d2..88b66a91d7 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -3,6 +3,7 @@
 include mips-softmmu-common.mak
 CONFIG_IDE_VIA=y
 CONFIG_FULONG=y
+CONFIG_PCI_BONITO=y
 CONFIG_JAZZ=y
 CONFIG_VT82C686=y
 CONFIG_MIPS_BOSTON=y
diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
index b39ea297ba..9abadafaf5 100644
--- a/hw/pci-host/Kconfig
+++ b/hw/pci-host/Kconfig
@@ -49,3 +49,7 @@ config PCI_EXPRESS_XILINX
 config PCI_EXPRESS_DESIGNWARE
 bool
 select PCI_EXPRESS
+
+config PCI_BONITO
+select PCI
+bool
diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
index a9cd3e022d..d6e86b9b89 100644
--- a/hw/pci-host/Makefile.objs
+++ b/hw/pci-host/Makefile.objs
@@ -12,7 +12,7 @@ common-obj-$(CONFIG_PPCE500_PCI) += ppce500.o
 common-obj-$(CONFIG_VERSATILE_PCI) += versatile.o
 
 common-obj-$(CONFIG_PCI_SABRE) += sabre.o
-common-obj-$(CONFIG_FULONG) += bonito.o
+common-obj-$(CONFIG_PCI_BONITO) += bonito.o
 common-obj-$(CONFIG_PCI_PIIX) += piix.o
 common-obj-$(CONFIG_PCI_EXPRESS_Q35) += q35.o
 common-obj-$(CONFIG_PCI_EXPRESS_GENERIC_BRIDGE) += gpex.o
-- 
2.20.1

[Qemu-devel] [PATCH v3 5/7] hw/mips: Express dependencies of the Boston machine with Kconfig

[Philippe Mathieu-Daudé]

Boston is built around a Xilinx FPGA, which includes a PCIe root port
and an UART. An Intel EG20T PCH connects the I/O peripherals, but only
the SATA bus is emulated.

Reviewed-by: Thomas Huth 
Reviewed-by: Paul Burton 
Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/mips64el-softmmu.mak | 4 
 hw/mips/Kconfig  | 5 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index a7b88318b2..c7409d23d2 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -5,8 +5,4 @@ CONFIG_IDE_VIA=y
 CONFIG_FULONG=y
 CONFIG_JAZZ=y
 CONFIG_VT82C686=y
-CONFIG_AHCI=y
 CONFIG_MIPS_BOSTON=y
-CONFIG_FITLOADER=y
-CONFIG_PCI_EXPRESS=y
-CONFIG_PCI_EXPRESS_XILINX=y
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index 5678c9cf15..bd6e3be2cd 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -50,3 +50,8 @@ config MIPS_CPS
 
 config MIPS_BOSTON
 bool
+select FITLOADER
+select MIPS_CPS
+select PCI_EXPRESS_XILINX
+select AHCI
+select SERIAL
-- 
2.20.1

[Qemu-devel] [PATCH v3 3/7] hw/mips: Express dependencies of the r4k platform with Kconfig

[Philippe Mathieu-Daudé]

This platform use standard PC devices connected to an ISA bus.
Networking is provided by a ne2000 chipset.

Signed-off-by: Philippe Mathieu-Daudé 
---
v3: remove CONFIG_NE2000_ISA (Thomas)
add PFLASH_CFI01
---
 default-configs/mips-softmmu-common.mak |  1 -
 hw/mips/Kconfig | 11 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index caebafd416..2ca57bfee1 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -24,7 +24,6 @@ CONFIG_I8257=y
 CONFIG_PIIX4=y
 CONFIG_IDE_ISA=y
 CONFIG_IDE_PIIX=y
-CONFIG_NE2000_ISA=y
 CONFIG_PFLASH_CFI01=y
 CONFIG_I8259=y
 CONFIG_MC146818RTC=y
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index ab006477c7..5678c9cf15 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -1,5 +1,16 @@
 config R4K
 bool
+select ISA_BUS
+select SERIAL_ISA
+select I8259
+select I8254
+select MC146818RTC
+select VGA_ISA
+select NE2000_ISA
+select IDE_ISA
+# I8042
+select PCKBD
+select PFLASH_CFI01
 
 config MALTA
 bool
-- 
2.20.1

[Qemu-devel] [PATCH v3 4/7] hw/mips: Remove the redundant CONFIG_MIPS_ITU Makefile variable

[Philippe Mathieu-Daudé]

The Inter-Thread Communication Unit (ITU, introduced in commit
34fa7e83e11) is part of the Coherent Processing System (CPS),
as describe in commit 408294352ad:

Make ITU available in the system if CPU supports multithreading
and is part of CPS.

Replate the CONFIG_MIPS_ITU variable by the CONFIG_MIPS_CPS one.

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/mips-softmmu-common.mak | 1 -
 hw/misc/Kconfig | 3 ---
 hw/misc/Makefile.objs   | 2 +-
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 2ca57bfee1..c5b148b1c6 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -29,7 +29,6 @@ CONFIG_I8259=y
 CONFIG_MC146818RTC=y
 CONFIG_EMPTY_SLOT=y
 CONFIG_MIPS_CPS=y
-CONFIG_MIPS_ITU=y
 CONFIG_R4K=y
 CONFIG_MALTA=y
 CONFIG_MIPSSIM=y
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 2c60be99bc..3125cf86f2 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -80,9 +80,6 @@ config IMX
 config STM32F2XX_SYSCFG
 bool
 
-config MIPS_ITU
-bool
-
 config MPS2_FPGAIO
 bool
 
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index c71e07ae35..22565d72af 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -59,7 +59,7 @@ obj-$(CONFIG_ZYNQ) += zynq-xadc.o
 obj-$(CONFIG_STM32F2XX_SYSCFG) += stm32f2xx_syscfg.o
 obj-$(CONFIG_MIPS_CPS) += mips_cmgcr.o
 obj-$(CONFIG_MIPS_CPS) += mips_cpc.o
-obj-$(CONFIG_MIPS_ITU) += mips_itu.o
+obj-$(CONFIG_MIPS_CPS) += mips_itu.o
 obj-$(CONFIG_MPS2_FPGAIO) += mps2-fpgaio.o
 obj-$(CONFIG_MPS2_SCC) += mps2-scc.o
 
-- 
2.20.1

[Qemu-devel] [PATCH v3 7/7] hw/mips: Express dependencies of the Fulong 2E machine with Kconfig

[Philippe Mathieu-Daudé]

The Fulong 2E machine uses a Loongson 2E as CPU, a Bonito64 system
controller as North Bridge and a VT82C686 chipset as South Bridge.
The network card chipset is a RTL8139D.

Signed-off-by: Philippe Mathieu-Daudé 
---
v3: Loongson 2E = CPU, Fulong 2E = machine (Aleksandar)
---
 default-configs/mips64el-softmmu.mak |  3 ---
 hw/isa/Kconfig   | 13 +
 hw/mips/Kconfig  |  5 +
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index 88b66a91d7..d0814e76af 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -1,9 +1,6 @@
 # Default configuration for mips64el-softmmu
 
 include mips-softmmu-common.mak
-CONFIG_IDE_VIA=y
 CONFIG_FULONG=y
-CONFIG_PCI_BONITO=y
 CONFIG_JAZZ=y
-CONFIG_VT82C686=y
 CONFIG_MIPS_BOSTON=y
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 57e09a0cb8..30055aed82 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -32,10 +32,15 @@ config PIIX4
 
 config VT82C686
 bool
-select ISA_BUS
-select ACPI_SMBUS
-select SERIAL_ISA
-select FDC
+select PCI
+select I8259
+select I8254
+select I8257
+select PARALLEL
+select IDE_ISA
+select IDE_VIA
+select USB_UHCI
+#select PCKBD
 
 config SMC37C669
 bool
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index bd6e3be2cd..b06d70bf01 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -43,6 +43,11 @@ config JAZZ
 
 config FULONG
 bool
+select PCI_BONITO
+select VT82C686
+select SMBUS_EEPROM
+select RTL8139_PCI
+select MC146818RTC
 
 config MIPS_CPS
 bool
-- 
2.20.1

[Qemu-devel] [PATCH v3 2/7] hw/mips: Express dependencies of the Jazz machine with Kconfig

[Philippe Mathieu-Daudé]

The Jazz use the RC4030 Asic to provide an EISA bus and DMA/IRQ. The
framebuffer display is managed by a G364, the network card is a Sonic
DP83932. A QLogic ESP216 provides a SCSI bus.

Signed-off-by: Philippe Mathieu-Daudé 
---
v3: Keep CONFIG_JAZZ in default-configs/mips64el-softmmu.mak (Thomas)
---
 default-configs/mips-softmmu-common.mak |  1 -
 default-configs/mips64-softmmu.mak  |  5 -
 default-configs/mips64el-softmmu.mak|  5 -
 hw/mips/Kconfig | 17 +
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 8c5fdf5ee1..caebafd416 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -3,7 +3,6 @@
 CONFIG_ISA_BUS=y
 CONFIG_PCI=y
 CONFIG_PCI_DEVICES=y
-CONFIG_ESP=y
 CONFIG_VGA_ISA=y
 CONFIG_VGA_ISA_MM=y
 CONFIG_VGA_CIRRUS=y
diff --git a/default-configs/mips64-softmmu.mak 
b/default-configs/mips64-softmmu.mak
index bad7496672..a169738635 100644
--- a/default-configs/mips64-softmmu.mak
+++ b/default-configs/mips64-softmmu.mak
@@ -1,9 +1,4 @@
 # Default configuration for mips64-softmmu
 
 include mips-softmmu-common.mak
-CONFIG_RC4030=y
-CONFIG_DP8393X=y
-CONFIG_DS1225Y=y
 CONFIG_JAZZ=y
-CONFIG_G364FB=y
-CONFIG_JAZZ_LED=y
diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index 8b255efc54..a7b88318b2 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -2,13 +2,8 @@
 
 include mips-softmmu-common.mak
 CONFIG_IDE_VIA=y
-CONFIG_RC4030=y
-CONFIG_DP8393X=y
-CONFIG_DS1225Y=y
 CONFIG_FULONG=y
 CONFIG_JAZZ=y
-CONFIG_G364FB=y
-CONFIG_JAZZ_LED=y
 CONFIG_VT82C686=y
 CONFIG_AHCI=y
 CONFIG_MIPS_BOSTON=y
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index 3433e97e1a..ab006477c7 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -12,6 +12,23 @@ config MIPSSIM
 
 config JAZZ
 bool
+select ISA_BUS
+select RC4030
+select I8259
+select I8254
+select I8257
+select PCSPK
+select VGA_ISA_MM
+select G364FB
+select DP8393X
+select ESP
+select FDC
+select MC146818RTC
+select PCKBD
+select SERIAL
+select PARALLEL
+select DS1225Y
+select JAZZ_LED
 
 config FULONG
 bool
-- 
2.20.1

[Qemu-devel] [PATCH v3 0/7] Kconfig dependencies for MIPS machines (but Malta)

[Philippe Mathieu-Daudé]

Express the MIPS machine dependencies with Kconfig.

Due to its complexity, the Malta board fill follow in a different
series.

v3:
- addressed review comments from Thomas and Aleksandar
  (noted in each patch)

v2: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg00887.html
- Do not remove machines from the default config (Thomas)
- Corrected comment about CONFIG_PCI_BONITO (Thomas)

v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg593013.html

$ git backport-diff -u kconfig_mips-v2
Key:
[] : patches are identical
[] : number of functional differences between upstream/downstream patch
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/7:[] [--] 'hw/mips: Express dependencies of the MIPSsim machine with 
kconfig'
002/7:[0001] [FC] 'hw/mips: Express dependencies of the Jazz machine with 
kconfig'
003/7:[0002] [FC] 'hw/mips: Express dependencies of the r4k platform with 
kconfig'
004/7:[down] 'hw/mips: Remove the redundant CONFIG_MIPS_ITU Makefile variable'
005/7:[] [-C] 'hw/mips: Express dependencies of the Boston machine with 
kconfig'
006/7:[] [-C] 'hw/pci-host: Use CONFIG_PCI_BONITO to select the Bonito 
North Bridge'
007/7:[] [-C] 'hw/mips: Express dependencies of the Fulong 2E machine with 
kconfig'

Regards,

Phil.

Philippe Mathieu-Daudé (7):
  hw/mips: Express dependencies of the MIPSsim machine with Kconfig
  hw/mips: Express dependencies of the Jazz machine with Kconfig
  hw/mips: Express dependencies of the r4k platform with Kconfig
  hw/mips: Remove the redundant CONFIG_MIPS_ITU Makefile variable
  hw/mips: Express dependencies of the Boston machine with Kconfig
  hw/pci-host: Use CONFIG_PCI_BONITO to select the Bonito North Bridge
  hw/mips: Express dependencies of the Fulong 2E machine with Kconfig

 default-configs/mips-softmmu-common.mak |  4 ---
 default-configs/mips64-softmmu.mak  |  5 ---
 default-configs/mips64el-softmmu.mak| 11 ---
 hw/isa/Kconfig  | 13 +---
 hw/mips/Kconfig | 41 +
 hw/misc/Kconfig |  3 --
 hw/misc/Makefile.objs   |  2 +-
 hw/pci-host/Kconfig |  4 +++
 hw/pci-host/Makefile.objs   |  2 +-
 9 files changed, 56 insertions(+), 29 deletions(-)

-- 
2.20.1

[Qemu-devel] [PATCH v3 1/7] hw/mips: Express dependencies of the MIPSsim machine with Kconfig

[Philippe Mathieu-Daudé]

The MIPSsim machine only emulates an 8250 UART and a simple network
controller, connected via an ISA bus.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/mips-softmmu-common.mak | 1 -
 hw/mips/Kconfig | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 0795d522db..8c5fdf5ee1 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -26,7 +26,6 @@ CONFIG_PIIX4=y
 CONFIG_IDE_ISA=y
 CONFIG_IDE_PIIX=y
 CONFIG_NE2000_ISA=y
-CONFIG_MIPSNET=y
 CONFIG_PFLASH_CFI01=y
 CONFIG_I8259=y
 CONFIG_MC146818RTC=y
diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index cdc07e59b6..3433e97e1a 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -6,6 +6,9 @@ config MALTA
 
 config MIPSSIM
 bool
+select ISA_BUS
+select SERIAL_ISA
+select MIPSNET
 
 config JAZZ
 bool
-- 
2.20.1

Re: [Qemu-devel] [PATCH v7 2/2] mips_fulong2e: Add on-board graphics chip

[Philippe Mathieu-Daudé]

On 3/9/19 6:21 PM, BALATON Zoltan wrote:
> Add (partial) emulation of the on-board GPU of the machine. This
> allows the PMON2000 firmware to run and should also work with Linux
> console but probably not with X yet.
> 
> Signed-off-by: BALATON Zoltan 
> Reviewed-by: Philippe Mathieu-Daudé 
> Tested-by: Philippe Mathieu-Daudé 

Mojibaked again :(

I guess this is the last respin and this series will be applied,
so to the maintainer: Can you fix using:

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

Zoltan if you have to respin, please simply use:

Reviewed-by: Philippe Mathieu-Daude 
Tested-by: Philippe Mathieu-Daude 

> Reviewed-by: Aleksandar Markovic 
> ---
> v7:
> - set vgamem_mb explicitely to match board instead of relying on default
> 
>  hw/mips/mips_fulong2e.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/hw/mips/mips_fulong2e.c b/hw/mips/mips_fulong2e.c
> index fbbc543eed..2bdb766ed1 100644
> --- a/hw/mips/mips_fulong2e.c
> +++ b/hw/mips/mips_fulong2e.c
> @@ -287,6 +287,7 @@ static void mips_fulong2e_init(MachineState *machine)
>  I2CBus *smbus;
>  MIPSCPU *cpu;
>  CPUMIPSState *env;
> +DeviceState *dev;
>  
>  /* init CPUs */
>  cpu = MIPS_CPU(cpu_create(machine->cpu_type));
> @@ -347,6 +348,12 @@ static void mips_fulong2e_init(MachineState *machine)
>  vt82c686b_southbridge_init(pci_bus, FULONG2E_VIA_SLOT, env->irq[5],
> &smbus, &isa_bus);
>  
> +/* GPU */
> +dev = DEVICE(pci_create(pci_bus, -1, "ati-vga"));
> +qdev_prop_set_uint32(dev, "vgamem_mb", 16);
> +qdev_prop_set_uint16(dev, "x-device-id", 0x5159);
> +qdev_init_nofail(dev);
> +
>  /* Populate SPD eeprom data */
>  spd_data = spd_data_generate(DDR, ram_size, &err);
>  if (err) {
> 

[Qemu-devel] [PATCH 4/5] NOTFORMERGE roms/edk2: Use arm-linux-gnueabihf-gcc on Debian based distribs

[Philippe Mathieu-Daudé]

Do not enforce GCCx_ARM_PREFIX=arm-linux-gnu- on Debian based
distributions.
This is a kludge not meant for merging!

Signed-off-by: Philippe Mathieu-Daudé 
---
 roms/edk2-funcs.sh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
index 402fc126fb..2f1fa2af1a 100644
--- a/roms/edk2-funcs.sh
+++ b/roms/edk2-funcs.sh
@@ -113,6 +113,11 @@ qemu_edk2_get_cross_prefix()
 # no cross-compiler needed
 :
   else
+if [ -f /etc/lsb-release ] && [ "$gcc_arch" = arm ]; then
+  # XXX kludge for Debian-based distribs
+  printf 'arm-linux-gnueabihf-\n'
+  return 0
+fi
 printf '%s-linux-gnu-\n' "$gcc_arch"
   fi
 }
-- 
2.20.1

[Qemu-devel] [PATCH 2/5] roms/edk2: Avoid bashism in script

[Philippe Mathieu-Daudé]

Use the POSIX '=' to evaluate equality.

This fixes building the roms with a dash shell:

  $ make -C roms efi
  [...]
  cp edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/FV/QEMU_EFI.fd \
../pc-bios/edk2-arm-code.fd
  truncate --size=64M ../pc-bios/edk2-arm-code.fd
  /bin/sh: 111: [: i686: unexpected operator
  /bin/sh: 112: [: i686: unexpected operator
  /bin/sh: 116: [: i686: unexpected operator

Signed-off-by: Philippe Mathieu-Daudé 
---
 roms/edk2-funcs.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
index 7fc62f074c..402fc126fb 100644
--- a/roms/edk2-funcs.sh
+++ b/roms/edk2-funcs.sh
@@ -108,8 +108,8 @@ qemu_edk2_get_cross_prefix()
 
   host_arch=$(uname -m)
 
-  if [ "$gcc_arch" == "$host_arch" ] ||
- ( [ "$gcc_arch" == i686 ] && [ "$host_arch" == x86_64 ] ); then
+  if [ "$gcc_arch" = "$host_arch" ] ||
+ ( [ "$gcc_arch" = i686 ] && [ "$host_arch" = x86_64 ] ); then
 # no cross-compiler needed
 :
   else
-- 
2.20.1

[Qemu-devel] [PATCH 5/5] .travis.yml: Build and install EDK2 roms

[Philippe Mathieu-Daudé]

Add a job to build and install the EDK2 platform firmware binaries.

This job is only triggered if the last commit matches the EDK2
name (case insensitive), or when tag are created (such releases
or release candidates).

Signed-off-by: Philippe Mathieu-Daudé 
---
 .travis.yml | 21 +
 1 file changed, 21 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index e942175dd3..628cc52c99 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -258,3 +258,24 @@ matrix:
 - env:
 - CONFIG="--disable-system"
 - TEST_CMD="make -j3 check-tcg V=1"
+
+
+# EDK2 roms builds
+- if: tag IS present OR commit_message =~ /(edk2|EDK2)/
+  env:
+- CONFIG="--disable-system --disable-user --prefix=$PWD/dist"
+- EDK2_BUILD_OPTIONS="--quiet --silent"
+  script:
+- git submodule update --init roms/edk2
+- make -j3
+- make -C roms efi -j2
+- make install
+  addons:
+apt:
+  packages:
+- dos2unix
+- gcc-aarch64-linux-gnu
+- gcc-arm-linux-gnueabihf
+- iasl
+- nasm
+- uuid-dev
-- 
2.20.1

[Qemu-devel] [PATCH 1/5] roms/edk2: Avoid bashism in Makefile 'shell' function

[Philippe Mathieu-Daudé]

The shell builtin 'source' command is a bash extension.
Use the '.' portable command.

This fix building when /bin/sh is dash (Ubuntu 16):

  $ make -C roms efi
  [...]
  Fd File Name:QEMU_EFI
  (/source/qemu/roms/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/QEMU_EFI.fd)
  Fd File Name:QEMU_VARS
  (/source/qemu/roms/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/QEMU_VARS.fd)
  GUID cross reference file can be found at
  /source/qemu/roms/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/Guid.xref
  - Done -
  Build end time: 16:33:29, Mar.09 2019
  Build total time: 00:03:35
  cp edk2/Build/ArmVirtQemu-AARCH64/DEBUG_/FV/QEMU_EFI.fd \
../pc-bios/edk2-aarch64-code.fd
  cp: cannot stat 'edk2/Build/ArmVirtQemu-AARCH64/DEBUG_/FV/QEMU_EFI.fd':
  No such file or directory
  Makefile.edk2:45: recipe for target '../pc-bios/edk2-aarch64-code.fd' failed
  make[1]: *** [../pc-bios/edk2-aarch64-code.fd] Error 1
  make[1]: Leaving directory '/source/qemu/roms'
  Makefile:148: recipe for target 'efi' failed
  make: *** [efi] Error 2
  make: Leaving directory '/source/qemu/roms'

Signed-off-by: Philippe Mathieu-Daudé 
---
 roms/Makefile.edk2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index ad6fff044c..6c5e9b9eea 100644
--- a/roms/Makefile.edk2
+++ b/roms/Makefile.edk2
@@ -11,7 +11,7 @@
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
 # WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-toolchain = $(shell source ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
+toolchain = $(shell . ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
 
 licenses := \
edk2/License.txt \
-- 
2.20.1

[Qemu-devel] [PATCH 0/5] travis-ci: Build EDK2 roms

[Philippe Mathieu-Daudé]

Hi,

This series add a job to Travis CI to build the last EDK2 stable
release roms within QEMU.
This job is only triggered if a commit matches 'EDK2' or during
QEMU releases (when tags are pushed).

Job output: https://travis-ci.org/philmd/qemu/jobs/504460932
Duration: 33 min 51 sec (output 5080 lines)

Based on Laszlo's series "bundle edk2 platform firmware with QEMU":
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02846.html

Please review,

Phil.

Based-on: 20190309004826.9027-1-ler...@redhat.com

Philippe Mathieu-Daudé (5):
  roms/edk2: Avoid bashism in Makefile 'shell' function
  roms/edk2: Avoid bashism in script
  roms/edk2: Pass extra arguments to the build script via
EDK2_BUILD_OPTIONS
  NOTFORMERGE roms/edk2: Use arm-linux-gnueabihf-gcc on Debian based
distribs
  .travis.yml: Build and install EDK2 roms

 .travis.yml| 21 +
 roms/Makefile.edk2 |  8 +++-
 roms/edk2-funcs.sh |  9 +++--
 3 files changed, 35 insertions(+), 3 deletions(-)

-- 
2.20.1

[Qemu-devel] [PATCH 3/5] roms/edk2: Pass extra arguments to the build script via EDK2_BUILD_OPTIONS

[Philippe Mathieu-Daudé]

The current EDK2 options produce a very verbose output.
When building the roms on Continuous Integration systems (such
Travis CI) the system limit is quickly reached.

Add an variable to optionally pass arguments to the edk2-build.sh
script.

Example of use:

  $ EDK2_BUILD_OPTIONS="--quiet --silent" make -C roms efi
  ...

Signed-off-by: Philippe Mathieu-Daudé 
---
 roms/Makefile.edk2 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index 6c5e9b9eea..70f84b20df 100644
--- a/roms/Makefile.edk2
+++ b/roms/Makefile.edk2
@@ -44,6 +44,7 @@ submodules:
 ../pc-bios/edk2-aarch64-code.fd: submodules
+./edk2-build.sh \
aarch64 \
+   $(EDK2_BUILD_OPTIONS) \
--arch=AARCH64 \
--platform=ArmVirtPkg/ArmVirtQemu.dsc \
-D NETWORK_IP6_ENABLE \
@@ -55,6 +56,7 @@ submodules:
 ../pc-bios/edk2-arm-code.fd: submodules
+./edk2-build.sh \
arm \
+   $(EDK2_BUILD_OPTIONS) \
--arch=ARM \
--platform=ArmVirtPkg/ArmVirtQemu.dsc \
-D NETWORK_IP6_ENABLE \
@@ -66,6 +68,7 @@ submodules:
 ../pc-bios/edk2-i386-code.fd: submodules
+./edk2-build.sh \
i386 \
+   $(EDK2_BUILD_OPTIONS) \
--arch=IA32 \
--platform=OvmfPkg/OvmfPkgIa32.dsc \
-D NETWORK_IP6_ENABLE \
@@ -78,6 +81,7 @@ submodules:
 ../pc-bios/edk2-i386-secure-code.fd: submodules
+./edk2-build.sh \
i386 \
+   $(EDK2_BUILD_OPTIONS) \
--arch=IA32 \
--platform=OvmfPkg/OvmfPkgIa32.dsc \
-D NETWORK_IP6_ENABLE \
@@ -92,6 +96,7 @@ submodules:
 ../pc-bios/edk2-x86_64-code.fd: submodules
+./edk2-build.sh \
x86_64 \
+   $(EDK2_BUILD_OPTIONS) \
--arch=X64 \
--platform=OvmfPkg/OvmfPkgX64.dsc \
-D NETWORK_IP6_ENABLE \
@@ -104,6 +109,7 @@ submodules:
 ../pc-bios/edk2-x86_64-secure-code.fd: submodules
+./edk2-build.sh \
x86_64 \
+   $(EDK2_BUILD_OPTIONS) \
--arch=IA32 \
--arch=X64 \
--platform=OvmfPkg/OvmfPkgIa32X64.dsc \
-- 
2.20.1

Re: [Qemu-devel] [PATCH 1/8] hw/i2c: The ACPI_SMBUS Kconfig depends on ACPI

[Philippe Mathieu-Daudé]

On 3/11/19 12:53 AM, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i2c/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/i2c/Kconfig b/hw/i2c/Kconfig
> index ef1caa6d89..ec62909fa1 100644
> --- a/hw/i2c/Kconfig
> +++ b/hw/i2c/Kconfig
> @@ -17,6 +17,7 @@ config VERSATILE_I2C
>  config ACPI_SMBUS
>  bool
>  select I2C
> +depends on ACPI

Please ignore this patch in this series, I incorrectly reordered it here
while rebasing, but it doesn't work without the next series "Kconfig:
Cleanup the ICH9 device". As it there is a circular dependency with
PC_ACPI.

>  
>  config BITBANG_I2C
>  bool
> 

[Qemu-devel] [PATCH 8/8] hw/i386: Move ACPI_SMBUS out of I440FX (Kconfig)

[Philippe Mathieu-Daudé]

The SMBus interface is a slow bus not related to the i440fx
northbridge, it comes from the PIIX3 southbridge.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 56e72abb8c..9ac833b930 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -51,7 +51,6 @@ config I440FX
 bool
 select PC_PCI
 select PC_ACPI
-select ACPI_SMBUS
 select DIMM
 select SMBIOS
 select VMPORT
@@ -68,6 +67,7 @@ config ISAPC
 select PIIX3
 # QEMU isapc weirdness: it uses PIIX3 with ACPI features from PIIX4
 select ACPI_PIIX4
+select ACPI_SMBUS
 
 config Q35
 bool
-- 
2.20.1

[Qemu-devel] [PATCH 5/8] hw/southbridge: Cleanup the PIIX4 chipset in Kconfig

[Philippe Mathieu-Daudé]

The PIIX4 (Intel 82371AB) is a bridge between PCI <-> ISA.

It is an exhanced PIIX3, thus contains the same features.
It also contains:
 - Power Management (ACPI rev 1.0)
 - IDE UDMA/33
 - SMBus interface (host and slave)
 - RTC

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/Kconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index f8494edd67..1c923dfd07 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -48,9 +48,13 @@ config PIIX3
 
 config PIIX4
 bool
+select PIIX3
+#select ACPI_PIIX4
+#select IDE_PIIX4
+select ACPI_SMBUS
+select MC146818RTC
 # For historical reasons, SuperIO devices are created in the board
 # for PIIX4.
-select ISA_BUS
 
 config VT82C686
 bool
-- 
2.20.1

[Qemu-devel] [PATCH 4/8] hw/southbridge: Add the PIIX3 chipset to Kconfig

[Philippe Mathieu-Daudé]

The PIIX3 (Intel 82371SB) is a bridge between PCI <-> ISA.

It is an exhanced PIIX, thus contains the same features.
It also contains:
 - separate Master/Slave IDE mode
 - compliant to PCI rev 2.1 specifications
 - IOAPIC
 - USB UHCI (2 ports)
 - USB Legacy Support (emulated devices):
   - 8042 Keyboard Controller
   - A20-Gate

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 681e6f1bce..f8494edd67 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -37,6 +37,15 @@ config PIIX
 #select NMI_PIIX
 select ISA_BUS
 
+config PIIX3
+bool
+select PIIX
+#select PCI_PIIX3
+#select IDE_PIIX3
+select IOAPIC
+select USB_UHCI
+select I8042
+
 config PIIX4
 bool
 # For historical reasons, SuperIO devices are created in the board
-- 
2.20.1

[Qemu-devel] [PATCH 7/8] hw/i386: The 'isapc' machine is built around a PIIX3 southbridge

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/Kconfig | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index f6b74e2dc0..56e72abb8c 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -52,8 +52,6 @@ config I440FX
 select PC_PCI
 select PC_ACPI
 select ACPI_SMBUS
-select PCI_PIIX
-select IDE_PIIX
 select DIMM
 select SMBIOS
 select VMPORT
@@ -62,13 +60,12 @@ config I440FX
 
 config ISAPC
 bool
-select ISA_BUS
 select PC
-select IDE_ISA
 select VGA_ISA
 # FIXME: it is in the same file as i440fx, and does not compile
 # if separated
 depends on I440FX
+select PIIX3
 # QEMU isapc weirdness: it uses PIIX3 with ACPI features from PIIX4
 select ACPI_PIIX4
 
-- 
2.20.1

[Qemu-devel] [PATCH 6/8] hw/southbridge: Add ACPI_PIIX4 to Kconfig

[Philippe Mathieu-Daudé]

Since the default-configs/mips-softmmu-common.mak is not yet ported
to the Kconfig format, we have to select this variable there (used
by the MIPS Malta machine).

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/mips-softmmu-common.mak | 1 +
 hw/acpi/Kconfig | 7 +++
 hw/acpi/Makefile.objs   | 3 ++-
 hw/i386/Kconfig | 2 ++
 hw/isa/Kconfig  | 2 +-
 5 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 0795d522db..61cc3d2c6b 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -20,6 +20,7 @@ CONFIG_ACPI_X86=y
 CONFIG_ACPI_MEMORY_HOTPLUG=y
 CONFIG_ACPI_NVDIMM=y
 CONFIG_ACPI_CPU_HOTPLUG=y
+CONFIG_ACPI_PIIX4=y
 CONFIG_APM=y
 CONFIG_I8257=y
 CONFIG_PIIX4=y
diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index eca3beed75..627f5e9768 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -8,6 +8,13 @@ config ACPI_X86
 select ACPI_CPU_HOTPLUG
 select ACPI_MEMORY_HOTPLUG
 
+config ACPI_PIIX4
+bool
+select ACPI
+select ACPI_NVDIMM
+select ACPI_CPU_HOTPLUG
+select ACPI_MEMORY_HOTPLUG
+
 config ACPI_X86_ICH
 bool
 select ACPI_X86
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index 2d46e3789a..2ef78175cb 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -1,5 +1,6 @@
 ifeq ($(CONFIG_ACPI),y)
-common-obj-$(CONFIG_ACPI_X86) += core.o piix4.o pcihp.o
+common-obj-$(CONFIG_ACPI_X86) += core.o pcihp.o
+common-obj-$(CONFIG_ACPI_PIIX4) += piix4.o
 common-obj-$(CONFIG_ACPI_X86_ICH) += ich9.o tco.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu_hotplug.o
 common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 78fd70396a..f6b74e2dc0 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -69,6 +69,8 @@ config ISAPC
 # FIXME: it is in the same file as i440fx, and does not compile
 # if separated
 depends on I440FX
+# QEMU isapc weirdness: it uses PIIX3 with ACPI features from PIIX4
+select ACPI_PIIX4
 
 config Q35
 bool
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 1c923dfd07..d3f03ef7d5 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -49,7 +49,7 @@ config PIIX3
 config PIIX4
 bool
 select PIIX3
-#select ACPI_PIIX4
+select ACPI_PIIX4
 #select IDE_PIIX4
 select ACPI_SMBUS
 select MC146818RTC
-- 
2.20.1

[Qemu-devel] [PATCH 3/8] hw/southbridge: Add the PIIX chipset to Kconfig

[Philippe Mathieu-Daudé]

The PIIX (Intel 82371FB) is a bridge between PCI <-> ISA.

It contains:
 - IDE interface (PIO and burst transfers)
 - one 82c54 timer (and speaker tone output)
 - two 82c59 interrupts controllers
 - two 8237 DMA controllers
 - Power Management (programmable SMI)
 - NMI

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/ide/Kconfig |  1 +
 hw/isa/Kconfig | 13 +
 2 files changed, 14 insertions(+)

diff --git a/hw/ide/Kconfig b/hw/ide/Kconfig
index ab47b6a7a3..1d997240c1 100644
--- a/hw/ide/Kconfig
+++ b/hw/ide/Kconfig
@@ -17,6 +17,7 @@ config IDE_ISA
 
 config IDE_PIIX
 bool
+select IDE_ISA
 select IDE_PCI
 select IDE_QDEV
 
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 57e09a0cb8..681e6f1bce 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -24,6 +24,19 @@ config PC87312
 select FDC
 select IDE_ISA
 
+config PIIX
+bool
+select PCI_PIIX
+select IDE_PIIX
+select I8254
+select I8259
+select PCSPK
+select I8257
+#select PM_PIIX
+#select SMI_PIIX
+#select NMI_PIIX
+select ISA_BUS
+
 config PIIX4
 bool
 # For historical reasons, SuperIO devices are created in the board
-- 
2.20.1

[Qemu-devel] [PATCH 1/8] hw/i2c: The ACPI_SMBUS Kconfig depends on ACPI

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i2c/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i2c/Kconfig b/hw/i2c/Kconfig
index ef1caa6d89..ec62909fa1 100644
--- a/hw/i2c/Kconfig
+++ b/hw/i2c/Kconfig
@@ -17,6 +17,7 @@ config VERSATILE_I2C
 config ACPI_SMBUS
 bool
 select I2C
+depends on ACPI
 
 config BITBANG_I2C
 bool
-- 
2.20.1

[Qemu-devel] [PATCH 0/8] Kconfig: Clean up the PIIX southbridge devices

[Philippe Mathieu-Daudé]

Hi,

This series is a cleanup for the PIIX/PIIX3/PIIX4 devices.

The isapc machine split isn't clean because while designed
on a PIIX3, our model uses ACPI features from the PIIX4.

The i440fx cleanup is left for the the next development cycle.

This series is a prerequisite for the MIPS Malta port to Kconfig.

Please review.

Regards,

Phil.

Philippe Mathieu-Daudé (8):
  hw/i2c: The ACPI_SMBUS Kconfig depends on ACPI
  hw/input: Add 8042 PS/2 Keyboard Controller to Kconfig
  hw/southbridge: Add the PIIX chipset to Kconfig
  hw/southbridge: Add the PIIX3 chipset to Kconfig
  hw/southbridge: Cleanup the PIIX4 chipset in Kconfig
  hw/southbridge: Add ACPI_PIIX4 to Kconfig
  hw/i386: The 'isapc' machine is built around a PIIX3 southbridge
  hw/i386: Move ACPI_SMBUS out of I440FX (Kconfig)

 default-configs/mips-softmmu-common.mak |  1 +
 hw/acpi/Kconfig |  7 +++
 hw/acpi/Makefile.objs   |  3 ++-
 hw/i2c/Kconfig  |  1 +
 hw/i386/Kconfig |  9 
 hw/ide/Kconfig  |  1 +
 hw/input/Kconfig|  4 
 hw/isa/Kconfig  | 28 -
 8 files changed, 47 insertions(+), 7 deletions(-)

-- 
2.20.1

[Qemu-devel] [PATCH 2/8] hw/input: Add 8042 PS/2 Keyboard Controller to Kconfig

[Philippe Mathieu-Daudé]

The Intel 8042 chipset also includes some functions unrelated to
the keyboard, such the A20-Gate.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/input/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/input/Kconfig b/hw/input/Kconfig
index e2e66f0858..83e4546a28 100644
--- a/hw/input/Kconfig
+++ b/hw/input/Kconfig
@@ -10,6 +10,10 @@ config PCKBD
 default y
 depends on ISA_BUS
 
+config I8042
+bool
+select PCKBD
+
 config PL050
 bool
 
-- 
2.20.1

Re: [Qemu-devel] [PATCH] hw/char/parallel: Make it possible to compile also without CONFIG_PARALLEL

[Peter Maydell]

On Sat, 9 Mar 2019 at 08:21, Thomas Huth  wrote:
>
> For the downstream distribution of QEMU, we want to compile without
> CONFIG_PARALLEL. Commit 9157eee1b1c076ff3 already moved the function
> parallel_hds_isa_init() (which is still required for linking) into a file
> that is included anyway, but commit bb3d5ea858e7f888563a moved it
> to a separate file which is only compiled again if CONFIG_PARALLEL is
> set. To be able to link QEMU again without CONFIG_PARALLEL, let's
> move this file unconditionally to common-obj-y again. And while we're
> at it, also rename it to parallel-helper.c (since parallel.c is also
> about ISA already)

parallel.c also provides an MMIO interface to the
parallel port via parallel_mm_init(), used by the MIPS
Jazz board. (In an ideal world this would be a proper
device, but it is ancient code.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] hw/char/parallel: Make it possible to compile also without CONFIG_PARALLEL

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1552119170-15474-1-git-send-email-th...@redhat.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  GEN x86_64-softmmu/qemu-system-x86_64.exe
../hw/char/parallel-helper.o: In function `parallel_init':
/tmp/qemu-test/src/hw/char/parallel-helper.c:22: undefined reference to 
`isa_create'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:212: qemu-system-aarch64w.exe] Error 1
make: *** [Makefile:449: subdir-aarch64-softmmu] Error 2
make: *** Waiting for unfinished jobs


The full log is available at
http://patchew.org/logs/1552119170-15474-1-git-send-email-th...@redhat.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH 04/10] roms/edk2: advance to tag edk2-stable201903

[Philippe Mathieu-Daudé]

On 3/9/19 1:48 AM, Laszlo Ersek wrote:
> Update the roms/edk2 submodule hash from edk2-stable201811 to
> edk2-stable201903. The release notes are available at
> .
> 
> $ git shortlog edk2-stable201811..edk2-stable201903
> 
> Achin Gupta (9):
>   ArmPkg: Add PCDs needed for MM communication driver.
>   ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
>   ArmPkg/Include: Add MM interface SVC return codes.
>   ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
>   StandaloneMmPkg: Add missing dependency on PL011UartClockLib
>   StandaloneMmPkg: Enforce alignment check for AArch64
>   StandaloneMmPkg: Zero data structure explicitly
>   StandaloneMmPkg: Replace dependency on ArmMmuLib
>   StandaloneMmPkg: Update dependency on PeCoffExtraActionLib
> 
> Albecki, Mateusz (1):
>   MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
> 
> Alex James (2):
>   StdLib/sys/termios: Define cc_t as unsigned
>   StdLib/Environs: Avoid infinite recursion in _Exit
> 
> Antoine Coeur (5):
>   ArmVirtPkg: Fix various typos
>   CryptoPkg: Fix various typos
>   CorebootPayloadPkg: Fix various typos
>   CorebootModulePkg: Fix various typos
>   BaseTools: Various typo
> 
> Ard Biesheuvel (116):
>   MdePkg/BaseIoLibIntrinsicArmVirt ARM: avoid double word loads and stores
>   ArmPkg/ArmGicDxe ARM: fix encoding for GICv3 interrupt acknowledge
>   ArmPlatformPkg: clear frame pointer in startup code
>   ArmVirtPkg/PrePi: clear frame pointer in startup code
>   ArmPkg/ArmSmcPsciResetSystemLib: add missing call to ExitBootServices()
>   ArmPkg: remove now unused BsdLib.h
>   ArmPlatformPkg/NorFlashDxe: prepare for devicepath format change
>   ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash 
> banks
>   ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into account
>   ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
>   ArmPlatformPkg/NorFlashPlatformLib: remove unused Guid member from 
> struct
>   ArmPkg/ArmPkg.dsc: move ArmMmuStandaloneMmLib.inf to AARCH64 section
>   EmbeddedPkg/TemplateSec: remove unused module
>   EmbeddedPkg/PrePiHobLib: drop CreateHobList() from library
>   ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory 
> map
>   ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
>   MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
>   ArmPkg/ArmLib: add support for reading the max physical address space 
> size
>   ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
>   ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
>   ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
>   ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
>   ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
>   BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
>   ArmPlatformPkg/PlatformPei: drop unused PCD references
>   EmbeddedPkg/PrePiLib: drop unused PCD reference
>   ArmVirtPkg: drop PcdPrePiCpuMemorySize assignments from all platforms
>   EmbeddedPkg/EmbeddedPkg.dec: drop PcdPrePiCpuMemorySize declarations
>   ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()
>   ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating permissions
>   ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
>   ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
>   BaseTools/CommonLib: avoid using 'native' word size in IP address 
> handling
>   BaseTools/CommonLib: use explicit 64-bit type in Strtoi()
>   BaseTools/DevicePath: use explicit 64-bit number parsing routines
>   BaseTools/CommonLib: add definition of MAX_UINT32
>   BaseTools/DevicePath: use MAX_UINT32 as default device path max size
>   BaseTools/CommonLib: get rid of 'native' type string parsing routines
>   BaseTools/CommonLib: drop definition of MAX_UINTN
>   BaseTools/CommonLib: drop the use of MAX_ADDRESS
>   Revert "MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits"
>   MdeModulePkg/FileExplorerLib: avoid packed struct for program data
>   BaseTools/tools_def AARCH64 RELEASE: move GCC49/GGC5 to 4 KB alignment
>   ArmVirtPkg/ArmVirtQemuKernel ARM: make some PCD settings apply to ARM
>   ArmVirtPkg/PrePiUniCoreRelocatable CLANG38: work around build issues
>   BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations
>   MdePkg/BaseMemoryLibOptDxe ARM: add missing function annotations
>   BaseTools/tools_def ARM CLANG35: work around -mno-movt option name 
> change
>   ArmVirtPkg/PrePi ARM CLANG35: drop incompatible command line option
>   ArmVirtPkg/ArmVirt.dsc.inc: define TcpIoLib resolution unconditionally
>   A

Re: [Qemu-devel] [PATCH v4 19/29] hw/arm: Express dependencies of the MPS2 boards with Kconfig

[Philippe Mathieu-Daudé]

Hi Thomas,

On 3/7/19 3:18 PM, Thomas Huth wrote:
> Add Kconfig dependencies for the mps2-an* machines.
> 
> Signed-off-by: Thomas Huth 
> ---
>  default-configs/arm-softmmu.mak | 20 +---
>  hw/arm/Kconfig  | 18 ++
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index b6f3d60..b8509fd 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -27,6 +27,7 @@ CONFIG_Z2=y
>  CONFIG_COLLIE=y
>  CONFIG_ASPEED_SOC=y
>  CONFIG_NETDUINO2=y
> +CONFIG_MPS2=y
>  
>  CONFIG_VGA=y
>  CONFIG_SSI_M25P80=y
> @@ -35,28 +36,9 @@ CONFIG_IMX_FEC=y
>  CONFIG_FRAMEBUFFER=y
>  
>  CONFIG_DIGIC=y
> -CONFIG_MPS2=y
>  CONFIG_RASPI=y
>  CONFIG_NRF51_SOC=y
>  
> -CONFIG_CMSDK_APB_TIMER=y
> -CONFIG_CMSDK_APB_DUALTIMER=y
> -CONFIG_CMSDK_APB_UART=y
> -CONFIG_CMSDK_APB_WATCHDOG=y
> -
> -CONFIG_MPS2_FPGAIO=y
> -CONFIG_MPS2_SCC=y
> -
> -CONFIG_TZ_MPC=y
> -CONFIG_TZ_MSC=y
> -CONFIG_TZ_PPC=y
> -CONFIG_ARMSSE=y
> -CONFIG_IOTKIT_SECCTL=y
> -CONFIG_IOTKIT_SYSCTL=y
> -CONFIG_IOTKIT_SYSINFO=y
> -CONFIG_ARMSSE_CPUID=y
> -CONFIG_ARMSSE_MHU=y
> -
>  CONFIG_FSL_IMX6=y
>  CONFIG_FSL_IMX25=y
>  CONFIG_FSL_IMX7=y
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 743c78b..32c8663 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -308,6 +308,13 @@ config ASPEED_SOC
>  
>  config MPS2
>  bool
> +select ARMSSE
> +select LAN9118
> +select MPS2_FPGAIO
> +select MPS2_SCC
> +select PL022# Serial port
> +select PL080# DMA controller
> +select TZ_MPC

Can we move TZ_MPC to ARMSSE?

>  config FSL_IMX7
>  bool
> @@ -347,6 +354,17 @@ config ARM11MPCORE
>  
>  config ARMSSE
>  bool
> +select ARMSSE_CPUID
> +select ARMSSE_MHU
> +select CMSDK_APB_TIMER
> +select CMSDK_APB_DUALTIMER
> +select CMSDK_APB_UART
> +select CMSDK_APB_WATCHDOG
> +select IOTKIT_SECCTL
> +select IOTKIT_SYSCTL
> +select IOTKIT_SYSINFO
> +select TZ_MSC
> +select TZ_PPC
>  
>  config ARMSSE_CPUID
>  bool
> 

Re: [Qemu-devel] [PATCH v4 03/29] hw/sd/sdhci: Move PCI-related code into a separate file

[Philippe Mathieu-Daudé]

On 3/7/19 3:18 PM, Thomas Huth wrote:
> Some machines have an SDHCI device, but no PCI. To be able to
> compile hw/sd/sdhci.c without CONFIG_PCI, we must not call functions
> like pci_get_address_space() and pci_allocate_irq() there. Thus
> move the PCI-related code into a separate file.
> 
> This is required for the new Kconfig-like build system, e.g. it is
> needed if a user wants to compile a QEMU binary with just one machine
> that has SDHCI, but no PCI, like the ARM "raspi" machines for example.
> 
> Signed-off-by: Thomas Huth 
> ---
>  hw/sd/Kconfig  |  6 +++-
>  hw/sd/Makefile.objs|  1 +
>  hw/sd/sdhci-internal.h | 34 ++
>  hw/sd/sdhci-pci.c  | 87 
>  hw/sd/sdhci.c  | 98 
> +++---
>  5 files changed, 132 insertions(+), 94 deletions(-)
>  create mode 100644 hw/sd/sdhci-pci.c
> 
> diff --git a/hw/sd/Kconfig b/hw/sd/Kconfig
> index 864f535..c5e1e55 100644
> --- a/hw/sd/Kconfig
> +++ b/hw/sd/Kconfig
> @@ -12,6 +12,10 @@ config SD
>  
>  config SDHCI
>  bool
> +select SD

Hmm this should be SDBUS. I'll clean that up later.

Reviewed-by: Philippe Mathieu-Daudé 

> +
> +config SDHCI_PCI
> +bool
>  default y if PCI_DEVICES
>  depends on PCI
> -select SD
> +select SDHCI
> diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
> index a99d9fb..0665727 100644
> --- a/hw/sd/Makefile.objs
> +++ b/hw/sd/Makefile.objs
> @@ -2,6 +2,7 @@ common-obj-$(CONFIG_PL181) += pl181.o
>  common-obj-$(CONFIG_SSI_SD) += ssi-sd.o
>  common-obj-$(CONFIG_SD) += sd.o core.o sdmmc-internal.o
>  common-obj-$(CONFIG_SDHCI) += sdhci.o
> +common-obj-$(CONFIG_SDHCI_PCI) += sdhci-pci.o
>  
>  obj-$(CONFIG_MILKYMIST) += milkymist-memcard.o
>  obj-$(CONFIG_OMAP) += omap_mmc.o
> diff --git a/hw/sd/sdhci-internal.h b/hw/sd/sdhci-internal.h
> index 19665fd..3414140 100644
> --- a/hw/sd/sdhci-internal.h
> +++ b/hw/sd/sdhci-internal.h
> @@ -304,4 +304,38 @@ extern const VMStateDescription sdhci_vmstate;
>  
>  #define ESDHC_PRNSTS_SDSTB  (1 << 3)
>  
> +/*
> + * Default SD/MMC host controller features information, which will be
> + * presented in CAPABILITIES register of generic SD host controller at reset.
> + *
> + * support:
> + * - 3.3v and 1.8v voltages
> + * - SDMA/ADMA1/ADMA2
> + * - high-speed
> + * max host controller R/W buffers size: 512B
> + * max clock frequency for SDclock: 52 MHz
> + * timeout clock frequency: 52 MHz
> + *
> + * does not support:
> + * - 3.0v voltage
> + * - 64-bit system bus
> + * - suspend/resume
> + */
> +#define SDHC_CAPAB_REG_DEFAULT 0x057834b4
> +
> +#define DEFINE_SDHCI_COMMON_PROPERTIES(_state) \
> +DEFINE_PROP_UINT8("sd-spec-version", _state, sd_spec_version, 2), \
> +DEFINE_PROP_UINT8("uhs", _state, uhs_mode, UHS_NOT_SUPPORTED), \
> +\
> +/* Capabilities registers provide information on supported
> + * features of this specific host controller implementation */ \
> +DEFINE_PROP_UINT64("capareg", _state, capareg, SDHC_CAPAB_REG_DEFAULT), \
> +DEFINE_PROP_UINT64("maxcurr", _state, maxcurr, 0)
> +
> +void sdhci_initfn(SDHCIState *s);
> +void sdhci_uninitfn(SDHCIState *s);
> +void sdhci_common_realize(SDHCIState *s, Error **errp);
> +void sdhci_common_unrealize(SDHCIState *s, Error **errp);
> +void sdhci_common_class_init(ObjectClass *klass, void *data);
> +
>  #endif
> diff --git a/hw/sd/sdhci-pci.c b/hw/sd/sdhci-pci.c
> new file mode 100644
> index 000..f884661
> --- /dev/null
> +++ b/hw/sd/sdhci-pci.c
> @@ -0,0 +1,87 @@
> +/*
> + * SDHCI device on PCI
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> + * See the GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "hw/hw.h"
> +#include "hw/sd/sdhci.h"
> +#include "sdhci-internal.h"
> +
> +static Property sdhci_pci_properties[] = {
> +DEFINE_SDHCI_COMMON_PROPERTIES(SDHCIState),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void sdhci_pci_realize(PCIDevice *dev, Error **errp)
> +{
> +SDHCIState *s = PCI_SDHCI(dev);
> +Error *local_err = NULL;
> +
> +sdhci_initfn(s);
> +sdhci_common_realize(s, &local_err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> +dev->config[PCI_CLASS_PROG] = 0x01; /* Standard Host supported DMA */
> +dev->config

Re: [Qemu-devel] [PATCH v5 0/2] arm/acpi: simplify aml code and enable SHPC

[Michael S. Tsirkin]

On Sat, Mar 09, 2019 at 10:30:47AM +0800, Heyi Guo wrote:
> After the introduction of generic PCIe root port and PCIe-PCI bridge, we will
> also have SHPC controller on ARM, and we don't support ACPI hot plug, so just
> enable SHPC native hot plug.
> 
> Igor also spotted the store operation outside of bit and/or is not necessary, 
> so
> simply the code at first.
> 
> v5:
> - Refine commit message of patch 1/2
> 
> v4:
> - Improve the code indention.
> 
> Cc: Shannon Zhao 
> Cc: Peter Maydell 
> Cc: "Michael S. Tsirkin" 
> Cc: Igor Mammedov 


Reviewed-by: Michael S. Tsirkin 

> 
> 
> Heyi Guo (2):
>   hw/arm/acpi: simplify AML bit and/or statement
>   hw/arm/acpi: enable SHPC native hot plug
> 
>  hw/arm/virt-acpi-build.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> -- 
> 1.8.3.1

Re: [Qemu-devel] [PATCH] hw/riscv/virt: re-add machine-specific compatible string to /soc/ node

[Auer, Lukas]

Hi Bin,

On Sun, 2019-03-10 at 22:57 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Sun, Mar 10, 2019 at 9:44 PM Auer, Lukas
>  wrote:
> > Hi Bin,
> > 
> > On Sun, 2019-03-10 at 09:07 +0800, Bin Meng wrote:
> > > Hi Lukas,
> > > 
> > > On Mon, Feb 11, 2019 at 6:13 AM Lukas Auer
> > >  wrote:
> > > > Re-add the previous compatible string "riscv-virtio-soc" to the
> > > > soc
> > > > device tree node to allow U-Boot and Linux to bind machine-
> > > > specific
> > > > drivers to it. The current compatible string "simple-bus" is
> > > > retained.
> > > > 
> > > > This is required by U-Boot to bind devices early, as part of
> > > > the
> > > > pre-relocation driver model.
> > > > 
> > > 
> > > I see no problem with U-Boot working with current compatible
> > > string
> > > "simple-bus". In fact I had planned to remove the compatible
> > > string
> > > "riscv-virtio-soc" in U-Boot but did not get time to work on it.
> > > 
> > 
> > It is only required if U-Boot is running in machine-mode. For
> > relocation it needs to use the CLINT driver to send appropriate
> > IPIs to
> > the other harts. To be able to probe the driver, the device and its
> > parent device tree node (soc) must therefore be available in the
> > pre-
> > relocation device model.
> > This patch was the easiest way I could think of for achieving this.
> > It
> > could be that there is a better way of solving this.
> > 
> 
> I tested your SMP U-Boot series in both M-mode and S-mode, using a 4
> core 'virt' target. Works fine. I am using QEMU 3.1.0 so it is
> "simple-bus".
> 

That is actually my fault, it should not work.
What is happening is that U-Boot fails to relocate the secondary harts,
because the CLINT driver cannot get the memory address of the CLINT
device. This error is currently silently ignored.
The secondary harts are still waiting to receive IPIs, so booting Linux
works fine, because U-Boot can now send IPIs. This will however break
if U-Boot overwrites the code the secondary harts are running, which
could happen when loading an image.

I will update my SMP U-Boot series to print a warning if sending an IPI
fails.

Thanks,
Lukas

Re: [Qemu-devel] [PATCH 01/10] roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 3/10/19 4:17 PM, Philippe Mathieu-Daudé wrote:
> On 3/9/19 1:48 AM, Laszlo Ersek wrote:
>> Extract the dense logic for architecture and toolchain massaging from
>> "tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
>> these functions for building full platform firmware images.
>>
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  roms/edk2-funcs.sh | 240 
>>  tests/uefi-test-tools/build.sh |  97 +---
>>  2 files changed, 246 insertions(+), 91 deletions(-)
>>
>> diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
>> new file mode 100644
>> index ..908c7665c6ed
>> --- /dev/null
>> +++ b/roms/edk2-funcs.sh
>> @@ -0,0 +1,240 @@
>> +# Shell script that defines functions for determining some environmental
>> +# characteristics for the edk2 "build" utility.
>> +#
>> +# This script is meant to be sourced.
>> +#
>> +# Copyright (C) 2019, Red Hat, Inc.
>> +#
>> +# This program and the accompanying materials are licensed and made 
>> available
>> +# under the terms and conditions of the BSD License that accompanies this
>> +# distribution. The full text of the license may be found at
>> +# .
>> +#
>> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
>> WITHOUT
>> +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>> +
>> +
>> +# Verify whether the QEMU system emulation target is supported by the UEFI 
>> spec
>> +# and edk2. Print a message to the standard error, and return with nonzero
>> +# status, if verification fails.
>> +#
>> +# Parameters:
>> +#   $1: QEMU system emulation target
>> +qemu_edk2_verify_arch()
>> +{
>> +  local emulation_target="$1"
>> +  local program_name=$(basename -- "$0")
>> +
>> +  case "$emulation_target" in
>> +(arm|aarch64|i386|x86_64)
>> +  ;;
>> +(*)
>> +  printf '%s: unknown/unsupported QEMU system emulation target "%s"\n' \
>> +"$program_name" "$emulation_target" >&2
>> +  return 1
>> +  ;;
>> +  esac
>> +}
>> +
>> +
>> +# Translate the QEMU system emulation target to the edk2 architecture
>> +# identifier. Print the result to the standard output.
>> +#
>> +# Parameters:
>> +#   $1: QEMU system emulation target
>> +qemu_edk2_get_arch()
>> +{
>> +  local emulation_target="$1"
>> +
>> +  if ! qemu_edk2_verify_arch "$emulation_target"; then
>> +return 1
>> +  fi
>> +
>> +  case "$emulation_target" in
>> +(arm)
>> +  printf 'ARM\n'
>> +  ;;
>> +(aarch64)
>> +  printf 'AARCH64\n'
>> +  ;;
>> +(i386)
>> +  printf 'IA32\n'
>> +  ;;
>> +(x86_64)
>> +  printf 'X64\n'
>> +  ;;
>> +  esac
>> +}
>> +
>> +
>> +# Translate the QEMU system emulation target to the gcc cross-compilation
>> +# architecture identifier. Print the result to the standard output.
>> +#
>> +# Parameters:
>> +#   $1: QEMU system emulation target
>> +qemu_edk2_get_gcc_arch()
>> +{
>> +  local emulation_target="$1"
>> +
>> +  if ! qemu_edk2_verify_arch "$emulation_target"; then
>> +return 1
>> +  fi
>> +
>> +  case "$emulation_target" in
>> +(arm|aarch64|x86_64)
>> +  printf '%s\n' "$emulation_target"
>> +  ;;
>> +(i386)
>> +  printf 'i686\n'
>> +  ;;
>> +  esac
>> +}
>> +
>> +
>> +# Determine the gcc cross-compiler prefix (if any) for use with the edk2
>> +# toolchain. Print the result to the standard output.
>> +#
>> +# Parameters:
>> +#   $1: QEMU system emulation target
>> +qemu_edk2_get_cross_prefix()
>> +{
>> +  local emulation_target="$1"
>> +  local gcc_arch
>> +  local host_arch
>> +
>> +  if ! gcc_arch=$(qemu_edk2_get_gcc_arch "$emulation_target"); then
>> +return 1
>> +  fi
>> +
>> +  host_arch=$(uname -m)
>> +
>> +  if [ "$gcc_arch" == "$host_arch" ] ||
>> + ( [ "$gcc_arch" == i686 ] && [ "$host_arch" == x86_64 ] ); then
>> +# no cross-compiler needed
>> +:
>> +  else
>> +printf '%s-linux-gnu-\n' "$gcc_arch"

Testing on Ubuntu (bionic), the gcc-arm-linux-gnueabihf provides the
arm-linux-gnueabihf-gcc binary, therefore I use:

GCC5_ARM_PREFIX="arm-linux-gnueabihf-" make -C roms efi

But this function enforce cross prefix to be arm-linux-gnu- :(

I tried with the following Linaro toolchains:

gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf.tar.xz
gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf.tar.xz
gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz

With the distrib toolchain or the Linaro enumerated, I get:

/bin/sh: 1: arm-linux-gnu-gcc: not found

>> +  fi
>> +}
>> +
>> +
>> +# Determine the edk2 toolchain tag for the QEMU system emulation target. 
>> Print
>> +# the result to the standard output. Print a message to the standard error, 
>> and
>> +# return with nonzero status, if the (conditional) gcc version check fails.
>> +#
>> +# Parameters:
>> +#   $1: QEMU system emulation target
>> +qemu_edk2_get_toolchain()
>> +{
>> +  local emulation_target="$1"
>> +  local program_name=$(basename -- "$0

Re: [Qemu-devel] [PATCH v3 10/10] qemu-binfmt-conf.sh: support QEMU_TARGETS

[Laurent Vivier]

On 06/03/2019 05:55, Unai Martinez-Corral wrote:
> Rename CPUS to TARGETS, and support QEMU_TARGETS environment variable.
> This does not break backward compatibility, because it is just a placeholder.
> 
> Consistently with 'path', 'suffix', 'persistent' and 'credential',
> provide an environment variable to set the list of target architectures.
> The supported formats are the same as for positional arguments, which have
> priority. If both the variable and the list of positional arguments are empty,
> defaults to 'ALL'.
> 
> Signed-off-by: Unai Martinez-Corral 
> ---
>  scripts/qemu-binfmt-conf.sh | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index 8ca2647ed0..0676f86512 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -6,7 +6,7 @@ mips mipsel mipsn32 mipsn32el mips64 mips64el \
>  sh4 sh4eb s390x aarch64 aarch64_be hppa riscv32 riscv64 xtensa xtensaeb \
>  microblaze microblazeel or1k x86_64"
> 
> -# check if given target CPUS is/are in the supported target list
> +# check if given TARGETS is/are in the supported target list
>  qemu_check_target_list() {
>  all="$qemu_target_list"
>  if [ "x$1" = "xALL" ] ; then
> @@ -199,12 +199,12 @@ usage() {
>  cat <  Usage: qemu-binfmt-conf.sh [--help][--path PATH][--suffix SUFFIX]
> [--persistent][--credential][--exportdir PATH]
> -   [--reset ARCHS][--systemd][--debian][CPUS]
> +   [--reset ARCHS][--systemd][--debian][TARGETS]
> 
> -Configure binfmt_misc to use qemu interpreter for the given CPUS.
> -Supported formats for CPUS are: single arch or comma/space separated 
> list.
> -See QEMU target list below. If CPUS is 'ALL' or empty, configure all 
> known
> -cpus. If CPUS is 'NONE', no interpreter is configured.
> +Configure binfmt_misc to use qemu interpreter for the given TARGETS.
> +Supported formats for TARGETS are: single arch or comma/space separated 
> list.
> +See QEMU target list below. If TARGETS is 'ALL' or empty, configure all 
> known
> +TARGETS. If TARGETS is 'NONE', no interpreter is configured.
> 
>  --help:display this usage.
>  --path:set path to qemu interpreter.
> @@ -244,6 +244,7 @@ Usage: qemu-binfmt-conf.sh [--help][--path PATH][--suffix 
> SUFFIX]
>QEMU_SUFFIX=
>QEMU_PERSISTENT=no
>QEMU_CREDENTIAL=no
> +  QEMU_TARGETS=

 QEMU_TARGETS=$QEMU_TARGETS

> 
>  EOF
>  }
> @@ -324,17 +325,17 @@ EOF
>  }
> 
>  qemu_set_binfmts() {
> -if [ "x$1" = "xNONE" ] ; then
> -  return
> -fi
> -
>  # probe cpu type
>  host_family=$(qemu_get_family)
> 
>  # reduce the list of target interpreters to those given in the CLI
> -targets="$@"
>  if [ $# -eq 0 ] ; then
> -  targets="ALL"
> +  targets="${QEMU_TARGETS:-ALL}"
> +else
> +  if [ "x$1" = "xNONE" ] ; then

In fact, I think it would be cleaner to have a "--dry-run" option
instead (something setting BINFMT_SET to ':' I think)

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v3 9/10] qemu-binfmt-conf.sh: update usage()

[Laurent Vivier]

On 06/03/2019 05:54, Unai Martinez-Corral wrote:
> Reduce indentation to better use available space.
> 
> Add list of supported environment variables and their default values.
> 
> Signed-off-by: Unai Martinez-Corral 
> ---
>  scripts/qemu-binfmt-conf.sh | 61 -
>  1 file changed, 33 insertions(+), 28 deletions(-)
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index 4a45636b53..8ca2647ed0 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -201,34 +201,31 @@ Usage: qemu-binfmt-conf.sh [--help][--path 
> PATH][--suffix SUFFIX]
> [--persistent][--credential][--exportdir PATH]
> [--reset ARCHS][--systemd][--debian][CPUS]
> 
> -   Configure binfmt_misc to use qemu interpreter for the given CPUS.
> -   Supported formats for CPUS are: single arch or comma/space separated 
> list.
> -   See QEMU target list below. If CPUS is 'ALL' or empty, configure all 
> known
> -   cpus. If CPUS is 'NONE', no interpreter is configured.
> +Configure binfmt_misc to use qemu interpreter for the given CPUS.
> +Supported formats for CPUS are: single arch or comma/space separated 
> list.
> +See QEMU target list below. If CPUS is 'ALL' or empty, configure all 
> known
> +cpus. If CPUS is 'NONE', no interpreter is configured.
> 
> -   --help:display this usage
> -   --path:set path to qemu interpreter ($QEMU_PATH)
> -   --suffix:  add a suffix to the default interpreter name
> -  ($QEMU_SUFFIX)
> -   --persistent:  if present, the interpreter is loaded when binfmt is
> -  configured and remains in memory. All future uses
> -  are cloned from the open file.
> -  ($QEMU_PERSISTENT=yes)
> -   --credential:  if present, credential and security tokens are
> -  calculated according to the binary to interpret
> -  ($QEMU_CREDENTIAL=yes)
> -   --exportdir:   define where to write configuration files
> -  (default: $SYSTEMDDIR or $DEBIANDIR)
> -   --reset:   remove registered interpreter for target ARCHS (comma
> -  separated list). If ARCHS is 'ALL', remove all 
> registered
> -  'qemu-*' interpreters.
> -   --systemd: don't write into /proc,
> -  instead generate file for systemd-binfmt.service;
> -  environment variable HOST_ARCH allows to override 
> 'uname'
> -  to generate configuration files for a different
> -  architecture than the current one.
> -   --debian:  don't write into /proc,
> -  instead generate update-binfmts templates
> +--help:display this usage.
> +--path:set path to qemu interpreter.
> +--suffix:  add a suffix to the default interpreter name.
> +--persistent:  if present, the interpreter is loaded when binfmt is
> +   configured and remains in memory. All future uses
> +   are cloned from the open file.
> +--credential:  if present, credential and security tokens are
> +   calculated according to the binary to interpret.
> +--exportdir:   define where to write configuration files.
> +   (default: $SYSTEMDDIR or $DEBIANDIR)
> +--reset:   remove registered interpreter for target ARCHS (comma
> +   separated list). If ARCHS is 'ALL', remove all registered
> +   'qemu-*' interpreters.
> +--systemd: don't write into /proc,
> +   instead generate file(s) for systemd-binfmt.service;
> +   environment variable HOST_ARCH allows to override 'uname'
> +   to generate configuration files for a different
> +   architecture than the current one.
> +--debian:  don't write into /proc,
> +   instead generate update-binfmts templates.
> 
>  To import templates with update-binfmts, use :
> 
> @@ -240,6 +237,14 @@ Usage: qemu-binfmt-conf.sh [--help][--path 
> PATH][--suffix SUFFIX]
> 
>  QEMU target list: $qemu_target_list
> 
> +Options 'path, 'suffix', 'persistent' and 'credential' are also supported
> +through environment variables. Defaults are:
> +
> +  QEMU_PATH=/usr/local/bin

You can write

QEMU_PATH=$QEMU_PATH

to have the actual value.

> +  QEMU_SUFFIX=
> +  QEMU_PERSISTENT=no
> +  QEMU_CREDENTIAL=no

and
 QEMU_SUFFIX=$QEMU_SUFFIX
 QEMU_PERSISTENT=$QEMU_PERSISTENT
 QEMU_CREDENTIAL=$QEMU_CREDENTIAL=

> +
>  EOF
>  }
> 
> @@ -384,8 +389,8 @@ DEBIANDIR="/usr/share/binfmts"
> 
>  QEMU_PATH="${QEMU_PATH:-/usr/local/bin}"
>  QEMU_SUFFIX="${QEMU_SUFFIX:-}"
> -QEMU_CREDENTIAL="${QEMU_CREDENTIAL:-no}"
>  QEMU_

Re: [Qemu-devel] [PATCH v3 8/10] qemu-binfmt-conf.sh: refactor usage()

[Laurent Vivier]

On 06/03/2019 05:53, Unai Martinez-Corral wrote:
> Reorder how the options are presented to the user. Move 'systemd'
> and 'debian' to the end, so that the latter is close to the additional
> comments and example commands about it. Make the order in the prototype
> consistent with the list where each option is explained.
> 
> Signed-off-by: Unai Martinez-Corral 
> ---
>  scripts/qemu-binfmt-conf.sh | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index 824e3c4c34..4a45636b53 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -197,9 +197,9 @@ qemu_get_family() {
> 
>  usage() {
>  cat < -Usage: qemu-binfmt-conf.sh [--help][--path PATH][--debian][--systemd]
> -   [--reset ARCHS][--credential][--exportdir PATH]
> -   [--persistent][--suffix SUFFIX][CPUS]
> +Usage: qemu-binfmt-conf.sh [--help][--path PATH][--suffix SUFFIX]
> +   [--persistent][--credential][--exportdir PATH]
> +   [--reset ARCHS][--systemd][--debian][CPUS]
> 
> Configure binfmt_misc to use qemu interpreter for the given CPUS.
> Supported formats for CPUS are: single arch or comma/space separated 
> list.
> @@ -210,25 +210,25 @@ Usage: qemu-binfmt-conf.sh [--help][--path 
> PATH][--debian][--systemd]
> --path:set path to qemu interpreter ($QEMU_PATH)
> --suffix:  add a suffix to the default interpreter name
>($QEMU_SUFFIX)
> -   --debian:  don't write into /proc,
> -  instead generate update-binfmts templates
> -   --systemd: don't write into /proc,
> -  instead generate file for systemd-binfmt.service;
> -  environment variable HOST_ARCH allows to override 
> 'uname'
> -  to generate configuration files for a different
> -  architecture than the current one.
> +   --persistent:  if present, the interpreter is loaded when binfmt is
> +  configured and remains in memory. All future uses
> +  are cloned from the open file.
> +  ($QEMU_PERSISTENT=yes)
> +   --credential:  if present, credential and security tokens are
> +  calculated according to the binary to interpret
> +  ($QEMU_CREDENTIAL=yes)
> --exportdir:   define where to write configuration files
>(default: $SYSTEMDDIR or $DEBIANDIR)
> --reset:   remove registered interpreter for target ARCHS (comma
>separated list). If ARCHS is 'ALL', remove all 
> registered
>'qemu-*' interpreters.
> -   --credential:  if present, credential and security tokens are
> -  calculated according to the binary to interpret
> -  ($QEMU_CREDENTIAL=yes)
> -   --persistent:  if present, the interpreter is loaded when binfmt is
> -  configured and remains in memory. All future uses
> -  are cloned from the open file.
> -  ($QEMU_PERSISTENT=yes)
> +   --systemd: don't write into /proc,
> +  instead generate file for systemd-binfmt.service;
> +  environment variable HOST_ARCH allows to override 
> 'uname'
> +  to generate configuration files for a different
> +  architecture than the current one.
> +   --debian:  don't write into /proc,
> +  instead generate update-binfmts templates
> 
>  To import templates with update-binfmts, use :
> 

Please, use the same presentation format as for qemu-XXX ("Argument
   Env-variable  Description")

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v3 7/10] qemu-binfmt-conf.sh: add option --reset

[Laurent Vivier]

On 06/03/2019 05:52, Unai Martinez-Corral wrote:
> This is a partial implementation.
> 
> Allows to remove a single or a list of already registered binfmt
> interpreters. If  is a list, it must be comma-separated.

I think ARCHS and CPUS are the same thing, so use the same word.

> Valid values are those in qemu_target_list. If  is 'ALL', all
> the existing 'qemu-*' interpreters are removed.
> 
> This is partial because 'debian' and 'systemd' configurations are not
> removed. If option 'reset' is provided before any of those, reset is
> executed first and the configuration proceeds. However, if 'reset' is
> provided after any of them, the script will exit with error 'option
> reset not implemented for this mode yet'.
> 
> Removal is done by printing '-1' as explained at:
> https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst
> 
> Signed-off-by: Unai Martinez-Corral 
> ---
>  scripts/qemu-binfmt-conf.sh | 36 +---
>  1 file changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index 2751363089..824e3c4c34 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -197,8 +197,8 @@ qemu_get_family() {
> 
>  usage() {
>  cat < -Usage: qemu-binfmt-conf.sh [--path PATH][--debian][--systemd]
> -   [--help][--credential][--exportdir PATH]
> +Usage: qemu-binfmt-conf.sh [--help][--path PATH][--debian][--systemd]
> +   [--reset ARCHS][--credential][--exportdir PATH]
> [--persistent][--suffix SUFFIX][CPUS]

I don't like the idea of being able to set and reset different
interpretes with same command line call.

Make "--reset" exclusive without parameter to be able to use the common
cpu list at the end of the command line (this way, I think you would be
able to share more common code between setting an resetting).

You could have a look to Alex Bennée's patch:

  https://patchwork.ozlabs.org/patch/938796/

I think this is the good way to do this and it should merge easily with
your series.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v3 6/10] qemu-binfmt-conf.sh: generalize to positional

[Laurent Vivier]

On 06/03/2019 05:50, Unai Martinez-Corral wrote:
> This breaks brackward compatibility.
> 
> Option '--systemd CPU' allows to register binfmt interpreters for a
> single target architecture or for 'ALL' (of them). This patch
> generalizes the approach to support it in any mode (default, '--debian'
> or '--systemd'). To do so, option 'systemd' is changed to be boolean
> (no args). Then, all the positional arguments are considered to be a
> list of target architectures.
> 
> The list can be separated by spaces, tabs, newlines or commas. If no

I think it would be simpler to not manage commas, and to use the default
field separator.

> positional argument is provided, or when it is 'ALL', all of the
> architectures in qemu_target_list are registered.
> 
> Conversely, argument value 'NONE' allows to make a 'dry run' of the
> script. I.e., checks are executed according to the mode, but no
> interpreter is registered.
> 
> Signed-off-by: Unai Martinez-Corral 
> ---
>  scripts/qemu-binfmt-conf.sh | 92 +++--
>  1 file changed, 57 insertions(+), 35 deletions(-)
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index c113ff131e..2751363089 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -6,6 +6,36 @@ mips mipsel mipsn32 mipsn32el mips64 mips64el \
>  sh4 sh4eb s390x aarch64 aarch64_be hppa riscv32 riscv64 xtensa xtensaeb \
>  microblaze microblazeel or1k x86_64"
> 
> +# check if given target CPUS is/are in the supported target list
> +qemu_check_target_list() {
> +all="$qemu_target_list"

Why do you need to introduce a new variable "all", you can use directly
"qemu_target_list".

> +if [ "x$1" = "xALL" ] ; then
> +  checked_target_list="$all"
> +  return
> +fi
> +list=""

No need to introduce a new variable, you can use directly
checked_target_list

> +bIFS="$IFS"
> +IFS=$"$IFS",

Keep it simple, don't manage comma.

> +for target ; do
> +unknown_target="true"
> +for cpu in $all ; do

Use directly "qemu_target_list"

> +if [ "x$cpu" = "x$target" ] ; then
> +list="$list $target"
> +unknown_target="false"
> +break
> +fi
> +done
> +if [ "$unknown_target" = "true" ] ; then

You don't need a new variable, you can check "x$cpu" = "x$target" to
know if you have found the target.

> +IFS="$bIFS"
> +echo "ERROR: unknown CPU \"$target\"" 1>&2
> +usage
> +exit 1
> +fi
> +done
> +IFS="$bIFS"
> +checked_target_list="$list"
> +}
> +
>  
> i386_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00'
>  
> i386_mask='\xff\xff\xff\xff\xff\xfe\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
>  i386_family=i386
> @@ -167,11 +197,14 @@ qemu_get_family() {
> 
>  usage() {
>  cat < -Usage: qemu-binfmt-conf.sh [--path PATH][--debian][--systemd CPU]
> +Usage: qemu-binfmt-conf.sh [--path PATH][--debian][--systemd]
> [--help][--credential][--exportdir PATH]
> -   [--persistent][--suffix SUFFIX]
> +   [--persistent][--suffix SUFFIX][CPUS]
> 
> -   Configure binfmt_misc to use qemu interpreter
> +   Configure binfmt_misc to use qemu interpreter for the given CPUS.
> +   Supported formats for CPUS are: single arch or comma/space separated 
> list.
> +   See QEMU target list below. If CPUS is 'ALL' or empty, configure all 
> known
> +   cpus. If CPUS is 'NONE', no interpreter is configured.
> 
> --help:display this usage
> --path:set path to qemu interpreter ($QEMU_PATH)
> @@ -180,9 +213,10 @@ Usage: qemu-binfmt-conf.sh [--path 
> PATH][--debian][--systemd CPU]
> --debian:  don't write into /proc,
>instead generate update-binfmts templates
> --systemd: don't write into /proc,
> -  instead generate file for systemd-binfmt.service
> -  for the given CPU. If CPU is "ALL", generate a
> -  file for all known cpus
> +  instead generate file for systemd-binfmt.service;
> +  environment variable HOST_ARCH allows to override 
> 'uname'
> +  to generate configuration files for a different
> +  architecture than the current one.
> --exportdir:   define where to write configuration files
>(default: $SYSTEMDDIR or $DEBIANDIR)
> --credential:  if present, credential and security tokens are
> @@ -201,14 +235,7 @@ Usage: qemu-binfmt-conf.sh [--path 
> PATH][--debian][--systemd CPU]
> 
>  sudo update-binfmts --package qemu-CPU --remove qemu-CPU $QEMU_PATH
> 
> -With systemd, binfmt files are loaded by systemd-binfmt.service
> -
> -The environment variable HOST_AR

Re: [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with persistent bitmaps

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190305234337.18353-1-js...@redhat.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  crypto/tlssession.o
  CC  crypto/secret.o
/tmp/qemu-test/src/block/qcow2-bitmap.c: In function 
'qcow2_truncate_bitmaps_check':
/tmp/qemu-test/src/block/qcow2-bitmap.c:1198:13: error: implicit declaration of 
function 'bdrv_dirty_bitmap_check'; did you mean 'bdrv_dirty_bitmap_lock'? 
[-Werror=implicit-function-declaration]
 if (bdrv_dirty_bitmap_check(bitmap, BDRV_BITMAP_DEFAULT, errp)) {
 ^~~
 bdrv_dirty_bitmap_lock
/tmp/qemu-test/src/block/qcow2-bitmap.c:1198:13: error: nested extern 
declaration of 'bdrv_dirty_bitmap_check' [-Werror=nested-externs]
/tmp/qemu-test/src/block/qcow2-bitmap.c:1198:45: error: 'BDRV_BITMAP_DEFAULT' 
undeclared (first use in this function); did you mean 'DM_OUT_DEFAULT'?
 if (bdrv_dirty_bitmap_check(bitmap, BDRV_BITMAP_DEFAULT, errp)) {
 ^~~
 DM_OUT_DEFAULT


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

Re: [Qemu-devel] converting build system to Meson?

[Markus Armbruster]

Cleber Rosa  writes:

> On Thu, Mar 07, 2019 at 01:09:52PM +, Peter Maydell wrote:
>> On Thu, 7 Mar 2019 at 12:56, Paolo Bonzini  wrote:
>> > In any case, this wouldn't change; as you suggest below, configure could
>> > remain as a front-end (well, in-srcdir builds are not supported by
>> > Meson, so "../configure && ninja" perhaps).
>> 
>> As an aside, it might be a nice idea to drop the in-srcdir
>> build altogether for QEMU anyway -- it's not really a very
>> good idea and it means our build system has to cope with two
>> different ways of working to no particularly useful end.
>>
>
> THIS.  Please.

Seconded.

If nothing beyond abandoning in-tree builds should come out of this
thread, it will have been totally worth it for me.

Re: [Qemu-devel] converting build system to Meson?

[Markus Armbruster]

Paolo Bonzini  writes:

> Hi all,
>
> lately I have been thinking of converting the QEMU build system to
> Meson.  Meson is a relatively new build system that can replace
> Autotools or hand-written Makefiles such as QEMU; as a die-hard
> Autotools fan, I must say that Meson is by far better than anything else
> that has ever tried to replace Autotools, and actually has the potential
> to do so.
>
> Advantages of Meson that directly matter for QEMU include:
[...]
> - ease of distributing a full copy of Meson to support distros that ship
> an older version (no dependencies apart from Python 3.5).  At 4
> lines of Python, Meson is relatively small.

Meson is licensed under the Apache 2 license.  QEMU as a whole is
licensed under GPLv2 (and no later versions).  From
:

This is a free software license, compatible with version 3 of the
GNU GPL.

Please note that this license is not compatible with GPL version 2,
because it has some requirements that are not in that GPL version.
These include certain patent termination and indemnification
provisions.  The patent termination provision is a good thing, which
is why we recommend the Apache 2.0 license for substantial programs
over other lax permissive licenses.

Can we distribute Meson along with QEMU anyway?

[...]

Re: [Qemu-devel] [PATCH v2] linux-user: Add missing IPV6 sockopts

[Laurent Vivier]

On 10/03/2019 12:12, Helge Deller wrote:
> When running ssh over IPv6 with linux-user I faced this warning:
>  Unsupported setsockopt level=41 optname=67
>  setsockopt IPV6_TCLASS 32: Protocol not available:
> 
> This patch adds code to the linux-user emulatation for setting and
> retrieving of a few missing IPV6 options, including IPV6_TCLASS.
> 
> Signed-off-by: Helge Deller 
> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 208fd1813d..0da51b1208 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -1871,6 +1874,20 @@ static abi_long do_setsockopt(int sockfd, int level, 
> int optname,
>  case IPV6_RECVHOPLIMIT:
>  case IPV6_2292HOPLIMIT:
>  case IPV6_CHECKSUM:
> +case IPV6_ADDRFORM:
> +case IPV6_2292PKTINFO:
> +case IPV6_RECVTCLASS:
> +case IPV6_RECVRTHDR:
> +case IPV6_2292RTHDR:
> +case IPV6_RECVHOPOPTS:
> +case IPV6_2292HOPOPTS:
> +case IPV6_RECVDSTOPTS:
> +case IPV6_2292DSTOPTS:
> +case IPV6_TCLASS:
> +case IPV6_RECVPATHMTU:
> +case IPV6_TRANSPARENT:
> +case IPV6_FREEBIND:
> +case IPV6_RECVORIGDSTADDR:
>  val = 0;
>  if (optlen < sizeof(uint32_t)) {
>  return -TARGET_EINVAL;
> @@ -2365,6 +2382,20 @@ static abi_long do_getsockopt(int sockfd, int level, 
> int optname,
>  case IPV6_RECVHOPLIMIT:
>  case IPV6_2292HOPLIMIT:
>  case IPV6_CHECKSUM:
> +case IPV6_ADDRFORM:
> +case IPV6_2292PKTINFO:
> +case IPV6_RECVTCLASS:
> +case IPV6_RECVRTHDR:
> +case IPV6_2292RTHDR:
> +case IPV6_RECVHOPOPTS:
> +case IPV6_2292HOPOPTS:
> +case IPV6_RECVDSTOPTS:
> +case IPV6_2292DSTOPTS:
> +case IPV6_TCLASS:
> +case IPV6_RECVPATHMTU:
> +case IPV6_TRANSPARENT:
> +case IPV6_FREEBIND:
> +case IPV6_RECVORIGDSTADDR:
>  if (get_user_u32(len, optlen))
>  return -TARGET_EFAULT;
>  if (len < 0)
> 

Applied to my linux-user branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2] linux-user: Add missing IPV6 sockopts

[Laurent Vivier]

On 10/03/2019 12:12, Helge Deller wrote:
> When running ssh over IPv6 with linux-user I faced this warning:
>  Unsupported setsockopt level=41 optname=67
>  setsockopt IPV6_TCLASS 32: Protocol not available:
> 
> This patch adds code to the linux-user emulatation for setting and
> retrieving of a few missing IPV6 options, including IPV6_TCLASS.
> 
> Signed-off-by: Helge Deller 
> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 208fd1813d..0da51b1208 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -1871,6 +1874,20 @@ static abi_long do_setsockopt(int sockfd, int level, 
> int optname,
>  case IPV6_RECVHOPLIMIT:
>  case IPV6_2292HOPLIMIT:
>  case IPV6_CHECKSUM:
> +case IPV6_ADDRFORM:
> +case IPV6_2292PKTINFO:
> +case IPV6_RECVTCLASS:
> +case IPV6_RECVRTHDR:
> +case IPV6_2292RTHDR:
> +case IPV6_RECVHOPOPTS:
> +case IPV6_2292HOPOPTS:
> +case IPV6_RECVDSTOPTS:
> +case IPV6_2292DSTOPTS:
> +case IPV6_TCLASS:
> +case IPV6_RECVPATHMTU:
> +case IPV6_TRANSPARENT:
> +case IPV6_FREEBIND:
> +case IPV6_RECVORIGDSTADDR:
>  val = 0;
>  if (optlen < sizeof(uint32_t)) {
>  return -TARGET_EINVAL;
> @@ -2365,6 +2382,20 @@ static abi_long do_getsockopt(int sockfd, int level, 
> int optname,
>  case IPV6_RECVHOPLIMIT:
>  case IPV6_2292HOPLIMIT:
>  case IPV6_CHECKSUM:
> +case IPV6_ADDRFORM:
> +case IPV6_2292PKTINFO:
> +case IPV6_RECVTCLASS:
> +case IPV6_RECVRTHDR:
> +case IPV6_2292RTHDR:
> +case IPV6_RECVHOPOPTS:
> +case IPV6_2292HOPOPTS:
> +case IPV6_RECVDSTOPTS:
> +case IPV6_2292DSTOPTS:
> +case IPV6_TCLASS:
> +case IPV6_RECVPATHMTU:
> +case IPV6_TRANSPARENT:
> +case IPV6_FREEBIND:
> +case IPV6_RECVORIGDSTADDR:
>  if (get_user_u32(len, optlen))
>  return -TARGET_EFAULT;
>  if (len < 0)
> 

Reviewed-by: Laurent Vivier 

[Qemu-devel] [PATCH] tests: test-qgraph: fix a memory leak

[Li Qiang]

Spotted by ASAN when 'make check'.

Signed-off-by: Li Qiang 
---
 tests/test-qgraph.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/test-qgraph.c b/tests/test-qgraph.c
index f6a6565e31..5c7e457075 100644
--- a/tests/test-qgraph.c
+++ b/tests/test-qgraph.c
@@ -122,7 +122,7 @@ static void check_driver(const char *driver)
 static void check_test(const char *test, const char *interface)
 {
 QOSGraphEdge *edge;
-const char *full_name = g_strdup_printf("%s-tests/%s", interface, test);
+char *full_name = g_strdup_printf("%s-tests/%s", interface, test);
 
 qos_add_test(test, interface, testfunct, NULL);
 g_assert_cmpint(qos_graph_has_machine(test), ==, FALSE);
@@ -138,6 +138,7 @@ static void check_test(const char *test, const char 
*interface)
 g_assert_cmpint(qos_graph_get_node_availability(full_name), ==, TRUE);
 qos_graph_node_set_availability(full_name, FALSE);
 g_assert_cmpint(qos_graph_get_node_availability(full_name), ==, FALSE);
+g_free(full_name);
 }
 
 static void count_each_test(QOSGraphNode *path, int len)
-- 
2.17.1

Re: [Qemu-devel] [PULL 00/60] ppc-for-4.0 queue 20190310

[Peter Maydell]

On Sun, 10 Mar 2019 at 08:27, David Gibson  wrote:
>
> The following changes since commit f5b4c31030f45293bb4517445722768434829d91:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2019-03-09 17:35:48 +)
>
> are available in the Git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-4.0-20190310
>
> for you to fetch changes up to 08d020471fcd41cb020fc9987ed1945eefcc8805:
>
>   spapr: Use CamelCase properly (2019-03-10 14:35:44 +1100)
>
> 
> ppc patch queue for 2019-03-10
>
> Here's a final pull request before the 4.0 soft freeze.  Changes
> include:
>   * A Great Renaming to use camel case properly in spapr code
>   * Optimization of some vector instructions
>   * Support for POWER9 cpus in the powernv machine
>   * Fixes a regression from the last pull request in handling VSX
> instructions with mixed operands from the FPR and VMX parts of the
> register array
>   * Optimization hack to avoid scanning all the (empty) entries on a
> new IOMMU window
>   * Add FSL I2C controller model for E500
>   * Support for KVM acceleration of the H_PAGE_INIT hypercall on spapr
>   * Update u-boot image for E500
>   * Enable Specre/Meltdown mitigations by default on the new machine type
>   * Enable large decrementer support for POWER9
>
> Plus a number of assorted bugfixes and cleanups.
>

Hi. This pullreq generates a pile of new 'warning' messages
during 'make check':

MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64
QTEST_QEMU_IMG=qemu-img tests/
boot-serial-test -m=quick -k --tap < /dev/null |
./scripts/tap-driver.pl --test-name="boot-serial-test"
PASS 1 boot-serial-test /ppc64/boot-serial/ppce500
PASS 2 boot-serial-test /ppc64/boot-serial/40p
PASS 3 boot-serial-test /ppc64/boot-serial/mac99
qemu-system-ppc64: warning: TCG doesn't support requested feature,
cap-cfpc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature,
cap-sbbc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature,
cap-ibs=workaround
PASS 4 boot-serial-test /ppc64/boot-serial/pseries
PASS 5 boot-serial-test /ppc64/boot-serial/powernv
PASS 6 boot-serial-test /ppc64/boot-serial/sam460ex

and similarly during the boot-pxe-test.

Could you silence these, please?

thanks
-- PMM

[Qemu-devel] [Bug 1371915] Re: Make Uninstall Rule Requested

[Deepika Choudhary]

Can ubuntu 14.04 support the "checkinstall" program?
If yes, then can we use the checkinstall program to fix this issue??

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

Title:
  Make Uninstall Rule Requested

Status in QEMU:
  New

Bug description:
  Environment: Ubuntu 14.04 - Qemu 2.1.1
  --
  I've configured qemu with some --prefix, compiled the sources and installed 
the binaries; now, for some reason, I need to uninstall qemu to configure it 
with the default prefix, recompile the sources and reinstall the binaries.
  However, there's no rule to uninstall qemu.

  All other packages which I have compiled and installed on my system
  offer the possibility to uninstall it: why not Qemu?

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

Re: [Qemu-devel] [PATCH 01/10] roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"

[Philippe Mathieu-Daudé]

On 3/9/19 1:48 AM, Laszlo Ersek wrote:
> Extract the dense logic for architecture and toolchain massaging from
> "tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
> these functions for building full platform firmware images.
> 
> Signed-off-by: Laszlo Ersek 
> ---
>  roms/edk2-funcs.sh | 240 
>  tests/uefi-test-tools/build.sh |  97 +---
>  2 files changed, 246 insertions(+), 91 deletions(-)
> 
> diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
> new file mode 100644
> index ..908c7665c6ed
> --- /dev/null
> +++ b/roms/edk2-funcs.sh
> @@ -0,0 +1,240 @@
> +# Shell script that defines functions for determining some environmental
> +# characteristics for the edk2 "build" utility.
> +#
> +# This script is meant to be sourced.
> +#
> +# Copyright (C) 2019, Red Hat, Inc.
> +#
> +# This program and the accompanying materials are licensed and made available
> +# under the terms and conditions of the BSD License that accompanies this
> +# distribution. The full text of the license may be found at
> +# .
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +
> +# Verify whether the QEMU system emulation target is supported by the UEFI 
> spec
> +# and edk2. Print a message to the standard error, and return with nonzero
> +# status, if verification fails.
> +#
> +# Parameters:
> +#   $1: QEMU system emulation target
> +qemu_edk2_verify_arch()
> +{
> +  local emulation_target="$1"
> +  local program_name=$(basename -- "$0")
> +
> +  case "$emulation_target" in
> +(arm|aarch64|i386|x86_64)
> +  ;;
> +(*)
> +  printf '%s: unknown/unsupported QEMU system emulation target "%s"\n' \
> +"$program_name" "$emulation_target" >&2
> +  return 1
> +  ;;
> +  esac
> +}
> +
> +
> +# Translate the QEMU system emulation target to the edk2 architecture
> +# identifier. Print the result to the standard output.
> +#
> +# Parameters:
> +#   $1: QEMU system emulation target
> +qemu_edk2_get_arch()
> +{
> +  local emulation_target="$1"
> +
> +  if ! qemu_edk2_verify_arch "$emulation_target"; then
> +return 1
> +  fi
> +
> +  case "$emulation_target" in
> +(arm)
> +  printf 'ARM\n'
> +  ;;
> +(aarch64)
> +  printf 'AARCH64\n'
> +  ;;
> +(i386)
> +  printf 'IA32\n'
> +  ;;
> +(x86_64)
> +  printf 'X64\n'
> +  ;;
> +  esac
> +}
> +
> +
> +# Translate the QEMU system emulation target to the gcc cross-compilation
> +# architecture identifier. Print the result to the standard output.
> +#
> +# Parameters:
> +#   $1: QEMU system emulation target
> +qemu_edk2_get_gcc_arch()
> +{
> +  local emulation_target="$1"
> +
> +  if ! qemu_edk2_verify_arch "$emulation_target"; then
> +return 1
> +  fi
> +
> +  case "$emulation_target" in
> +(arm|aarch64|x86_64)
> +  printf '%s\n' "$emulation_target"
> +  ;;
> +(i386)
> +  printf 'i686\n'
> +  ;;
> +  esac
> +}
> +
> +
> +# Determine the gcc cross-compiler prefix (if any) for use with the edk2
> +# toolchain. Print the result to the standard output.
> +#
> +# Parameters:
> +#   $1: QEMU system emulation target
> +qemu_edk2_get_cross_prefix()
> +{
> +  local emulation_target="$1"
> +  local gcc_arch
> +  local host_arch
> +
> +  if ! gcc_arch=$(qemu_edk2_get_gcc_arch "$emulation_target"); then
> +return 1
> +  fi
> +
> +  host_arch=$(uname -m)
> +
> +  if [ "$gcc_arch" == "$host_arch" ] ||
> + ( [ "$gcc_arch" == i686 ] && [ "$host_arch" == x86_64 ] ); then
> +# no cross-compiler needed
> +:
> +  else
> +printf '%s-linux-gnu-\n' "$gcc_arch"
> +  fi
> +}
> +
> +
> +# Determine the edk2 toolchain tag for the QEMU system emulation target. 
> Print
> +# the result to the standard output. Print a message to the standard error, 
> and
> +# return with nonzero status, if the (conditional) gcc version check fails.
> +#
> +# Parameters:
> +#   $1: QEMU system emulation target
> +qemu_edk2_get_toolchain()
> +{
> +  local emulation_target="$1"
> +  local program_name=$(basename -- "$0")
> +  local cross_prefix
> +  local gcc_version
> +
> +  if ! qemu_edk2_verify_arch "$emulation_target"; then
> +return 1
> +  fi
> +
> +  case "$emulation_target" in
> +(arm|aarch64)
> +  printf 'GCC5\n'
> +  ;;
> +
> +(i386|x86_64)
> +  if ! cross_prefix=$(qemu_edk2_get_cross_prefix "$emulation_target"); 
> then
> +return 1
> +  fi
> +
> +  gcc_version=$("${cross_prefix}gcc" -v 2>&1 | tail -1 | awk '{print 
> $3}')
> +  # Run "git-blame" on "OvmfPkg/build.sh" in edk2 for more information on
> +  # the mapping below.
> +  case "$gcc_version" in
> +([1-3].*|4.[0-3].*)
> +  printf '%s: unsupported gcc version "%s"\n' \
> +"$program_name" "$gcc_version" >&2
> +  return 1
> +  ;;
>

Re: [Qemu-devel] [PATCH 06/10] roms/Makefile: replace the $(EFIROM) target with "edk2-basetools"

[Philippe Mathieu-Daudé]

On 3/9/19 2:53 AM, Philippe Mathieu-Daudé wrote:
> On 3/9/19 2:32 AM, Philippe Mathieu-Daudé wrote:
>> Hi Laszlo,
>>
>> On 3/9/19 1:48 AM, Laszlo Ersek wrote:
>>> We don't (can't) have a recipe for building just $(EFIROM); therefore,
>>> while we call the target $(EFIROM), we actually build all of the edk2
>>> BaseTools. Rename the target to edk2-basetools, and update the iPXE
>>> prerequisite accordingly. This will let other targets depend on
>>> "edk2-basetools", where an $(EFIROM) pre-requisite would be misleading.
>>>
>>> Signed-off-by: Laszlo Ersek 
>>> ---
>>>  roms/Makefile | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/roms/Makefile b/roms/Makefile
>>> index 78d5dd18c301..2e83ececa25a 100644
>>> --- a/roms/Makefile
>>> +++ b/roms/Makefile
>>> @@ -102,7 +102,7 @@ pxe-rom-%: build-pxe-roms
>>>  
>>>  efirom: $(patsubst %,efi-rom-%,$(pxerom_variants))
>>>  
>>> -efi-rom-%: build-pxe-roms build-efi-roms $(EFIROM)
>>> +efi-rom-%: build-pxe-roms build-efi-roms edk2-basetools
>>> $(EFIROM) -f "0x$(VID)" -i "0x$(DID)" -l 0x02 \
>>> -b ipxe/src/bin/$(VID)$(DID).rom \
>>> -ec ipxe/src/bin-i386-efi/$(VID)$(DID).efidrv \
>>> @@ -120,7 +120,7 @@ build-efi-roms: build-pxe-roms
>>> $(patsubst %,bin-i386-efi/%.efidrv,$(pxerom_targets)) \
>>> $(patsubst %,bin-x86_64-efi/%.efidrv,$(pxerom_targets))
>>>  
>>> -$(EFIROM):
>>> +edk2-basetools:
>>
>> Should we add:
>>
>> $(MAKE) -f Makefile.edk2 submodules
>>
>> from your next patch?
>>
>> There might be a circular dependency else, if the user doesn't init the
>> submodules manually.
>>
>> The next patch add a make dependency 'efi' -> 'edk2-basetools', but
>> 'edk2-basetools' build the BaseTools within edk2/.
>>
> 
> OK I mixed, the Makefile.edk2's submodules rules is for the edk2
> repository submodules, while by 'the user submodules' I mean the QEMU
> submodules...
> 
> So the user has to initialize the roms/edk2 submodule previous to run
> both efi/edk2-basetools rules of this Makefile.

Maybe we can 'test -e edk2/.git' and display an error "edk2 submodule
not initialized.", what do you think?

Regardless:
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

>>> $(MAKE) -C edk2/BaseTools
>>>  
>>>  slof:
>>>

Re: [Qemu-devel] [PATCH 05/10] roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function

[Philippe Mathieu-Daudé]

On 3/9/19 1:48 AM, Laszlo Ersek wrote:
> The edk2 "build" utility natively supports building modules (that is, INF
> files) in parallel. The feature is not useful when building a single
> module (with the "-m" option), but it is useful for platform firmware
> builds (which include many modules). Add a function that determines the
> "-n" option argument for "build", from the MAKEFLAGS variable (i.e. based
> on the presence of a make job server).
> 
> Signed-off-by: Laszlo Ersek 
> ---
>  roms/edk2-funcs.sh | 25 
>  1 file changed, 25 insertions(+)
> 
> diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
> index 22a5dc8f6ab6..7fc62f074c59 100644
> --- a/roms/edk2-funcs.sh
> +++ b/roms/edk2-funcs.sh
> @@ -226,3 +226,28 @@ qemu_edk2_set_cross_env()
>  
>eval "export $cross_prefix_var=\$cross_prefix"
>  }
> +
> +
> +# Determine the "-n" option argument (that is, the number of modules to build
> +# in parallel) for the edk2 "build" utility. Print the result to the standard
> +# output.
> +#
> +# Parameters:
> +#   $1: the value of the MAKEFLAGS variable
> +qemu_edk2_get_thread_count()
> +{
> +  local makeflags="$1"
> +
> +  if [[ "$makeflags" == *--jobserver-auth=* ]] ||
> + [[ "$makeflags" == *--jobserver-fds=* ]]; then
> +# If there is a job server, allow the edk2 "build" utility to parallelize
> +# as many module builds as there are logical CPUs in the system. The 
> "make"
> +# instances forked by "build" are supposed to limit themselves through 
> the
> +# job server. The zero value below causes the edk2 "build" utility to 
> fetch
> +# the logical CPU count with Python's multiprocessing.cpu_count() method.
> +printf '0\n'

Nice, it works smoothly :)

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

> +  else
> +# Build a single module at a time.
> +printf '1\n'
> +  fi
> +}
> 

Re: [Qemu-devel] [PATCH 02/10] roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64

[Philippe Mathieu-Daudé]

On 3/9/19 1:48 AM, Laszlo Ersek wrote:
> Adapt the qemu_edk2_get_toolchain() function in "roms/edk2-funcs.sh" in
> advance to edk2 commit 8d7cdfae8cb8 ("OvmfPkg: require GCC48 or later",
> 2019-01-08), which is part of the "edk2-stable201903" tag.
> 
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

> ---
>  roms/edk2-funcs.sh | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
> index 908c7665c6ed..22a5dc8f6ab6 100644
> --- a/roms/edk2-funcs.sh
> +++ b/roms/edk2-funcs.sh
> @@ -149,23 +149,11 @@ qemu_edk2_get_toolchain()
># Run "git-blame" on "OvmfPkg/build.sh" in edk2 for more information on
># the mapping below.
>case "$gcc_version" in
> -([1-3].*|4.[0-3].*)
> +([1-3].*|4.[0-7].*)
>printf '%s: unsupported gcc version "%s"\n' \
>  "$program_name" "$gcc_version" >&2
>return 1
>;;
> -(4.4.*)
> -  printf 'GCC44\n'
> -  ;;
> -(4.5.*)
> -  printf 'GCC45\n'
> -  ;;
> -(4.6.*)
> -  printf 'GCC46\n'
> -  ;;
> -(4.7.*)
> -  printf 'GCC47\n'
> -  ;;
>  (4.8.*)
>printf 'GCC48\n'
>;;
> 

Re: [Qemu-devel] [PATCH 07/10] roms: build edk2 firmware binaries and variable store templates

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 3/9/19 5:48 PM, Philippe Mathieu-Daudé wrote:
> On 3/9/19 1:48 AM, Laszlo Ersek wrote:
>> Add the "efi" target to "Makefile".
>>
>> Introduce "Makefile.edk2" for building and cleaning the firmware images
>> and varstore templates.
>>
>> Collect the common bits from the recipes in the helper script
>> "edk2-build.sh".
>>
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  roms/Makefile  |   5 +
>>  roms/Makefile.edk2 | 138 
>>  roms/edk2-build.sh |  55 
>>  3 files changed, 198 insertions(+)
>>
>> diff --git a/roms/Makefile b/roms/Makefile
>> index 2e83ececa25a..054b432834ba 100644
>> --- a/roms/Makefile
>> +++ b/roms/Makefile
>> @@ -61,6 +61,7 @@ default:
>>  @echo "  skiboot-- update skiboot.lid"
>>  @echo "  u-boot.e500-- update u-boot.e500"
>>  @echo "  u-boot.sam460  -- update u-boot.sam460"
>> +@echo "  efi-- update UEFI (edk2) platform firmware"
>>  
>>  bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
>>  cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
>> @@ -143,6 +144,9 @@ skiboot:
>>  $(MAKE) -C skiboot CROSS=$(powerpc64_cross_prefix)
>>  cp skiboot/skiboot.lid ../pc-bios/skiboot.lid
>>  
>> +efi: edk2-basetools
>> +$(MAKE) -f Makefile.edk2
>> +
>>  clean:
>>  rm -rf seabios/.config seabios/out seabios/builds
>>  $(MAKE) -C sgabios clean
>> @@ -153,3 +157,4 @@ clean:
>>  rm -rf u-boot/build.e500
>>  $(MAKE) -C u-boot-sam460ex distclean
>>  $(MAKE) -C skiboot clean
>> +$(MAKE) -f Makefile.edk2 clean
>> diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
>> new file mode 100644
>> index ..ad6fff044cd6
>> --- /dev/null
>> +++ b/roms/Makefile.edk2
>> @@ -0,0 +1,138 @@
>> +# Makefile for building firmware binaries and variable store templates for a
>> +# number of virtual platforms in edk2.
>> +#
>> +# Copyright (C) 2019, Red Hat, Inc.
>> +#
>> +# This program and the accompanying materials are licensed and made 
>> available
>> +# under the terms and conditions of the BSD License that accompanies this
>> +# distribution. The full text of the license may be found at
>> +# .
>> +#
>> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
>> WITHOUT
>> +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>> +
>> +toolchain = $(shell source ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))

Well I finally figured out why building on Ubuntu fails. It default
shell is dash, and 'source' is a bash builtin command. The portable
equivalent is '.' (dot).

The fix is:

-- >8 --
-toolchain = $(shell source ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
+toolchain = $(shell . ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
---

With this hunk:
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

>> +
>> +licenses := \
>> +edk2/License.txt \
>> +edk2/OvmfPkg/License.txt \
>> +edk2/CryptoPkg/Library/OpensslLib/openssl/LICENSE
>> +
>> +# The "edk2-arm-vars.fd" varstore template is suitable for aarch64 as well.
>> +# Similarly, the "edk2-i386-vars.fd" varstore template is suitable for 
>> x86_64
>> +# as well, independently of "secure" too.
>> +all: \
>> +../pc-bios/edk2-aarch64-code.fd \
>> +../pc-bios/edk2-arm-code.fd \
>> +../pc-bios/edk2-i386-code.fd \
>> +../pc-bios/edk2-i386-secure-code.fd \
>> +../pc-bios/edk2-x86_64-code.fd \
>> +../pc-bios/edk2-x86_64-secure-code.fd \
>> +\
>> +../pc-bios/edk2-arm-vars.fd \
>> +../pc-bios/edk2-i386-vars.fd \
>> +\
>> +../pc-bios/edk2-licenses.txt
>> +
>> +submodules:
>> +cd edk2 && git submodule update --init --force
>> +
>> +# See notes on the ".NOTPARALLEL" target and the "+" indicator in
>> +# "tests/uefi-test-tools/Makefile".
>> +.NOTPARALLEL:
>> +
>> +../pc-bios/edk2-aarch64-code.fd: submodules
>> ++./edk2-build.sh \
>> +aarch64 \
>> +--arch=AARCH64 \
>> +--platform=ArmVirtPkg/ArmVirtQemu.dsc \
>> +-D NETWORK_IP6_ENABLE \
>> +-D HTTP_BOOT_ENABLE
>> +cp edk2/Build/ArmVirtQemu-AARCH64/DEBUG_$(call 
>> toolchain,aarch64)/FV/QEMU_EFI.fd \
>> +$@
>> +truncate --size=64M $@
> [...]
> 
> Trying on Ubuntu I get:
> 
> $ make -C roms efi
> [...]
> Fd File Name:QEMU_EFI
> (/home/phil/source/qemu/roms/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/QEMU_EFI.fd)
> Fd File Name:QEMU_VARS
> (/home/phil/source/qemu/roms/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/QEMU_VARS.fd)
> GUID cross reference file can be found at
> /home/phil/source/qemu/roms/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/Guid.xref
> - Done -
> Build end time: 16:33:29, Mar.09 2019
> Build total time: 00:03:35
> cp edk2/Build/ArmVirtQemu-AARCH64/DEBUG_/FV/QEMU_EFI.fd \
>   ../pc-bios/edk2-aarch64-code.fd
> cp: cannot stat 'edk2/Build/ArmVirtQemu-AARCH64/DEBUG_/FV/QEMU_EFI.fd':
> No such file or dire

Re: [Qemu-devel] [PATCH] hw/riscv/virt: re-add machine-specific compatible string to /soc/ node

[Bin Meng]

Hi Lukas,

On Sun, Mar 10, 2019 at 9:44 PM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Sun, 2019-03-10 at 09:07 +0800, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Mon, Feb 11, 2019 at 6:13 AM Lukas Auer
> >  wrote:
> > > Re-add the previous compatible string "riscv-virtio-soc" to the soc
> > > device tree node to allow U-Boot and Linux to bind machine-specific
> > > drivers to it. The current compatible string "simple-bus" is
> > > retained.
> > >
> > > This is required by U-Boot to bind devices early, as part of the
> > > pre-relocation driver model.
> > >
> >
> > I see no problem with U-Boot working with current compatible string
> > "simple-bus". In fact I had planned to remove the compatible string
> > "riscv-virtio-soc" in U-Boot but did not get time to work on it.
> >
>
> It is only required if U-Boot is running in machine-mode. For
> relocation it needs to use the CLINT driver to send appropriate IPIs to
> the other harts. To be able to probe the driver, the device and its
> parent device tree node (soc) must therefore be available in the pre-
> relocation device model.
> This patch was the easiest way I could think of for achieving this. It
> could be that there is a better way of solving this.
>

I tested your SMP U-Boot series in both M-mode and S-mode, using a 4
core 'virt' target. Works fine. I am using QEMU 3.1.0 so it is
"simple-bus".

Regards,
Bin

Re: [Qemu-devel] [PATCH] tests: test-bdrv-graph-mod: fix memory leak

[Philippe Mathieu-Daudé]

On 3/10/19 12:34 PM, Li Qiang wrote:
> Fixes: 2dbfadf

  ^ Please keep tags together (with Signed-off-by, ...)

> Spotted by ASAN when 'make check'.

I'm not native English speaker but I'd say:

Spotted by ASAN [with] 'make check'.

or

Spotted by ASAN [while running] 'make check'.

Here goes:

"Fixes: 2dbfadf"

> Signed-off-by: Li Qiang 
> ---
>  tests/test-bdrv-graph-mod.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/test-bdrv-graph-mod.c b/tests/test-bdrv-graph-mod.c
> index 458dfa6661..8bf0fe735d 100644
> --- a/tests/test-bdrv-graph-mod.c
> +++ b/tests/test-bdrv-graph-mod.c
> @@ -117,6 +117,7 @@ static void test_update_perm_tree(void)
>  
>  bdrv_unref(bs);
>  blk_unref(root);
> +error_free(local_err);

Reviewed-by: Philippe Mathieu-Daudé 

>  }
>  
>  /*
> 

Re: [Qemu-devel] converting build system to Meson?

[Markus Armbruster]

Peter Maydell  writes:

> On Thu, 7 Mar 2019 at 06:39, Thomas Huth  wrote:
>> On 06/03/2019 19.12, Paolo Bonzini wrote:
>> > lately I have been thinking of converting the QEMU build system to
>> > Meson.  Meson is a relatively new build system that can replace
>> > Autotools or hand-written Makefiles such as QEMU; as a die-hard
>> > Autotools fan, I must say that Meson is by far better than anything else
>> > that has ever tried to replace Autotools, and actually has the potential
>> > to do so.
>> >
>> > Advantages of Meson that directly matter for QEMU include:[...]
>>
>> I'm not objecting a new build system per se, but could you elaborate on
>>  problems of the current QEMU build system that will be fixed by this
>> change? Since apart from some minor glitches (with the *.mak file
>> dependencies for example), the current build system seems to work quite
>> well for me ... so at least I currently don't feel enough pain yet to do
>> such a big step, just because there is another new cool build system
>> around...
>
> Yes, that tends to be my view. Our current build system:
>  * has no dependencies that are problematic for older hosts
>(contrast Meson, which needs Python 3.5, even if we take
>the drastic step of shipping an entire build tool along
>with QEMU; OSX python is 2.7 still)

By the time Meson is ready for us, and we're ready for Meson, chances
are even OS-X has moved on from Python 2.

https://pythonclock.org/

>  * is not particularly hard to deal with for the common cases
>("add new source file" is straightforward)

Yes.  Quite an achievement.

>  * covers all our requirements as far as I'm aware
>(whereas you've listed a couple of places where Meson
>would need changes/extensions to support things we do already)
>  * is generally flexible enough to be hackable to deal with odd
>cases (it has escape mechanisms to generic-programmability,
>even if they're ugly and awkward)

Yes, it's hackable, but it takes quite a hacker to hack it.  While it's
reasonably easy to do simple things in it with basic voodoo skills, the
learning curve goes up like the Zimbabwean inflation rate after that.  I
got plenty of experience in Make, and consider myself pretty fluent, yet
I find myself running to Paolo for help.

> So I think we'd need a more compelling reason to move right now.
> (This might change in the future, eg if Meson catches on to the
> extent that everybody is using it and competitors like CMake are
> more obviously eclipsed by it, in the way that git took over
> from svn and relegated mercurial and bzr to obscurity.)
>
> thanks
> -- PMM

[Qemu-devel] [Bug 1819343] [NEW] Qcow2 image stuck as locked after host crash

[Tim Schuster]

Public bug reported:

After a host crash, the qcow2 image of the VM, stored on a remote NFS
share, has become inaccessible. Libvirt/QEMU reports that 'failed to get
"write" lock\nIs another process using the image
[/path/nfs/image.qcow2]?'. No process is accessing the image from either
host or the network share side. There is no obvious way in qemu-img to
force unlocking the file or repair the image (attempting a qemu-img
check with -r all results in qemu-img complaining about the lock and
being unable to do force-share=on on anything but readonly images).

I'm currently attempting to fix this by converting the image via 'qemu-
img convert -U -f qcow2 -O qcow2 image.qcow2 image_2.gcow2', though this
will likely take some time.

Using QEMU 3.1.0

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Qcow2 image stuck as locked after host crash

Status in QEMU:
  New

Bug description:
  After a host crash, the qcow2 image of the VM, stored on a remote NFS
  share, has become inaccessible. Libvirt/QEMU reports that 'failed to
  get "write" lock\nIs another process using the image
  [/path/nfs/image.qcow2]?'. No process is accessing the image from
  either host or the network share side. There is no obvious way in
  qemu-img to force unlocking the file or repair the image (attempting a
  qemu-img check with -r all results in qemu-img complaining about the
  lock and being unable to do force-share=on on anything but readonly
  images).

  I'm currently attempting to fix this by converting the image via
  'qemu-img convert -U -f qcow2 -O qcow2 image.qcow2 image_2.gcow2',
  though this will likely take some time.

  Using QEMU 3.1.0

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

Re: [Qemu-devel] converting build system to Meson?

[Markus Armbruster]

Daniel P. Berrangé  writes:

[...]
> As long term contributors we've built enough enough knowledge to
> QEMU to consider our build system attractive or even "simple",

The words that come to my mind aren't "attractive" or "simple", but
"impressively clever", "brittle", and "uh, can I hack on something else
today?"

I've obviously failed to develop enough of a Stockholm Syndrome in 8+
years.

> which skews our view of the benefits of alternatives to people
> without this tribal knowledge.

[Qemu-devel] [Bug 1818483] Re: qemu user mode does not support binfmt_misc config with flags include "P"

[YunQiang Su]

@Peter Luyou and me are working on try to pass the info about whether P
flag is enabled or not by enviroment var or auxval. While we have not
found the right method to do it from binfmt_misc.

In fact, currently qemu trys to process the O flag, and it cannot work at all.
When you install qemu-user-static package from Debian/Ubuntu, the O flag is 
enabled,
while 
   execfd = qemu_getauxval(AT_EXECFD);
always return 0.

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

Title:
  qemu user mode does not support binfmt_misc config with flags include
  "P"

Status in QEMU:
  New

Bug description:
  Hi Sir:
  During our test in chroot environment with qemu-user-static, we got some test 
cases failed because of program output warning with unexpected full path name.
  For example in test module "Devscripts"
  the test item for broken tarball expected the warning info:
  
  but the output was:
  
  the cause is the config file of binfmt_misc was set not to send argv0, for 
example:
  type command "tar" after chroot:
  ==
  lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot .
  [sudo] password for lpeng: 
  root@lpeng-VirtualBox:/# tar
  /bin/tar: You must specify one of the '-Acdtrux', '--delete' or 
'--test-label' options
  Try '/bin/tar --help' or '/bin/tar --usage' for more information.
  root@lpeng-VirtualBox:/# 
  ===

  by adding output log in main()@qemu/Linux-user/main.c
  we found the original input command was changed, and qemu do not know that, 
we got the input args:
  argv_0/usr/bin/qemu-mips64el-static---
  argv_1/bin/tar---
  argv_2NULL---

  Next step we modified the flags=P in the corresponding config under folder 
/proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu.
  But chroot could not start bash because in current qemu dose not consider 
about this unexpected one more"argv[0]"

  
  After modified qemu code temporary to handle the new argv list we got the 
input args, and from argv[2] is the original input command
  argv_0/usr/bin/qemu-mips64el-static---
  argv_1/bin/tar---
  argv_2tar---

  We need the original input from command line, so is it possible that let 
binfmt_misc to pass one more additional args or env to qemu as a token of the 
binfmt_misc flag, then qemu can judge how to parse the input args by it?
  looking forward your suggestions.

  Thanks
  luyou

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

[Qemu-devel] [PATCH v7 0/2] Basic ATI VGA emulation

[BALATON Zoltan]

Rebase on master to fix build with new Kconfig based stuff.

BALATON Zoltan (2):
  hw/display: Add basic ATI VGA emulation
  mips_fulong2e: Add on-board graphics chip

 hw/display/Kconfig   |   6 +
 hw/display/Makefile.objs |   2 +
 hw/display/ati.c | 865 +++
 hw/display/ati_2d.c  | 167 +
 hw/display/ati_dbg.c | 259 ++
 hw/display/ati_int.h |  96 ++
 hw/display/ati_regs.h| 461 +
 hw/display/trace-events  |   4 +
 hw/mips/mips_fulong2e.c  |   7 +
 vl.c |   1 +
 10 files changed, 1868 insertions(+)
 create mode 100644 hw/display/ati.c
 create mode 100644 hw/display/ati_2d.c
 create mode 100644 hw/display/ati_dbg.c
 create mode 100644 hw/display/ati_int.h
 create mode 100644 hw/display/ati_regs.h

-- 
2.13.7

[Qemu-devel] [PATCH v7 2/2] mips_fulong2e: Add on-board graphics chip

[BALATON Zoltan]

Add (partial) emulation of the on-board GPU of the machine. This
allows the PMON2000 firmware to run and should also work with Linux
console but probably not with X yet.

Signed-off-by: BALATON Zoltan 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Aleksandar Markovic 
---
v7:
- set vgamem_mb explicitely to match board instead of relying on default

 hw/mips/mips_fulong2e.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/mips/mips_fulong2e.c b/hw/mips/mips_fulong2e.c
index fbbc543eed..2bdb766ed1 100644
--- a/hw/mips/mips_fulong2e.c
+++ b/hw/mips/mips_fulong2e.c
@@ -287,6 +287,7 @@ static void mips_fulong2e_init(MachineState *machine)
 I2CBus *smbus;
 MIPSCPU *cpu;
 CPUMIPSState *env;
+DeviceState *dev;
 
 /* init CPUs */
 cpu = MIPS_CPU(cpu_create(machine->cpu_type));
@@ -347,6 +348,12 @@ static void mips_fulong2e_init(MachineState *machine)
 vt82c686b_southbridge_init(pci_bus, FULONG2E_VIA_SLOT, env->irq[5],
&smbus, &isa_bus);
 
+/* GPU */
+dev = DEVICE(pci_create(pci_bus, -1, "ati-vga"));
+qdev_prop_set_uint32(dev, "vgamem_mb", 16);
+qdev_prop_set_uint16(dev, "x-device-id", 0x5159);
+qdev_init_nofail(dev);
+
 /* Populate SPD eeprom data */
 spd_data = spd_data_generate(DDR, ram_size, &err);
 if (err) {
-- 
2.13.7

[Qemu-devel] [PATCH v7 1/2] hw/display: Add basic ATI VGA emulation

[BALATON Zoltan]

At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
guests running on these and the PMON2000 firmware of the fulong2e
expect this to be available. Fortunately these are very similar chips
so they can be mostly emulated in the same device model. This patch
adds basic emulation of these ATI VGA chips.

While this is incomplete and currently only enough to run the MIPS
firmware and get framebuffer output with Linux, it allows the fulong2e
board to work more like the real hardware and having it in QEMU in
this state provides a way to experiment with it and allows others to
contribute to improve it. It is compiled for all archs but only the
fulong2e (which currently has no display output at all) is set to use
it by default (in a separate patch).

Signed-off-by: BALATON Zoltan 
Acked-by: Aleksandar Markovic 
Tested-by: Andrew Randrianasulu 
Tested-by: Howard Spoelstra 
---
v7:
- rebased for Kconfig changes in master
- added Tested-by: tags

v6:
- add support for hwcursor rendered in device as well, enable with
  guest_hwcursor=true property

v5:
- review suggestions: add const to model aliases, \n to log, %u in trace
- implemented hardware cursor support

v4:
- fix mingw build (from Gerd)
- set dev_id in realize to allow pci_patch_ids to change bios rom
- add model aliases to select device variant by name instead of id
- misc mode switch and 2d fixes (better but still not quite right)

v3:
- add to default-configs/pci.mak instead of mips64el and ppc only
- rename device_id property to x-device-id
- use extract32/deposit32 in *_offs functions
- add ati-vga to vl.c default_list[]

v2:
- Extended debug logs
- Fix mode switching and some registers
- Fixes to 2D functions

 hw/display/Kconfig   |   6 +
 hw/display/Makefile.objs |   2 +
 hw/display/ati.c | 865 +++
 hw/display/ati_2d.c  | 167 +
 hw/display/ati_dbg.c | 259 ++
 hw/display/ati_int.h |  96 ++
 hw/display/ati_regs.h| 461 +
 hw/display/trace-events  |   4 +
 vl.c |   1 +
 9 files changed, 1861 insertions(+)
 create mode 100644 hw/display/ati.c
 create mode 100644 hw/display/ati_2d.c
 create mode 100644 hw/display/ati_dbg.c
 create mode 100644 hw/display/ati_int.h
 create mode 100644 hw/display/ati_regs.h

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index a96ea763a8..86c1d544c5 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -106,3 +106,9 @@ config VIRTIO_VGA
 
 config DPCD
 bool
+
+config ATI_VGA
+bool
+default y if PCI_DEVICES
+depends on PCI
+select VGA
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 576fca4eb6..dbd453ab1b 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -51,3 +51,5 @@ virtio-gpu-3d.o-cflags := $(VIRGL_CFLAGS)
 virtio-gpu-3d.o-libs += $(VIRGL_LIBS)
 obj-$(CONFIG_DPCD) += dpcd.o
 obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dp.o
+
+obj-$(CONFIG_ATI_VGA) += ati.o ati_2d.o ati_dbg.o
diff --git a/hw/display/ati.c b/hw/display/ati.c
new file mode 100644
index 00..8322f52aff
--- /dev/null
+++ b/hw/display/ati.c
@@ -0,0 +1,865 @@
+/*
+ * QEMU ATI SVGA emulation
+ *
+ * Copyright (c) 2019 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ */
+
+/*
+ * WARNING:
+ * This is very incomplete and only enough for Linux console and some
+ * unaccelerated X output at the moment.
+ * Currently it's little more than a frame buffer with minimal functions,
+ * other more advanced features of the hardware are yet to be implemented.
+ * We only aim for Rage 128 Pro (and some RV100) and 2D only at first,
+ * No 3D at all yet (maybe after 2D works, but feel free to improve it)
+ */
+
+#include "ati_int.h"
+#include "ati_regs.h"
+#include "vga_regs.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "ui/console.h"
+#include "trace.h"
+
+#define ATI_DEBUG_HW_CURSOR 0
+
+static const struct {
+const char *name;
+uint16_t dev_id;
+} ati_model_aliases[] = {
+{ "rage128p", PCI_DEVICE_ID_ATI_RAGE128_PF },
+{ "rv100", PCI_DEVICE_ID_ATI_RADEON_QY },
+};
+
+enum { VGA_MODE, EXT_MODE };
+
+static void ati_vga_switch_mode(ATIVGAState *s)
+{
+DPRINTF("%d -> %d\n",
+s->mode, !!(s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN));
+if (s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN) {
+/* Extended mode enabled */
+s->mode = EXT_MODE;
+if (s->regs.crtc_gen_cntl & CRTC2_EN) {
+/* CRT controller enabled, use CRTC values */
+uint32_t offs = s->regs.crtc_offset & 0x07ff;
+int stride = (s->regs.crtc_pitch & 0x7ff) * 8;
+int bpp = 0;
+int h, v;
+
+if (s->regs.crtc_h_total_disp == 0) {
+s->regs.crtc_h_total_disp = ((640 / 8) - 1) << 16;
+   

[Qemu-devel] [PATCH] isa: Add APM and ACPI dependencies for VT82C686

[BALATON Zoltan]

Compiling vt82c686.c fails without APM and ACPI_PM funtions. Add
dependency on these in Kconfig to fix this.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 57e09a0cb8..e092da3fc3 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -36,6 +36,8 @@ config VT82C686
 select ACPI_SMBUS
 select SERIAL_ISA
 select FDC
+select APM
+select ACPI_X86
 
 config SMC37C669
 bool
-- 
2.13.7

[Qemu-devel] [PATCH] ati-vga: Implement DDC and EDID info from monitor

[BALATON Zoltan]

This adds DDC support to ati-vga and connects i2c-ddc to provide EDID
info that is read by guests to find available screen modes. Not sure
if this is 100% correct yet but at least MorphOS is happy with it and
starts in a high resolution mode instead of 640x480 (although its
splash screen is still not correct). Linux needs support from VESA
vgabios, it seems to be missing INT10 0x4F15 function (see
https://gitlab.freedesktop.org/xorg/xserver/blob/master/hw/xfree86/vbe/vbe.c)
without which no DDC is available that also prevents loading the
accelerated X driver.

Besides, this depends on bitbang_i2c.h which is now in hw/i2c so if
including it from there is not desirable that may need to be moved
somewhere.

Signed-off-by: BALATON Zoltan 
---
 hw/display/Kconfig   |  2 ++
 hw/display/ati.c | 24 ++--
 hw/display/ati_int.h |  3 +++
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index 86c1d544c5..f8d65802a9 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -112,3 +112,5 @@ config ATI_VGA
 default y if PCI_DEVICES
 depends on PCI
 select VGA
+select BITBANG_I2C
+select DDC
diff --git a/hw/display/ati.c b/hw/display/ati.c
index 8322f52aff..260cd803d8 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -24,6 +24,8 @@
 #include "qapi/error.h"
 #include "hw/hw.h"
 #include "ui/console.h"
+#include "hw/i2c/i2c-ddc.h"
+#include "../i2c/bitbang_i2c.h"
 #include "trace.h"
 
 #define ATI_DEBUG_HW_CURSOR 0
@@ -267,7 +269,9 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr, 
unsigned int size)
 case DAC_CNTL:
 val = s->regs.dac_cntl;
 break;
-/*case GPIO_MONID: FIXME hook up DDC I2C here */
+case GPIO_MONID:
+val = s->regs.gpio_monid;
+break;
 case PALETTE_INDEX:
 /* FIXME unaligned access */
 val = vga_ioport_read(&s->vga, VGA_PEL_IR) << 16;
@@ -501,7 +505,17 @@ static void ati_mm_write(void *opaque, hwaddr addr,
 s->regs.dac_cntl = data & 0xe3ff;
 s->vga.dac_8bit = !!(data & DAC_8BIT_EN);
 break;
-/*case GPIO_MONID: FIXME hook up DDC I2C here */
+case GPIO_MONID:
+s->regs.gpio_monid = data & 0x0f0f000f;
+if (data & BIT(2) << 24) {
+s->regs.gpio_monid |= !!(data & BIT(2)) << 10;
+bitbang_i2c_set(s->bbi2c, BITBANG_I2C_SCL, (data & BIT(2)) != 0);
+}
+if (data & BIT(1) << 24) {
+s->regs.gpio_monid |= bitbang_i2c_set(s->bbi2c, BITBANG_I2C_SDA,
+  (data & BIT(1)) != 0) << 9;
+}
+break;
 case PALETTE_INDEX ... PALETTE_INDEX + 3:
 if (size == 4) {
 vga_ioport_write(&s->vga, VGA_PEL_IR, (data >> 16) & 0xff);
@@ -792,6 +806,12 @@ static void ati_vga_realize(PCIDevice *dev, Error **errp)
 vga->cursor_draw_line = ati_cursor_draw_line;
 }
 
+/* ddc, edid */
+I2CBus *i2cbus = i2c_init_bus(DEVICE(s), "ati-vga.ddc");
+s->bbi2c = bitbang_i2c_init(i2cbus);
+I2CSlave *i2cddc = I2C_SLAVE(qdev_create(BUS(i2cbus), TYPE_I2CDDC));
+i2c_set_slave_address(i2cddc, 0x50);
+
 /* mmio register space */
 memory_region_init_io(&s->mm, OBJECT(s), &ati_mm_ops, s,
   "ati.mmregs", 0x4000);
diff --git a/hw/display/ati_int.h b/hw/display/ati_int.h
index a6f3e20e63..8df00efd93 100644
--- a/hw/display/ati_int.h
+++ b/hw/display/ati_int.h
@@ -11,6 +11,7 @@
 
 #include "qemu/osdep.h"
 #include "hw/pci/pci.h"
+#include "hw/i2c/i2c.h"
 #include "vga_int.h"
 
 /*#define DEBUG_ATI*/
@@ -36,6 +37,7 @@ typedef struct ATIVGARegs {
 uint32_t crtc_gen_cntl;
 uint32_t crtc_ext_cntl;
 uint32_t dac_cntl;
+uint32_t gpio_monid;
 uint32_t crtc_h_total_disp;
 uint32_t crtc_h_sync_strt_wid;
 uint32_t crtc_v_total_disp;
@@ -84,6 +86,7 @@ typedef struct ATIVGAState {
 uint16_t cursor_size;
 uint32_t cursor_offset;
 QEMUCursor *cursor;
+bitbang_i2c_interface *bbi2c;
 MemoryRegion io;
 MemoryRegion mm;
 ATIVGARegs regs;
-- 
2.13.7

Re: [Qemu-devel] [PATCH] hw/riscv/virt: re-add machine-specific compatible string to /soc/ node

[Auer, Lukas]

Hi Bin,

On Sun, 2019-03-10 at 09:07 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Mon, Feb 11, 2019 at 6:13 AM Lukas Auer
>  wrote:
> > Re-add the previous compatible string "riscv-virtio-soc" to the soc
> > device tree node to allow U-Boot and Linux to bind machine-specific
> > drivers to it. The current compatible string "simple-bus" is
> > retained.
> > 
> > This is required by U-Boot to bind devices early, as part of the
> > pre-relocation driver model.
> > 
> 
> I see no problem with U-Boot working with current compatible string
> "simple-bus". In fact I had planned to remove the compatible string
> "riscv-virtio-soc" in U-Boot but did not get time to work on it.
> 

It is only required if U-Boot is running in machine-mode. For
relocation it needs to use the CLINT driver to send appropriate IPIs to
the other harts. To be able to probe the driver, the device and its
parent device tree node (soc) must therefore be available in the pre-
relocation device model.
This patch was the easiest way I could think of for achieving this. It
could be that there is a better way of solving this.

Thanks,
Lukas

> > Fixes: 53f54508dae6("hw/riscv/virtio: Set the soc device tree node
> > as a
> > simple-bus")
> > Signed-off-by: Lukas Auer 
> > ---
> > 
> >  hw/riscv/virt.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> 
> Regards,
> Bin

[Qemu-devel] [PATCH] tests: test-announce-self: fix memory leak

[Li Qiang]

Spotted by ASAN when 'make check'.

Signed-off-by: Li Qiang 
---
 tests/test-announce-self.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/tests/test-announce-self.c b/tests/test-announce-self.c
index 1644d34a3f..3f370d8bf5 100644
--- a/tests/test-announce-self.c
+++ b/tests/test-announce-self.c
@@ -21,17 +21,6 @@
 #define ETH_P_RARP 0x8035
 #endif
 
-static QTestState *test_init(int socket)
-{
-char *args;
-
-args = g_strdup_printf("-netdev socket,fd=%d,id=hs0 -device "
-   "virtio-net-pci,netdev=hs0", socket);
-
-return qtest_start(args);
-}
-
-
 static void test_announce(int socket)
 {
 char buffer[60];
@@ -58,19 +47,22 @@ static void test_announce(int socket)
 
 static void setup(gconstpointer data)
 {
-QTestState *qs;
 void (*func) (int socket) = data;
 int sv[2], ret;
+char *args;
 
 ret = socketpair(PF_UNIX, SOCK_STREAM, 0, sv);
 g_assert_cmpint(ret, !=, -1);
 
-qs = test_init(sv[1]);
+args = g_strdup_printf("-netdev socket,fd=%d,id=hs0 -device "
+   "virtio-net-pci,netdev=hs0", sv[1]);
+qtest_start(args);
 func(sv[0]);
 
 /* End test */
 close(sv[0]);
-qtest_quit(qs);
+qtest_end();
+g_free(args);
 }
 
 int main(int argc, char **argv)
-- 
2.17.1

Re: [Qemu-devel] [PULL 00/25] Misc patches for QEMU 4.0 soft freeze

[Peter Maydell]

On Sat, 9 Mar 2019 at 07:50, Paolo Bonzini  wrote:
>
> The following changes since commit 62cfabb52210139843e26c95434356f73a0631b9:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-hppa-20190307' into 
> staging (2019-03-08 15:17:01 +)
>
> are available in the git repository at:
>
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to d7fa7c30d45c375fb7d9ad6f58462a64c3317037:
>
>   exec: streamline flatview_add_to_dispatch (2019-03-09 08:46:56 +0100)
>
> 
> * allow building QEMU without TCG or KVM support (Anthony)
> * update AMD IOMMU copyright (David)
> * compilation fixes for GCC and BSDs (Alexey, David, Paolo, Philippe)
> * coalesced I/O bugfix (Jagannathan)
> * Processor Tracing cpuid fix (Luwei)
> * Kconfig fix (Paolo)
> * Cleanups (Paolo)
> * PVH vs. multiboot fix (Stefano)
> * LSI bugfixes (Sven)
> * elf2dmp Coverity fix (Victor)
> * scsi-disk fix (Zhengui)

Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Philippe Mathieu-Daudé 
ERROR: pull request includes tag with UTF-8 error in person name

(Maybe we should add "patch includes LATIN CAPITAL LETTER A WITH TILDE"
in checkpatch.pl as a warning, since it's much more likely to
be "something got doubly-utf-8-encoded" than intentional.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] qom: cpu: destroy work_mutex in cpu_common_finalize

[李强]

Hi Paolo,

What's the status of this patch? I don't see it in upstream.


Thanks,
Li Qiang


At 2019-01-08 07:41:09, "Paolo Bonzini"  wrote:
>On 02/01/19 08:41, Li Qiang wrote:
>> Commit 376692b9dc6(cpus: protect work list with work_mutex)
>> initialize a work_mutex in cpu_common_initfn, however forget
>> to destroy it. This will cause resource leak when hotunplug cpu
>> or hotplug cpu fails.
>> 
>> Signed-off-by: Li Qiang 
>> ---
>>  qom/cpu.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/qom/cpu.c b/qom/cpu.c
>> index 9ad1372d57..367ebf9d61 100644
>> --- a/qom/cpu.c
>> +++ b/qom/cpu.c
>> @@ -380,6 +380,9 @@ static void cpu_common_initfn(Object *obj)
>>  
>>  static void cpu_common_finalize(Object *obj)
>>  {
>> +CPUState *cpu = CPU(obj);
>> +
>> +qemu_mutex_destroy(&cpu->work_mutex);
>>  }
>>  
>>  static int64_t cpu_common_get_arch_id(CPUState *cpu)
>> 
>
>Queued, thanks.
>
>Paolo

Re: [Qemu-devel] [PATCH 00/10] bundle edk2 platform firmware with QEMU

[Philippe Mathieu-Daudé]

On 3/10/19 4:56 AM, Michael S. Tsirkin wrote:
> On Sat, Mar 09, 2019 at 01:48:16AM +0100, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/qemu.git
>> Branch: edk2_build
>>
>> This series advances the roms/edk2 submodule to the "edk2-stable201903"
>> release, and builds and captures platform firmware binaries from that
>> release. At this point they are meant to be used by both end-users and
>> by Igor's ACPI unit tests in qtest ("make check").
>>
>> Previous discussion:
>>
>>   [Qemu-devel] bundling edk2 platform firmware images with QEMU
>>   80f0bae3-e79a-bb68-04c4-1c9c684d95b8@redhat.com">http://mid.mail-archive.com/80f0bae3-e79a-bb68-04c4-1c9c684d95b8@redhat.com
>>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02601.html

There David raised a concern about "[adding] ~206 MB of binaries to the
pc-bios directory". I'm also worried.

GitHub kindly suggest to use git-lfs. It is an extra dependency I'd
rather strongly avoid (because we support a wide range of host OS, each
using a wide types of filesystems).

What about storing those binaries on a file server (http/ftp) altogether
with a file containing its hashed digest (SHA1/SHA256)? Then we already
have all the required tools to fetch and verify those blob roms with the
build system.
Or we could store the hashes in the QEMU repository too.

>> Note that the series was formatted with "--no-binary" (affecting patch
>> #8), therefore it cannot be applied with "git-am". See the remote
>> repo/branch reference near the top instead.
>>
>> Thanks,
>> Laszlo
> 
> High time IMO.

:)

> Reviewed-by: Michael S. Tsirkin 
> 
> Laszlo I suggest you add an entry to MAINTAINERS
> and start doing pull requests.

This is the entry I added here:
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02967.html

> 
> Peter, what do you say? OK with you?

Since this series doesn't change the QEMU binaries built, it looks OK to
me to merge it past soft freeze (as we do we tests/CI), this way it get
merged with the final EDK2 release tag.
Else we can merge it next week, and update the EDK2 submodule tag
previous QEMU release.

>> Laszlo Ersek (10):
>>   roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"
>>   roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64
>>   tests/uefi-test-tools/build.sh: work around TianoCore#1607
>>   roms/edk2: advance to tag edk2-stable201903
>>   roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function
>>   roms/Makefile: replace the $(EFIROM) target with "edk2-basetools"
>>   roms: build edk2 firmware binaries and variable store templates
>>   pc-bios: add edk2 firmware binaries and variable store templates
>>   pc-bios: document the edk2 firmware images; add firmware descriptors
>>   Makefile: install the edk2 firmware images and their descriptors
>>
>>  Makefile   |  17 +-
>>  pc-bios/README |  11 +
>>  pc-bios/descriptors/50-edk2-i386-secure.json   |  34 +++
>>  pc-bios/descriptors/50-edk2-x86_64-secure.json |  35 +++
>>  pc-bios/descriptors/60-edk2-aarch64.json   |  31 +++
>>  pc-bios/descriptors/60-edk2-arm.json   |  31 +++
>>  pc-bios/descriptors/60-edk2-i386.json  |  33 +++
>>  pc-bios/descriptors/60-edk2-x86_64.json|  34 +++
>>  pc-bios/edk2-aarch64-code.fd   | Bin 0 -> 67108864 bytes
>>  pc-bios/edk2-arm-code.fd   | Bin 0 -> 67108864 bytes
>>  pc-bios/edk2-arm-vars.fd   | Bin 0 -> 67108864 bytes
>>  pc-bios/edk2-i386-code.fd  | Bin 0 -> 3653632 bytes
>>  pc-bios/edk2-i386-secure-code.fd   | Bin 0 -> 3653632 bytes
>>  pc-bios/edk2-i386-vars.fd  | Bin 0 -> 540672 bytes
>>  pc-bios/edk2-licenses.txt  | 209 
>>  pc-bios/edk2-x86_64-code.fd| Bin 0 -> 3653632 bytes
>>  pc-bios/edk2-x86_64-secure-code.fd | Bin 0 -> 3653632 bytes
>>  roms/Makefile  |   9 +-
>>  roms/Makefile.edk2 | 138 +++
>>  roms/edk2  |   2 +-
>>  roms/edk2-build.sh |  55 +
>>  roms/edk2-funcs.sh | 253 
>>  tests/uefi-test-tools/build.sh | 100 +---
>>  23 files changed, 897 insertions(+), 95 deletions(-)
>>  create mode 100644 pc-bios/descriptors/50-edk2-i386-secure.json
>>  create mode 100644 pc-bios/descriptors/50-edk2-x86_64-secure.json
>>  create mode 100644 pc-bios/descriptors/60-edk2-aarch64.json
>>  create mode 100644 pc-bios/descriptors/60-edk2-arm.json
>>  create mode 100644 pc-bios/descriptors/60-edk2-i386.json
>>  create mode 100644 pc-bios/descriptors/60-edk2-x86_64.json
>>  create mode 100644 pc-bios/edk2-aarch64-code.fd
>>  create mode 100644 pc-bios/edk2-arm-code.fd
>>  create mode 100644 pc-bios/edk2-arm-vars.fd
>>  create mode 100644

Re: [Qemu-devel] [PATCH] net: tap: use qemu_set_nonblock

[Li Qiang]

Hi Jason,

What's the status of this patch? I don't see it in upstream.

Thanks,
Li Qiang

Jason Wang  于2018年11月22日周四 上午10:22写道：

>
> On 2018/11/22 上午1:39, Michael S. Tsirkin wrote:
> > On Wed, Nov 21, 2018 at 11:30:41AM -0600, Eric Blake wrote:
> >> On 11/21/18 6:23 AM, Michael S. Tsirkin wrote:
> >>
>  I agree it is good to preserve fcntl flags though, so this patch
>  looks desirable.
> 
>  Reviewed-by: Daniel P. Berrangé 
> >>> Sure
> >>>
> >>> Acked-by: Michael S. Tsirkin 
> >>>
> >>> but really not for this release I guess as we are in freeze.
> >> We're in freeze, so the criteria is: Does this fix a bug that we would
> >> otherwise not want in 3.1.  If the code is pre-existing (that is, if
> 3.0 was
> >> released with the same problem), or then delaying the patch to 4.0 is an
> >> easier call to make.  If the problem is new to 3.1, then fixing it for
> -rc3
> >> is still reasonable with maintainer discretion (although once -rc3
> lands, we
> >> want as little as possible to go into -rc4, even if our track record
> says we
> >> will be unable to avoid -rc4 altogether).
> >>
> >> I think that losing flags is likely enough to be a noticeable bug worth
> >> fixing for 3.1, but I did not research when the problem was introduced,
> so I
> >> don't have a strong preference for 3.1 vs. 4.0.
> > Maintainer in this case is Jason, so it's up to him
>
>
> I've queued this for 4.0.
>
> Thanks
>
>

Re: [Qemu-devel] [PULL 0/4] NBD patches for 2019-03-08, 4.0 softfreeze

[Peter Maydell]

On Fri, 8 Mar 2019 at 17:41, Eric Blake  wrote:
>
> The following changes since commit c557a8c7b755d8c153fc0f5be00688228be96e76:
>
>   Merge remote-tracking branch 
> 'remotes/dgilbert/tags/pull-migration-20190306a' into staging (2019-03-06 
> 14:50:33 +)
>
> are available in the Git repository at:
>
>   https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2019-03-08
>
> for you to fetch changes up to 054be3605459d4342e9ee5a82ae0fcffeeb09e4d:
>
>   iotests: Wait for qemu to end in 223 (2019-03-06 11:05:27 -0600)
>
> 
> nbd patches for 2019-03-08
>
> - support TLS client authorization in NBD servers
> - iotest 223 race fix
>
> 
> Daniel P. Berrangé (3):
>   qemu-nbd: add support for authorization of TLS clients
>   nbd: allow authorization with nbd-server-start QMP command
>   nbd: fix outdated qapi docs syntax for tls-creds
>
> Eric Blake (1):
>   iotests: Wait for qemu to end in 223

Applied, thanks.

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

-- PMM

Re: [Qemu-devel] [PATCH 07/10] roms: build edk2 firmware binaries and variable store templates

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 3/9/19 1:48 AM, Laszlo Ersek wrote:
> Add the "efi" target to "Makefile".
> 
> Introduce "Makefile.edk2" for building and cleaning the firmware images
> and varstore templates.
> 
> Collect the common bits from the recipes in the helper script
> "edk2-build.sh".
> 
> Signed-off-by: Laszlo Ersek 
> ---
>  roms/Makefile  |   5 +
>  roms/Makefile.edk2 | 138 
>  roms/edk2-build.sh |  55 
>  3 files changed, 198 insertions(+)
> 
> diff --git a/roms/Makefile b/roms/Makefile
> index 2e83ececa25a..054b432834ba 100644
> --- a/roms/Makefile
> +++ b/roms/Makefile
> @@ -61,6 +61,7 @@ default:
>   @echo "  skiboot-- update skiboot.lid"
>   @echo "  u-boot.e500-- update u-boot.e500"
>   @echo "  u-boot.sam460  -- update u-boot.sam460"
> + @echo "  efi-- update UEFI (edk2) platform firmware"
>  
>  bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
>   cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
> @@ -143,6 +144,9 @@ skiboot:
>   $(MAKE) -C skiboot CROSS=$(powerpc64_cross_prefix)
>   cp skiboot/skiboot.lid ../pc-bios/skiboot.lid
>  
> +efi: edk2-basetools
> + $(MAKE) -f Makefile.edk2
> +
>  clean:
>   rm -rf seabios/.config seabios/out seabios/builds
>   $(MAKE) -C sgabios clean
> @@ -153,3 +157,4 @@ clean:
>   rm -rf u-boot/build.e500
>   $(MAKE) -C u-boot-sam460ex distclean
>   $(MAKE) -C skiboot clean
> + $(MAKE) -f Makefile.edk2 clean
> diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
> new file mode 100644
> index ..ad6fff044cd6
> --- /dev/null
> +++ b/roms/Makefile.edk2
> @@ -0,0 +1,138 @@
> +# Makefile for building firmware binaries and variable store templates for a
> +# number of virtual platforms in edk2.
> +#
> +# Copyright (C) 2019, Red Hat, Inc.
> +#
> +# This program and the accompanying materials are licensed and made available
> +# under the terms and conditions of the BSD License that accompanies this
> +# distribution. The full text of the license may be found at
> +# .
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +toolchain = $(shell source ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
> +
> +licenses := \
> + edk2/License.txt \
> + edk2/OvmfPkg/License.txt \
> + edk2/CryptoPkg/Library/OpensslLib/openssl/LICENSE
> +
> +# The "edk2-arm-vars.fd" varstore template is suitable for aarch64 as well.
> +# Similarly, the "edk2-i386-vars.fd" varstore template is suitable for x86_64
> +# as well, independently of "secure" too.
> +all: \
> + ../pc-bios/edk2-aarch64-code.fd \
> + ../pc-bios/edk2-arm-code.fd \
> + ../pc-bios/edk2-i386-code.fd \
> + ../pc-bios/edk2-i386-secure-code.fd \
> + ../pc-bios/edk2-x86_64-code.fd \
> + ../pc-bios/edk2-x86_64-secure-code.fd \
> + \
> + ../pc-bios/edk2-arm-vars.fd \
> + ../pc-bios/edk2-i386-vars.fd \
> + \
> + ../pc-bios/edk2-licenses.txt
> +
> +submodules:
> + cd edk2 && git submodule update --init --force
> +
> +# See notes on the ".NOTPARALLEL" target and the "+" indicator in
> +# "tests/uefi-test-tools/Makefile".
> +.NOTPARALLEL:
> +
> +../pc-bios/edk2-aarch64-code.fd: submodules
> + +./edk2-build.sh \
> + aarch64 \
> + --arch=AARCH64 \
> + --platform=ArmVirtPkg/ArmVirtQemu.dsc \
> + -D NETWORK_IP6_ENABLE \
> + -D HTTP_BOOT_ENABLE
> + cp edk2/Build/ArmVirtQemu-AARCH64/DEBUG_$(call 
> toolchain,aarch64)/FV/QEMU_EFI.fd \
> + $@
> + truncate --size=64M $@
> +
> +../pc-bios/edk2-arm-code.fd: submodules
> + +./edk2-build.sh \
> + arm \
> + --arch=ARM \
> + --platform=ArmVirtPkg/ArmVirtQemu.dsc \
> + -D NETWORK_IP6_ENABLE \
> + -D HTTP_BOOT_ENABLE
> + cp edk2/Build/ArmVirtQemu-ARM/DEBUG_$(call 
> toolchain,arm)/FV/QEMU_EFI.fd \
> + $@
> + truncate --size=64M $@
> +
> +../pc-bios/edk2-i386-code.fd: submodules
> + +./edk2-build.sh \
> + i386 \
> + --arch=IA32 \
> + --platform=OvmfPkg/OvmfPkgIa32.dsc \
> + -D NETWORK_IP6_ENABLE \
> + -D HTTP_BOOT_ENABLE \
> + -D TLS_ENABLE \
> + -D TPM2_ENABLE \
> + -D TPM2_CONFIG_ENABLE
> + cp edk2/Build/OvmfIa32/DEBUG_$(call toolchain,i386)/FV/OVMF_CODE.fd $@
> +
> +../pc-bios/edk2-i386-secure-code.fd: submodules
> + +./edk2-build.sh \
> + i386 \
> + --arch=IA32 \
> + --platform=OvmfPkg/OvmfPkgIa32.dsc \
> + -D NETWORK_IP6_ENABLE \
> + -D HTTP_BOOT_ENABLE \
> + -D TLS_ENABLE \
> + -D TPM2_ENABLE \
> + -D TPM2_CONFIG_ENABLE \
> + -D SECURE_BOOT_ENABLE \
> +  

[Qemu-devel] [PATCH] tests: test-bdrv-graph-mod: fix memory leak

[Li Qiang]

Fixes: 2dbfadf
Spotted by ASAN when 'make check'.

Signed-off-by: Li Qiang 
---
 tests/test-bdrv-graph-mod.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/test-bdrv-graph-mod.c b/tests/test-bdrv-graph-mod.c
index 458dfa6661..8bf0fe735d 100644
--- a/tests/test-bdrv-graph-mod.c
+++ b/tests/test-bdrv-graph-mod.c
@@ -117,6 +117,7 @@ static void test_update_perm_tree(void)
 
 bdrv_unref(bs);
 blk_unref(root);
+error_free(local_err);
 }
 
 /*
-- 
2.17.1

[Qemu-devel] [PATCH v2] linux-user: Add missing IPV6 sockopts

[Helge Deller]

When running ssh over IPv6 with linux-user I faced this warning:
 Unsupported setsockopt level=41 optname=67
 setsockopt IPV6_TCLASS 32: Protocol not available:

This patch adds code to the linux-user emulatation for setting and
retrieving of a few missing IPV6 options, including IPV6_TCLASS.

Signed-off-by: Helge Deller 

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 208fd1813d..0da51b1208 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1871,6 +1874,20 @@ static abi_long do_setsockopt(int sockfd, int level, int 
optname,
 case IPV6_RECVHOPLIMIT:
 case IPV6_2292HOPLIMIT:
 case IPV6_CHECKSUM:
+case IPV6_ADDRFORM:
+case IPV6_2292PKTINFO:
+case IPV6_RECVTCLASS:
+case IPV6_RECVRTHDR:
+case IPV6_2292RTHDR:
+case IPV6_RECVHOPOPTS:
+case IPV6_2292HOPOPTS:
+case IPV6_RECVDSTOPTS:
+case IPV6_2292DSTOPTS:
+case IPV6_TCLASS:
+case IPV6_RECVPATHMTU:
+case IPV6_TRANSPARENT:
+case IPV6_FREEBIND:
+case IPV6_RECVORIGDSTADDR:
 val = 0;
 if (optlen < sizeof(uint32_t)) {
 return -TARGET_EINVAL;
@@ -2365,6 +2382,20 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 case IPV6_RECVHOPLIMIT:
 case IPV6_2292HOPLIMIT:
 case IPV6_CHECKSUM:
+case IPV6_ADDRFORM:
+case IPV6_2292PKTINFO:
+case IPV6_RECVTCLASS:
+case IPV6_RECVRTHDR:
+case IPV6_2292RTHDR:
+case IPV6_RECVHOPOPTS:
+case IPV6_2292HOPOPTS:
+case IPV6_RECVDSTOPTS:
+case IPV6_2292DSTOPTS:
+case IPV6_TCLASS:
+case IPV6_RECVPATHMTU:
+case IPV6_TRANSPARENT:
+case IPV6_FREEBIND:
+case IPV6_RECVORIGDSTADDR:
 if (get_user_u32(len, optlen))
 return -TARGET_EFAULT;
 if (len < 0)

Re: [Qemu-devel] [PATCH] Added periodic IRQ support for bcm2836_control local timer

[bzt]

Hi,

Okay, as you wish. My code works either way and on real hardware as
well, because I acknowledge the periodic IRQ as soon as possible, so
good for me.

Sign-off-by: Zoltán Baldaszti 
Subject: [PATCH] Added periodic IRQ support for bcm2836_control local timer
diff --git a/hw/intc/bcm2836_control.c b/hw/intc/bcm2836_control.c
index cfa5bc7365..82d2f51ffe 100644
--- a/hw/intc/bcm2836_control.c
+++ b/hw/intc/bcm2836_control.c
@@ -7,7 +7,13 @@
  * This code is licensed under the GNU GPLv2 and later.
  *
  * At present, only implements interrupt routing, and mailboxes (i.e.,
- * not local timer, PMU interrupt, or AXI counters).
+ * not PMU interrupt, or AXI counters).
+ *
+ * ARM Local Timer IRQ Copyright (c) 2019. Zoltán Baldaszti
+ * The IRQ_TIMER support is still very basic, does not provide timer counter
+ * access and other timer features, it just generates periodic IRQs. But it
+ * still requires not only the interrupt enable, but the timer enable bit to
+ * be set.
  *
  * Ref:
  * 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf
@@ -18,6 +24,9 @@
 #include "qemu/log.h"

 #define REG_GPU_ROUTE   0x0c
+#define REG_LOCALTIMERROUTING   0x24
+#define REG_LOCALTIMERCONTROL   0x34
+#define REG_LOCALTIMERACK   0x38
 #define REG_TIMERCONTROL0x40
 #define REG_MBOXCONTROL 0x50
 #define REG_IRQSRC  0x60
@@ -43,6 +52,13 @@
 #define IRQ_TIMER   11
 #define IRQ_MAX IRQ_TIMER

+#define LOCALTIMER_FREQ  3840
+#define LOCALTIMER_INTFLAG   (1 << 31)
+#define LOCALTIMER_RELOAD(1 << 30)
+#define LOCALTIMER_INTENABLE (1 << 29)
+#define LOCALTIMER_ENABLE(1 << 28)
+#define LOCALTIMER_VALUE(x)  ((x) & 0xfff)
+
 static void deliver_local(BCM2836ControlState *s, uint8_t core, uint8_t irq,
   uint32_t controlreg, uint8_t controlidx)
 {
@@ -78,6 +94,17 @@ static void bcm2836_control_update(BCM2836ControlState *s)
 s->fiqsrc[s->route_gpu_fiq] |= (uint32_t)1 << IRQ_GPU;
 }

+/* handle THE local timer interrupt for one of the cores' IRQ/FIQ */
+if ((s->local_timer_control & LOCALTIMER_INTENABLE) &&
+(s->local_timer_control & LOCALTIMER_INTFLAG)) {
+/* note: this will keep firing the IRQ as Peter asked */
+if (s->route_localtimer & 4) {
+s->fiqsrc[(s->route_localtimer & 3)] |= (uint32_t)1 << IRQ_TIMER;
+} else {
+s->irqsrc[(s->route_localtimer & 3)] |= (uint32_t)1 << IRQ_TIMER;
+}
+}
+
 for (i = 0; i < BCM2836_NCORES; i++) {
 /* handle local timer interrupts for this core */
 if (s->timerirqs[i]) {
@@ -162,6 +189,54 @@ static void bcm2836_control_set_gpu_fiq(void
*opaque, int irq, int level)
 bcm2836_control_update(s);
 }

+static void bcm2836_control_local_timer_set_next(void *opaque)
+{
+BCM2836ControlState *s = opaque;
+uint64_t next_event;
+
+assert(LOCALTIMER_VALUE(s->local_timer_control) > 0);
+
+next_event = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
+muldiv64(LOCALTIMER_VALUE(s->local_timer_control),
+NANOSECONDS_PER_SECOND, LOCALTIMER_FREQ);
+timer_mod(&s->timer, next_event);
+}
+
+static void bcm2836_control_local_timer_tick(void *opaque)
+{
+BCM2836ControlState *s = opaque;
+
+bcm2836_control_local_timer_set_next(s);
+
+s->local_timer_control |= LOCALTIMER_INTFLAG;
+bcm2836_control_update(s);
+}
+
+static void bcm2836_control_local_timer_control(void *opaque, uint32_t val)
+{
+BCM2836ControlState *s = opaque;
+
+s->local_timer_control = val;
+if (val & LOCALTIMER_ENABLE) {
+bcm2836_control_local_timer_set_next(s);
+} else {
+timer_del(&s->timer);
+}
+}
+
+static void bcm2836_control_local_timer_ack(void *opaque, uint32_t val)
+{
+BCM2836ControlState *s = opaque;
+
+if (val & LOCALTIMER_INTFLAG) {
+s->local_timer_control &= ~LOCALTIMER_INTFLAG;
+}
+if ((val & LOCALTIMER_RELOAD) &&
+(s->local_timer_control & LOCALTIMER_ENABLE)) {
+bcm2836_control_local_timer_set_next(s);
+}
+}
+
 static uint64_t bcm2836_control_read(void *opaque, hwaddr offset,
unsigned size)
 {
 BCM2836ControlState *s = opaque;
@@ -170,6 +245,12 @@ static uint64_t bcm2836_control_read(void
*opaque, hwaddr offset, unsigned size)
 assert(s->route_gpu_fiq < BCM2836_NCORES
&& s->route_gpu_irq < BCM2836_NCORES);
 return ((uint32_t)s->route_gpu_fiq << 2) | s->route_gpu_irq;
+} else if (offset == REG_LOCALTIMERROUTING) {
+return s->route_localtimer;
+} else if (offset == REG_LOCALTIMERCONTROL) {
+return s->local_timer_control;
+} else if (offset == REG_LOCALTIMERACK) {
+return 0;
 } else if (offset >= REG_TIMERCONTROL && offset < REG_MBOXCONTROL) {
 return s->timercontrol[(offset - REG_TIMERCONTROL) >> 2];
 } else if (offset >= REG_MBOXCONTROL && offset < REG_IRQSRC) {
@@ -195,6 +276,12 @@ static void

Re: [Qemu-devel] [PATCH v3 2/2] hw/nvram/fw_cfg: Use the ldst API

[Laurent Vivier]

On 09/03/2019 19:19, Philippe Mathieu-Daudé wrote:
> The load/store API eases code review.
> 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/nvram/fw_cfg.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 7fdf04adc9..3d8859e333 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -85,7 +85,7 @@ static char *read_splashfile(char *filename, gsize 
> *file_sizep,
>  }
>  
>  /* check magic ID */
> -filehead = ((content[0] & 0xff) + (content[1] << 8)) & 0x;
> +filehead = lduw_le_p(content);
>  if (filehead == 0xd8ff) {
>  file_type = JPG_FILE;
>  } else if (filehead == 0x4d42) {
> @@ -96,7 +96,7 @@ static char *read_splashfile(char *filename, gsize 
> *file_sizep,
>  
>  /* check BMP bpp */
>  if (file_type == BMP_FILE) {
> -bmp_bpp = (content[28] + (content[29] << 8)) & 0x;
> +bmp_bpp = lduw_le_p(&content[28]);
>  if (bmp_bpp != 24) {
>  goto error;
>  }
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v3 1/2] hw/arm/virt: Remove null-check in virt_build_smbios()

[Laurent Vivier]

On 09/03/2019 19:19, Philippe Mathieu-Daudé wrote:
> Since commit 578f3c7b0835 ("arm: add fw_cfg to "virt" board",
> 2014-12-22), the machvirt_init() unconditionally creates the
> fw_cfg object.  Later, commit c30e15658b1b ("smbios: implement
> smbios support for mach-virt", 2015-09-07) added a superfluous
> null-check on it.
> Remove this superfluous check.
> 
> Reviewed-by: Laszlo Ersek 
> Reviewed-by: Markus Armbruster 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v2: Corrected commit reference (Laszlo)
> v3: Dropped 'Fixes:' (Markus)
> ---
>  hw/arm/virt.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 7f66ddad89..377e95a4cd 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1281,10 +1281,6 @@ static void virt_build_smbios(VirtMachineState *vms)
>  size_t smbios_tables_len, smbios_anchor_len;
>  const char *product = "QEMU Virtual Machine";
>  
> -if (!vms->fw_cfg) {
> -return;
> -}
> -
>  if (kvm_enabled()) {
>  product = "KVM Virtual Machine";
>  }
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH] vfio-pci: enable by default

[Daniel Henrique Barboza]

Just faced this problem when trying to test vfio-pci using upstream:

qemu-system-ppc64: -device vfio-pci,host=0035:03:00.0,id=hostdev8: 
'vfio-pci' is not a valid device model name



This patch fixed it.

Tested-by: Daniel Henrique Barboza 


On 3/8/19 2:36 PM, Paolo Bonzini wrote:

CONFIG_VFIO_PCI was not "default y" - and once you do that, it is also important
to disable it if PCI is not there.

Reported-by: Alex Williamson 
Signed-off-by: Paolo Bonzini 
---
  hw/vfio/Kconfig | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
index ebda9fdf22..34da2a3cfd 100644
--- a/hw/vfio/Kconfig
+++ b/hw/vfio/Kconfig
@@ -4,8 +4,9 @@ config VFIO
  
  config VFIO_PCI

  bool
+default y
  select VFIO
-depends on LINUX
+depends on LINUX && PCI
  
  config VFIO_CCW

  bool

Re: [Qemu-devel] [libvirt] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option

[Markus Armbruster]

Daniel P. Berrangé  writes:

> On Wed, Mar 06, 2019 at 08:03:48PM +0100, Igor Mammedov wrote:
>> On Mon, 4 Mar 2019 16:35:16 +
>> Daniel P. Berrangé  wrote:
>> 
>> > On Mon, Mar 04, 2019 at 05:20:13PM +0100, Michal Privoznik wrote:
>> > > We couldn't have done that. How we would migrate from older qemu?
>> > > 
>> > > Anyway, now that I look into this (esp. git log) I came accross:
>> > > 
>> > > commit f309db1f4d51009bad0d32e12efc75530b66836b
>> > > Author: Michal Privoznik 
>> > > AuthorDate: Thu Dec 18 12:36:48 2014 +0100
>> > > Commit: Michal Privoznik 
>> > > CommitDate: Fri Dec 19 07:44:44 2014 +0100
>> > > 
>> > > qemu: Create memory-backend-{ram,file} iff needed
>> > > 
>> > > Or this 7832fac84741d65e851dbdbfaf474785cbfdcf3c. We did try to generated
>> > > newer cmd line but then for various reasong (e.g. avoiding triggering a 
>> > > qemu
>> > > bug) we turned it off and make libvirt default to older (now deprecated) 
>> > > cmd
>> > > line.
>> > > 
>> > > Frankly, I don't know how to proceed. Unless qemu is fixed to allow
>> > > migration from deprecated to new cmd line (unlikely, if not impossible,
>> > > right?) then I guess the only approach we can have is that:
>> > > 
>> > > 1) whenever so called cold booting a new machine (fresh, brand new start 
>> > > of
>> > > a new domain) libvirt would default to modern cmd line,
>> > > 
>> > > 2) on migration, libvirt would record in the migration stream (or status 
>> > > XML
>> > > or wherever) that modern cmd line was generated and thus it'll make the
>> > > destination generate modern cmd line too.
>> > > 
>> > > This solution still suffers a couple of problems:
>> > > a) migration to older libvirt will fail as older libvirt won't recognize 
>> > > the
>> > > flag set in 2) and therefore would default to deprecated cmd line
>> > > b) migrating from one host to another won't modernize the cmd line
>> > > 
>> > > But I guess we have to draw a line somewhere (if we are not willing to 
>> > > write
>> > > those migration patches).
>> > 
>> > Yeah supporting backwards migration is a non-optional requirement from at
>> > least one of the mgmt apps using libvirt, so breaking the new to old case
>> > is something we always aim to avoid.
>> Aiming for support of 
>> "new QEMU + new machine type" => "old QEMU + non-existing machine type"
>> seems a bit difficult.
>
> That's not the scenario that's the problem. The problem is
>
>new QEMU + new machine type + new libvirt   -> new QEMU + new machine type 
> + old libvirt
>
> Previously released versions of libvirt will happily use any new machine
> type that QEMU introduces. So we can't make new libvirt use a different
> options, only for new machine types, as old libvirt supports those machine
> types too.

Avoiding tight coupling between QEMU und libvirt versions makes sense,
because having to upgrade stuff in lock-step is such a pain.

Does not imply we must support arbitrary combinations of QEMU and
libvirt versions.

Unless upstream libvirt's test matrix covers all versions of libvirt
against all released versions of QEMU, "previously released versions of
libvirt will continue to work with new QEMU" is largely an empty promise
anyway.  The real promise is more like "we won't break it intentionally;
good luck".

Mind, I'm not criticizing that real promise.  I'm criticizing cutting
yourself off from large areas of the solution space so you can continue
to pretend to yourself you actually deliver on the empty promise.

Now, if you limited what you promise to something more realistic,
ideally to something you actually test, we could talk about deprecation
schedules constructively.

For instance, if you promised

QEMU as of time T + its latest machine type + libvirt as of time T
 -> QEMU as of time T + its latest machine type + libvirt as of time T - d

will work for a certain value of d, then once all released versions of
libvirt since T - d support a new way of doing things, flipping to that
new way becomes a whole lot easier.