Re: [PATCH 0/2] tcg/aarch64: Fixes to vector ops

2021-02-21 Thread Stefan Weil

Am 20.02.21 um 22:29 schrieb Richard Henderson:


I guess it has been a while since I've run aa32 risu on aa64 host.

The launchpad bug is something that should have been seen from the
beginning, but the similar aa64 operations are expanded as integer
code, not vector code.  The aa32 neon code has only recently been
converted to use gvecs.

The cmle0 (zero) bug has been exposed by the recent constant
propagation improvements; previously we saw a reg/reg compare.


r~


Richard Henderson (2):
   tcg/aarch64: Fix I3617_CMLE0
   tcg/aarch64: Fix generation of "scalar" vector operations

  tcg/aarch64/tcg-target.c.inc | 213 ++-
  1 file changed, 182 insertions(+), 31 deletions(-)



Thanks. This fixes https://bugs.launchpad.net/qemu/+bug/1916112.

Tested-by: Stefan Weil 






Re: who's using the ozlabs patchwork install for QEMU patches ?

2021-02-21 Thread Cédric Le Goater
On 2/19/21 5:26 PM, Peter Maydell wrote:
> Does anybody use the ozlabs patchwork install for QEMU patches,
> either occasionally or on a regular basis ?
> http://patchwork.ozlabs.org/project/qemu-devel/list/
> The admins for that system are trying to identify which of
> the various projects are really using their patchwork instances,
> so I figured I'd do a quick survey here. We don't use it
> as an official project tool but it's certainly possible to
> use it as an individual developer in one way or another.
> 
> (Personally I am in the "occasionally it's useful for finding
> a patch which didn't get archived by patchew or the 'patches'
> tool for some reason" camp at the moment.)

I do on a regular basis. 

Thanks,

C. 



[PATCH] migration: Remove time_t cast for OpenBSD

2021-02-21 Thread Brad Smith
OpenBSD has supported 64-bit time_t across all archs since 5.5 released in 2014.

Remove a time_t cast that is no longer necessary.


Signed-off-by: Brad Smith 

diff --git a/migration/savevm.c b/migration/savevm.c
index 52e2d72e4b..9557f85ba9 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2849,8 +2849,7 @@ bool save_snapshot(const char *name, bool overwrite, 
const char *vmstate,
 if (name) {
 pstrcpy(sn->name, sizeof(sn->name), name);
 } else {
-/* cast below needed for OpenBSD where tv_sec is still 'long' */
-localtime_r((const time_t *)_sec, );
+localtime_r(_sec, );
 strftime(sn->name, sizeof(sn->name), "vm-%Y%m%d%H%M%S", );
 }
 



Re: who's using the ozlabs patchwork install for QEMU patches ?

2021-02-21 Thread Greg Kurz
On Fri, 19 Feb 2021 17:51:02 +0100
Thomas Huth  wrote:

> On 19/02/2021 17.26, Peter Maydell wrote:
> > Does anybody use the ozlabs patchwork install for QEMU patches,
> > either occasionally or on a regular basis ?
> > http://patchwork.ozlabs.org/project/qemu-devel/list/
> > The admins for that system are trying to identify which of
> > the various projects are really using their patchwork instances,
> > so I figured I'd do a quick survey here. We don't use it
> > as an official project tool but it's certainly possible to
> > use it as an individual developer in one way or another.
> 
> I think it might be used by some of the ppc hackers ... so CC:-ing to 
> qemu-pcc ...
> 

I do on a very regular basis.

>   Thomas
> 
> 




[PATCH 3/3] hw/block/nvme: report non-mdts command size limit for dsm

2021-02-21 Thread Klaus Jensen
From: Gollu Appalanaidu 

Dataset Management is not subject to MDTS, but exceeded a certain size
per range causes internal looping. Report this limit (DMRSL) in the NVM
command set specific identify controller data structure.

Signed-off-by: Gollu Appalanaidu 
Signed-off-by: Klaus Jensen 
---
 hw/block/nvme.h   |  1 +
 include/block/nvme.h  | 11 +++
 hw/block/nvme.c   | 30 --
 hw/block/trace-events |  1 +
 4 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/hw/block/nvme.h b/hw/block/nvme.h
index cb2b5175f1a1..3046b82b3da1 100644
--- a/hw/block/nvme.h
+++ b/hw/block/nvme.h
@@ -172,6 +172,7 @@ typedef struct NvmeCtrl {
 int aer_queued;
 
 uint8_t zasl;
+uint32_tdmrsl;
 
 NvmeSubsystem   *subsys;
 
diff --git a/include/block/nvme.h b/include/block/nvme.h
index b23f3ae2279f..16d8c4c90f7e 100644
--- a/include/block/nvme.h
+++ b/include/block/nvme.h
@@ -1041,6 +1041,16 @@ typedef struct NvmeIdCtrlZoned {
 uint8_t rsvd1[4095];
 } NvmeIdCtrlZoned;
 
+typedef struct NvmeIdCtrlNvm {
+uint8_t vsl;
+uint8_t wzsl;
+uint8_t wusl;
+uint8_t dmrl;
+uint32_tdmrsl;
+uint64_tdmsl;
+uint8_t rsvd16[4080];
+} NvmeIdCtrlNvm;
+
 enum NvmeIdCtrlOacs {
 NVME_OACS_SECURITY  = 1 << 0,
 NVME_OACS_FORMAT= 1 << 1,
@@ -1396,6 +1406,7 @@ static inline void _nvme_check_size(void)
 QEMU_BUILD_BUG_ON(sizeof(NvmeEffectsLog) != 4096);
 QEMU_BUILD_BUG_ON(sizeof(NvmeIdCtrl) != 4096);
 QEMU_BUILD_BUG_ON(sizeof(NvmeIdCtrlZoned) != 4096);
+QEMU_BUILD_BUG_ON(sizeof(NvmeIdCtrlNvm) != 4096);
 QEMU_BUILD_BUG_ON(sizeof(NvmeLBAF) != 4);
 QEMU_BUILD_BUG_ON(sizeof(NvmeLBAFE) != 16);
 QEMU_BUILD_BUG_ON(sizeof(NvmeIdNs) != 4096);
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 897b9ff0db91..5d6bba5fcb0d 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1777,6 +1777,10 @@ static uint16_t nvme_dsm(NvmeCtrl *n, NvmeRequest *req)
 trace_pci_nvme_dsm_deallocate(nvme_cid(req), nvme_nsid(ns), slba,
   nlb);
 
+if (nlb > n->dmrsl) {
+trace_pci_nvme_dsm_single_range_limit_exceeded(nlb, n->dmrsl);
+}
+
 offset = nvme_l2b(ns, slba);
 len = nvme_l2b(ns, nlb);
 
@@ -3202,21 +3206,24 @@ static uint16_t nvme_identify_ctrl(NvmeCtrl *n, 
NvmeRequest *req)
 static uint16_t nvme_identify_ctrl_csi(NvmeCtrl *n, NvmeRequest *req)
 {
 NvmeIdentify *c = (NvmeIdentify *)>cmd;
-NvmeIdCtrlZoned id = {};
+uint8_t id[NVME_IDENTIFY_DATA_SIZE] = {};
 
 trace_pci_nvme_identify_ctrl_csi(c->csi);
 
-if (c->csi == NVME_CSI_NVM) {
-return nvme_rpt_empty_id_struct(n, req);
-} else if (c->csi == NVME_CSI_ZONED) {
-if (n->params.zasl_bs) {
-id.zasl = n->zasl;
-}
-return nvme_dma(n, (uint8_t *), sizeof(id),
-DMA_DIRECTION_FROM_DEVICE, req);
+switch (c->csi) {
+case NVME_CSI_NVM:
+((NvmeIdCtrlNvm *))->dmrsl = cpu_to_le32(n->dmrsl);
+break;
+
+case NVME_CSI_ZONED:
+((NvmeIdCtrlZoned *))->zasl = n->zasl;
+break;
+
+default:
+return NVME_INVALID_FIELD | NVME_DNR;
 }
 
-return NVME_INVALID_FIELD | NVME_DNR;
+return nvme_dma(n, id, sizeof(id), DMA_DIRECTION_FROM_DEVICE, req);
 }
 
 static uint16_t nvme_identify_ns(NvmeCtrl *n, NvmeRequest *req)
@@ -4670,6 +4677,9 @@ int nvme_register_namespace(NvmeCtrl *n, NvmeNamespace 
*ns, Error **errp)
 
 n->namespaces[nsid - 1] = ns;
 
+n->dmrsl = MIN_NON_ZERO(n->dmrsl,
+BDRV_REQUEST_MAX_BYTES / nvme_l2b(ns, 1));
+
 return 0;
 }
 
diff --git a/hw/block/trace-events b/hw/block/trace-events
index 1f958d09d2a9..27940fe2e98a 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -51,6 +51,7 @@ pci_nvme_copy_cb(uint16_t cid) "cid %"PRIu16""
 pci_nvme_block_status(int64_t offset, int64_t bytes, int64_t pnum, int ret, 
bool zeroed) "offset %"PRId64" bytes %"PRId64" pnum %"PRId64" ret 0x%x zeroed 
%d"
 pci_nvme_dsm(uint16_t cid, uint32_t nsid, uint32_t nr, uint32_t attr) "cid 
%"PRIu16" nsid %"PRIu32" nr %"PRIu32" attr 0x%"PRIx32""
 pci_nvme_dsm_deallocate(uint16_t cid, uint32_t nsid, uint64_t slba, uint32_t 
nlb) "cid %"PRIu16" nsid %"PRIu32" slba %"PRIu64" nlb %"PRIu32""
+pci_nvme_dsm_single_range_limit_exceeded(uint32_t nlb, uint32_t dmrsl) "nlb 
%"PRIu32" dmrsl %"PRIu32""
 pci_nvme_compare(uint16_t cid, uint32_t nsid, uint64_t slba, uint32_t nlb) 
"cid %"PRIu16" nsid %"PRIu32" slba 0x%"PRIx64" nlb %"PRIu32""
 pci_nvme_compare_cb(uint16_t cid) "cid %"PRIu16""
 pci_nvme_aio_discard_cb(uint16_t cid) "cid %"PRIu16""
-- 
2.30.1




[PATCH 1/3] hw/block/nvme: nvme_identify fixes

2021-02-21 Thread Klaus Jensen
From: Gollu Appalanaidu 

Remove an unnecessary le_to_cpu conversion and add trace event for
Identify.

Signed-off-by: Gollu Appalanaidu 
Signed-off-by: Klaus Jensen 
---
 hw/block/nvme.c   | 5 -
 hw/block/trace-events | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 1cd82fa3c9fe..ddc83f7f7a19 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -3415,7 +3415,10 @@ static uint16_t nvme_identify(NvmeCtrl *n, NvmeRequest 
*req)
 {
 NvmeIdentify *c = (NvmeIdentify *)>cmd;
 
-switch (le32_to_cpu(c->cns)) {
+trace_pci_nvme_identify(nvme_cid(req), c->cns, le16_to_cpu(c->ctrlid),
+c->csi);
+
+switch (c->cns) {
 case NVME_ID_CNS_NS:
  /* fall through */
 case NVME_ID_CNS_NS_PRESENT:
diff --git a/hw/block/trace-events b/hw/block/trace-events
index b04f7a3e1890..1f958d09d2a9 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -61,6 +61,7 @@ pci_nvme_create_sq(uint64_t addr, uint16_t sqid, uint16_t 
cqid, uint16_t qsize,
 pci_nvme_create_cq(uint64_t addr, uint16_t cqid, uint16_t vector, uint16_t 
size, uint16_t qflags, int ien) "create completion queue, addr=0x%"PRIx64", 
cqid=%"PRIu16", vector=%"PRIu16", qsize=%"PRIu16", qflags=%"PRIu16", ien=%d"
 pci_nvme_del_sq(uint16_t qid) "deleting submission queue sqid=%"PRIu16""
 pci_nvme_del_cq(uint16_t cqid) "deleted completion queue, cqid=%"PRIu16""
+pci_nvme_identify(uint16_t cid, uint8_t cns, uint16_t ctrlid, uint8_t csi) 
"cid %"PRIu16" cns 0x%"PRIx8" ctrlid %"PRIu16" csi 0x%"PRIx8""
 pci_nvme_identify_ctrl(void) "identify controller"
 pci_nvme_identify_ctrl_csi(uint8_t csi) "identify controller, csi=0x%"PRIx8""
 pci_nvme_identify_ns(uint32_t ns) "nsid %"PRIu32""
-- 
2.30.1




[PATCH 0/3] hw/block/nvme: misc fixes

2021-02-21 Thread Klaus Jensen
From: Klaus Jensen 

Small set of misc fixes from Gollu.

Gollu Appalanaidu (3):
  hw/block/nvme: nvme_identify fixes
  hw/block/nvme: fix potential compilation error
  hw/block/nvme: report non-mdts command size limit for dsm

 hw/block/nvme.h   |  1 +
 include/block/nvme.h  | 11 +++
 hw/block/nvme.c   | 46 +++
 hw/block/trace-events |  2 ++
 4 files changed, 43 insertions(+), 17 deletions(-)

-- 
2.30.1




[PATCH 2/3] hw/block/nvme: fix potential compilation error

2021-02-21 Thread Klaus Jensen
From: Gollu Appalanaidu 

assert may be compiled to a noop and we could end up returning an
uninitialized status.

Fix this by always returning Internal Device Error as a fallback.

Signed-off-by: Gollu Appalanaidu 
Signed-off-by: Klaus Jensen 
---
 hw/block/nvme.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index ddc83f7f7a19..897b9ff0db91 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1232,7 +1232,7 @@ static uint16_t nvme_check_zone_write(NvmeNamespace *ns, 
NvmeZone *zone,
 
 static uint16_t nvme_check_zone_state_for_read(NvmeZone *zone)
 {
-uint16_t status;
+uint64_t zslba = zone->d.zslba;
 
 switch (nvme_get_zone_state(zone)) {
 case NVME_ZONE_STATE_EMPTY:
@@ -1241,16 +1241,15 @@ static uint16_t nvme_check_zone_state_for_read(NvmeZone 
*zone)
 case NVME_ZONE_STATE_FULL:
 case NVME_ZONE_STATE_CLOSED:
 case NVME_ZONE_STATE_READ_ONLY:
-status = NVME_SUCCESS;
-break;
+return NVME_SUCCESS;
 case NVME_ZONE_STATE_OFFLINE:
-status = NVME_ZONE_OFFLINE;
-break;
+trace_pci_nvme_err_zone_is_offline(zslba);
+return NVME_ZONE_OFFLINE;
 default:
 assert(false);
 }
 
-return status;
+return NVME_INTERNAL_DEV_ERROR;
 }
 
 static uint16_t nvme_check_zone_read(NvmeNamespace *ns, uint64_t slba,
-- 
2.30.1




Re: [PATCH v4 70/71] tests/tcg: Increase timeout for TCI

2021-02-21 Thread Richard Henderson
On 2/17/21 10:09 PM, Thomas Huth wrote:
>> -ifeq ($(CONFIG_DEBUG_TCG),y)
>> +# If TCG debugging, or TCI is enabled things are a lot slower
>> +ifneq ($(CONFIG_TCG_INTERPRETER),)
>> +TIMEOUT=90
>> +else ifneq ($(CONFIG_DEBUG_TCG),)
>>   TIMEOUT=60
>>   else
>>   TIMEOUT=15
> 
> Reviewed-by: Thomas Huth 
> 
> Does it even get slower if you enable both at the same time, TCG debugging and
> TCI?

As it happens, my testing was with --enable-debug-tcg.
So, unless you're doing --enable-debug (-O0) testing, we should be fine.


r~



Re: [PATCH v5 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook

2021-02-21 Thread Erik Skultety
On Fri, Feb 19, 2021 at 04:58:37PM -0500, Cleber Rosa wrote:
> To have the jobs dispatched to custom runners, gitlab-runner must
> be installed, active as a service and properly configured.  The
> variables file and playbook introduced here should help with those
> steps.
> 
> The playbook introduced here covers a number of different Linux
> distributions and FreeBSD, and are intended to provide a reproducible
> environment.
> 
> Signed-off-by: Cleber Rosa 
> Reviewed-by: Daniel P. Berrangé 
> ---
>  docs/devel/ci.rst  | 58 ++
>  scripts/ci/setup/.gitignore|  1 +
>  scripts/ci/setup/gitlab-runner.yml | 65 ++
>  scripts/ci/setup/vars.yml.template | 13 ++
>  4 files changed, 137 insertions(+)
>  create mode 100644 scripts/ci/setup/.gitignore
>  create mode 100644 scripts/ci/setup/gitlab-runner.yml
>  create mode 100644 scripts/ci/setup/vars.yml.template
> 
> diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst
> index a556558435..9f9c4bd3f9 100644
> --- a/docs/devel/ci.rst
> +++ b/docs/devel/ci.rst
> @@ -56,3 +56,61 @@ To run the playbook, execute::
>  
>cd scripts/ci/setup
>ansible-playbook -i inventory build-environment.yml
> +
> +gitlab-runner setup and registration
> +
> +
> +The gitlab-runner agent needs to be installed on each machine that
> +will run jobs.  The association between a machine and a GitLab project
> +happens with a registration token.  To find the registration token for
> +your repository/project, navigate on GitLab's web UI to:

I think the word order should be "on GitLab's web UI navigate to:"

> +
> + * Settings (the gears like icon), then
> + * CI/CD, then
> + * Runners, and click on the "Expand" button, then
> + * Under "Set up a specific Runner manually", look for the value under
> +   "Use the following registration token during setup"
> +
> +Copy the ``scripts/ci/setup/vars.yml.template`` file to
> +``scripts/ci/setup/vars.yml``.  Then, set the
> +``gitlab_runner_registration_token`` variable to the value obtained
> +earlier.
> +
> +.. note:: gitlab-runner is not available from the standard location
> +  for all OS and architectures combinations.  For some systems,
> +  a custom build may be necessary.  Some builds are avaiable

s/avaiable/available

> +  at https://cleber.fedorapeople.org/gitlab-runner/ and this
> +  URI may be used as a value on ``vars.yml``
> +
> +To run the playbook, execute::
> +
> +  cd scripts/ci/setup
> +  ansible-playbook -i inventory gitlab-runner.yml
> +
> +Following the registration, it's necessary to configure the runner tags,
> +and optionally other configurations on the GitLab UI.  Navigate to:
> +
> + * Settings (the gears like icon), then
> + * CI/CD, then
> + * Runners, and click on the "Expand" button, then
> + * "Runners activated for this project", then
> + * Click on the "Edit" icon (next to the "Lock" Icon)
> +
> +Under tags, add values matching the jobs a runner should run.  For a
> +Ubuntu 20.04 aarch64 system, the tags should be set as::
> +
> +  ubuntu_20.04,aarch64
> +
> +Because the job definition at ``.gitlab-ci.d/custom-runners.yml``
> +would contain::
> +
> +  ubuntu-20.04-aarch64-all:
> +   tags:
> +   - ubuntu_20.04
> +   - aarch64
> +
> +It's also recommended to:
> +
> + * increase the "Maximum job timeout" to something like ``2h``
> + * uncheck the "Run untagged jobs" check box
> + * give it a better Description
> diff --git a/scripts/ci/setup/.gitignore b/scripts/ci/setup/.gitignore
> new file mode 100644
> index 00..f112d05dd0
> --- /dev/null
> +++ b/scripts/ci/setup/.gitignore
> @@ -0,0 +1 @@
> +vars.yml
> \ No newline at end of file
> diff --git a/scripts/ci/setup/gitlab-runner.yml 
> b/scripts/ci/setup/gitlab-runner.yml
> new file mode 100644
> index 00..ab1944965f
> --- /dev/null
> +++ b/scripts/ci/setup/gitlab-runner.yml
> @@ -0,0 +1,65 @@
> +---
> +- name: Installation of gitlab-runner
> +  hosts: all
> +  vars_files:
> +- vars.yml
> +  tasks:
> +- debug:
> +msg: 'Checking for a valid GitLab registration token'
> +  failed_when: "gitlab_runner_registration_token == 
> 'PLEASE_PROVIDE_A_VALID_TOKEN'"
> +
> +- name: Checks the availability of official gitlab-runner builds in the 
> archive
> +  uri:
> +url: https://s3.amazonaws.com/gitlab-runner-downloads/v{{ 
> gitlab_runner_version  }}/binaries/gitlab-runner-linux-386
> +method: HEAD
> +status_code:
> +  - 200
> +  - 403
> +  register: gitlab_runner_available_archive
> +
> +- name: Update base url
> +  set_fact:
> +gitlab_runner_base_url: 
> https://s3.amazonaws.com/gitlab-runner-downloads/v{{ gitlab_runner_version  
> }}/binaries/gitlab-runner-
> +  when: gitlab_runner_available_archive.status == 200
> +- debug:
> +msg: Base gitlab-runner url is {{ gitlab_runner_base_url  }}
> +
> +- name: 

Re: [RFC v1 08/38] target/arm/tcg: split softmmu parts of v8_cp_reginfo and el2_cp_reginfo

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> since ats_write64 is only used there, make it softmmu-only.
> 
> gt_cntvoff_write, gt_hyp_*_write and gt_hyp_timer_reset are only used
> in el2_cp_reginfo, so they can be softmmu-only too.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/tcg/helper-tcg.h |  16 ++--
>  target/arm/tcg/helper.c | 129 +++-
>  target/arm/tcg/softmmu/helper.c | 145 +---
>  3 files changed, 149 insertions(+), 141 deletions(-)

Hum.  As long as we're moving code around, let's put all the cp_regs stuff in
its own file, rather than creating another massive file with random stuff in it.


r~



Re: tests: n810 arm failing

2021-02-21 Thread Thomas Huth

On 21/02/2021 20.33, Peter Maydell wrote:

On Sun, 21 Feb 2021 at 17:26, Philippe Mathieu-Daudé  wrote:


Hi,

The n810 arm test failed on latest master:

https://gitlab.com/qemu-project/qemu/-/jobs/1045015424/artifacts/browse/build/tests/results/latest/test-results/26-tests_acceptance_machine_arm_n8x0.py_N8x0Machine.test_n810/


It passed on the gitlab CI run on the exact same commit hash
as 'staging' before I pushed the merge, though...


Looking at the following run, it failed with some timeouts as well:

 https://gitlab.com/qemu-project/qemu/-/pipelines/259425956

... but in completely different spots. So maybe it was "just" a global 
slow-down in the CI farm? (Which sounds somewhat worrisome, too ... I hope 
gitlab-CI is not going down the same road as travis-ci.org did during the 
past year)


 Thomas




Re: [RFC v1 05/38] target/arm: wrap arm_cpu_exec_interrupt in CONFIG_TCG

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> +#ifdef CONFIG_TCG
>  bool arm_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
>  {
>  CPUClass *cc = CPU_GET_CLASS(cs);
> @@ -607,6 +608,7 @@ bool arm_cpu_exec_interrupt(CPUState *cs, int 
> interrupt_request)
>  cc->tcg_ops->do_interrupt(cs);
>  return true;
>  }
> +#endif /* CONFIG_TCG */

I presume this function gets moved later?  What does this aid in the interim?


r~



Re: [RFC v1 03/38] arm: tcg: only build under CONFIG_TCG

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/tcg/meson.build | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Richard Henderson 

r~




Re: [RFC v1 02/38] target/arm: move helpers to tcg/

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana 
> ---
>  meson.build  |  1 +
>  target/arm/tcg/trace.h   |  1 +
>  target/arm/{ => tcg}/crypto_helper.c |  0
>  target/arm/{ => tcg}/debug_helper.c  |  0
>  target/arm/{ => tcg}/helper-a64.c|  0
>  target/arm/{ => tcg}/helper.c|  0
>  target/arm/{ => tcg}/iwmmxt_helper.c |  0
>  target/arm/{ => tcg}/m_helper.c  |  0
>  target/arm/{ => tcg}/mte_helper.c|  0
>  target/arm/{ => tcg}/neon_helper.c   |  0
>  target/arm/{ => tcg}/op_helper.c |  0
>  target/arm/{ => tcg}/pauth_helper.c  |  0
>  target/arm/{ => tcg}/sve_helper.c|  0
>  target/arm/{ => tcg}/tlb_helper.c|  0
>  target/arm/{ => tcg}/vec_helper.c|  0
>  target/arm/{ => tcg}/vfp_helper.c|  0
>  target/arm/meson.build   | 14 --
>  target/arm/tcg/meson.build   | 14 ++
>  target/arm/tcg/trace-events  | 10 ++
>  target/arm/trace-events  |  9 -
>  20 files changed, 26 insertions(+), 23 deletions(-)
>  create mode 100644 target/arm/tcg/trace.h
>  rename target/arm/{ => tcg}/crypto_helper.c (100%)
>  rename target/arm/{ => tcg}/debug_helper.c (100%)
>  rename target/arm/{ => tcg}/helper-a64.c (100%)
>  rename target/arm/{ => tcg}/helper.c (100%)
>  rename target/arm/{ => tcg}/iwmmxt_helper.c (100%)
>  rename target/arm/{ => tcg}/m_helper.c (100%)
>  rename target/arm/{ => tcg}/mte_helper.c (100%)
>  rename target/arm/{ => tcg}/neon_helper.c (100%)
>  rename target/arm/{ => tcg}/op_helper.c (100%)
>  rename target/arm/{ => tcg}/pauth_helper.c (100%)
>  rename target/arm/{ => tcg}/sve_helper.c (100%)
>  rename target/arm/{ => tcg}/tlb_helper.c (100%)
>  rename target/arm/{ => tcg}/vec_helper.c (100%)
>  rename target/arm/{ => tcg}/vfp_helper.c (100%)
>  create mode 100644 target/arm/tcg/trace-events

Can vec_internal.h be moved here too, rather than later?

Anyway,
Reviewed-by: Richard Henderson 

r~




Re: [RFC v1 01/38] target/arm: move translate modules to tcg/

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/{ => tcg}/translate-a64.h  |  0
>  target/arm/{ => tcg}/translate.h  |  0
>  target/arm/{ => tcg}/a32-uncond.decode|  0
>  target/arm/{ => tcg}/a32.decode   |  0
>  target/arm/{ => tcg}/m-nocp.decode|  0
>  target/arm/{ => tcg}/neon-dp.decode   |  0
>  target/arm/{ => tcg}/neon-ls.decode   |  0
>  target/arm/{ => tcg}/neon-shared.decode   |  0
>  target/arm/{ => tcg}/sve.decode   |  0
>  target/arm/{ => tcg}/t16.decode   |  0
>  target/arm/{ => tcg}/t32.decode   |  0
>  target/arm/{ => tcg}/vfp-uncond.decode|  0
>  target/arm/{ => tcg}/vfp.decode   |  0
>  target/arm/{ => tcg}/translate-a64.c  |  0
>  target/arm/{ => tcg}/translate-sve.c  |  0
>  target/arm/{ => tcg}/translate.c  |  0
>  target/arm/{ => tcg}/translate-neon.c.inc |  0
>  target/arm/{ => tcg}/translate-vfp.c.inc  |  0
>  target/arm/meson.build| 20 ++-
>  target/arm/tcg/meson.build| 24 +++
>  20 files changed, 26 insertions(+), 18 deletions(-)
>  rename target/arm/{ => tcg}/translate-a64.h (100%)
>  rename target/arm/{ => tcg}/translate.h (100%)
>  rename target/arm/{ => tcg}/a32-uncond.decode (100%)
>  rename target/arm/{ => tcg}/a32.decode (100%)
>  rename target/arm/{ => tcg}/m-nocp.decode (100%)
>  rename target/arm/{ => tcg}/neon-dp.decode (100%)
>  rename target/arm/{ => tcg}/neon-ls.decode (100%)
>  rename target/arm/{ => tcg}/neon-shared.decode (100%)
>  rename target/arm/{ => tcg}/sve.decode (100%)
>  rename target/arm/{ => tcg}/t16.decode (100%)
>  rename target/arm/{ => tcg}/t32.decode (100%)
>  rename target/arm/{ => tcg}/vfp-uncond.decode (100%)
>  rename target/arm/{ => tcg}/vfp.decode (100%)
>  rename target/arm/{ => tcg}/translate-a64.c (100%)
>  rename target/arm/{ => tcg}/translate-sve.c (100%)
>  rename target/arm/{ => tcg}/translate.c (100%)
>  rename target/arm/{ => tcg}/translate-neon.c.inc (100%)
>  rename target/arm/{ => tcg}/translate-vfp.c.inc (100%)
>  create mode 100644 target/arm/tcg/meson.build

Reviewed-by: Richard Henderson 

r~



Re: [RFC v1 32/38] target/arm: cpu: do not initialize TCG PMU for KVM

2021-02-21 Thread Richard Henderson
On 2/21/21 1:53 AM, Philippe Mathieu-Daudé wrote:
> On 2/21/21 10:24 AM, Claudio Fontana wrote:
>> From: Claudio Fontana 
>>
>> KVM uses its own PMU initialization.
>>
>> Signed-off-by: Claudio Fontana 
>> ---
>>  target/arm/cpu.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
>> index a8321fecf8..d334987cad 100644
>> --- a/target/arm/cpu.c
>> +++ b/target/arm/cpu.c
>> @@ -1648,6 +1648,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
>> **errp)
>>  unset_feature(env, ARM_FEATURE_PMU);
>>  }
>>  if (arm_feature(env, ARM_FEATURE_PMU)) {
>> +#ifdef CONFIG_TCG
> 
> Shouldn't this be #if !defined(CONFIG_KVM) ?

No, because that would break the normal build which enables both tcg and kvm.

But I think there shouldn't be an ifdef at all, just a stub.


r~



Re: [RFC v1 28/38] target/arm: make arm_pmu_timer_cb TCG-only, starting tcg-stub

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> @@ -634,10 +635,11 @@ static int cpu_pre_save(void *opaque)
>  {
>  ARMCPU *cpu = opaque;
>  
> -if (!kvm_enabled()) {
> +#ifdef CONFIG_TCG
> +if (tcg_enabled()) {
>  pmu_op_start(>env);
>  }
> -
> +#endif /* CONFIG_TCG */

Why the ifdef?  Seems like a lack of stub.
I agree that !kvm rather than tcg is a bug.


r~



Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

2021-02-21 Thread David Gibson
On Fri, Feb 19, 2021 at 03:13:33PM +1100, Alexey Kardashevskiy wrote:
> The following changes since commit ef450767d7d162dec67ec4674f85f9044a3d80cc:
> 
>   spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical() 
> (2021-02-17 11:50:21 +1100)
> 
> are available in the Git repository at:
> 
>   g...@github.com:aik/qemu.git tags/qemu-slof-20210217
> 
> for you to fetch changes up to 7745df3b2bc512e71badb52f8f07452260ad7409:
> 
>   pseries: Update SLOF firmware image (2021-02-19 14:56:39 +1100)

Merged into ppc-for-6.0, thanks.

> 
> 
> Alexey Kardashevskiy (1):
>   pseries: Update SLOF firmware image
> 
>  pc-bios/README   |   2 +-
>  pc-bios/slof.bin | Bin 968368 -> 96 bytes
>  roms/SLOF|   2 +-
>  3 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> *** Note: this is not for master, this is for pseries
> 
> This is mostly compiler warnings fixed but while doing this,
> a bug in MIN() in tcgbios was found.
> 
> Alexey Kardashevskiy (14):
>   helpers: Define MIN()
>   libc: Compile with -Wextra
>   elf: Compile with -Wextra
>   usb: Compile with -Wextra
>   veth: Compile with -Wextra
>   virtio: Compile with -Wextra
>   e1000: Compile with -Wextra
>   libnet: Compile with -Wextra
>   libhv: Compile with -Wextra
>   libnvram: Compile with -Wextra
>   libtpm: Compile with -Wextra
>   slof/prim: Compile with -Wextra
>   Makefile: Actually compile with -Wextra
>   version: update to 20210217
> 
> Thomas Huth (1):
>   virtio-serial: Remove superfluous serial-* words
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [RFC v1 27/38] target/arm: move sve_zcr_len_for_el to common_cpu

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> it is needed for KVM too.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu-common.c | 33 +
>  target/arm/tcg/helper.c | 33 -
>  2 files changed, 33 insertions(+), 33 deletions(-)

This is related to rebuild_hflags, I assume.
Fix that and this isn't needed.


r~



Re: [RFC v1 26/38] target/arm: move sve_exception_el to cpu

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> it is needed for KVM too, move away from tcg helpers.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu-softmmu.c| 60 +
>  target/arm/cpu-user.c   |  5 +++
>  target/arm/tcg/softmmu/helper.c | 59 
>  target/arm/tcg/user/helper.c|  5 ---
>  4 files changed, 65 insertions(+), 64 deletions(-)

This is related to rebuild_hflags, I assume.
Fix that and this isn't needed.


r~



Re: [RFC v1 25/38] target/arm: move fp_exception_el outside of tcg helpers

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> it is needed also for KVM.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu-softmmu.c| 95 +
>  target/arm/cpu-user.c   |  9 
>  target/arm/tcg/softmmu/helper.c | 92 ---
>  target/arm/tcg/user/helper.c|  8 ---
>  4 files changed, 104 insertions(+), 100 deletions(-)

This is related to rebuild_hflags, I assume.
Fix that and this isn't needed.


r~



Re: [RFC v1 24/38] target/arm: move aa64_va_parameter_tbi,tbid,tcma and arm_rebuild_hflags

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> they are needed for KVM too, move them out of TCG helpers.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/internals.h  |  37 +
>  target/arm/tcg/helper-tcg.h |  32 -
>  target/arm/cpu-common.c | 252 ++
>  target/arm/tcg/helper.c | 264 +---
>  4 files changed, 293 insertions(+), 292 deletions(-)
> 
> diff --git a/target/arm/internals.h b/target/arm/internals.h
> index 6589b63ebc..9eb5d7fd79 100644
> --- a/target/arm/internals.h
> +++ b/target/arm/internals.h
> @@ -1196,6 +1196,43 @@ static inline uint64_t 
> useronly_maybe_clean_ptr(uint32_t desc, uint64_t ptr)
>  return ptr;
>  }
>  
> +/*
> + * Convert a possible stage1+2 MMU index into the appropriate
> + * stage 1 MMU index
> + */
> +static inline ARMMMUIdx stage_1_mmu_idx(ARMMMUIdx mmu_idx)
> +{
> +switch (mmu_idx) {
> +case ARMMMUIdx_SE10_0:
> +return ARMMMUIdx_Stage1_SE0;
> +case ARMMMUIdx_SE10_1:
> +return ARMMMUIdx_Stage1_SE1;
> +case ARMMMUIdx_SE10_1_PAN:
> +return ARMMMUIdx_Stage1_SE1_PAN;
> +case ARMMMUIdx_E10_0:
> +return ARMMMUIdx_Stage1_E0;
> +case ARMMMUIdx_E10_1:
> +return ARMMMUIdx_Stage1_E1;
> +case ARMMMUIdx_E10_1_PAN:
> +return ARMMMUIdx_Stage1_E1_PAN;
> +default:
> +return mmu_idx;
> +}
> +}
> +
> +int aa64_va_parameter_tbi(uint64_t tcr, ARMMMUIdx mmu_idx);
> +int aa64_va_parameter_tbid(uint64_t tcr, ARMMMUIdx mmu_idx);

I can see these being needed for get-phys-addr -- and that probably answers my
arm_mmu_idx_el question earlier too.


> +uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
> +ARMMMUIdx mmu_idx);
> +uint32_t rebuild_hflags_a32(CPUARMState *env, int fp_el, ARMMMUIdx mmu_idx);
> +uint32_t rebuild_hflags_m32(CPUARMState *env, int fp_el, ARMMMUIdx mmu_idx);

However these really really shouldn't be used for !tcg.  I would even wrap
CPUARMState::hflags in #ifdef CONFIG_TCG to enforce that.

I think maybe the best option is

if (tcg_enabled()) {
rebuild_hflags();
}

so that we don't spend the time on the rebuild for a regular build that has
both tcg and kvm enabled, and the symbol gets
compiled out when tcg is disabled.


r~



[Bug 1836501] Re: cpu_address_space_init fails with assertion

2021-02-21 Thread Ravishankar
When I use gdb i see that the assert line uses:

   /* KVM cannot currently support multiple address spaces. */
assert(asidx == 0 || !kvm_enabled());

the asidx is 1. So since KVM is not supporting multiple addresses spaces
that the Raspi3 requires the assertion occurs.

I wonder what the workaround could be for this

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

Title:
  cpu_address_space_init fails with assertion

Status in QEMU:
  Expired

Bug description:
  qemu-system-arm does not start with version >= 2.6 and KVM enabled.

cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()'
  failed.

  Hardware is Odroid XU4 with Exynos with 4.9.61+ Tested with Debian
  Stretch (9) or Buster (10).

  Without KVM it is running fine but slow. I'm operating Debian Jessie
  with qemu 2.1 for a long time with KVM virtualization working
  flawlessly. When I upgraded to Stretch I ran into the trouble
  described before. I tried Debian Stretch and Buster with all Kernels
  provided by the Board manufacturer (Hardkernel).

  It seems to be related to the feature introduced in Version 2.6:
  https://wiki.qemu.org/ChangeLog/2.6
  - Support for a separate EL3 address space

  KVM is enabled, so I assume the adress space index asidx to be causing
  the assert to fail.

  dmesg | grep -i KVM
  [0.741714] kvm [1]: 8-bit VMID
  [0.741721] kvm [1]: IDMAP page: 40201000
  [0.741729] kvm [1]: HYP VA range: c000:
  [0.742543] kvm [1]: Hyp mode initialized successfully
  [0.742600] kvm [1]: vgic-v2@10484000
  [0.742924] kvm [1]: vgic interrupt IRQ16
  [0.742943] kvm [1]: virtual timer IRQ60

  Full command line is:
  qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -cpu host -enable-kvm -kernel 
vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device 
virtio-blk-device,drive=inst-blk -drive 
file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw 
console=ttyAMA0" -nographic

  Is there anything to do to understand, if this is a hardware related
  failure or probably just a missing parameter?

  Regards

  Lutz

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



Re: [PATCH v3 7/7] spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state

2021-02-21 Thread David Gibson
On Fri, Feb 19, 2021 at 06:31:46PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 2/16/21 11:31 PM, David Gibson wrote:
> > On Thu, Feb 11, 2021 at 07:52:46PM -0300, Daniel Henrique Barboza wrote:
> > > Handling errors in memory hotunplug in the pSeries machine is more complex
> > > than any other device type, because there are all the complications that 
> > > other
> > > devices has, and more.
> 
> [...]
> 
> > > 
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index ecce8abf14..4bcded4a1a 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -3575,6 +3575,36 @@ static SpaprDimmState 
> > > *spapr_recover_pending_dimm_state(SpaprMachineState *ms,
> > >   return spapr_pending_dimm_unplugs_add(ms, avail_lmbs, dimm);
> > >   }
> > > +void spapr_clear_pending_dimm_unplug_state(SpaprMachineState *spapr,
> > > +   PCDIMMDevice *dimm)
> > > +{
> > > +SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, dimm);
> > > +SpaprDrc *drc;
> > > +uint32_t nr_lmbs;
> > > +uint64_t size, addr_start, addr;
> > > +int i;
> > > +
> > > +if (ds) {
> > > +spapr_pending_dimm_unplugs_remove(spapr, ds);
> > > +}
> > 
> > Hrm... how would !ds arise?  Could this just be an assert?
> 
> !ds would appear if we do not assert g_assert(drc->dev) down there, where you
> suggested down below that a malicious/buggy code would trigger it, for 
> example.
> With that assert in place then this less likely to occcur.
> 
> I guess what I can do here is:
> 
> - remove the g_assert(drc->dev) from down below, since it's more related to 
> the
> logic of this function;
> 
> - here, check if drc->dev is NULL. Return doing nothing if that's the case 
> (all the
> function relies on drc->dev being valid);
> 
> - if drc->dev is not NULL, then we can g_assert(ds) and proceed with the rest 
> of
> the function
> 
> This way we become a little more tolerant on drc->dev being NULL, but if 
> drc->dev
> is valid we will expect a unplug dimm state to always exist and
> assert it.

Seems reasonable.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [RFC PATCH v2 06/11] hw/ppc: Restrict KVM to various PPC machines

2021-02-21 Thread David Gibson
On Fri, Feb 19, 2021 at 06:38:42PM +0100, Philippe Mathieu-Daudé wrote:
> Restrit KVM to the following PPC machines:
> - 40p
> - bamboo
> - g3beige
> - mac99
> - mpc8544ds
> - ppce500
> - pseries
> - sam460ex
> - virtex-ml507

Hrm.

The reason this list is kind of surprising is because there are 3
different "flavours" of KVM on ppc: KVM HV ("pseries" only), KVM PR
(almost any combination, theoretically, but kind of buggy in
practice), and the Book E specific KVM (Book-E systems with HV
extensions only).

But basically, qemu explicitly managing what accelerators are
available for each machine seems the wrong way around to me.  The
approach we've generally taken is that qemu requests the specific
features it needs of KVM, and KVM tells us whether it can supply those
or not (which may involve selecting between one of the several
flavours).

That way we can extend KVM to cover more situations without needing
corresponding changes in qemu every time.


> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> RFC: I'm surprise by this list, but this is the result of
>  auditing calls to kvm_enabled() checks.
> 
>  hw/ppc/e500plat.c  | 5 +
>  hw/ppc/mac_newworld.c  | 6 ++
>  hw/ppc/mac_oldworld.c  | 5 +
>  hw/ppc/mpc8544ds.c | 5 +
>  hw/ppc/ppc440_bamboo.c | 5 +
>  hw/ppc/prep.c  | 5 +
>  hw/ppc/sam460ex.c  | 5 +
>  hw/ppc/spapr.c | 5 +
>  8 files changed, 41 insertions(+)
> 
> diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
> index bddd5e7c48f..9701dbc2231 100644
> --- a/hw/ppc/e500plat.c
> +++ b/hw/ppc/e500plat.c
> @@ -67,6 +67,10 @@ HotplugHandler 
> *e500plat_machine_get_hotpug_handler(MachineState *machine,
>  
>  #define TYPE_E500PLAT_MACHINE  MACHINE_TYPE_NAME("ppce500")
>  
> +static const char *const valid_accels[] = {
> +"tcg", "kvm", NULL
> +};
> +
>  static void e500plat_machine_class_init(ObjectClass *oc, void *data)
>  {
>  PPCE500MachineClass *pmc = PPCE500_MACHINE_CLASS(oc);
> @@ -98,6 +102,7 @@ static void e500plat_machine_class_init(ObjectClass *oc, 
> void *data)
>  mc->max_cpus = 32;
>  mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("e500v2_v30");
>  mc->default_ram_id = "mpc8544ds.ram";
> +mc->valid_accelerators = valid_accels;
>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ETSEC_COMMON);
>   }
>  
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index e991db4addb..634f5ad19a0 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -578,6 +578,11 @@ static char *core99_fw_dev_path(FWPathProvider *p, 
> BusState *bus,
>  
>  return NULL;
>  }
> +
> +static const char *const valid_accels[] = {
> +"tcg", "kvm", NULL
> +};
> +
>  static int core99_kvm_type(MachineState *machine, const char *arg)
>  {
>  /* Always force PR KVM */
> @@ -595,6 +600,7 @@ static void core99_machine_class_init(ObjectClass *oc, 
> void *data)
>  mc->max_cpus = MAX_CPUS;
>  mc->default_boot_order = "cd";
>  mc->default_display = "std";
> +mc->valid_accelerators = valid_accels;
>  mc->kvm_type = core99_kvm_type;
>  #ifdef TARGET_PPC64
>  mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 44ee99be886..2c58f73b589 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -424,6 +424,10 @@ static char *heathrow_fw_dev_path(FWPathProvider *p, 
> BusState *bus,
>  return NULL;
>  }
>  
> +static const char *const valid_accels[] = {
> +"tcg", "kvm", NULL
> +};
> +
>  static int heathrow_kvm_type(MachineState *machine, const char *arg)
>  {
>  /* Always force PR KVM */
> @@ -444,6 +448,7 @@ static void heathrow_class_init(ObjectClass *oc, void 
> *data)
>  #endif
>  /* TOFIX "cad" when Mac floppy is implemented */
>  mc->default_boot_order = "cd";
> +mc->valid_accelerators = valid_accels;
>  mc->kvm_type = heathrow_kvm_type;
>  mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("750_v3.1");
>  mc->default_display = "std";
> diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
> index 81177505f02..92b0e926c1b 100644
> --- a/hw/ppc/mpc8544ds.c
> +++ b/hw/ppc/mpc8544ds.c
> @@ -36,6 +36,10 @@ static void mpc8544ds_init(MachineState *machine)
>  ppce500_init(machine);
>  }
>  
> +static const char *const valid_accels[] = {
> +"tcg", "kvm", NULL
> +};
> +
>  static void e500plat_machine_class_init(ObjectClass *oc, void *data)
>  {
>  MachineClass *mc = MACHINE_CLASS(oc);
> @@ -56,6 +60,7 @@ static void e500plat_machine_class_init(ObjectClass *oc, 
> void *data)
>  mc->max_cpus = 15;
>  mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("e500v2_v30");
>  mc->default_ram_id = "mpc8544ds.ram";
> +mc->valid_accelerators = valid_accels;
>  }
>  
>  #define TYPE_MPC8544DS_MACHINE  MACHINE_TYPE_NAME("mpc8544ds")
> diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
> index b156bcb9990..02501f489e4 100644
> --- a/hw/ppc/ppc440_bamboo.c
> 

Re: [PATCH v3 7/7] spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state

2021-02-21 Thread David Gibson
On Fri, Feb 19, 2021 at 05:04:23PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 2/16/21 11:31 PM, David Gibson wrote:
> > On Thu, Feb 11, 2021 at 07:52:46PM -0300, Daniel Henrique Barboza wrote:
> > > Handling errors in memory hotunplug in the pSeries machine is more complex
> > > than any other device type, because there are all the complications that 
> > > other
> > > devices has, and more.
> > > 
> > > For instance, determining a timeout for a DIMM hotunplug must consider if 
> > > it's a
> > > Hash-MMU or a Radix-MMU guest, because Hash guests takes longer to 
> > > hotunplug DIMMs.
> > > The size of the DIMM is also a factor, given that longer DIMMs naturally 
> > > takes
> > > longer to be hotunplugged from the kernel. And there's also the guest 
> > > memory usage to
> > > be considered: if there's a process that is consuming memory that would 
> > > be lost by
> > > the DIMM unplug, the kernel will postpone the unplug process until the 
> > > process
> > > finishes, and then initiate the regular hotunplug process. The first two
> > > considerations are manageable, but the last one is a deal breaker.
> > > 
> > > There is no sane way for the pSeries machine to determine the memory load 
> > > in the guest
> > > when attempting a DIMM hotunplug - and even if there was a way, the guest 
> > > can start
> > > using all the RAM in the middle of the unplug process and invalidate our 
> > > previous
> > > assumptions - and in result we can't even begin to calculate a timeout 
> > > for the
> > > operation. This means that we can't implement a viable timeout mechanism 
> > > for memory
> > > unplug in pSeries.
> > > 
> > > Going back to why we would consider an unplug timeout, the reason is that 
> > > we can't
> > > know if the kernel is giving up the unplug. Turns out that, sometimes, we 
> > > can.
> > > Consider a failed memory hotunplug attempt where the kernel will error 
> > > out with
> > > the following message:
> > > 
> > > 'pseries-hotplug-mem: Memory indexed-count-remove failed, adding any 
> > > removed LMBs'
> > > 
> > > This happens when there is a LMB that the kernel gave up in removing, and 
> > > the LMBs
> > > marked for removal of the same DIMM are now being added back. This 
> > > process happens
> > 
> > We need to be a little careful about terminology here.  From the
> > guest's point of view, there's no such thing as a DIMM, only LMBs.
> > What the guest is doing here is essentially rejecting a single "index
> > + number" DRC unplug request, which corresponds to one DIMM on the
> > qemu side.
> 
> I'll reword this paragraph to avoid using "DIMM" in the context of the guest
> kernel.
> 
> > 
> > > in the pseries kernel in [1], dlpar_memory_remove_by_ic() into 
> > > dlpar_add_lmb(), and
> > > after that update_lmb_associativity_index(). In this function, the kernel 
> > > is configuring
> > > the LMB DRC connector again. Note that this is a valid usage in LOPAR, as 
> > > stated in
> > > section "ibm,configure-connector RTAS Call":
> > > 
> > > 'A subsequent sequence of calls to ibm,configure-connector with the same 
> > > entry from
> > > the “ibm,drc-indexes” or “ibm,drc-info” property will restart the 
> > > configuration of
> > > devices which were not completely configured.'
> > > 
> > > We can use this kernel behavior in our favor. If a DRC connector 
> > > reconfiguration
> > > for a LMB that we marked as unplug pending happens, this indicates that 
> > > the kernel
> > > changed its mind about the unplug and is reasserting that it will keep 
> > > using the
> > > DIMM. In this case, it's safe to assume that the whole DIMM unplug was 
> > > cancelled.
> > > 
> > > This patch hops into rtas_ibm_configure_connector() and, in the scenario 
> > > described
> > > above, clear the unplug state for the DIMM device. This will not solve 
> > > all the
> > > problems we still have with memory unplug, but it will cover this case 
> > > where the
> > > kernel reconfigures LMBs after a failed unplug. We are a bit more 
> > > resilient,
> > > without using an unreliable timeout, and we didn't make the remaining 
> > > error cases
> > > any worse.
> > 
> > I wonder if we could use this as a beginning of a hotplug failure
> > reporting mechanism.  As noted, this is explicitly allowed by PAPR and
> > I think in general it makes sense that a configure-connector would
> > re-assert that the guest is using the resource and we can't unplug it.
> > 
> 
> I think it's worth looking into it. The kernel already does that in case of 
> hotunplug
> failure of LMBs (at least in this particular case), so it's a matter of 
> evaluating
> how hard it is to do the same for e.g. CPUs.
> 
> 
> > Could we extend guests to do an indicative configure-connector on any
> > unplug it knows it can't complete?  Or if configure-connector is too
> > disruptive could we use an (extra) H_SET_INDICATOR to "UNISOLATE"
> > state? If I'm reading right, that should be both permitted and a no-op
> > for existing PAPR 

Re: [RFC v1 23/38] target/arm: move arm_mmu_idx_el to common-cpu

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu-common.c | 51 +
>  target/arm/tcg/helper.c | 51 -
>  2 files changed, 51 insertions(+), 51 deletions(-)

How does this escape from tcg code?  I think this is indicative of something
else escaping first.


r~



Re: [RFC v1 20/38] target/arm: move arm_hcr_el2_eff to common_cpu

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
> From: Claudio Fontana 
> 
> extract it from the tcg helpers, as functionality is needed
> for KVM too.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu-common.c | 68 +
>  target/arm/tcg/helper.c | 68 -
>  2 files changed, 68 insertions(+), 68 deletions(-)

Hmm, not really.  The hypervisor (the linux kernel for kvm) uses EL2 itself,
and only exposes EL1 and EL0 to the virtualized guest.  Due to how
virtualization works on ARM, the same will be true for all hypervisors.

Thus, ARM_FEATURE_EL2 will always be unset, and arm_is_el2_enabled will always
be false.

I think you want a stub for !tcg like

/* EL2 is used by the hypervisor and never enabled for the guest. */
uint64_t arm_hcr_el2_eff(CPUARMState *env) { return 0; }


r~



Re: [PATCH v2] configure: fix --enable-fuzzing linker failures

2021-02-21 Thread Thomas Huth

On 21/02/2021 18.45, Alexander Bulekov wrote:

With --enable-fuzzing, QEMU_CFLAGS include -fsanitize=fuzzer-no-link.
This should allow us to build non-fuzzer binaries using objects
instrumented for fuzzing. However, to do that, we also need to link with
-fsanitize=fuzzer-no-link. We were not doing that.

Reported-by: Li Qiang ,
Signed-off-by: Alexander Bulekov 
---
v2: Fix a mistake in the added QEMU_LDFLAGS line

  configure | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/configure b/configure
index a79b3746d4..19f2b88589 100755
--- a/configure
+++ b/configure
@@ -6096,7 +6096,17 @@ if test "$fuzzing" = "yes" ; then
# If LIB_FUZZING_ENGINE is set, assume we are running on OSS-Fuzz, and the
# needed CFLAGS have already been provided
if test -z "${LIB_FUZZING_ENGINE+xxx}" ; then
+# Add CFLAGS to tell clang to add fuzzer-related instrumentation to all the
+# compiled code.
  QEMU_CFLAGS="$QEMU_CFLAGS -fsanitize=fuzzer-no-link"
+# To build non-fuzzer binaries with --enable-fuzzing, link everything with
+# fsanitize=fuzzer-no-link. Otherwise, the linker will be unable to bind
+# the fuzzer-related callbacks added by instrumentation.
+QEMU_LDFLAGS="$QEMU_LDFLAGS -fsanitize=fuzzer-no-link"
+# For the actual fuzzer binaries, we need to link against the libfuzzer
+# library. Provide the flags for doing this in FUZZ_EXE_LDFLAGS. The meson
+# rule for the fuzzer adds these to the link_args. They need to be
+# configurable, to support OSS-Fuzz
  FUZZ_EXE_LDFLAGS="-fsanitize=fuzzer"
else
  FUZZ_EXE_LDFLAGS="$LIB_FUZZING_ENGINE"



Reviewed-by: Thomas Huth 




[Bug 1836501] Re: cpu_address_space_init fails with assertion

2021-02-21 Thread Ravishankar
I am having a similar problem. I want to use KVM on jetson nano and boot
Raspbian Buster 32bit OS with native machine emulation.

Run into a similar problem. I used latest QEMU.

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

Title:
  cpu_address_space_init fails with assertion

Status in QEMU:
  Expired

Bug description:
  qemu-system-arm does not start with version >= 2.6 and KVM enabled.

cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()'
  failed.

  Hardware is Odroid XU4 with Exynos with 4.9.61+ Tested with Debian
  Stretch (9) or Buster (10).

  Without KVM it is running fine but slow. I'm operating Debian Jessie
  with qemu 2.1 for a long time with KVM virtualization working
  flawlessly. When I upgraded to Stretch I ran into the trouble
  described before. I tried Debian Stretch and Buster with all Kernels
  provided by the Board manufacturer (Hardkernel).

  It seems to be related to the feature introduced in Version 2.6:
  https://wiki.qemu.org/ChangeLog/2.6
  - Support for a separate EL3 address space

  KVM is enabled, so I assume the adress space index asidx to be causing
  the assert to fail.

  dmesg | grep -i KVM
  [0.741714] kvm [1]: 8-bit VMID
  [0.741721] kvm [1]: IDMAP page: 40201000
  [0.741729] kvm [1]: HYP VA range: c000:
  [0.742543] kvm [1]: Hyp mode initialized successfully
  [0.742600] kvm [1]: vgic-v2@10484000
  [0.742924] kvm [1]: vgic interrupt IRQ16
  [0.742943] kvm [1]: virtual timer IRQ60

  Full command line is:
  qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -cpu host -enable-kvm -kernel 
vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device 
virtio-blk-device,drive=inst-blk -drive 
file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw 
console=ttyAMA0" -nographic

  Is there anything to do to understand, if this is a hardware related
  failure or probably just a missing parameter?

  Regards

  Lutz

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



Re: [RFC v1 00/38] arm cleanup experiment for kvm-only build

2021-02-21 Thread Richard Henderson
On 2/21/21 1:24 AM, Claudio Fontana wrote:
>   target/arm: move psci.c into tcg/softmmu/

Terminology: the opposite of user-only is not "softmmu" but "system".

One glorious day in the far future user-only will, as an option, use softmmu.
It will fix all sorts of problems with alignment faults and host/guest virtual
address space mismatch.


r~



Re: [PATCH] gitlab-ci: Remove unused container images

2021-02-21 Thread Thomas Huth

On 20/02/2021 22.10, Alex Bennée wrote:


Thomas Huth  writes:


We're building a lot of containers in the gitlab-CI that we never use.
This takes away network bandwidth and CPU time from other jobs for no
use, so let's remove them for now. The individual containers could be
re-added later when we really need them.


They are used - when people run check-tcg their builds are cached via
gitlab.


Oh, I didn't know that. But where's the magic that tells the tcg tests to 
use the registry from gitlab?

"grep -ri gitlab tests/tcg" does not show any results?
Also some documentation would be helpful, docs/devel/testing.rst does not 
talk about gitlab at all...?


 Thomas




Re: [RFC PATCH 0/5] target/arm: Add MTE support to KVM guest

2021-02-21 Thread Haibo Xu
On Tue, 16 Feb 2021 at 19:20, Peter Maydell  wrote:
>
> Adding the migration maintainers to the cc list, because
> the real meat of this patchset is "how should the migration
> of MTE tags be integrated into the migration/ram.c code",
> which is pretty well out of my area of expertise...
>
> thanks
> -- PMM
>

Hi Peter,

Thanks for cc-ing to the related maintainers!

Regards,
Haibo

> On Mon, 8 Feb 2021 at 03:20, Haibo Xu  wrote:
> >
> > This series add support for MTE(Memory Tagging Extension)[1]
> > in KVM guest. It's based on Steven Price's kernel KVM patches
> > V7[2], and has been tested to ensure that test case[3] can be
> > passed in a KVM guest. Basic pre-copy migration test also passed
> > between two MTE enabled kvm guest.
> >
> > This is a RFC patch series becuase:
> > (1) Need to add some arm MTE specific codes to the ram migration
> > loop. There may be better way to do that in a more abstract way.
> > (2) Only pre-copy migration is supported and tested currently,
> > post-copy as well as compress/zero page migration are still WIP.
> >
> > All kinds of feedbacks are very welcomed, especially for the migration
> > support.
> >
> > Note:
> > (1) To support MTE migration, tags for one page are appended to
> > the page data during ram save iteration which make it easier
> > to sync the page data and tags.
> >
> > [1] https://community.arm.com/developer/ip-products/processors/b/
> > processors-ip-blog/posts/enhancing-memory-safety
> > [2] https://lwn.net/Articles/842827/
> > [3] https://elixir.bootlin.com/linux/latest/source/Documentation/
> > arm64/memory-tagging-extension.rst
> >
> > Haibo Xu (5):
> >   Update Linux headers with new MTE support
> >   Add basic MTE support to KVM guest
> >   Add APIs to get/set MTE tags
> >   Add migration support for KVM guest with MTE
> >   Enable the MTE support for KVM guest
> >
> >  hw/arm/virt.c | 44 +---
> >  include/hw/arm/virt.h |  2 +
> >  include/migration/misc.h  |  1 +
> >  linux-headers/linux/kvm.h | 15 +++
> >  migration/ram.c   | 86 ++-
> >  target/arm/cpu.c  |  2 +-
> >  target/arm/kvm.c  |  9 
> >  target/arm/kvm64.c| 31 ++
> >  target/arm/kvm_arm.h  |  2 +
> >  9 files changed, 176 insertions(+), 16 deletions(-)



[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host

2021-02-21 Thread Ven Karri
I am not sure if a separate slirp installation via macports is
necessary. When you install qemu via homebrew, it's supposed to install
any slirp related libarries as part of qemu installation. Having said
that, I haven't noticed a slirp package installed on my mac when I did a
`brew list`.

So, I don't know how exactly is qemu packing slirp libraries within
itself while installing on a mac. I think there's some kinda git option
during installation. Perhaps brew uses that.

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

Title:
  User mode networking not working properly on QEMU on Mac OS X host

Status in QEMU:
  New

Bug description:
  Steps to reproduce:

  1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur)
  2. Spin up a guest VM (say) Cent OS 8 using user mode networking.
  3. Install podman inside the guest
  4. Run podman pull alpine

  The result is:

  [root@localhost ~]# podman pull alpine
  Resolved "alpine" as an alias 
(/etc/containers/registries.conf.d/shortnames.conf)
  Trying to pull docker.io/library/alpine:latest...
  Getting image source signatures
  Copying blob ba3557a56b15 [==] 2.7MiB / 
2.7MiB
    unexpected EOF
  Error: Error writing blob: error storing blob to file 
"/var/tmp/storage851171596/1": error happened during read: unexpected EOF

  This is happening because QEMU is telling the guest that the TCP
  connection is closed even before reading all the data from the host
  socket and forwarding it to the guest.

  This issue doesn't happen on a Linux host. So, that tells me that this
  has something to do with QEMU installation on Mac OS X.

  This could be a slirp related issue. So, QEMU/slirp may need to work
  together on fixing this. Here's the link to the libslirp issue:

  https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35

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



[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host

2021-02-21 Thread John Arbuckle
I built QEMU from the git repo. My Windows XP and Mac OS 10.4 guests
cannot access the internet. I'm on a M1 Mac running Mac OS 11.1. I use
qemu-system-i386 and qemu-system-ppc.

I tried installing slirp from MacPorts but it is broken. It might have
been broken for years. See https://trac.macports.org/ticket/41875. So
slirp networking probably isn't going to work.



** Bug watch added: trac.macports.org #41875
   http://trac.macports.org/ticket/41875

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

Title:
  User mode networking not working properly on QEMU on Mac OS X host

Status in QEMU:
  New

Bug description:
  Steps to reproduce:

  1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur)
  2. Spin up a guest VM (say) Cent OS 8 using user mode networking.
  3. Install podman inside the guest
  4. Run podman pull alpine

  The result is:

  [root@localhost ~]# podman pull alpine
  Resolved "alpine" as an alias 
(/etc/containers/registries.conf.d/shortnames.conf)
  Trying to pull docker.io/library/alpine:latest...
  Getting image source signatures
  Copying blob ba3557a56b15 [==] 2.7MiB / 
2.7MiB
    unexpected EOF
  Error: Error writing blob: error storing blob to file 
"/var/tmp/storage851171596/1": error happened during read: unexpected EOF

  This is happening because QEMU is telling the guest that the TCP
  connection is closed even before reading all the data from the host
  socket and forwarding it to the guest.

  This issue doesn't happen on a Linux host. So, that tells me that this
  has something to do with QEMU installation on Mac OS X.

  This could be a slirp related issue. So, QEMU/slirp may need to work
  together on fixing this. Here's the link to the libslirp issue:

  https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35

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



Re: [PATCH] linux-user: fix O_NONBLOCK in signalfd4() and eventfd2() syscalls

2021-02-21 Thread Helge Deller

Dear qemu-stable,

can you please consider adding this patch to the qemu-stable branch.
Upstream commit 78721301138114cf37fb179a6cf73a27c1b3a927
Thanks,
Helge


On 2/13/21 8:16 PM, Laurent Vivier wrote:

Le 10/02/2021 à 07:12, Helge Deller a écrit :

On the hppa target userspace binaries may call signalfd4() and
eventfd2() with an old TARGET_O_NONBLOCK value of 00024 instead of
00020 for the "mask" syscall parameter, in which case the current
emulation doesn't handle the translation to the native O_NONBLOCK value
correctly.

The 0x04 bit is not masked out before the new O_NONBLOCK bit is set and
as such when calling the native syscall errors out with EINVAL.

Fix this by introducing TARGET_O_NONBLOCK_MASK which is used to mask off
all possible bits. This define defaults to TARGET_O_NONBLOCK when not
defined otherwise, so for all other targets the implementation will
behave as before.

This patch needs to be applied on top of my previous two patches.

Bug was found and patch was verified by using qemu-hppa as debian buildd
server on x86_64.

Signed-off-by: Helge Deller 

---

diff --git a/linux-user/hppa/target_fcntl.h b/linux-user/hppa/target_fcntl.h
index 08e3a4fcb0..4eb0ec98e2 100644
--- a/linux-user/hppa/target_fcntl.h
+++ b/linux-user/hppa/target_fcntl.h
@@ -9,6 +9,7 @@
  #define HPPA_TARGET_FCNTL_H

  #define TARGET_O_NONBLOCK00020
+#define TARGET_O_NONBLOCK_MASK 00024 /* includes old HP-UX NDELAY flag */
  #define TARGET_O_APPEND  00010
  #define TARGET_O_CREAT   00400 /* not fcntl */
  #define TARGET_O_EXCL02000 /* not fcntl */
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 27adee908e..3031aa342f 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -273,6 +273,11 @@ static type name (type1 arg1,type2 arg2,type3 arg3,type4 
arg4,type5 arg5,  \
  #define TARGET_NR__llseek TARGET_NR_llseek
  #endif

+/* some platforms need to mask more bits than just TARGET_O_NONBLOCK */
+#ifndef TARGET_O_NONBLOCK_MASK
+#define TARGET_O_NONBLOCK_MASK TARGET_O_NONBLOCK
+#endif
+
  #define __NR_sys_gettid __NR_gettid
  _syscall0(int, sys_gettid)

@@ -7719,7 +7724,7 @@ static abi_long do_signalfd4(int fd, abi_long mask, int 
flags)
  sigset_t host_mask;
  abi_long ret;

-if (flags & ~(TARGET_O_NONBLOCK | TARGET_O_CLOEXEC)) {
+if (flags & ~(TARGET_O_NONBLOCK_MASK | TARGET_O_CLOEXEC)) {
  return -TARGET_EINVAL;
  }
  if (!lock_user_struct(VERIFY_READ, target_mask, mask, 1)) {
@@ -12508,7 +12513,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  #if defined(TARGET_NR_eventfd2)
  case TARGET_NR_eventfd2:
  {
-int host_flags = arg2 & (~(TARGET_O_NONBLOCK | TARGET_O_CLOEXEC));
+int host_flags = arg2 & (~(TARGET_O_NONBLOCK_MASK | TARGET_O_CLOEXEC));
  if (arg2 & TARGET_O_NONBLOCK) {
  host_flags |= O_NONBLOCK;
  }



Applied to my linux-user-for-6.0 branch.

Thanks,
Laurent






Re: [PATCH v2] linux-user: fix O_NONBLOCK usage for hppa target

2021-02-21 Thread Helge Deller

Dear qemu-stable,

can you please consider adding this patch to the qemu-stable branch.
Upstream commit 2bdc74f3d7c4cacb65dbde910471c62992640275

Thanks,
Helge


On 2/13/21 5:25 PM, Laurent Vivier wrote:

Le 01/02/2021 à 23:05, Helge Deller a écrit :

Historically the parisc linux port tried to be compatible with HP-UX
userspace and as such defined the O_NONBLOCK constant to 024 to
emulate separate NDELAY & NONBLOCK values.

Since parisc was the only Linux platform which had two bits set, this
produced various userspace issues. Finally it was decided to drop the
(never completed) HP-UX compatibilty, which is why O_NONBLOCK was
changed upstream to only have one bit set in future with this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75ae04206a4d0e4f541c1d692b7febd1c0fdb814

This patch simply adjusts the value for qemu-user too.

Signed-off-by: Helge Deller 

---

diff --git a/linux-user/hppa/target_fcntl.h b/linux-user/hppa/target_fcntl.h
index bd966a59b8..08e3a4fcb0 100644
--- a/linux-user/hppa/target_fcntl.h
+++ b/linux-user/hppa/target_fcntl.h
@@ -8,7 +8,7 @@
  #ifndef HPPA_TARGET_FCNTL_H
  #define HPPA_TARGET_FCNTL_H

-#define TARGET_O_NONBLOCK00024 /* HPUX has separate NDELAY & NONBLOCK 
*/
+#define TARGET_O_NONBLOCK00020
  #define TARGET_O_APPEND  00010
  #define TARGET_O_CREAT   00400 /* not fcntl */
  #define TARGET_O_EXCL02000 /* not fcntl */



Applied to my linux-user-for-6.0 branch.

Thanks,
Laurent






Re: [PATCH] linux-user: Add missing TARGET___O_TMPFILE for hppa and alpha

2021-02-21 Thread Helge Deller

Dear qemu-stable,

can you please consider adding this patch to the qemu-stable branch.
Upstream commit 23b311155078bdd5bacc016ff3b3ebb5462b10c0

Thanks,
Helge

On 2/1/21 4:59 PM, Helge Deller wrote:

The hppa and alpha targets miss the #define of the TARGET___O_TMPFILE
and as such fail to run a trivial symlink command like

 ln -s /bin/bash /tmp

which results in an -EINVAL return code.

Adding the define fixes the problem.

Signed-off-by: Helge Deller 

---

diff --git a/linux-user/alpha/target_fcntl.h b/linux-user/alpha/target_fcntl.h
index 2617e73472..0a74807a8b 100644
--- a/linux-user/alpha/target_fcntl.h
+++ b/linux-user/alpha/target_fcntl.h
@@ -23,6 +23,7 @@
  #define TARGET_O_CLOEXEC 01000
  #define TARGET___O_SYNC  02000
  #define TARGET_O_PATH04000
+#define TARGET___O_TMPFILE  01

  #define TARGET_F_GETLK 7
  #define TARGET_F_SETLK 8
diff --git a/linux-user/hppa/target_fcntl.h b/linux-user/hppa/target_fcntl.h
index bd966a59b8..08e3a4fcb0 100644
--- a/linux-user/hppa/target_fcntl.h
+++ b/linux-user/hppa/target_fcntl.h
@@ -21,6 +21,7 @@
  #define TARGET_O_CLOEXEC 01000
  #define TARGET___O_SYNC  00010
  #define TARGET_O_PATH02000
+#define TARGET___O_TMPFILE   04000

  #define TARGET_F_RDLCK 1
  #define TARGET_F_WRLCK 2






Re: [PATCH 0/2] tcg/aarch64: Fixes to vector ops

2021-02-21 Thread Richard Henderson
On 2/21/21 4:12 AM, Peter Maydell wrote:
> On Sat, 20 Feb 2021 at 21:29, Richard Henderson
>  wrote:
>>
>> I guess it has been a while since I've run aa32 risu on aa64 host.
>>
>> The launchpad bug is something that should have been seen from the
>> beginning, but the similar aa64 operations are expanded as integer
>> code, not vector code.  The aa32 neon code has only recently been
>> converted to use gvecs.
>>
>> The cmle0 (zero) bug has been exposed by the recent constant
>> propagation improvements; previously we saw a reg/reg compare.
> 
> Idle thought: would it be possible to have a test framework that
> exercised the TCG backend without being dependent on a particular
> guest frontend?

*shrug* The question has been asked before.  It might be possible, but it's not
trivial.

In order to actually test something, there has to be enough board-level stuff
to do something.  Which means we have to at least define a virt board, the "tcg
guest" front end that can read the tcg input, etc.

It's not unlike gcc, for which similar "can we 'just' test rtl" questions were
mooted for years, to no effect.

What we haven't been doing with tcg, which did happen for gcc, is the regular
and consistent addition of regression tests. But even that runs afoul of the
fact that we've only got docker cross-compilers for x86_64.

Also, it'd be nice to actually run risu regularly, on all of the tcg hosts,
which I think is the main failure here.  We did all of the recent NEON testing
on x86_64 and (apparently) none at all on aarch64.


r~



Can we run QEMU Avocado tests without root access?

2021-02-21 Thread Philippe Mathieu-Daudé
Hi,

On a system I want to run the QEMU integration tests I got:

$ make check-venv
  GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3
tests/fp/berkeley-softfloat-3 dtc capstone slirp
  VENVbuild/tests/venv
The virtual environment was not created successfully because ensurepip
is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt-get install python3-venv

You may need to use sudo with that command.  After installing the
python3-venv
package, recreate your virtual environment.

Failing command: ['build/tests/venv/bin/python3', '-Im', 'ensurepip',
'--upgrade', '--default-pip']

make: *** [/home/philmd/qemu/tests/Makefile.include:98:
build/tests/venv] Error 1

However I could do:

$ python3 -m pip install --user virtualenv
Collecting virtualenv
  Downloading virtualenv-20.4.2-py2.py3-none-any.whl (7.2 MB)
 || 7.2 MB 6.4 MB/s
Collecting distlib<1,>=0.3.1
  Downloading distlib-0.3.1-py2.py3-none-any.whl (335 kB)
 || 335 kB 6.4 MB/s
Collecting appdirs<2,>=1.4.3
  Downloading appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Requirement already satisfied: six<2,>=1.9.0 in
/usr/lib/python3/dist-packages (from virtualenv) (1.15.0)
Collecting filelock<4,>=3.0.0
  Downloading filelock-3.0.12-py3-none-any.whl (7.6 kB)
Installing collected packages: distlib, appdirs, filelock, virtualenv
Successfully installed appdirs-1.4.4 distlib-0.3.1 filelock-3.0.12
virtualenv-20.4.2

$ virtualenv --version
virtualenv 20.4.2 from
/home/philmd/.local/lib/python3.9/site-packages/virtualenv/__init__.py

Note, there is still the old tests/venv/ dir created bug:

$ make check-venv
  GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3
tests/fp/berkeley-softfloat-3 dtc capstone slirp
make: Nothing to be done for 'check-venv'.

Although it might be true... If I don't have root access, there is
nothing to be done ¯\_(ツ)_/¯

Thanks,

Phil.




Re: [PATCH v4 01/71] tcg/tci: Use exec/cpu_ldst.h interfaces

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/17/21 9:19 PM, Richard Henderson wrote:
> Use the provided cpu_ldst.h interfaces.  This fixes the build vs
> the unconverted uses of g2h(), adds missed memory trace events,
> and correctly recognizes when a SIGSEGV belongs to the guest via
> set_helper_retaddr().
> 
> Fixes: 3e8f1628e864
> Signed-off-by: Richard Henderson 
> ---
>  tcg/tci.c | 73 +--
>  1 file changed, 28 insertions(+), 45 deletions(-)

Hit that today:

../tcg/tci.c: In function ‘tcg_qemu_tb_exec’:
../tcg/tci.c:379:37: error: passing argument 1 of ‘g2h’ makes pointer
from integer without a cast [-Werror=int-conversion]
  379 | # define qemu_ld_ub  ldub_p(g2h(taddr))
  | ^
  | |
  | target_ulong {aka unsigned int}
../tcg/tci.c:1034:25: note: in expansion of macro ‘qemu_ld_ub’
 1034 | tmp32 = qemu_ld_ub;
  | ^~
In file included from ../tcg/tci.c:32:
include/exec/cpu_ldst.h:85:35: note: expected ‘CPUState *’ but argument
is of type ‘target_ulong’ {aka ‘unsigned int’}
   85 | static inline void *g2h(CPUState *cs, abi_ptr x)
  | ~~^~
../tcg/tci.c:379:33: error: too few arguments to function ‘g2h’
  379 | # define qemu_ld_ub  ldub_p(g2h(taddr))
  | ^~~
../tcg/tci.c:1034:25: note: in expansion of macro ‘qemu_ld_ub’
 1034 | tmp32 = qemu_ld_ub;
  | ^~

So:
Tested-by: Philippe Mathieu-Daudé 



[PATCH v2 3/3] hw/lm32/Kconfig: Have MILKYMIST select LM32_DEVICES

2021-02-21 Thread Philippe Mathieu-Daudé
The Milkymist board requires more than the PTIMER. Directly
select the LM32_DEVICES. This fixes:

  /usr/bin/ld:
  libqemu-lm32-softmmu.fa.p/target_lm32_gdbstub.c.o: in function 
`lm32_cpu_gdb_read_register':
  target/lm32/gdbstub.c:46: undefined reference to `lm32_pic_get_im'
  target/lm32/gdbstub.c:48: undefined reference to `lm32_pic_get_ip'
  libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function 
`helper_wcsr_im':
  target/lm32/op_helper.c:107: undefined reference to `lm32_pic_set_im'
  libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function 
`helper_wcsr_ip':
  target/lm32/op_helper.c:114: undefined reference to `lm32_pic_set_ip'
  libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function 
`helper_wcsr_jtx':
  target/lm32/op_helper.c:120: undefined reference to `lm32_juart_set_jtx'
  libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function 
`helper_wcsr_jrx':
  target/lm32/op_helper.c:125: undefined reference to `lm32_juart_set_jrx'
  libqemu-lm32-softmmu.fa.p/target_lm32_translate.c.o: in function 
`lm32_cpu_dump_state':
  target/lm32/translate.c:1161: undefined reference to `lm32_pic_get_ip'
  target/lm32/translate.c:1161: undefined reference to `lm32_pic_get_im'

Reviewed-by: Alex Bennée 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/lm32/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/lm32/Kconfig b/hw/lm32/Kconfig
index 518c84ed508..8ac94205d71 100644
--- a/hw/lm32/Kconfig
+++ b/hw/lm32/Kconfig
@@ -6,11 +6,11 @@ config MILKYMIST
 bool
 # FIXME: disabling it results in compile-time errors
 select MILKYMIST_TMU2 if OPENGL && X11
-select PTIMER
 select PFLASH_CFI01
 select FRAMEBUFFER
 select SD
 select USB_OHCI
+select LM32_DEVICES
 
 config LM32_EVR
 bool
-- 
2.26.2




[PATCH v2 2/3] hw/lm32/Kconfig: Rename CONFIG_LM32 -> CONFIG_LM32_DEVICES

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'LM32' config for architecture
specific features. As CONFIG_LM32 is only used to select
peripherals, rename it CONFIG_LM32_DEVICES.

Reviewed-by: Alex Bennée 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/char/meson.build  | 4 ++--
 hw/intc/meson.build  | 2 +-
 hw/lm32/Kconfig  | 4 ++--
 hw/timer/meson.build | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/char/meson.build b/hw/char/meson.build
index 196ac91fa29..b95e8958514 100644
--- a/hw/char/meson.build
+++ b/hw/char/meson.build
@@ -8,8 +8,8 @@
 softmmu_ss.add(when: 'CONFIG_IPACK', if_true: files('ipoctal232.c'))
 softmmu_ss.add(when: 'CONFIG_ISA_BUS', if_true: files('parallel-isa.c'))
 softmmu_ss.add(when: 'CONFIG_ISA_DEBUG', if_true: files('debugcon.c'))
-softmmu_ss.add(when: 'CONFIG_LM32', if_true: files('lm32_juart.c'))
-softmmu_ss.add(when: 'CONFIG_LM32', if_true: files('lm32_uart.c'))
+softmmu_ss.add(when: 'CONFIG_LM32_DEVICES', if_true: files('lm32_juart.c'))
+softmmu_ss.add(when: 'CONFIG_LM32_DEVICES', if_true: files('lm32_uart.c'))
 softmmu_ss.add(when: 'CONFIG_MILKYMIST', if_true: files('milkymist-uart.c'))
 softmmu_ss.add(when: 'CONFIG_NRF51_SOC', if_true: files('nrf51_uart.c'))
 softmmu_ss.add(when: 'CONFIG_PARALLEL', if_true: files('parallel.c'))
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 53cba115690..b2c4c085af9 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -14,7 +14,7 @@
 softmmu_ss.add(when: 'CONFIG_I8259', if_true: files('i8259_common.c', 
'i8259.c'))
 softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('imx_avic.c', 'imx_gpcv2.c'))
 softmmu_ss.add(when: 'CONFIG_IOAPIC', if_true: files('ioapic_common.c'))
-softmmu_ss.add(when: 'CONFIG_LM32', if_true: files('lm32_pic.c'))
+softmmu_ss.add(when: 'CONFIG_LM32_DEVICES', if_true: files('lm32_pic.c'))
 softmmu_ss.add(when: 'CONFIG_OPENPIC', if_true: files('openpic.c'))
 softmmu_ss.add(when: 'CONFIG_PL190', if_true: files('pl190.c'))
 softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_intc.c'))
diff --git a/hw/lm32/Kconfig b/hw/lm32/Kconfig
index 20c36edc402..518c84ed508 100644
--- a/hw/lm32/Kconfig
+++ b/hw/lm32/Kconfig
@@ -1,4 +1,4 @@
-config LM32
+config LM32_DEVICES
 bool
 select PTIMER
 
@@ -14,5 +14,5 @@ config MILKYMIST
 
 config LM32_EVR
 bool
-select LM32
+select LM32_DEVICES
 select PFLASH_CFI02
diff --git a/hw/timer/meson.build b/hw/timer/meson.build
index be343f68fed..52723f34c42 100644
--- a/hw/timer/meson.build
+++ b/hw/timer/meson.build
@@ -19,7 +19,7 @@
 softmmu_ss.add(when: 'CONFIG_I8254', if_true: files('i8254_common.c', 
'i8254.c'))
 softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('imx_epit.c'))
 softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('imx_gpt.c'))
-softmmu_ss.add(when: 'CONFIG_LM32', if_true: files('lm32_timer.c'))
+softmmu_ss.add(when: 'CONFIG_LM32_DEVICES', if_true: files('lm32_timer.c'))
 softmmu_ss.add(when: 'CONFIG_MILKYMIST', if_true: files('milkymist-sysctl.c'))
 softmmu_ss.add(when: 'CONFIG_MIPS_CPS', if_true: files('mips_gictimer.c'))
 softmmu_ss.add(when: 'CONFIG_MSF2', if_true: files('mss-timer.c'))
-- 
2.26.2




[PATCH v2 1/3] hw/lm32/Kconfig: Introduce CONFIG_LM32_EVR for lm32-evr/uclinux boards

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'LM32' config for architecture
specific features. Introduce CONFIG_LM32_EVR to select the
lm32-evr / lm32-uclinux boards.

Reviewed-by: Alex Bennée 
Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/lm32-softmmu.mak | 2 +-
 hw/lm32/Kconfig  | 6 +-
 hw/lm32/meson.build  | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/default-configs/devices/lm32-softmmu.mak 
b/default-configs/devices/lm32-softmmu.mak
index 115b3e34c98..1bce3f6e8b6 100644
--- a/default-configs/devices/lm32-softmmu.mak
+++ b/default-configs/devices/lm32-softmmu.mak
@@ -8,5 +8,5 @@ CONFIG_SEMIHOSTING=y
 
 # Boards:
 #
-CONFIG_LM32=y
+CONFIG_LM32_EVR=y
 CONFIG_MILKYMIST=y
diff --git a/hw/lm32/Kconfig b/hw/lm32/Kconfig
index ed2e3060b04..20c36edc402 100644
--- a/hw/lm32/Kconfig
+++ b/hw/lm32/Kconfig
@@ -1,7 +1,6 @@
 config LM32
 bool
 select PTIMER
-select PFLASH_CFI02
 
 config MILKYMIST
 bool
@@ -12,3 +11,8 @@ config MILKYMIST
 select FRAMEBUFFER
 select SD
 select USB_OHCI
+
+config LM32_EVR
+bool
+select LM32
+select PFLASH_CFI02
diff --git a/hw/lm32/meson.build b/hw/lm32/meson.build
index 8caf0a727ff..42d6f8db3d9 100644
--- a/hw/lm32/meson.build
+++ b/hw/lm32/meson.build
@@ -1,6 +1,6 @@
 lm32_ss = ss.source_set()
 # LM32 boards
-lm32_ss.add(when: 'CONFIG_LM32', if_true: files('lm32_boards.c'))
+lm32_ss.add(when: 'CONFIG_LM32_EVR', if_true: files('lm32_boards.c'))
 lm32_ss.add(when: 'CONFIG_MILKYMIST', if_true: files('milkymist.c'))
 
 hw_arch += {'lm32': lm32_ss}
-- 
2.26.2




[PATCH v2 0/3] hw/lm32: Kconfig cleanups

2021-02-21 Thread Philippe Mathieu-Daudé
Hi Laurent,

This series is fully reviewed. Since LM32 is not very
active, can this go via qemu-trivial@?

Thanks,

Phil.

v2: Rebased

Supersedes: <20210208135048.2601693-1-f4...@amsat.org>

Philippe Mathieu-Daudé (3):
  hw/lm32/Kconfig: Introduce CONFIG_LM32_EVR for lm32-evr/uclinux boards
  hw/lm32/Kconfig: Rename CONFIG_LM32 -> CONFIG_LM32_DEVICES
  hw/lm32/Kconfig: Have MILKYMIST select LM32_DEVICES

 default-configs/devices/lm32-softmmu.mak |  2 +-
 hw/char/meson.build  |  4 ++--
 hw/intc/meson.build  |  2 +-
 hw/lm32/Kconfig  | 10 +++---
 hw/lm32/meson.build  |  2 +-
 hw/timer/meson.build |  2 +-
 6 files changed, 13 insertions(+), 9 deletions(-)

-- 
2.26.2




Re: [RFC PATCH] target/mips/cp0_timer: Use new clock_ns_to_ticks()

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/21/21 9:12 PM, Peter Maydell wrote:
> On Sun, 21 Feb 2021 at 20:07, Philippe Mathieu-Daudé  wrote:
>>
>> On 2/11/21 12:43 AM, Philippe Mathieu-Daudé wrote:
>>> Use the new clock_ns_to_ticks() function in cp0_timer where
>>> appropriate. This allows us to remove CPUMIPSState::cp0_count_ns
>>> and mips_cp0_period_set().
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>> Based-on: <20210209132040.5091-1-peter.mayd...@linaro.org>
>>>
>>> RFC because this is just a starter patch to test Peter's series
>>> providing a handy function which "tells me how many times this
>>> clock would tick in this length of time".
>>>
>>> Also because we could rethink the MIPS CP0 timer logic to avoid
>>> too frequent divu128 calls (painful on 32-bit hosts).
>>>
>>> The style should be updated, using more variables for easier
>>> review. env_archcpu() could eventually be dropped (by passing
>>> MIPSCPU* instead of CPUMIPSState*).
>>
>> I guess it is better to wait for Peter patches to get merged
>> before posting the updated patches (not much, just one previous
>> patch MIPSCPU* instead of CPUMIPSState*).
> 
> This patch is still on my to-review queue, fwiw (though I am
> taking a week off work next week, so I probably won't get to
> it til March.)

Thanks for the update, I'll repost during the first day of March
then :) Also I'll try to rebase my "hw/char/serial: Use the Clock
API to feed the UART reference clock" too.

Regards,

Phil.



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

2021-02-21 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

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

Reported-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.c | 331 ---
 target/arm/cpu_tcg.c | 314 
 2 files changed, 314 insertions(+), 331 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6865ea76466..ae04884408c 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1922,327 +1922,6 @@ static ObjectClass *arm_cpu_class_by_name(const char 
*cpu_model)
 return oc;
 }
 
-/* CPU models. These are not needed for the AArch64 linux-user build. */
-#if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
-
-static const ARMCPRegInfo cortexa8_cp_reginfo[] = {
-{ .name = "L2LOCKDOWN", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 0,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "L2AUXCR", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 2,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-REGINFO_SENTINEL
-};
-
-static void cortex_a8_initfn(Object *obj)
-{
-ARMCPU *cpu = ARM_CPU(obj);
-
-cpu->dtb_compatible = "arm,cortex-a8";
-set_feature(>env, ARM_FEATURE_V7);
-set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
-set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
-set_feature(>env, ARM_FEATURE_EL3);
-cpu->midr = 0x410fc080;
-cpu->reset_fpsid = 0x410330c0;
-cpu->isar.mvfr0 = 0x0222;
-cpu->isar.mvfr1 = 0x0001;
-cpu->ctr = 0x82048004;
-cpu->reset_sctlr = 0x00c50078;
-cpu->isar.id_pfr0 = 0x1031;
-cpu->isar.id_pfr1 = 0x11;
-cpu->isar.id_dfr0 = 0x400;
-cpu->id_afr0 = 0;
-cpu->isar.id_mmfr0 = 0x3113;
-cpu->isar.id_mmfr1 = 0x2000;
-cpu->isar.id_mmfr2 = 0x01202000;
-cpu->isar.id_mmfr3 = 0x11;
-cpu->isar.id_isar0 = 0x0010;
-cpu->isar.id_isar1 = 0x12112111;
-cpu->isar.id_isar2 = 0x21232031;
-cpu->isar.id_isar3 = 0x2131;
-cpu->isar.id_isar4 = 0x0042;
-cpu->isar.dbgdidr = 0x15141000;
-cpu->clidr = (1 << 27) | (2 << 24) | 3;
-cpu->ccsidr[0] = 0xe007e01a; /* 16k L1 dcache. */
-cpu->ccsidr[1] = 0x2007e01a; /* 16k L1 icache. */
-cpu->ccsidr[2] = 0xf000; /* No L2 icache. */
-cpu->reset_auxcr = 2;
-define_arm_cp_regs(cpu, cortexa8_cp_reginfo);
-}
-
-static const ARMCPRegInfo cortexa9_cp_reginfo[] = {
-/*
- * power_control should be set to maximum latency. Again,
- * default to 0 and set by private hook
- */
-{ .name = "A9_PWRCTL", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 0,
-  .access = PL1_RW, .resetvalue = 0,
-  .fieldoffset = offsetof(CPUARMState, cp15.c15_power_control) },
-{ .name = "A9_DIAG", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 1,
-  .access = PL1_RW, .resetvalue = 0,
-  .fieldoffset = offsetof(CPUARMState, cp15.c15_diagnostic) },
-{ .name = "A9_PWRDIAG", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 
2,
-  .access = PL1_RW, .resetvalue = 0,
-  .fieldoffset = offsetof(CPUARMState, cp15.c15_power_diagnostic) },
-{ .name = "NEONBUSY", .cp = 15, .crn = 15, .crm = 1, .opc1 = 0, .opc2 = 0,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-/* TLB lockdown control */
-{ .name = "TLB_LOCKR", .cp = 15, .crn = 15, .crm = 4, .opc1 = 5, .opc2 = 2,
-  .access = PL1_W, .resetvalue = 0, .type = ARM_CP_NOP },
-{ .name = "TLB_LOCKW", .cp = 15, .crn = 15, .crm = 4, .opc1 = 5, .opc2 = 4,
-  .access = PL1_W, .resetvalue = 0, .type = ARM_CP_NOP },
-{ .name = "TLB_VA", .cp = 15, .crn = 15, .crm = 5, .opc1 = 5, .opc2 = 2,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-{ .name = "TLB_PA", .cp = 15, .crn = 15, .crm = 6, .opc1 = 5, .opc2 = 2,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-{ .name = "TLB_ATTR", .cp = 15, .crn = 15, .crm = 7, .opc1 = 5, .opc2 = 2,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-REGINFO_SENTINEL
-};
-
-static void cortex_a9_initfn(Object *obj)
-{
-ARMCPU *cpu = ARM_CPU(obj);
-
-cpu->dtb_compatible = "arm,cortex-a9";
-set_feature(>env, ARM_FEATURE_V7);
-set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
-set_feature(>env, ARM_FEATURE_EL3);
-/*
- * Note that A9 supports the MP extensions even for
- * A9UP and single-core A9MP (which are both different
- * and valid configurations; we don't model A9UP).
- */
-set_feature(>env, ARM_FEATURE_V7MP);
-set_feature(>env, ARM_FEATURE_CBAR);
-cpu->midr = 0x410fc090;
-cpu->reset_fpsid = 0x41033090;
-cpu->isar.mvfr0 = 

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

2021-02-21 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture.

Restrict the last ARMv7 CPUs (A-profile) to TCG.

Series almost fully reviewed (missing review is trivial code style).

Since v1: Only include patches which don't depends on  previous series

Philippe Mathieu-Daudé (3):
  target/arm: Restrict v8M IDAU to TCG
  target/arm/cpu: Update coding style to make checkpatch.pl happy
  target/arm: Restrict v7A TCG cpus to TCG accel

 target/arm/cpu.c | 334 ---
 target/arm/cpu_tcg.c | 322 +
 2 files changed, 322 insertions(+), 334 deletions(-)

-- 
2.26.2




[PATCH v2 2/3] target/arm/cpu: Update coding style to make checkpatch.pl happy

2021-02-21 Thread Philippe Mathieu-Daudé
We will move this code in the next commit. Clean it up
first to avoid checkpatch.pl errors.

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index a772fd4926f..6865ea76466 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1972,7 +1972,8 @@ static void cortex_a8_initfn(Object *obj)
 }
 
 static const ARMCPRegInfo cortexa9_cp_reginfo[] = {
-/* power_control should be set to maximum latency. Again,
+/*
+ * power_control should be set to maximum latency. Again,
  * default to 0 and set by private hook
  */
 { .name = "A9_PWRCTL", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 0,
@@ -2009,7 +2010,8 @@ static void cortex_a9_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_NEON);
 set_feature(>env, ARM_FEATURE_THUMB2EE);
 set_feature(>env, ARM_FEATURE_EL3);
-/* Note that A9 supports the MP extensions even for
+/*
+ * Note that A9 supports the MP extensions even for
  * A9UP and single-core A9MP (which are both different
  * and valid configurations; we don't model A9UP).
  */
@@ -2046,7 +2048,8 @@ static uint64_t a15_l2ctlr_read(CPUARMState *env, const 
ARMCPRegInfo *ri)
 {
 MachineState *ms = MACHINE(qdev_get_machine());
 
-/* Linux wants the number of processors from here.
+/*
+ * Linux wants the number of processors from here.
  * Might as well set the interrupt-controller bit too.
  */
 return ((ms->smp.cpus - 1) << 24) | (1 << 23);
@@ -2093,7 +2096,8 @@ static void cortex_a7_initfn(Object *obj)
 cpu->isar.id_mmfr1 = 0x4000;
 cpu->isar.id_mmfr2 = 0x0124;
 cpu->isar.id_mmfr3 = 0x02102211;
-/* a7_mpcore_r0p5_trm, page 4-4 gives 0x01101110; but
+/*
+ * a7_mpcore_r0p5_trm, page 4-4 gives 0x01101110; but
  * table 4-41 gives 0x02101110, which includes the arm div insns.
  */
 cpu->isar.id_isar0 = 0x02101110;
-- 
2.26.2




[PATCH v2 1/3] target/arm: Restrict v8M IDAU to TCG

2021-02-21 Thread Philippe Mathieu-Daudé
IDAU is specific to M-profile. KVM only supports A-profile.
Restrict this interface to TCG, as it is pointless (and
confusing) on a KVM-only build.

Reviewed-by: Richard Henderson 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.c | 7 ---
 target/arm/cpu_tcg.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index b8bc89e71fc..a772fd4926f 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2380,12 +2380,6 @@ static const TypeInfo arm_cpu_type_info = {
 .class_init = arm_cpu_class_init,
 };
 
-static const TypeInfo idau_interface_type_info = {
-.name = TYPE_IDAU_INTERFACE,
-.parent = TYPE_INTERFACE,
-.class_size = sizeof(IDAUInterfaceClass),
-};
-
 static void arm_cpu_register_types(void)
 {
 const size_t cpu_count = ARRAY_SIZE(arm_cpus);
@@ -2399,7 +2393,6 @@ static void arm_cpu_register_types(void)
 if (cpu_count) {
 size_t i;
 
-type_register_static(_interface_type_info);
 for (i = 0; i < cpu_count; ++i) {
 arm_cpu_register(_cpus[i]);
 }
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index c29b434c60d..fb07a336939 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -14,6 +14,7 @@
 #include "hw/core/tcg-cpu-ops.h"
 #endif /* CONFIG_TCG */
 #include "internals.h"
+#include "target/arm/idau.h"
 
 /* CPU models. These are not needed for the AArch64 linux-user build. */
 #if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
@@ -739,10 +740,17 @@ static const ARMCPUInfo arm_tcg_cpus[] = {
 { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
 };
 
+static const TypeInfo idau_interface_type_info = {
+.name = TYPE_IDAU_INTERFACE,
+.parent = TYPE_INTERFACE,
+.class_size = sizeof(IDAUInterfaceClass),
+};
+
 static void arm_tcg_cpu_register_types(void)
 {
 size_t i;
 
+type_register_static(_interface_type_info);
 for (i = 0; i < ARRAY_SIZE(arm_tcg_cpus); ++i) {
 arm_cpu_register(_tcg_cpus[i]);
 }
-- 
2.26.2




[PATCH v3 5/8] hw/timer: Introduce SH_TIMER Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_TIMER selector for the SH4 timer control unit.

Add the missing MAINTAINERS entries.

Suggested-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS  | 2 ++
 hw/sh4/Kconfig   | 2 +-
 hw/timer/Kconfig | 4 
 hw/timer/meson.build | 2 +-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b53a937714a..a03557f4f7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1391,6 +1391,7 @@ S: Odd Fixes
 F: hw/char/sh_serial.c
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
+F: hw/timer/sh_timer.c
 F: include/hw/sh4/sh_intc.h
 
 Shix
@@ -1400,6 +1401,7 @@ S: Odd Fixes
 F: hw/char/sh_serial.c
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
+F: hw/timer/sh_timer.c
 F: include/hw/sh4/sh_intc.h
 
 SPARC Machines
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 47240aa97b7..e569470a614 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -21,7 +21,7 @@ config SH7750
 bool
 select SH_INTC
 select SH_SCI
+select SH_TIMER
 
 config SH4
 bool
-select PTIMER
diff --git a/hw/timer/Kconfig b/hw/timer/Kconfig
index 8749edfb6a5..18936ef55bf 100644
--- a/hw/timer/Kconfig
+++ b/hw/timer/Kconfig
@@ -36,6 +36,10 @@ config CMSDK_APB_DUALTIMER
 bool
 select PTIMER
 
+config SH_TIMER
+bool
+select PTIMER
+
 config RENESAS_TMR
 bool
 
diff --git a/hw/timer/meson.build b/hw/timer/meson.build
index be343f68fed..26c2701fd78 100644
--- a/hw/timer/meson.build
+++ b/hw/timer/meson.build
@@ -30,7 +30,7 @@
 softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_ost.c'))
 softmmu_ss.add(when: 'CONFIG_PXA2XX', if_true: files('pxa2xx_timer.c'))
 softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_systmr.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('sh_timer.c'))
+softmmu_ss.add(when: 'CONFIG_SH_TIMER', if_true: files('sh_timer.c'))
 softmmu_ss.add(when: 'CONFIG_SLAVIO', if_true: files('slavio_timer.c'))
 softmmu_ss.add(when: 'CONFIG_STM32F2XX_TIMER', if_true: 
files('stm32f2xx_timer.c'))
 softmmu_ss.add(when: 'CONFIG_XILINX', if_true: files('xilinx_timer.c'))
-- 
2.26.2




[PATCH v3 4/8] hw/char: Introduce SH_SCI Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_SCI selector for the SH4 serial controller.

Add the missing MAINTAINERS entries.

Suggested-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS | 2 ++
 hw/char/Kconfig | 3 +++
 hw/char/meson.build | 2 +-
 hw/sh4/Kconfig  | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9b2aa18e1fe..b53a937714a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1388,6 +1388,7 @@ R2D
 M: Yoshinori Sato 
 R: Magnus Damm 
 S: Odd Fixes
+F: hw/char/sh_serial.c
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
 F: include/hw/sh4/sh_intc.h
@@ -1396,6 +1397,7 @@ Shix
 M: Yoshinori Sato 
 R: Magnus Damm 
 S: Odd Fixes
+F: hw/char/sh_serial.c
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
 F: include/hw/sh4/sh_intc.h
diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index 939bc447588..f6f4fffd1b7 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -50,6 +50,9 @@ config SCLPCONSOLE
 config TERMINAL3270
 bool
 
+config SH_SCI
+bool
+
 config RENESAS_SCI
 bool
 
diff --git a/hw/char/meson.build b/hw/char/meson.build
index 196ac91fa29..afe9a0af88c 100644
--- a/hw/char/meson.build
+++ b/hw/char/meson.build
@@ -31,7 +31,7 @@
 softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_aux.c'))
 softmmu_ss.add(when: 'CONFIG_RENESAS_SCI', if_true: files('renesas_sci.c'))
 softmmu_ss.add(when: 'CONFIG_SIFIVE_UART', if_true: files('sifive_uart.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('sh_serial.c'))
+softmmu_ss.add(when: 'CONFIG_SH_SCI', if_true: files('sh_serial.c'))
 softmmu_ss.add(when: 'CONFIG_STM32F2XX_USART', if_true: 
files('stm32f2xx_usart.c'))
 softmmu_ss.add(when: 'CONFIG_MCHP_PFSOC_MMUART', if_true: 
files('mchp_pfsoc_mmuart.c'))
 
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index c2008c6a0d2..47240aa97b7 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -20,6 +20,7 @@ config SHIX
 config SH7750
 bool
 select SH_INTC
+select SH_SCI
 
 config SH4
 bool
-- 
2.26.2




[PATCH v3 6/8] hw/block: Introduce TC58128 eeprom Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
Add more fine-grained selection by adding a CONFIG_TC58128
selector for the TC58128 eeprom.

As this device is only used by the Shix machine, add an entry
to the proper section in MAINTAINERS.

Suggested-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS  | 1 +
 hw/block/Kconfig | 3 +++
 hw/block/meson.build | 2 +-
 hw/sh4/Kconfig   | 1 +
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a03557f4f7c..a0cb89161cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1398,6 +1398,7 @@ Shix
 M: Yoshinori Sato 
 R: Magnus Damm 
 S: Odd Fixes
+F: hw/block/tc58128.c
 F: hw/char/sh_serial.c
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
diff --git a/hw/block/Kconfig b/hw/block/Kconfig
index 2d17f481adc..4fcd1521668 100644
--- a/hw/block/Kconfig
+++ b/hw/block/Kconfig
@@ -22,6 +22,9 @@ config ECC
 config ONENAND
 bool
 
+config TC58128
+bool
+
 config NVME_PCI
 bool
 default y if PCI_DEVICES
diff --git a/hw/block/meson.build b/hw/block/meson.build
index 602ca6c8541..4bf994c64ff 100644
--- a/hw/block/meson.build
+++ b/hw/block/meson.build
@@ -12,7 +12,7 @@
 softmmu_ss.add(when: 'CONFIG_SSI_M25P80', if_true: files('m25p80.c'))
 softmmu_ss.add(when: 'CONFIG_SWIM', if_true: files('swim.c'))
 softmmu_ss.add(when: 'CONFIG_XEN', if_true: files('xen-block.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('tc58128.c'))
+softmmu_ss.add(when: 'CONFIG_TC58128', if_true: files('tc58128.c'))
 softmmu_ss.add(when: 'CONFIG_NVME_PCI', if_true: files('nvme.c', 'nvme-ns.c'))
 
 specific_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true: files('virtio-blk.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index e569470a614..34c01dadde9 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -16,6 +16,7 @@ config SHIX
 bool
 select SH7750
 select SH4
+select TC58128
 
 config SH7750
 bool
-- 
2.26.2




[PATCH v3 3/8] hw/intc: Introduce SH_INTC Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_INTC selector for the SH4 interrupt controller.

Suggested-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/intc/Kconfig | 3 +++
 hw/intc/meson.build | 2 +-
 hw/sh4/Kconfig  | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig
index c18d11142a8..66bf0b90b47 100644
--- a/hw/intc/Kconfig
+++ b/hw/intc/Kconfig
@@ -53,6 +53,9 @@ config OMPIC
 config PPC_UIC
 bool
 
+config SH_INTC
+bool
+
 config RX_ICU
 bool
 
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 53cba115690..b3d9345a0d2 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -47,7 +47,7 @@
 specific_ss.add(when: 'CONFIG_RX_ICU', if_true: files('rx_icu.c'))
 specific_ss.add(when: 'CONFIG_S390_FLIC', if_true: files('s390_flic.c'))
 specific_ss.add(when: 'CONFIG_S390_FLIC_KVM', if_true: 
files('s390_flic_kvm.c'))
-specific_ss.add(when: 'CONFIG_SH4', if_true: files('sh_intc.c'))
+specific_ss.add(when: 'CONFIG_SH_INTC', if_true: files('sh_intc.c'))
 specific_ss.add(when: 'CONFIG_SIFIVE_CLINT', if_true: files('sifive_clint.c'))
 specific_ss.add(when: 'CONFIG_SIFIVE_PLIC', if_true: files('sifive_plic.c'))
 specific_ss.add(when: 'CONFIG_XICS', if_true: files('xics.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 0452b4624ae..c2008c6a0d2 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -19,6 +19,7 @@ config SHIX
 
 config SH7750
 bool
+select SH_INTC
 
 config SH4
 bool
-- 
2.26.2




[PATCH v3 8/8] hw/sh4: Remove now unused CONFIG_SH4 from Kconfig

2021-02-21 Thread Philippe Mathieu-Daudé
As replaced the generic CONFIG_SH4 by more fine-grained
selectors, we can remove this now unused config variable.

Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/sh4/Kconfig | 5 -
 1 file changed, 5 deletions(-)

diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index b9f0538d57f..ab733a3f760 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -9,14 +9,12 @@ config R2D
 select USB_OHCI_PCI
 select PCI
 select SM501
-select SH4
 select SH7750
 select SH_PCI
 
 config SHIX
 bool
 select SH7750
-select SH4
 select TC58128
 
 config SH7750
@@ -24,6 +22,3 @@ config SH7750
 select SH_INTC
 select SH_SCI
 select SH_TIMER
-
-config SH4
-bool
-- 
2.26.2




[PATCH v3 7/8] hw/pci-host: Introduce SH_PCI Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_PCI selector for the SH4 PCI controller.
Move the file with the other PCI host devices in hw/pci-host
and add its missing MAINTAINERS entries.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/{sh4 => pci-host}/sh_pci.c | 0
 MAINTAINERS   | 1 +
 hw/pci-host/Kconfig   | 4 
 hw/pci-host/meson.build   | 1 +
 hw/sh4/Kconfig| 1 +
 hw/sh4/meson.build| 1 -
 6 files changed, 7 insertions(+), 1 deletion(-)
 rename hw/{sh4 => pci-host}/sh_pci.c (100%)

diff --git a/hw/sh4/sh_pci.c b/hw/pci-host/sh_pci.c
similarity index 100%
rename from hw/sh4/sh_pci.c
rename to hw/pci-host/sh_pci.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a0cb89161cb..e39997f129a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1391,6 +1391,7 @@ S: Odd Fixes
 F: hw/char/sh_serial.c
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
+F: hw/pci-host/sh_pci.c
 F: hw/timer/sh_timer.c
 F: include/hw/sh4/sh_intc.h
 
diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
index 8b8c763c28c..2ccc96f02ce 100644
--- a/hw/pci-host/Kconfig
+++ b/hw/pci-host/Kconfig
@@ -68,3 +68,7 @@ config PCI_POWERNV
 
 config REMOTE_PCIHOST
 bool
+
+config SH_PCI
+bool
+select PCI
diff --git a/hw/pci-host/meson.build b/hw/pci-host/meson.build
index 1847c69905c..87a896973e7 100644
--- a/hw/pci-host/meson.build
+++ b/hw/pci-host/meson.build
@@ -10,6 +10,7 @@
 pci_ss.add(when: 'CONFIG_PCI_SABRE', if_true: files('sabre.c'))
 pci_ss.add(when: 'CONFIG_XEN_IGD_PASSTHROUGH', if_true: files('xen_igd_pt.c'))
 pci_ss.add(when: 'CONFIG_REMOTE_PCIHOST', if_true: files('remote.c'))
+pci_ss.add(when: 'CONFIG_SH_PCI', if_true: files('sh_pci.c'))
 
 # PPC devices
 pci_ss.add(when: 'CONFIG_PREP_PCI', if_true: files('prep.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 34c01dadde9..b9f0538d57f 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -11,6 +11,7 @@ config R2D
 select SM501
 select SH4
 select SH7750
+select SH_PCI
 
 config SHIX
 bool
diff --git a/hw/sh4/meson.build b/hw/sh4/meson.build
index 303c0f42879..424d5674dea 100644
--- a/hw/sh4/meson.build
+++ b/hw/sh4/meson.build
@@ -2,7 +2,6 @@
 sh4_ss.add(files(
   'sh7750.c',
   'sh7750_regnames.c',
-  'sh_pci.c'
 ))
 sh4_ss.add(when: 'CONFIG_R2D', if_true: files('r2d.c'))
 sh4_ss.add(when: 'CONFIG_SHIX', if_true: files('shix.c'))
-- 
2.26.2




[PATCH v3 0/8] hw/sh4: Kconfig cleanups

2021-02-21 Thread Philippe Mathieu-Daudé
Missing review: 1 (license) and 7 (pci)

Since v2:
- Added missing TC58128/SH_PCI Kconfig entries (Peter)

Since v1:
- Addressed Peter Maydell review comments from
https://www.mail-archive.com/qemu-block@nongnu.org/msg80599.html

Philippe Mathieu-Daudé (8):
  hw/sh4: Add missing license
  hw/sh4: Add missing Kconfig dependency on SH7750 for the R2D board
  hw/intc: Introduce SH_INTC Kconfig entry
  hw/char: Introduce SH_SCI Kconfig entry
  hw/timer: Introduce SH_TIMER Kconfig entry
  hw/block: Introduce TC58128 eeprom Kconfig entry
  hw/pci-host: Introduce SH_PCI Kconfig entry
  hw/sh4: Remove now unused CONFIG_SH4 from Kconfig

 include/hw/sh4/sh.h   | 12 +---
 hw/block/tc58128.c|  7 +++
 hw/{sh4 => pci-host}/sh_pci.c |  0
 MAINTAINERS   |  6 ++
 hw/block/Kconfig  |  3 +++
 hw/block/meson.build  |  2 +-
 hw/char/Kconfig   |  3 +++
 hw/char/meson.build   |  2 +-
 hw/intc/Kconfig   |  3 +++
 hw/intc/meson.build   |  2 +-
 hw/pci-host/Kconfig   |  4 
 hw/pci-host/meson.build   |  1 +
 hw/sh4/Kconfig| 12 ++--
 hw/sh4/meson.build|  1 -
 hw/timer/Kconfig  |  4 
 hw/timer/meson.build  |  2 +-
 16 files changed, 50 insertions(+), 14 deletions(-)
 rename hw/{sh4 => pci-host}/sh_pci.c (100%)

-- 
2.26.2




[PATCH v3 2/8] hw/sh4: Add missing Kconfig dependency on SH7750 for the R2D board

2021-02-21 Thread Philippe Mathieu-Daudé
r2d_init() calls sh7750_init() so depends on SH7750.Harmless
at the moment because nothing actually uses CONFIG_SH7750
(hw/sh4/meson.build always compiles sh7750.c and sh7750_regnames.c
unconditionally).

Fixes: 7ab58d4c841 ("sh4-softmmu.mak: express dependencies with Kconfig")
Reported-by: Peter Maydell 
Reviewed-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/sh4/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 4cbce3a0ed5..0452b4624ae 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -10,6 +10,7 @@ config R2D
 select PCI
 select SM501
 select SH4
+select SH7750
 
 config SHIX
 bool
-- 
2.26.2




[PATCH v3 1/8] hw/sh4: Add missing license

2021-02-21 Thread Philippe Mathieu-Daudé
This code was introduced in commit 27c7ca7e775,
("SHIX board emulation (Samuel Tardieu)"). Use
the same license.

Cc: Samuel Tardieu 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/sh4/sh.h | 12 +---
 hw/block/tc58128.c  |  7 +++
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/include/hw/sh4/sh.h b/include/hw/sh4/sh.h
index 93f464bf4cd..33dde7a56dd 100644
--- a/include/hw/sh4/sh.h
+++ b/include/hw/sh4/sh.h
@@ -1,6 +1,12 @@
-#ifndef QEMU_SH_H
-#define QEMU_SH_H
-/* Definitions for SH board emulation.  */
+/*
+ * Definitions for SH board emulation
+ *
+ * Copyright (c) 2005 Samuel Tardieu
+ *
+ * SPDX-License-Identifier: MIT
+ */
+#ifndef QEMU_HW_SH_H
+#define QEMU_HW_SH_H
 
 #include "hw/sh4/sh_intc.h"
 #include "target/sh4/cpu-qom.h"
diff --git a/hw/block/tc58128.c b/hw/block/tc58128.c
index 9888f01ac60..1a0fa86d8ea 100644
--- a/hw/block/tc58128.c
+++ b/hw/block/tc58128.c
@@ -1,3 +1,10 @@
+/*
+ * TC58128 NAND EEPROM emulation
+ *
+ * Copyright (c) 2005 Samuel Tardieu
+ *
+ * SPDX-License-Identifier: MIT
+ */
 #include "qemu/osdep.h"
 #include "qemu/units.h"
 #include "hw/sh4/sh.h"
-- 
2.26.2




Re: [PATCH v2 4/8] hw/char: Introduce SH_SCI Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/21/21 9:45 PM, Peter Maydell wrote:
> On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>>
>> We want to be able to use the 'SH4' config for architecture
>> specific features. Add more fine-grained selection by adding
>> a CONFIG_SH_SCI selector for the SH4 serial controller.
>>
>> Add the missing MAINTAINERS entries.
>>
>> Suggested-by: Peter Maydell 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  MAINTAINERS | 2 ++
>>  hw/char/Kconfig | 3 +++
>>  hw/char/meson.build | 2 +-
>>  hw/sh4/Kconfig  | 1 +
>>  4 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index da10756abf7..34587d90637 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1387,6 +1387,7 @@ R2D
>>  M: Yoshinori Sato 
>>  R: Magnus Damm 
>>  S: Odd Fixes
>> +F: hw/char/sh_serial.c
>>  F: hw/sh4/r2d.c
>>  F: hw/intc/sh_intc.c
>>  F: include/hw/sh4/sh_intc.h
>> @@ -1395,6 +1396,7 @@ Shix
>>  M: Yoshinori Sato 
>>  R: Magnus Damm 
>>  S: Odd Fixes
>> +F: hw/char/sh_serial.c
>>  F: hw/sh4/shix.c
>>  F: hw/intc/sh_intc.c
>>  F: include/hw/sh4/sh_intc.h
> 
> I didn't realise you could list a file twice in MAINTAINERS,
> but we I guess we already do for sh_intc.c.

In this case this isn't very useful because both machines
have the same set of maintainers, otherwise it is when a
same (device) section is used by machines maintained by
different persons.

> Reviewed-by: Peter Maydell 

Thanks for reviewing this series!

Phil.



Re: [PATCH v2 7/8] hw/pci-host: Introduce SH_PCI Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/21/21 9:49 PM, Peter Maydell wrote:
> On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>>
>> We want to be able to use the 'SH4' config for architecture
>> specific features. Add more fine-grained selection by adding
>> a CONFIG_SH_PCI selector for the SH4 PCI controller.
>> Move the file with the other PCI host devices in hw/pci-host
>> and add its missing MAINTAINERS entries.
>>
>> Suggested-by: Peter Maydell 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  hw/{sh4 => pci-host}/sh_pci.c | 0
>>  MAINTAINERS   | 1 +
>>  hw/pci-host/meson.build   | 1 +
>>  hw/sh4/Kconfig| 1 +
>>  hw/sh4/meson.build| 1 -
>>  5 files changed, 3 insertions(+), 1 deletion(-)
>>  rename hw/{sh4 => pci-host}/sh_pci.c (100%)
> 
> Don't we need a hw/pci-host/Kconfig change to add
> the "config SH_PCI" section ?

Oops sorry...



Re: [PULL v2 00/43] MIPS patches for 2021-02-21

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 19:44, Philippe Mathieu-Daudé  wrote:
>
> The following changes since commit a528b8c4c638d60cc474c2f80952ff0f2e60521a:
>
>   Merge remote-tracking branch 'remotes/philmd-gitlab/tags/sdmmc-20210220' 
> into staging (2021-02-20 19:28:27 +)
>
> are available in the Git repository at:
>
>   https://gitlab.com/philmd/qemu.git tags/mips-20210221
>
> for you to fetch changes up to cc2b4550115baf77d556341f17eb464d18953cee:
>
>   vt82c686: Fix superio_cfg_{read,write}() functions (2021-02-21 19:42:34 
> +0100)
>
> Since v1: Add missing license in include/hw/mips/bootloader.h.
>
> 
> MIPS patches queue
>
> - Drop redundant struct MemmapEntry (Bin)
> - Fix for Coverity CID 1438965 and 1438967 (Jiaxun)
> - Add MIPS bootloader API (Jiaxun)
> - Use MIPS bootloader API on fuloong2e and boston machines (Jiaxun)
> - Add PMON test for Loongson-3A1000 CPU (Jiaxun)
> - Convert to translator API (Philippe)
> - MMU cleanups (Philippe)
> - Promote 128-bit multimedia registers as global ones (Philippe)
> - Various cleanups/fixes on the VT82C686B southbridge (Zoltan)
> 


Applied, thanks.

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

-- PMM



Re: [PATCH v2 8/8] hw/sh4: Remove now unused CONFIG_SH4 from Kconfig

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> As replaced the generic CONFIG_SH4 by more fine-grained
> selectors, we can remove this now unused config variable.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/sh4/Kconfig | 5 -
>  1 file changed, 5 deletions(-)

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v2 7/8] hw/pci-host: Introduce SH_PCI Kconfig entry

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> We want to be able to use the 'SH4' config for architecture
> specific features. Add more fine-grained selection by adding
> a CONFIG_SH_PCI selector for the SH4 PCI controller.
> Move the file with the other PCI host devices in hw/pci-host
> and add its missing MAINTAINERS entries.
>
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/{sh4 => pci-host}/sh_pci.c | 0
>  MAINTAINERS   | 1 +
>  hw/pci-host/meson.build   | 1 +
>  hw/sh4/Kconfig| 1 +
>  hw/sh4/meson.build| 1 -
>  5 files changed, 3 insertions(+), 1 deletion(-)
>  rename hw/{sh4 => pci-host}/sh_pci.c (100%)

Don't we need a hw/pci-host/Kconfig change to add
the "config SH_PCI" section ?

thanks
-- PMM



Re: [PATCH v2 6/8] hw/block: Introduce TC58128 eeprom Kconfig entry

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> Add more fine-grained selection by adding a CONFIG_TC58128
> selector for the TC58128 eeprom.
>
> As this device is only used by the Shix machine, add an entry
> to the proper section in MAINTAINERS.
>
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v2 5/8] hw/timer: Introduce SH_TIMER Kconfig entry

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> We want to be able to use the 'SH4' config for architecture
> specific features. Add more fine-grained selection by adding
> a CONFIG_SH_TIMER selector for the SH4 timer control unit.
>
> Add the missing MAINTAINERS entries.
>
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v2 4/8] hw/char: Introduce SH_SCI Kconfig entry

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> We want to be able to use the 'SH4' config for architecture
> specific features. Add more fine-grained selection by adding
> a CONFIG_SH_SCI selector for the SH4 serial controller.
>
> Add the missing MAINTAINERS entries.
>
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  MAINTAINERS | 2 ++
>  hw/char/Kconfig | 3 +++
>  hw/char/meson.build | 2 +-
>  hw/sh4/Kconfig  | 1 +
>  4 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index da10756abf7..34587d90637 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1387,6 +1387,7 @@ R2D
>  M: Yoshinori Sato 
>  R: Magnus Damm 
>  S: Odd Fixes
> +F: hw/char/sh_serial.c
>  F: hw/sh4/r2d.c
>  F: hw/intc/sh_intc.c
>  F: include/hw/sh4/sh_intc.h
> @@ -1395,6 +1396,7 @@ Shix
>  M: Yoshinori Sato 
>  R: Magnus Damm 
>  S: Odd Fixes
> +F: hw/char/sh_serial.c
>  F: hw/sh4/shix.c
>  F: hw/intc/sh_intc.c
>  F: include/hw/sh4/sh_intc.h

I didn't realise you could list a file twice in MAINTAINERS,
but we I guess we already do for sh_intc.c.

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v2 3/8] hw/intc: Introduce SH_INTC Kconfig entry

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> We want to be able to use the 'SH4' config for architecture
> specific features. Add more fine-grained selection by adding
> a CONFIG_SH_INTC selector for the SH4 interrupt controller.
>
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/intc/Kconfig | 3 +++
>  hw/intc/meson.build | 2 +-
>  hw/sh4/Kconfig  | 1 +
>  3 files changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v2 2/8] hw/sh4: Add missing Kconfig dependency on SH7750 for the R2D board

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:03, Philippe Mathieu-Daudé  wrote:
>
> r2d_init() calls sh7750_init() so depends on SH7750.Harmless
> at the moment because nothing actually uses CONFIG_SH7750
> (hw/sh4/meson.build always compiles sh7750.c and sh7750_regnames.c
> unconditionally).
>
> Fixes: 7ab58d4c841 ("sh4-softmmu.mak: express dependencies with Kconfig")
> Reported-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/sh4/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
> index 4cbce3a0ed5..0452b4624ae 100644
> --- a/hw/sh4/Kconfig
> +++ b/hw/sh4/Kconfig
> @@ -10,6 +10,7 @@ config R2D
>  select PCI
>  select SM501
>  select SH4
> +select SH7750

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH 0/2] Allwinner H3 fixes for EMAC and acceptance tests

2021-02-21 Thread Niek Linnenbank
On Fri, Feb 19, 2021 at 7:24 PM Philippe Mathieu-Daudé 
wrote:

> Hi Niek,
>
> On 2/17/21 9:57 PM, Niek Linnenbank wrote:
> > Hi Daniel, Philippe,
> >
> > Op di 16 feb. 2021 10:49 schreef Daniel P. Berrangé  > >:
> >
> > On Fri, Feb 12, 2021 at 03:10:00PM +0100, Philippe Mathieu-Daudé
> wrote:
> > > Hi Niek and QEMU community,
> > >
> > > On 2/11/21 11:00 PM, Niek Linnenbank wrote:
> > > > The following are maintenance patches for the Allwinner H3. The
> > first patch
> > > > is a proposal to relocate the binary artifacts of the acceptance
> > tests away
> > > > from the apt.armbian.com  domain. In the
> > past we had problems with artifacts being
> > > > removed, and now the recently added Armbian 20.08.1 image has
> > been removed as well:
> > > >
> > > > $ wget
> >
> https://dl.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> > <
> https://dl.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> >
> > > > Connecting to dl.armbian.com 
> > (dl.armbian.com )|2605:7900:20::5|:443...
> > connected.
> > > > ...
> > > > HTTP request sent, awaiting response... 404 Not Found
> > > > 2021-02-11 22:34:45 ERROR 404: Not Found.
> > > >
> > > > I've now added the artifacts to a server maintained by me. The
> > machine has a stable
> > > > uptime of several years, ~100Mbit bandwidth and plenty of
> > available storage.
> > > > Also for other artifacts if needed. I'm open to discuss if there
> > is a proposal
> > > > for a better location for these artifacts or a more generic qemu
> > location.
> > >
> > > Thanks for trying to fix this long standing problem.
> > >
> > > While this works in your case, this doesn't scale to the community,
> > > as not all contributors have access to such hardware and bandwidth
> /
> > > storage.
> > >
> > > While your first patch is useful in showing where the artifacts are
> > > stored doesn't matter - as long as we use cryptographic hashes - I
> > > think it is a step in the wrong direction, so I am not keen on
> > > accepting it.
> > >
> > > My personal view is that any contributor should have the same
> > > possibilities to add tests to the project. Now I am also open to
> > > discuss with the others :) I might be proven wrong, and it could
> > > be better to rely on good willing contributors rather than having
> > > nothing useful at all.
> >
> > There aren't many options here
> >
> >  1. Rely on a vendor to provide stable download URLs for images
> >
> >  2. QEMU host all images we use in testing
> >
> >  3. Contributor finds some site to upload images to
> >
> >
> > For the armbian images we rely on (1), but the URLs didn't turn out
> > to be
> > stable. In fact no OS vendor seems to have guaranteed stable URLs
> > forever,
> > regardless of distro, though most eventually do have an archive site
> > that
> > has good life. Armbian was an exception in this respect IIUC.
> >
> > (2) would solve the long term stability problem as QEMU would be in
> full
> > control, and could open it up for any images we need. The big
> challenge
> > there is that QEMU now owns the license compliance problem. Merely
> > uploading
> > binary images/packages without the corresponding source is generally
> > a license
> > violation. QEMU could provide hosting, but we need to be clear about
> > the fact
> > that we now own the license compliance problem ourselves. Many sites
> > hosting
> > images simply ignore this problem, but that doesn't make it right.
> >
> >
> > This series is proposing (3), with a site the contributor happens to
> > control
> > themselves, but using a free 3rd party hosting site is no different
> > really.
> > Again there is a the same need for license compliance, but it is now
> the
> > responsibility of the user, not QEMU project.
> >
> > In this http://www.freenos.org/pub/qemu/cubieboard/
> >  site I can't even see
> a
> > directory listing, so even if corresponding source does exist in
> > this server,
> > I can't find it.
> >
> > The isn't really a problem for QEMU CI to consume the images, but as
> > a free
> > software developer I don't like encouraging practices that are not
> > compliant
> > with licensing reuqirement.
> >
> > It is an open question whether the (3) is really better than (1) in
> > terms
> > of URL stability long term, especially if running off a user's
> personal
> > server.
> >
> >
> > I understand your concerns. My goal here was to be able to re-activate
> > the orangepi tests, so we can 

Re: [RFC PATCH] target/mips/cp0_timer: Use new clock_ns_to_ticks()

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 20:07, Philippe Mathieu-Daudé  wrote:
>
> On 2/11/21 12:43 AM, Philippe Mathieu-Daudé wrote:
> > Use the new clock_ns_to_ticks() function in cp0_timer where
> > appropriate. This allows us to remove CPUMIPSState::cp0_count_ns
> > and mips_cp0_period_set().
> >
> > Signed-off-by: Philippe Mathieu-Daudé 
> > ---
> > Based-on: <20210209132040.5091-1-peter.mayd...@linaro.org>
> >
> > RFC because this is just a starter patch to test Peter's series
> > providing a handy function which "tells me how many times this
> > clock would tick in this length of time".
> >
> > Also because we could rethink the MIPS CP0 timer logic to avoid
> > too frequent divu128 calls (painful on 32-bit hosts).
> >
> > The style should be updated, using more variables for easier
> > review. env_archcpu() could eventually be dropped (by passing
> > MIPSCPU* instead of CPUMIPSState*).
>
> I guess it is better to wait for Peter patches to get merged
> before posting the updated patches (not much, just one previous
> patch MIPSCPU* instead of CPUMIPSState*).

This patch is still on my to-review queue, fwiw (though I am
taking a week off work next week, so I probably won't get to
it til March.)

-- PMM



Re: [RFC PATCH] target/mips/cp0_timer: Use new clock_ns_to_ticks()

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/11/21 12:43 AM, Philippe Mathieu-Daudé wrote:
> Use the new clock_ns_to_ticks() function in cp0_timer where
> appropriate. This allows us to remove CPUMIPSState::cp0_count_ns
> and mips_cp0_period_set().
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Based-on: <20210209132040.5091-1-peter.mayd...@linaro.org>
> 
> RFC because this is just a starter patch to test Peter's series
> providing a handy function which "tells me how many times this
> clock would tick in this length of time".
> 
> Also because we could rethink the MIPS CP0 timer logic to avoid
> too frequent divu128 calls (painful on 32-bit hosts).
> 
> The style should be updated, using more variables for easier
> review. env_archcpu() could eventually be dropped (by passing
> MIPSCPU* instead of CPUMIPSState*).

I guess it is better to wait for Peter patches to get merged
before posting the updated patches (not much, just one previous
patch MIPSCPU* instead of CPUMIPSState*).

Regards,

Phil.



[PATCH v2 6/8] hw/block: Introduce TC58128 eeprom Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
Add more fine-grained selection by adding a CONFIG_TC58128
selector for the TC58128 eeprom.

As this device is only used by the Shix machine, add an entry
to the proper section in MAINTAINERS.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS  | 1 +
 hw/block/meson.build | 2 +-
 hw/sh4/Kconfig   | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cacb5d125ab..6117ad414a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1397,6 +1397,7 @@ Shix
 M: Yoshinori Sato 
 R: Magnus Damm 
 S: Odd Fixes
+F: hw/block/tc58128.c
 F: hw/char/sh_serial.c
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
diff --git a/hw/block/meson.build b/hw/block/meson.build
index 602ca6c8541..4bf994c64ff 100644
--- a/hw/block/meson.build
+++ b/hw/block/meson.build
@@ -12,7 +12,7 @@
 softmmu_ss.add(when: 'CONFIG_SSI_M25P80', if_true: files('m25p80.c'))
 softmmu_ss.add(when: 'CONFIG_SWIM', if_true: files('swim.c'))
 softmmu_ss.add(when: 'CONFIG_XEN', if_true: files('xen-block.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('tc58128.c'))
+softmmu_ss.add(when: 'CONFIG_TC58128', if_true: files('tc58128.c'))
 softmmu_ss.add(when: 'CONFIG_NVME_PCI', if_true: files('nvme.c', 'nvme-ns.c'))
 
 specific_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true: files('virtio-blk.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index e569470a614..34c01dadde9 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -16,6 +16,7 @@ config SHIX
 bool
 select SH7750
 select SH4
+select TC58128
 
 config SH7750
 bool
-- 
2.26.2




[PATCH v2 5/8] hw/timer: Introduce SH_TIMER Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_TIMER selector for the SH4 timer control unit.

Add the missing MAINTAINERS entries.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS  | 2 ++
 hw/sh4/Kconfig   | 2 +-
 hw/timer/Kconfig | 4 
 hw/timer/meson.build | 2 +-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 34587d90637..cacb5d125ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1390,6 +1390,7 @@ S: Odd Fixes
 F: hw/char/sh_serial.c
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
+F: hw/timer/sh_timer.c
 F: include/hw/sh4/sh_intc.h
 
 Shix
@@ -1399,6 +1400,7 @@ S: Odd Fixes
 F: hw/char/sh_serial.c
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
+F: hw/timer/sh_timer.c
 F: include/hw/sh4/sh_intc.h
 
 SPARC Machines
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 47240aa97b7..e569470a614 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -21,7 +21,7 @@ config SH7750
 bool
 select SH_INTC
 select SH_SCI
+select SH_TIMER
 
 config SH4
 bool
-select PTIMER
diff --git a/hw/timer/Kconfig b/hw/timer/Kconfig
index 8749edfb6a5..18936ef55bf 100644
--- a/hw/timer/Kconfig
+++ b/hw/timer/Kconfig
@@ -36,6 +36,10 @@ config CMSDK_APB_DUALTIMER
 bool
 select PTIMER
 
+config SH_TIMER
+bool
+select PTIMER
+
 config RENESAS_TMR
 bool
 
diff --git a/hw/timer/meson.build b/hw/timer/meson.build
index be343f68fed..26c2701fd78 100644
--- a/hw/timer/meson.build
+++ b/hw/timer/meson.build
@@ -30,7 +30,7 @@
 softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_ost.c'))
 softmmu_ss.add(when: 'CONFIG_PXA2XX', if_true: files('pxa2xx_timer.c'))
 softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_systmr.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('sh_timer.c'))
+softmmu_ss.add(when: 'CONFIG_SH_TIMER', if_true: files('sh_timer.c'))
 softmmu_ss.add(when: 'CONFIG_SLAVIO', if_true: files('slavio_timer.c'))
 softmmu_ss.add(when: 'CONFIG_STM32F2XX_TIMER', if_true: 
files('stm32f2xx_timer.c'))
 softmmu_ss.add(when: 'CONFIG_XILINX', if_true: files('xilinx_timer.c'))
-- 
2.26.2




[PATCH v2 8/8] hw/sh4: Remove now unused CONFIG_SH4 from Kconfig

2021-02-21 Thread Philippe Mathieu-Daudé
As replaced the generic CONFIG_SH4 by more fine-grained
selectors, we can remove this now unused config variable.

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

diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index b9f0538d57f..ab733a3f760 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -9,14 +9,12 @@ config R2D
 select USB_OHCI_PCI
 select PCI
 select SM501
-select SH4
 select SH7750
 select SH_PCI
 
 config SHIX
 bool
 select SH7750
-select SH4
 select TC58128
 
 config SH7750
@@ -24,6 +22,3 @@ config SH7750
 select SH_INTC
 select SH_SCI
 select SH_TIMER
-
-config SH4
-bool
-- 
2.26.2




[PATCH v2 4/8] hw/char: Introduce SH_SCI Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_SCI selector for the SH4 serial controller.

Add the missing MAINTAINERS entries.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS | 2 ++
 hw/char/Kconfig | 3 +++
 hw/char/meson.build | 2 +-
 hw/sh4/Kconfig  | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index da10756abf7..34587d90637 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1387,6 +1387,7 @@ R2D
 M: Yoshinori Sato 
 R: Magnus Damm 
 S: Odd Fixes
+F: hw/char/sh_serial.c
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
 F: include/hw/sh4/sh_intc.h
@@ -1395,6 +1396,7 @@ Shix
 M: Yoshinori Sato 
 R: Magnus Damm 
 S: Odd Fixes
+F: hw/char/sh_serial.c
 F: hw/sh4/shix.c
 F: hw/intc/sh_intc.c
 F: include/hw/sh4/sh_intc.h
diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index 939bc447588..f6f4fffd1b7 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -50,6 +50,9 @@ config SCLPCONSOLE
 config TERMINAL3270
 bool
 
+config SH_SCI
+bool
+
 config RENESAS_SCI
 bool
 
diff --git a/hw/char/meson.build b/hw/char/meson.build
index 196ac91fa29..afe9a0af88c 100644
--- a/hw/char/meson.build
+++ b/hw/char/meson.build
@@ -31,7 +31,7 @@
 softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_aux.c'))
 softmmu_ss.add(when: 'CONFIG_RENESAS_SCI', if_true: files('renesas_sci.c'))
 softmmu_ss.add(when: 'CONFIG_SIFIVE_UART', if_true: files('sifive_uart.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('sh_serial.c'))
+softmmu_ss.add(when: 'CONFIG_SH_SCI', if_true: files('sh_serial.c'))
 softmmu_ss.add(when: 'CONFIG_STM32F2XX_USART', if_true: 
files('stm32f2xx_usart.c'))
 softmmu_ss.add(when: 'CONFIG_MCHP_PFSOC_MMUART', if_true: 
files('mchp_pfsoc_mmuart.c'))
 
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index c2008c6a0d2..47240aa97b7 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -20,6 +20,7 @@ config SHIX
 config SH7750
 bool
 select SH_INTC
+select SH_SCI
 
 config SH4
 bool
-- 
2.26.2




[PATCH v2 7/8] hw/pci-host: Introduce SH_PCI Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_PCI selector for the SH4 PCI controller.
Move the file with the other PCI host devices in hw/pci-host
and add its missing MAINTAINERS entries.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/{sh4 => pci-host}/sh_pci.c | 0
 MAINTAINERS   | 1 +
 hw/pci-host/meson.build   | 1 +
 hw/sh4/Kconfig| 1 +
 hw/sh4/meson.build| 1 -
 5 files changed, 3 insertions(+), 1 deletion(-)
 rename hw/{sh4 => pci-host}/sh_pci.c (100%)

diff --git a/hw/sh4/sh_pci.c b/hw/pci-host/sh_pci.c
similarity index 100%
rename from hw/sh4/sh_pci.c
rename to hw/pci-host/sh_pci.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 6117ad414a4..7698a69e621 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1390,6 +1390,7 @@ S: Odd Fixes
 F: hw/char/sh_serial.c
 F: hw/sh4/r2d.c
 F: hw/intc/sh_intc.c
+F: hw/pci-host/sh_pci.c
 F: hw/timer/sh_timer.c
 F: include/hw/sh4/sh_intc.h
 
diff --git a/hw/pci-host/meson.build b/hw/pci-host/meson.build
index 1847c69905c..87a896973e7 100644
--- a/hw/pci-host/meson.build
+++ b/hw/pci-host/meson.build
@@ -10,6 +10,7 @@
 pci_ss.add(when: 'CONFIG_PCI_SABRE', if_true: files('sabre.c'))
 pci_ss.add(when: 'CONFIG_XEN_IGD_PASSTHROUGH', if_true: files('xen_igd_pt.c'))
 pci_ss.add(when: 'CONFIG_REMOTE_PCIHOST', if_true: files('remote.c'))
+pci_ss.add(when: 'CONFIG_SH_PCI', if_true: files('sh_pci.c'))
 
 # PPC devices
 pci_ss.add(when: 'CONFIG_PREP_PCI', if_true: files('prep.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 34c01dadde9..b9f0538d57f 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -11,6 +11,7 @@ config R2D
 select SM501
 select SH4
 select SH7750
+select SH_PCI
 
 config SHIX
 bool
diff --git a/hw/sh4/meson.build b/hw/sh4/meson.build
index 303c0f42879..424d5674dea 100644
--- a/hw/sh4/meson.build
+++ b/hw/sh4/meson.build
@@ -2,7 +2,6 @@
 sh4_ss.add(files(
   'sh7750.c',
   'sh7750_regnames.c',
-  'sh_pci.c'
 ))
 sh4_ss.add(when: 'CONFIG_R2D', if_true: files('r2d.c'))
 sh4_ss.add(when: 'CONFIG_SHIX', if_true: files('shix.c'))
-- 
2.26.2




[PATCH v2 3/8] hw/intc: Introduce SH_INTC Kconfig entry

2021-02-21 Thread Philippe Mathieu-Daudé
We want to be able to use the 'SH4' config for architecture
specific features. Add more fine-grained selection by adding
a CONFIG_SH_INTC selector for the SH4 interrupt controller.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/intc/Kconfig | 3 +++
 hw/intc/meson.build | 2 +-
 hw/sh4/Kconfig  | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig
index c18d11142a8..66bf0b90b47 100644
--- a/hw/intc/Kconfig
+++ b/hw/intc/Kconfig
@@ -53,6 +53,9 @@ config OMPIC
 config PPC_UIC
 bool
 
+config SH_INTC
+bool
+
 config RX_ICU
 bool
 
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 53cba115690..b3d9345a0d2 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -47,7 +47,7 @@
 specific_ss.add(when: 'CONFIG_RX_ICU', if_true: files('rx_icu.c'))
 specific_ss.add(when: 'CONFIG_S390_FLIC', if_true: files('s390_flic.c'))
 specific_ss.add(when: 'CONFIG_S390_FLIC_KVM', if_true: 
files('s390_flic_kvm.c'))
-specific_ss.add(when: 'CONFIG_SH4', if_true: files('sh_intc.c'))
+specific_ss.add(when: 'CONFIG_SH_INTC', if_true: files('sh_intc.c'))
 specific_ss.add(when: 'CONFIG_SIFIVE_CLINT', if_true: files('sifive_clint.c'))
 specific_ss.add(when: 'CONFIG_SIFIVE_PLIC', if_true: files('sifive_plic.c'))
 specific_ss.add(when: 'CONFIG_XICS', if_true: files('xics.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 0452b4624ae..c2008c6a0d2 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -19,6 +19,7 @@ config SHIX
 
 config SH7750
 bool
+select SH_INTC
 
 config SH4
 bool
-- 
2.26.2




[PATCH v2 2/8] hw/sh4: Add missing Kconfig dependency on SH7750 for the R2D board

2021-02-21 Thread Philippe Mathieu-Daudé
r2d_init() calls sh7750_init() so depends on SH7750.Harmless
at the moment because nothing actually uses CONFIG_SH7750
(hw/sh4/meson.build always compiles sh7750.c and sh7750_regnames.c
unconditionally).

Fixes: 7ab58d4c841 ("sh4-softmmu.mak: express dependencies with Kconfig")
Reported-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/sh4/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 4cbce3a0ed5..0452b4624ae 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -10,6 +10,7 @@ config R2D
 select PCI
 select SM501
 select SH4
+select SH7750
 
 config SHIX
 bool
-- 
2.26.2




[PATCH v2 1/8] hw/sh4: Add missing license

2021-02-21 Thread Philippe Mathieu-Daudé
This code was introduced in commit 27c7ca7e775,
("SHIX board emulation (Samuel Tardieu)"). Use
the same license.

Cc: Samuel Tardieu 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/sh4/sh.h | 12 +---
 hw/block/tc58128.c  |  7 +++
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/include/hw/sh4/sh.h b/include/hw/sh4/sh.h
index 93f464bf4cd..33dde7a56dd 100644
--- a/include/hw/sh4/sh.h
+++ b/include/hw/sh4/sh.h
@@ -1,6 +1,12 @@
-#ifndef QEMU_SH_H
-#define QEMU_SH_H
-/* Definitions for SH board emulation.  */
+/*
+ * Definitions for SH board emulation
+ *
+ * Copyright (c) 2005 Samuel Tardieu
+ *
+ * SPDX-License-Identifier: MIT
+ */
+#ifndef QEMU_HW_SH_H
+#define QEMU_HW_SH_H
 
 #include "hw/sh4/sh_intc.h"
 #include "target/sh4/cpu-qom.h"
diff --git a/hw/block/tc58128.c b/hw/block/tc58128.c
index 9888f01ac60..1a0fa86d8ea 100644
--- a/hw/block/tc58128.c
+++ b/hw/block/tc58128.c
@@ -1,3 +1,10 @@
+/*
+ * TC58128 NAND EEPROM emulation
+ *
+ * Copyright (c) 2005 Samuel Tardieu
+ *
+ * SPDX-License-Identifier: MIT
+ */
 #include "qemu/osdep.h"
 #include "qemu/units.h"
 #include "hw/sh4/sh.h"
-- 
2.26.2




[PATCH v2 0/8] hw/sh4: Kconfig cleanups

2021-02-21 Thread Philippe Mathieu-Daudé
Since v1:
- Addressed Peter Maydell review comments from
https://www.mail-archive.com/qemu-block@nongnu.org/msg80599.html

Supersedes: <20210208135048.2601693-1-f4...@amsat.org>

Philippe Mathieu-Daudé (8):
  hw/sh4: Add missing license
  hw/sh4: Add missing Kconfig dependency on SH7750 for the R2D board
  hw/intc: Introduce SH_INTC Kconfig entry
  hw/char: Introduce SH_SCI Kconfig entry
  hw/timer: Introduce SH_TIMER Kconfig entry
  hw/block: Introduce TC58128 eeprom Kconfig entry
  hw/pci-host: Introduce SH_PCI Kconfig entry
  hw/sh4: Remove now unused CONFIG_SH4 from Kconfig

 include/hw/sh4/sh.h   | 12 +---
 hw/block/tc58128.c|  7 +++
 hw/{sh4 => pci-host}/sh_pci.c |  0
 MAINTAINERS   |  6 ++
 hw/block/meson.build  |  2 +-
 hw/char/Kconfig   |  3 +++
 hw/char/meson.build   |  2 +-
 hw/intc/Kconfig   |  3 +++
 hw/intc/meson.build   |  2 +-
 hw/pci-host/meson.build   |  1 +
 hw/sh4/Kconfig| 12 ++--
 hw/sh4/meson.build|  1 -
 hw/timer/Kconfig  |  4 
 hw/timer/meson.build  |  2 +-
 14 files changed, 43 insertions(+), 14 deletions(-)
 rename hw/{sh4 => pci-host}/sh_pci.c (100%)

-- 
2.26.2




[PULL v2 07/43] tests/acceptance: Test PMON with Loongson-3A1000 CPU

2021-02-21 Thread Philippe Mathieu-Daudé
From: Jiaxun Yang 

Test booting of PMON bootloader on loongson3-virt platform.

$ (venv) AVOCADO_ALLOW_UNTRUSTED_CODE=1 \
avocado --show=app,console \
  run -t machine:loongson3-virt tests/acceptance
Fetching asset from 
tests/acceptance/machine_mips_loongson3v.py:MipsLoongson3v.test_pmon_serial_console
JOB ID : 8e202b3727847c9104d0d3d6546ed225d35f6706
JOB LOG: 
/home/flygoat/avocado/job-results/job-2021-01-12T10.02-8e202b3/job.log
 (1/1) 
tests/acceptance/machine_mips_loongson3v.py:MipsLoongson3v.test_pmon_serial_console:
console: PMON2000 MIPS Initializing. Standby...
console: Jump to 9fc
console: Init Memory done.
console: The uncache data is:
console: :  
console: 0008:  
console: 0010:  
console: 0018:  
console: 0020:  
console: 0028:  
console: 0030:  
console: 0038:  
console: The cached  data is:
console: :  
console: 0008:  
console: 0010:  
console: 0018:  
console: 0020:  
console: 0028:  
console: 0030:  
console: 0038:  
console: Copy PMON to execute location...
console: start = 0x8f90
console: s0 = 0x3030
console: _edata = 0x8f989010
console: _end = 0x8f98a028copy text section done.
console: Copy PMON to execute location done.
console: sp=8f8fc000
console: Uncompressing 
BiosOK,Booting
 Bios
console: FREQ
console: DONE
console: DEVI
console: ENVI
console: MAPV
console: NVRAM@8f7ff898
console: STDV
console: 8010:  memory between 8f7ff400-8f80  is already been 
allocated,heap is already above this point
console: SBDD
console: P12PCIH
console: PCIH
console: PCID
console: setting up 1 bus
console: PCI bus 0 slot 1: probe...completed
console: PCI bus 0 slot 1/0: vendor/product: 0x106b/0x003f (serialbus, USB, 
interface: 0x10, revision: 0x00)
console: PCI bus 0 slot 1/0: reg 0x10 = 0xff00
console: PCI bus 0 slot 2: probe...completed
console: PCI bus 0 slot 2/0: vendor/product: 0x1af4/0x1000 (network, ethernet, 
interface: 0x00, revision: 0x00)
console: PCI bus 0 slot 2/0: reg 0x10 = 0xffe1
console: PCI bus 0 slot 2/0: reg 0x14 = 0xf000
console: PCI bus 0 slot 2/0: reg 0x20 = 0xc00c
console: PCI bus 0 slot 2/0: reg 0x30 = 0xfffc
console: PCI bus 0 slot 3: probe...completed
console: PCI bus 0 slot 4: probe...completed
console: PCI bus 0 slot 5: probe...completed
console: PCI bus 0 slot 6: probe...completed
console: PCI bus 0 slot 7: probe...completed
console: PCI bus 0 slot 8: probe...completed
console: PCI bus 0 slot 9: probe...completed
console: PCI bus 0 slot 10: probe...completed
console: PCI bus 0 slot 11: probe...completed
console: PCI bus 0 slot 12: probe...completed
console: PCI bus 0 slot 13: probe...completed
console: PCI bus 0 slot 14: probe...completed
console: PCI bus 0 slot 15: probe...completed
console: PCI bus 0 slot 16: probe...completed
console: PCI bus 0 slot 17: probe...completed
console: PCI bus 0 slot 18: probe...completed
console: PCI bus 0 slot 19: probe...completed
console: PCI bus 0 slot 20: probe...completed
console: PCI bus 0 slot 21: probe...completed
console: PCI bus 0 slot 22: probe...completed
console: PCI bus 0 slot 23: probe...completed
console: PCI bus 0 slot 24: probe...completed
console: PCI bus 0 slot 25: probe...completed
console: PCI bus 0 slot 26: probe...completed
console: PCI bus 0 slot 27: probe...completed
console: PCI bus 0 slot 28: probe...completed
console: PCI bus 0 slot 29: probe...completed
console: PCI bus 0 slot 30: probe...completed
console: PCI bus 0 slot 31: probe...completed
console: PCIS
console: PCIR
console: PCIW
console: PCI bus 0 slot 2/0: mem @0x4000, reg 0x30 262144 bytes
console: PCI bus 0 slot 2/0: mem @0x4004, reg 0x20 16384 bytes
console: PCI bus 0 slot 2/0: mem @0x40044000, reg 0x14 4096 bytes
console: PCI bus 0 slot 1/0: mem @0x40045000, reg 0x10 256 bytes
console: PCI bus 0 slot 2/0: exp @0x4000, 262144 bytes
console: PCI bus 0 slot 2/0: i/o @0x4000, reg 0x10 32 bytes
console: NETI
console: RTCL
console: PCID
console: VGAI
console: memorysize=c00,base=8f6ff508,sysMem=8f6ef500
console: in setup_int_vect!done!VESA
console: vga bios init failed, rc=-1
console: in configure
console: mainbus0 (root)
console: localbus0 at mainbus0
console: loopdev0 at mainbus0pcibr0 at mainbus0
console: pci0 at pcibr0 bus 0
console: ohci0 at pci0 dev 1 function 0 vendor/product: 0x106b/0x003f 
(serialbus, USB, interface: 0x10, revision: 0x00)usb base addr : 0xc0045000, 
bus_base is : 0xc000
console: OHCI revision: 0x0010
console: RH: a: 0x0203 b: 0x
console: early period(0x0)
console: OHCI 8c01ec00 initialized ok
console: New Device 0
console: 

Re: [PATCH] ui/cocoa: Fix mouse association state

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 18:31, Akihiko Odaki  wrote:
>
> Signed-off-by: Akihiko Odaki 

This is hard to review without a commit message that describes:
 * what the problem is that the change is trying to fix
 * what the change is doing
 * why this fixes the problem

Without a commit message you're asking code reviewers to
reverse-engineer your intentions from the code change,
which is a lot more work than if you told us up front :-)

thanks
-- PMM



[PULL v2 00/43] MIPS patches for 2021-02-21

2021-02-21 Thread Philippe Mathieu-Daudé
The following changes since commit a528b8c4c638d60cc474c2f80952ff0f2e60521a:

  Merge remote-tracking branch 'remotes/philmd-gitlab/tags/sdmmc-20210220' into 
staging (2021-02-20 19:28:27 +)

are available in the Git repository at:

  https://gitlab.com/philmd/qemu.git tags/mips-20210221

for you to fetch changes up to cc2b4550115baf77d556341f17eb464d18953cee:

  vt82c686: Fix superio_cfg_{read,write}() functions (2021-02-21 19:42:34 +0100)

Since v1: Add missing license in include/hw/mips/bootloader.h.


MIPS patches queue

- Drop redundant struct MemmapEntry (Bin)
- Fix for Coverity CID 1438965 and 1438967 (Jiaxun)
- Add MIPS bootloader API (Jiaxun)
- Use MIPS bootloader API on fuloong2e and boston machines (Jiaxun)
- Add PMON test for Loongson-3A1000 CPU (Jiaxun)
- Convert to translator API (Philippe)
- MMU cleanups (Philippe)
- Promote 128-bit multimedia registers as global ones (Philippe)
- Various cleanups/fixes on the VT82C686B southbridge (Zoltan)


BALATON Zoltan (16):
  vt82c686: Move superio memory region to SuperIOConfig struct
  vt82c686: Reorganise code
  vt82c686: Fix SMBus IO base and configuration registers
  vt82c686: Make vt82c686-pm an I/O tracing region
  vt82c686: Correct vt82c686-pm I/O size
  vt82c686: Correctly reset all registers to default values on reset
  vt82c686: Fix up power management io base and config
  vt82c686: Set user_creatable=false for VT82C686B_PM
  vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm
based on it
  vt82c686: Simplify vt82c686b_realize()
  vt82c686: Move creation of ISA devices to the ISA bridge
  vt82c686: Remove index field of SuperIOConfig
  vt82c686: Reduce indentation by returning early
  vt82c686: Simplify by returning earlier
  vt82c686: Log superio_cfg unimplemented accesses
  vt82c686: Fix superio_cfg_{read,write}() functions

Bin Meng (1):
  hw/mips: loongson3: Drop 'struct MemmapEntry'

Jiaxun Yang (6):
  hw/mips: Add a bootloader helper
  hw/mips/fuloong2e: Use bl_gen_kernel_jump to generate bootloaders
  hw/mips/boston: Use bl_gen_kernel_jump to generate bootloaders
  hw/mips/boston: Use bootloader helper to set GCRs
  hw/intc/loongson_liointc: Fix per core ISR handling
  tests/acceptance: Test PMON with Loongson-3A1000 CPU

Philippe Mathieu-Daudé (20):
  target/mips: fetch code with translator_ld
  target/mips: Remove access_type argument from map_address() handler
  target/mips: Remove access_type argument from get_seg_physical_address
  target/mips: Remove access_type arg from get_segctl_physical_address()
  target/mips: Remove access_type argument from get_physical_address()
  target/mips: Remove unused MMU definitions
  target/mips: Replace magic value by MMU_DATA_LOAD definition
  target/mips: Let do_translate_address() take MMUAccessType argument
  target/mips: Let cpu_mips_translate_address() take MMUAccessType arg
  target/mips: Let raise_mmu_exception() take MMUAccessType argument
  target/mips: Let get_physical_address() take MMUAccessType argument
  target/mips: Let get_seg*_physical_address() take MMUAccessType arg
  target/mips: Let CPUMIPSTLBContext::map_address() take MMUAccessType
  target/mips: Remove unused 'rw' argument from page_table_walk_refill()
  target/mips: Include missing "tcg/tcg.h" header
  target/mips: Make cpu_HI/LO registers public
  target/mips: Promote 128-bit multimedia registers as global ones
  target/mips: Rename 128-bit upper halve GPR registers
  target/mips: Introduce gen_load_gpr_hi() / gen_store_gpr_hi() helpers
  target/mips: Use GPR move functions in gen_HILO1_tx79()

 hw/mips/loongson3_bootp.h   |   7 +-
 include/hw/isa/vt82c686.h   |   1 +
 include/hw/mips/bootloader.h|  22 +
 include/hw/pci/pci_ids.h|   3 +-
 target/mips/cpu.h   |  26 +-
 target/mips/internal.h  |  10 +-
 target/mips/translate.h |   8 +
 hw/intc/loongson_liointc.c  |  16 +-
 hw/isa/vt82c686.c   | 542 
 hw/mips/bootloader.c| 200 
 hw/mips/boston.c|  62 +--
 hw/mips/fuloong2e.c |  60 +--
 hw/mips/loongson3_virt.c|   6 +-
 target/mips/msa_helper.c|   1 +
 target/mips/op_helper.c |   9 +-
 target/mips/tlb_helper.c|  80 ++-
 target/mips/translate.c | 111 ++--
 MAINTAINERS |   1 +
 hw/isa/trace-events |   2 +
 hw/mips/meson.build |   2 +-
 tests/acceptance/machine_mips_loongson3v.py |  39 ++
 21 files changed, 749 insertions(+), 459 deletions(-)
 create mode 100644 include/hw/mips/bootloader.h
 create mode 1006

[PULL v2 02/43] hw/mips: Add a bootloader helper

2021-02-21 Thread Philippe Mathieu-Daudé
From: Jiaxun Yang 

Add a bootloader helper to generate simple bootloaders for kernel.
It can help us reduce inline hex hack and also keep MIPS release 6
compatibility easier.

Signed-off-by: Jiaxun Yang 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210127065424.114125-2-jiaxun.y...@flygoat.com>
[PMD: Restricted bl_reg enum to C source,
  inverted bl_gen_write() args,
  added license in hw/mips/bootloader.h]
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/mips/bootloader.h |  22 
 hw/mips/bootloader.c | 200 +++
 hw/mips/meson.build  |   2 +-
 3 files changed, 223 insertions(+), 1 deletion(-)
 create mode 100644 include/hw/mips/bootloader.h
 create mode 100644 hw/mips/bootloader.c

diff --git a/include/hw/mips/bootloader.h b/include/hw/mips/bootloader.h
new file mode 100644
index 000..b5f48d71bba
--- /dev/null
+++ b/include/hw/mips/bootloader.h
@@ -0,0 +1,22 @@
+/*
+ * Utility for QEMU MIPS to generate it's simple bootloader
+ *
+ * Copyright (C) 2020 Jiaxun Yang 
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef HW_MIPS_BOOTLOADER_H
+#define HW_MIPS_BOOTLOADER_H
+
+#include "exec/cpu-defs.h"
+
+void bl_gen_jump_to(uint32_t **p, target_ulong jump_addr);
+void bl_gen_jump_kernel(uint32_t **p, target_ulong sp, target_ulong a0,
+target_ulong a1, target_ulong a2, target_ulong a3,
+target_ulong kernel_addr);
+void bl_gen_write_ulong(uint32_t **p, target_ulong addr, target_ulong val);
+void bl_gen_write_u32(uint32_t **p, target_ulong addr, uint32_t val);
+void bl_gen_write_u64(uint32_t **p, target_ulong addr, uint64_t val);
+
+#endif
diff --git a/hw/mips/bootloader.c b/hw/mips/bootloader.c
new file mode 100644
index 000..6ec83144909
--- /dev/null
+++ b/hw/mips/bootloader.c
@@ -0,0 +1,200 @@
+/*
+ * Utility for QEMU MIPS to generate it's simple bootloader
+ *
+ * Instructions used here are carefully selected to keep compatibility with
+ * MIPS Release 6.
+ *
+ * Copyright (C) 2020 Jiaxun Yang 
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/bitops.h"
+#include "cpu.h"
+#include "hw/mips/bootloader.h"
+
+typedef enum bl_reg {
+BL_REG_ZERO = 0,
+BL_REG_AT = 1,
+BL_REG_V0 = 2,
+BL_REG_V1 = 3,
+BL_REG_A0 = 4,
+BL_REG_A1 = 5,
+BL_REG_A2 = 6,
+BL_REG_A3 = 7,
+BL_REG_T0 = 8,
+BL_REG_T1 = 9,
+BL_REG_T2 = 10,
+BL_REG_T3 = 11,
+BL_REG_T4 = 12,
+BL_REG_T5 = 13,
+BL_REG_T6 = 14,
+BL_REG_T7 = 15,
+BL_REG_S0 = 16,
+BL_REG_S1 = 17,
+BL_REG_S2 = 18,
+BL_REG_S3 = 19,
+BL_REG_S4 = 20,
+BL_REG_S5 = 21,
+BL_REG_S6 = 22,
+BL_REG_S7 = 23,
+BL_REG_T8 = 24,
+BL_REG_T9 = 25,
+BL_REG_K0 = 26,
+BL_REG_K1 = 27,
+BL_REG_GP = 28,
+BL_REG_SP = 29,
+BL_REG_FP = 30,
+BL_REG_RA = 31,
+} bl_reg;
+
+static bool bootcpu_supports_isa(uint64_t isa_mask)
+{
+return cpu_supports_isa(_CPU(first_cpu)->env, isa_mask);
+}
+
+/* Base types */
+static void bl_gen_nop(uint32_t **p)
+{
+stl_p(*p, 0);
+*p = *p + 1;
+}
+
+static void bl_gen_r_type(uint32_t **p, uint8_t opcode,
+  bl_reg rs, bl_reg rt, bl_reg rd,
+  uint8_t shift, uint8_t funct)
+{
+uint32_t insn = 0;
+
+insn = deposit32(insn, 26, 6, opcode);
+insn = deposit32(insn, 21, 5, rs);
+insn = deposit32(insn, 16, 5, rt);
+insn = deposit32(insn, 11, 5, rd);
+insn = deposit32(insn, 6, 5, shift);
+insn = deposit32(insn, 0, 6, funct);
+
+stl_p(*p, insn);
+*p = *p + 1;
+}
+
+static void bl_gen_i_type(uint32_t **p, uint8_t opcode,
+  bl_reg rs, bl_reg rt, uint16_t imm)
+{
+uint32_t insn = 0;
+
+insn = deposit32(insn, 26, 6, opcode);
+insn = deposit32(insn, 21, 5, rs);
+insn = deposit32(insn, 16, 5, rt);
+insn = deposit32(insn, 0, 16, imm);
+
+stl_p(*p, insn);
+*p = *p + 1;
+}
+
+/* Single instructions */
+static void bl_gen_dsll(uint32_t **p, bl_reg rd, bl_reg rt, uint8_t sa)
+{
+if (bootcpu_supports_isa(ISA_MIPS3)) {
+bl_gen_r_type(p, 0, 0, rt, rd, sa, 0x38);
+} else {
+g_assert_not_reached(); /* unsupported */
+}
+}
+
+static void bl_gen_jalr(uint32_t **p, bl_reg rs)
+{
+bl_gen_r_type(p, 0, rs, 0, BL_REG_RA, 0, 0x09);
+}
+
+static void bl_gen_lui(uint32_t **p, bl_reg rt, uint16_t imm)
+{
+/* R6: It's a alias of AUI with RS = 0 */
+bl_gen_i_type(p, 0x0f, 0, rt, imm);
+}
+
+static void bl_gen_ori(uint32_t **p, bl_reg rt, bl_reg rs, uint16_t imm)
+{
+bl_gen_i_type(p, 0x0d, rs, rt, imm);
+}
+
+static void bl_gen_sw(uint32_t **p, bl_reg rt, uint8_t base, uint16_t offset)
+{
+bl_gen_i_type(p, 0x2b, base, rt, offset);
+}
+
+static void bl_gen_sd(uint32_t **p, bl_reg rt, uint8_t base, uint16_t offset)
+{
+if (bootcpu_supports_isa(ISA_MIPS3)) {
+bl_gen_i_type(p, 0x3f, base, rt, offset);
+ 

[Bug 1914849] Re: mprotect fails after MacOS 11.2 on arm mac

2021-02-21 Thread Stefan Weil
It works for me when I use "./configure --enable-debug-tcg --extra-
cflags=-I/opt/homebrew/include".

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

Title:
  mprotect fails after MacOS 11.2 on arm mac

Status in QEMU:
  Confirmed

Bug description:
  I got the following error when I ran qemu on arm mac(MacOS 11.2).

  ```
  $ ./qemu-system-x86_64
  qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied
  **
  ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  [1]34898 abort  ./qemu-system-x86_64
  ```

  I tested the same version of qemu on intel mac(MacOS 11.2), but it
  works fine.

  And my friend told me that they did not have this error with MacOS
  11.1.

  So, I think it is CPU architecture or an OS version dependent error.

  
  Environment:

  Qemu commit id: d0dddab40e472ba62b5f43f11cc7dba085dabe71
  OS: MacOS 11.2(20D64)
  Hardware: MacBook Air (M1, 2020)

  
  How to build:

  ```
  mkdir build/
  cd build/
  ../configure --target-list=aarch64-softmmu,x86_64-softmmu
  make
  ```

  
  How to reproduce:

  ```
  ./qemu-system-x86_64
  ```

  
  Error message:

  ```
  $ ./qemu-system-x86_64
  qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied
  **
  ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  [1]34898 abort  ./qemu-system-x86_64
  ```

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



Re: [PATCH] ui/cocoa: Fix stride resolution of pixman image

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 17:31, Akihiko Odaki  wrote:
>
> Signed-off-by: Akihiko Odaki 

In what situations does this change make a difference?
Obviously most of the time it works fine, or we'd have noticed
before now.

(This is the kind of detail that it's useful to provide in
the commit message.)

thanks
-- PMM



Re: tests: n810 arm failing

2021-02-21 Thread Peter Maydell
On Sun, 21 Feb 2021 at 17:26, Philippe Mathieu-Daudé  wrote:
>
> Hi,
>
> The n810 arm test failed on latest master:
>
> https://gitlab.com/qemu-project/qemu/-/jobs/1045015424/artifacts/browse/build/tests/results/latest/test-results/26-tests_acceptance_machine_arm_n8x0.py_N8x0Machine.test_n810/

It passed on the gitlab CI run on the exact same commit hash
as 'staging' before I pushed the merge, though...

-- PMM



Re: KVM Guest

2021-02-21 Thread Philippe Mathieu-Daudé
Hi Thomas,

On 2/9/21 2:32 AM, Huacai Chen wrote:
> I think it can be removed.
> 
> Huacai
> 
> On Tue, Feb 9, 2021 at 12:40 AM Jiaxun Yang  wrote:
>> On Mon, Feb 8, 2021, at 3:39 AM, Thomas Bogendoerfer wrote:
>>> On Wed, Feb 03, 2021 at 08:52:34PM +0800, Jiaxun Yang wrote:
 On Wed, Feb 3, 2021, at 8:34 PM, Thomas Bogendoerfer wrote:
> Hi,
>
> Does kvm guest kernel still work ? I'm playing with current mips-next
> and starting a kvm guest kernel inside an emulated malta system also
> running a mips-next kernel. The kvm guest kernel starts, but hangs
> in calibrate_delay (at least that's what info registers in qemu monitor
> suggests). Ayn ideas ?

 The current KVM guest kernel is actually a Trap-and-emul guest kernel.
 VZ based KVM uses the same binary with the host one, so does TCG.

 TE KVM is current unmaintained. I'll try to get a malta and do some test.
>>>
>>> hmm, so it looks broken, is unmaintained, how about removing it ?
>>
>> Probably. I got remote access of a CoreLV malta but no luck to boot kernel 
>> as well.
>>
>> + Huacai as KVM/MIPS Maintainer.
>> + Philippe as QEMU/MIPS Maintainer.
>> + qemu-devel for wider audience.
>>
>> If nobody intended to maintain it probably it's time to remove it.

For QEMU the situation is:

commit 1fa639e5618029e944ac68d27e32a99dcb85a349
Author: James Hogan 
Date:   Sat Dec 21 15:53:06 2019 +

MAINTAINERS: Orphan MIPS KVM CPUs

I haven't been active for 18 months, and don't have the hardware
set up to test KVM for MIPS, so mark it as orphaned and remove
myself as maintainer. Hopefully somebody from MIPS can pick this
up.

commit 15d983dee95edff1dc4c0bed71ce02fff877e766
Author: Aleksandar Markovic 
Date:   Wed Jul 1 20:25:58 2020 +0200

MAINTAINERS: Adjust MIPS maintainership (add Huacai & Jiaxun)

Huacai Chen and Jiaxun Yang step in as new energy.

commit ca263c0fb9f33cc746e6e3d968b7db80072ecf86
Author: Aleksandar Markovic 
Date:   Wed Oct 7 22:37:21 2020 +0200

MAINTAINERS: Remove myself

I have been working on project other than QEMU for some time,
and would like to devote myself to that project. It is impossible
for me to find enough time to perform maintainer's duties with
needed meticulousness and patience.


I don't have local hardware to test KVM. We have plan to add VZ testing
on Loongson hardware. For the rest I'll defer on Huacai and Jiaxun,
as long as it is useful to them, it is not a big burden for QEMU.

(IOW +1 for TE removal.)

Regards,

Phil.



[Bug 1914849] Re: mprotect fails after MacOS 11.2 on arm mac

2021-02-21 Thread Stefan Weil
** Changed in: qemu
   Status: New => Confirmed

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

Title:
  mprotect fails after MacOS 11.2 on arm mac

Status in QEMU:
  Confirmed

Bug description:
  I got the following error when I ran qemu on arm mac(MacOS 11.2).

  ```
  $ ./qemu-system-x86_64
  qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied
  **
  ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  [1]34898 abort  ./qemu-system-x86_64
  ```

  I tested the same version of qemu on intel mac(MacOS 11.2), but it
  works fine.

  And my friend told me that they did not have this error with MacOS
  11.1.

  So, I think it is CPU architecture or an OS version dependent error.

  
  Environment:

  Qemu commit id: d0dddab40e472ba62b5f43f11cc7dba085dabe71
  OS: MacOS 11.2(20D64)
  Hardware: MacBook Air (M1, 2020)

  
  How to build:

  ```
  mkdir build/
  cd build/
  ../configure --target-list=aarch64-softmmu,x86_64-softmmu
  make
  ```

  
  How to reproduce:

  ```
  ./qemu-system-x86_64
  ```

  
  Error message:

  ```
  $ ./qemu-system-x86_64
  qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied
  **
  ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc)
  [1]34898 abort  ./qemu-system-x86_64
  ```

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



[PATCH] ui/cocoa: Fix mouse association state

2021-02-21 Thread Akihiko Odaki
Signed-off-by: Akihiko Odaki 
---
 ui/cocoa.m | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 0ef5fdf3b7a..671af40b252 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -310,7 +310,6 @@ @interface QemuCocoaView : NSView
 BOOL isMouseGrabbed;
 BOOL isFullscreen;
 BOOL isAbsoluteEnabled;
-BOOL isMouseDeassociated;
 }
 - (void) switchSurface:(pixman_image_t *)image;
 - (void) grabMouse;
@@ -327,14 +326,9 @@ - (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled;
  * isMouseGrabbed tracks whether GUI events are directed to the guest;
  *   it controls whether special keys like Cmd get sent to the guest,
  *   and whether we capture the mouse when in non-absolute mode.
- * isMouseDeassociated tracks whether we've told MacOSX to disassociate
- *   the mouse and mouse cursor position by calling
- *   CGAssociateMouseAndMouseCursorPosition(FALSE)
- *   (which basically happens if we grab in non-absolute mode).
  */
 - (BOOL) isMouseGrabbed;
 - (BOOL) isAbsoluteEnabled;
-- (BOOL) isMouseDeassociated;
 - (float) cdx;
 - (float) cdy;
 - (QEMUScreen) gscreen;
@@ -974,10 +968,7 @@ - (void) grabMouse
 [normalWindow setTitle:@"QEMU - (Press ctrl + alt + g to release 
Mouse)"];
 }
 [self hideCursor];
-if (!isAbsoluteEnabled) {
-isMouseDeassociated = TRUE;
-CGAssociateMouseAndMouseCursorPosition(FALSE);
-}
+CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
 isMouseGrabbed = TRUE; // while isMouseGrabbed = TRUE, QemuCocoaApp sends 
all events to [cocoaView handleEvent:]
 }
 
@@ -992,17 +983,18 @@ - (void) ungrabMouse
 [normalWindow setTitle:@"QEMU"];
 }
 [self unhideCursor];
-if (isMouseDeassociated) {
-CGAssociateMouseAndMouseCursorPosition(TRUE);
-isMouseDeassociated = FALSE;
-}
+CGAssociateMouseAndMouseCursorPosition(TRUE);
 isMouseGrabbed = FALSE;
 }
 
-- (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled {isAbsoluteEnabled = 
tIsAbsoluteEnabled;}
+- (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled {
+isAbsoluteEnabled = tIsAbsoluteEnabled;
+if (isMouseGrabbed) {
+CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
+}
+}
 - (BOOL) isMouseGrabbed {return isMouseGrabbed;}
 - (BOOL) isAbsoluteEnabled {return isAbsoluteEnabled;}
-- (BOOL) isMouseDeassociated {return isMouseDeassociated;}
 - (float) cdx {return cdx;}
 - (float) cdy {return cdy;}
 - (QEMUScreen) gscreen {return screen;}
-- 
2.24.3 (Apple Git-128)




Re: [PATCH 1/4] hw/sh4/Kconfig: Rename CONFIG_SH4 -> CONFIG_SH4_DEVICES

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/21/21 7:07 PM, Philippe Mathieu-Daudé wrote:
> On 2/8/21 9:22 PM, Peter Maydell wrote:
>> On Mon, 8 Feb 2021 at 20:04, Philippe Mathieu-Daudé  wrote:
>>>
>>> We want to be able to use the 'SH4' config for architecture
>>> specific features. As CONFIG_SH4 is only used to select
>>> peripherals, rename it CONFIG_SH4_DEVICES.
>>>
>>> Reviewed-by: Alex Bennée 
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>  hw/block/meson.build | 2 +-
>>>  hw/char/meson.build  | 2 +-
>>>  hw/intc/meson.build  | 2 +-
>>>  hw/sh4/Kconfig   | 6 +++---
>>>  hw/timer/meson.build | 2 +-
>>>  5 files changed, 7 insertions(+), 7 deletions(-)
>>
>> We could if we wished be more fine-grained about this, eg by
>> adding new CONFIG options for each device:
>>  CONFIG_TC58128
>>  CONFIG_SH_SERIAL
>>  CONFIG_SH_INTC
>>  CONFIG_SH_TIMER
>>  CONFIG_SH_PCI
>>
>> and then in hw/sh4/Kconfig
>>  * config SH7750:
>>add 'select SH_SERIAL', 'select SH_INTC', 'select SH_TIMER'
>>  * config R2D:
>>add 'select SH7750' (it's a pre-existing bug that it doesn't, since
>>r2d.c has a call to sh7750_init(). Harmless at the moment because
>>nothing actually uses CONFIG_SH7750 -- hw/sh4/meson.build always
>>compiles sh7750.c and sh7750_regnames.c unconditionally...)
>>add 'select SH_PCI' (and make hw/sh4/meson.build build sh_pci.c
>>only if it is set...)
>>  * config SHIX
>>add 'select TC58128'
> 
> OK.

(Forgot to say in this case it makes sense because SH4 and RX targets
share peripherals IP cores, so some models could be reused.)



Re: [PATCH 1/4] hw/sh4/Kconfig: Rename CONFIG_SH4 -> CONFIG_SH4_DEVICES

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/8/21 9:22 PM, Peter Maydell wrote:
> On Mon, 8 Feb 2021 at 20:04, Philippe Mathieu-Daudé  wrote:
>>
>> We want to be able to use the 'SH4' config for architecture
>> specific features. As CONFIG_SH4 is only used to select
>> peripherals, rename it CONFIG_SH4_DEVICES.
>>
>> Reviewed-by: Alex Bennée 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  hw/block/meson.build | 2 +-
>>  hw/char/meson.build  | 2 +-
>>  hw/intc/meson.build  | 2 +-
>>  hw/sh4/Kconfig   | 6 +++---
>>  hw/timer/meson.build | 2 +-
>>  5 files changed, 7 insertions(+), 7 deletions(-)
> 
> We could if we wished be more fine-grained about this, eg by
> adding new CONFIG options for each device:
>  CONFIG_TC58128
>  CONFIG_SH_SERIAL
>  CONFIG_SH_INTC
>  CONFIG_SH_TIMER
>  CONFIG_SH_PCI
> 
> and then in hw/sh4/Kconfig
>  * config SH7750:
>add 'select SH_SERIAL', 'select SH_INTC', 'select SH_TIMER'
>  * config R2D:
>add 'select SH7750' (it's a pre-existing bug that it doesn't, since
>r2d.c has a call to sh7750_init(). Harmless at the moment because
>nothing actually uses CONFIG_SH7750 -- hw/sh4/meson.build always
>compiles sh7750.c and sh7750_regnames.c unconditionally...)
>add 'select SH_PCI' (and make hw/sh4/meson.build build sh_pci.c
>only if it is set...)
>  * config SHIX
>add 'select TC58128'

OK.

> Do we have a general preference for how fine-grained we go with the
> Kconfig switches ? Looking at the arm code, in some cases we have
> a CONFIG_ for the SoC that uses 'select' to turn on a separate
> CONFIG_ for each device (the STM32 SoCs are done this way), and
> in some cases we just have the meson.build use the SoC's CONFIG_*
> to control whether we compile its devices (the Xilinx and Exynos4
> SoCs are done this way). When reviewing new code it would be helpful
> to know whether to suggest doing it one way or the other :-)

My view is:

- Use fine granularity with shared/reusable models, so if someone
  wants to build a QEMU for a single machine, it is possible (using
  --without-default-devices and a specific target config.mak).
  Example: STM32F205_SOC and STM32F405_SOC

- For some (family of) SoC, a single switch is acceptable. In
  particular when all models are implemented in the same source file.
  Example: ASPEED_SOC

- Do not look at hw/i386/Kconfig

I have an old branch where I was generating a .dot of the Kconfig tree
for easier visualization, fine granularity was helpful. I'll try to
update it.

Regards,

Phil.



[PATCH v2] configure: fix --enable-fuzzing linker failures

2021-02-21 Thread Alexander Bulekov
With --enable-fuzzing, QEMU_CFLAGS include -fsanitize=fuzzer-no-link.
This should allow us to build non-fuzzer binaries using objects
instrumented for fuzzing. However, to do that, we also need to link with
-fsanitize=fuzzer-no-link. We were not doing that.

Reported-by: Li Qiang ,
Signed-off-by: Alexander Bulekov 
---
v2: Fix a mistake in the added QEMU_LDFLAGS line

 configure | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/configure b/configure
index a79b3746d4..19f2b88589 100755
--- a/configure
+++ b/configure
@@ -6096,7 +6096,17 @@ if test "$fuzzing" = "yes" ; then
   # If LIB_FUZZING_ENGINE is set, assume we are running on OSS-Fuzz, and the
   # needed CFLAGS have already been provided
   if test -z "${LIB_FUZZING_ENGINE+xxx}" ; then
+# Add CFLAGS to tell clang to add fuzzer-related instrumentation to all the
+# compiled code.
 QEMU_CFLAGS="$QEMU_CFLAGS -fsanitize=fuzzer-no-link"
+# To build non-fuzzer binaries with --enable-fuzzing, link everything with
+# fsanitize=fuzzer-no-link. Otherwise, the linker will be unable to bind
+# the fuzzer-related callbacks added by instrumentation.
+QEMU_LDFLAGS="$QEMU_LDFLAGS -fsanitize=fuzzer-no-link"
+# For the actual fuzzer binaries, we need to link against the libfuzzer
+# library. Provide the flags for doing this in FUZZ_EXE_LDFLAGS. The meson
+# rule for the fuzzer adds these to the link_args. They need to be
+# configurable, to support OSS-Fuzz
 FUZZ_EXE_LDFLAGS="-fsanitize=fuzzer"
   else
 FUZZ_EXE_LDFLAGS="$LIB_FUZZING_ENGINE"
-- 
2.27.0




Re: [PULL 00/43] MIPS patches for 2021-02-21

2021-02-21 Thread Philippe Mathieu-Daudé
Hi Peter,

On 2/21/21 3:33 PM, Philippe Mathieu-Daudé wrote:
> The following changes since commit a528b8c4c638d60cc474c2f80952ff0f2e60521a:
> 
>   Merge remote-tracking branch 'remotes/philmd-gitlab/tags/sdmmc-20210220' 
> into staging (2021-02-20 19:28:27 +)
> 
> are available in the Git repository at:
> 
>   https://gitlab.com/philmd/qemu.git tags/mips-20210221
> 
> for you to fetch changes up to 98e7c7108127bc9f2bf9065cbddd25778025b9c6:
> 
>   vt82c686: Fix superio_cfg_{read,write}() functions (2021-02-21 15:28:52 
> +0100)
> 
> 
> MIPS patches queue
> 
> - Drop redundant struct MemmapEntry (Bin)
> - Fix for Coverity CID 1438965 and 1438967 (Jiaxun)
> - Add MIPS bootloader API (Jiaxun)
> - Use MIPS bootloader API on fuloong2e and boston machines (Jiaxun)
> - Add PMON test for Loongson-3A1000 CPU (Jiaxun)
> - Convert to translator API (Philippe)
> - MMU cleanups (Philippe)
> - Promote 128-bit multimedia registers as global ones (Philippe)
> - Various cleanups/fixes on the VT82C686B southbridge (Zoltan)
> 
> 
> BALATON Zoltan (16):
>   vt82c686: Move superio memory region to SuperIOConfig struct
>   vt82c686: Reorganise code
>   vt82c686: Fix SMBus IO base and configuration registers
>   vt82c686: Make vt82c686-pm an I/O tracing region
>   vt82c686: Correct vt82c686-pm I/O size
>   vt82c686: Correctly reset all registers to default values on reset
>   vt82c686: Fix up power management io base and config
>   vt82c686: Set user_creatable=false for VT82C686B_PM
>   vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm
> based on it
>   vt82c686: Simplify vt82c686b_realize()
>   vt82c686: Move creation of ISA devices to the ISA bridge
>   vt82c686: Remove index field of SuperIOConfig
>   vt82c686: Reduce indentation by returning early
>   vt82c686: Simplify by returning earlier
>   vt82c686: Log superio_cfg unimplemented accesses
>   vt82c686: Fix superio_cfg_{read,write}() functions
> 
> Bin Meng (1):
>   hw/mips: loongson3: Drop 'struct MemmapEntry'
> 
> Jiaxun Yang (6):
>   hw/mips: Add a bootloader helper
>   hw/mips/fuloong2e: Use bl_gen_kernel_jump to generate bootloaders
>   hw/mips/boston: Use bl_gen_kernel_jump to generate bootloaders
>   hw/mips/boston: Use bootloader helper to set GCRs
>   hw/intc/loongson_liointc: Fix per core ISR handling
>   tests/acceptance: Test PMON with Loongson-3A1000 CPU
> 
> Philippe Mathieu-Daudé (20):
>   target/mips: fetch code with translator_ld
>   target/mips: Remove access_type argument from map_address() handler
>   target/mips: Remove access_type argument from get_seg_physical_address
>   target/mips: Remove access_type arg from get_segctl_physical_address()
>   target/mips: Remove access_type argument from get_physical_address()
>   target/mips: Remove unused MMU definitions
>   target/mips: Replace magic value by MMU_DATA_LOAD definition
>   target/mips: Let do_translate_address() take MMUAccessType argument
>   target/mips: Let cpu_mips_translate_address() take MMUAccessType arg
>   target/mips: Let raise_mmu_exception() take MMUAccessType argument
>   target/mips: Let get_physical_address() take MMUAccessType argument
>   target/mips: Let get_seg*_physical_address() take MMUAccessType arg
>   target/mips: Let CPUMIPSTLBContext::map_address() take MMUAccessType
>   target/mips: Remove unused 'rw' argument from page_table_walk_refill()
>   target/mips: Include missing "tcg/tcg.h" header
>   target/mips: Make cpu_HI/LO registers public
>   target/mips: Promote 128-bit multimedia registers as global ones
>   target/mips: Rename 128-bit upper halve GPR registers
>   target/mips: Introduce gen_load_gpr_hi() / gen_store_gpr_hi() helpers
>   target/mips: Use GPR move functions in gen_HILO1_tx79()

I am sorry I didn't notice hw/mips/bootloader.h is missing the
license (patch 2).

If it isn't too late for you I'll push a v2.

Thanks,

Phil.



[PATCH] ui/cocoa: Fix stride resolution of pixman image

2021-02-21 Thread Akihiko Odaki
Signed-off-by: Akihiko Odaki 
---
 ui/cocoa.m | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 0ef5fdf3b7a..2de72155dea 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -450,19 +450,19 @@ - (void) drawRect:(NSRect) rect
 int w = pixman_image_get_width(pixman_image);
 int h = pixman_image_get_height(pixman_image);
 int bitsPerPixel = 
PIXMAN_FORMAT_BPP(pixman_image_get_format(pixman_image));
-int bitsPerComponent = DIV_ROUND_UP(bitsPerPixel, 8) * 2;
+int stride = pixman_image_get_stride(pixman_image);
 CGDataProviderRef dataProviderRef = CGDataProviderCreateWithData(
 NULL,
 pixman_image_get_data(pixman_image),
-w * 4 * h,
+stride * h,
 NULL
 );
 CGImageRef imageRef = CGImageCreate(
 w, //width
 h, //height
-bitsPerComponent, //bitsPerComponent
+DIV_ROUND_UP(bitsPerPixel, 8) * 2, //bitsPerComponent
 bitsPerPixel, //bitsPerPixel
-(w * (bitsPerComponent/2)), //bytesPerRow
+stride, //bytesPerRow
 #ifdef __LITTLE_ENDIAN__
 CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB), //colorspace 
for OS X >= 10.4
 kCGBitmapByteOrder32Little | kCGImageAlphaNoneSkipFirst,
-- 
2.24.3 (Apple Git-128)




Re: [PULL 02/43] hw/mips: Add a bootloader helper

2021-02-21 Thread Philippe Mathieu-Daudé
On 2/21/21 3:33 PM, Philippe Mathieu-Daudé wrote:
> From: Jiaxun Yang 
> 
> Add a bootloader helper to generate simple bootloaders for kernel.
> It can help us reduce inline hex hack and also keep MIPS release 6
> compatibility easier.
> 
> Signed-off-by: Jiaxun Yang 
> Reviewed-by: Philippe Mathieu-Daudé 
> Message-Id: <20210127065424.114125-2-jiaxun.y...@flygoat.com>
> [PMD: Restricted bl_reg enum to C source, inverted bl_gen_write() args]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/mips/bootloader.h |  14 +++
>  hw/mips/bootloader.c | 200 +++
>  hw/mips/meson.build  |   2 +-
>  3 files changed, 215 insertions(+), 1 deletion(-)
>  create mode 100644 include/hw/mips/bootloader.h
>  create mode 100644 hw/mips/bootloader.c
> 
> diff --git a/include/hw/mips/bootloader.h b/include/hw/mips/bootloader.h
> new file mode 100644
> index 000..88eb9f49180
> --- /dev/null
> +++ b/include/hw/mips/bootloader.h
> @@ -0,0 +1,14 @@
> +#ifndef HW_MIPS_BOOTLOADER_H
> +#define HW_MIPS_BOOTLOADER_H

Missing license...

> +
> +#include "exec/cpu-defs.h"
> +
> +void bl_gen_jump_to(uint32_t **p, target_ulong jump_addr);
> +void bl_gen_jump_kernel(uint32_t **p, target_ulong sp, target_ulong a0,
> +target_ulong a1, target_ulong a2, target_ulong a3,
> +target_ulong kernel_addr);
> +void bl_gen_write_ulong(uint32_t **p, target_ulong addr, target_ulong val);
> +void bl_gen_write_u32(uint32_t **p, target_ulong addr, uint32_t val);
> +void bl_gen_write_u64(uint32_t **p, target_ulong addr, uint64_t val);
> +
> +#endif
> diff --git a/hw/mips/bootloader.c b/hw/mips/bootloader.c
> new file mode 100644
> index 000..6ec83144909
> --- /dev/null
> +++ b/hw/mips/bootloader.c
> @@ -0,0 +1,200 @@
> +/*
> + * Utility for QEMU MIPS to generate it's simple bootloader
> + *
> + * Instructions used here are carefully selected to keep compatibility with
> + * MIPS Release 6.
> + *
> + * Copyright (C) 2020 Jiaxun Yang 
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */



[Bug 1916394] [NEW] [git] Cannot build qemu: FAILED: target/hexagon/semantics_generated.pyinc

2021-02-21 Thread Frederic Bezies
Public bug reported:

Hello.

I'm using Archlinux and I maintain qemu-git AUR package.

I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
but it stops with this error message:

Found ninja-1.10.2 at /usr/bin/ninja
[632/9068] Generating semantics_generated.pyinc with a custom command
FAILED: target/hexagon/semantics_generated.pyinc
@INPUT@ target/hexagon/semantics_generated.pyinc
/bin/sh: line 1: @INPUT@: command not found
[637/9068] Compiling C object fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
ninja: build stopped: subcommand failed.

ninja version: 1.10.2
meson version: 0.57.1

Downgrading meson doesn't change anything.

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

  Hello.
  
  I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
  but it stops with this error message:
  
- [code]
+ 
  Found ninja-1.10.2 at /usr/bin/ninja
  [632/9068] Generating semantics_generated.pyinc with a custom command
- FAILED: target/hexagon/semantics_generated.pyinc 
+ FAILED: target/hexagon/semantics_generated.pyinc
  @INPUT@ target/hexagon/semantics_generated.pyinc
  /bin/sh: line 1: @INPUT@: command not found
  [637/9068] Compiling C object 
fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
  ninja: build stopped: subcommand failed.
- [/code]
+ 
  
  ninja version: 1.10.2
  meson version: 0.57.1

** Description changed:

  Hello.
  
  I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
  but it stops with this error message:
  
- 
+ ```
  Found ninja-1.10.2 at /usr/bin/ninja
  [632/9068] Generating semantics_generated.pyinc with a custom command
  FAILED: target/hexagon/semantics_generated.pyinc
  @INPUT@ target/hexagon/semantics_generated.pyinc
  /bin/sh: line 1: @INPUT@: command not found
  [637/9068] Compiling C object 
fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
  ninja: build stopped: subcommand failed.
- 
+ ```
  
  ninja version: 1.10.2
  meson version: 0.57.1

** Description changed:

  Hello.
  
  I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
  but it stops with this error message:
  
- ```
+ `
  Found ninja-1.10.2 at /usr/bin/ninja
  [632/9068] Generating semantics_generated.pyinc with a custom command
  FAILED: target/hexagon/semantics_generated.pyinc
  @INPUT@ target/hexagon/semantics_generated.pyinc
  /bin/sh: line 1: @INPUT@: command not found
  [637/9068] Compiling C object 
fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
  ninja: build stopped: subcommand failed.
- ```
+ `
  
  ninja version: 1.10.2
  meson version: 0.57.1

** Description changed:

  Hello.
  
  I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
  but it stops with this error message:
  
- `
+ 
  Found ninja-1.10.2 at /usr/bin/ninja
  [632/9068] Generating semantics_generated.pyinc with a custom command
  FAILED: target/hexagon/semantics_generated.pyinc
  @INPUT@ target/hexagon/semantics_generated.pyinc
  /bin/sh: line 1: @INPUT@: command not found
  [637/9068] Compiling C object 
fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
  ninja: build stopped: subcommand failed.
- `
  
  ninja version: 1.10.2
  meson version: 0.57.1

** Description changed:

  Hello.
+ 
+ I'm using Archlinux and I maintain qemu-git AUR package.
  
  I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
  but it stops with this error message:
- 
  
  Found ninja-1.10.2 at /usr/bin/ninja
  [632/9068] Generating semantics_generated.pyinc with a custom command
  FAILED: target/hexagon/semantics_generated.pyinc
  @INPUT@ target/hexagon/semantics_generated.pyinc
  /bin/sh: line 1: @INPUT@: command not found
  [637/9068] Compiling C object 
fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
  ninja: build stopped: subcommand failed.
  
  ninja version: 1.10.2
  meson version: 0.57.1

** Description changed:

  Hello.
  
  I'm using Archlinux and I maintain qemu-git AUR package.
  
  I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff
  but it stops with this error message:
  
  Found ninja-1.10.2 at /usr/bin/ninja
  [632/9068] Generating semantics_generated.pyinc with a custom command
  FAILED: target/hexagon/semantics_generated.pyinc
  @INPUT@ target/hexagon/semantics_generated.pyinc
  /bin/sh: line 1: @INPUT@: command not found
  [637/9068] Compiling C object 
fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o
  ninja: build stopped: subcommand failed.
  
  ninja version: 1.10.2
  meson version: 0.57.1
+ 
+ Downgrading meson doesn't change anything.

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

Title:
  [git] Cannot build qemu: FAILED:
  target/hexagon/semantics_generated.pyinc

Status in QEMU:
  New

Bug description:
  Hello.

  I'm using Archlinux and I maintain qemu-git AUR package.

  I tried to build Qemu at commit
  

[PATCH] ui/gtk: vte: fix sending multiple characeters

2021-02-21 Thread Zack Marvel
When using the GTK UI with libvte, multicharacter keystrokes are not
sent correctly (such as arrow keys). gd_vc_in should check the
CharBackend's can_receive instead of assuming multiple characters can be
received. This is not an issue for e.g. the SDL UI because
qemu_chr_be_write is called with len=1 for each character (SDL sends
more than once keystroke).

Modify gd_vc_in to call qemu_chr_be_write multiple times if necessary.

Buglink: https://bugs.launchpad.net/qemu/+bug/1407808

Signed-off-by: Zack Marvel 
---
 ui/gtk.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 79dc240120..bad716f136 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1786,7 +1786,16 @@ static gboolean gd_vc_in(VteTerminal *terminal, gchar 
*text, guint size,
 }
 }
 
-qemu_chr_be_write(vc->vte.chr, (uint8_t  *)text, (unsigned int)size);
+int remaining = size;
+uint8_t* p = (uint8_t *)text;
+while (remaining > 0) {
+int can_write = qemu_chr_be_can_write(vc->vte.chr);
+int written = MIN(remaining, can_write);
+qemu_chr_be_write(vc->vte.chr, p, written);
+
+remaining -= written;
+p += written;
+}
 return TRUE;
 }
 
-- 
2.20.1




  1   2   >