Re: [PATCH 4/6] docs: update README to use GitLab repo URLs

[Thomas Huth]

On 11/01/2021 12.50, Stefan Hajnoczi wrote:

qemu.org is running out of bandwidth and the QEMU project is moving
towards a gating CI on GitLab. Use the GitLab repos instead of qemu.org
(they will become mirrors).

Signed-off-by: Stefan Hajnoczi 
---
  README.rst | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.rst b/README.rst
index 58b9f2dc15..ce39d89077 100644
--- a/README.rst
+++ b/README.rst
@@ -60,7 +60,7 @@ The QEMU source code is maintained under the GIT version 
control system.
  
  .. code-block:: shell
  
-   git clone https://git.qemu.org/git/qemu.git

+   git clone https://gitlab.com/qemu-project/qemu.git
  
  When submitting patches, one common approach is to use 'git

  format-patch' and/or 'git send-email' to format & send the mail to the
@@ -78,7 +78,7 @@ The QEMU website is also maintained under source control.
  
  .. code-block:: shell
  
-  git clone https://git.qemu.org/git/qemu-web.git

+  git clone https://gitlab.com/qemu-project/qemu-web.git
  
  * ``_


Reviewed-by: Thomas Huth 

Re: [PATCH v6 10/13] spapr: Add PEF based confidential guest support

[Christian Borntraeger]

On 12.01.21 05:45, David Gibson wrote:
[...]
> diff --git a/include/hw/ppc/pef.h b/include/hw/ppc/pef.h
> new file mode 100644
> index 00..7c92391177
> --- /dev/null
> +++ b/include/hw/ppc/pef.h
> @@ -0,0 +1,26 @@
> +/*
> + * PEF (Protected Execution Facility) for POWER support
> + *
> + * Copyright David Gibson, Redhat Inc. 2020
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef HW_PPC_PEF_H
> +#define HW_PPC_PEF_H
> +
> +int pef_kvm_init(ConfidentialGuestSupport *cgs, Error **errp);
> +
> +#ifdef CONFIG_KVM
> +void kvmppc_svm_off(Error **errp);
> +#else
> +static inline void kvmppc_svm_off(Error **errp)
> +{
> +}
> +#endif
> +
> +
> +#endif /* HW_PPC_PEF_H */
> +

In case you do a respin, 

git am says
Applying: confidential guest support: Update documentation
Applying: spapr: Add PEF based confidential guest support
.git/rebase-apply/patch:254: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Applying: spapr: PEF: prevent migration

Re: [PATCH 3/6] gitlab-ci: remove redundant GitLab repo URL command

[Thomas Huth]

On 11/01/2021 12.50, Stefan Hajnoczi wrote:

It is no longer necessary to point .gitmodules at GitLab repos when
running in GitLab CI since they are now used all the time.

Signed-off-by: Stefan Hajnoczi 
---
  .gitlab-ci.yml | 1 -
  1 file changed, 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 01c9e46410..4c2a71b934 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -18,7 +18,6 @@ include:
image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest
before_script:
  - JOBS=$(expr $(nproc) + 1)
-- sed -i s,git.qemu.org/git,gitlab.com/qemu-project, .gitmodules
script:
  - mkdir build
  - cd build



Reviewed-by: Thomas Huth 

Re: [PATCH 2/6] gitmodules: use GitLab repos instead of qemu.org

[Thomas Huth]

On 11/01/2021 12.50, Stefan Hajnoczi wrote:

qemu.org is running out of bandwidth and the QEMU project is moving
towards a gating CI on GitLab. Use the GitLab repos instead of qemu.org
(they will become mirrors).

Signed-off-by: Stefan Hajnoczi 
---
  .gitmodules | 44 ++--
  1 file changed, 22 insertions(+), 22 deletions(-)


Reviewed-by: Thomas Huth 

Re: [PATCH] hvf: guard xgetbv call.

[Roman Bolshakov]

On Mon, Jan 11, 2021 at 07:06:22AM -1000, Richard Henderson wrote:
> On 1/10/21 6:31 PM, Roman Bolshakov wrote:
> >> Also, if we're going to put this some place common, forcing the caller to 
> >> do
> >> the cpuid that feeds this, then we should probably make all of the startup
> >> cpuid stuff common as well.
> >>
> > 
> > I proposed the version because all callers of xgetbv instruction already
> > call cpuid before invoking inline xgetbv.
> > 
> >> Note that we'd probably have to use constructor priorities to get that 
> >> right
> >> for util/bufferiszero.c.
> >>
> > 
> > Please correct me if I read this wrong. What you're saying is we should
> > initialize cpuid in constructors and then use cached cpuid ecx in
> > xgetbv() (and drop one argument, respectively)?
> 
> I would have xgetbv and all of the cpuid values cached at startup, and all
> three places would read global variables.
> 

It makes sense, thanks for the clarification.

Do you think it should be part of the change Hill is doing or it might
be a follow-up cleanup patch?

-Roman

Re: [PATCH 1/6] .github: point Repo Lockdown bot to GitLab repo

[Thomas Huth]

On 11/01/2021 12.51, Daniel P. Berrangé wrote:

On Mon, Jan 11, 2021 at 11:50:12AM +, Stefan Hajnoczi wrote:

Use the GitLab repo URL as the main repo location in order to reduce
load on qemu.org.

Signed-off-by: Stefan Hajnoczi 
---
  .github/lockdown.yml | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/.github/lockdown.yml b/.github/lockdown.yml
index 9acc393f1c..07fc2f31ee 100644
--- a/.github/lockdown.yml
+++ b/.github/lockdown.yml
@@ -10,8 +10,8 @@ issues:
comment: |
  Thank you for your interest in the QEMU project.
  
-This repository is a read-only mirror of the project's master

-repostories hosted on https://git.qemu.org/git/qemu.git.
+This repository is a read-only mirror of the project's repostories hosted
+at https://gitlab.com/qemu-project/qemu.git.


NB this URL triggers a redirect to strip the .git suffix

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


If you try to do:

 git clone https://gitlab.com/qemu-project/qemu

You get this warning message instead:

 warning: redirecting to https://gitlab.com/qemu-project/qemu.git/

So I think the patch is fine.

Reviewed-by: Thomas Huth 

[PATCH v2 0/1] add smart_critical_warning property for nvme

[zhenwei pi]

v1 -> v2:
Suggested by Philippe & Klaus, set/get smart_critical_warning by QMP.

v1:
Add smart_critical_warning for nvme device which can be set by QEMU
command line to emulate hardware error.

Zhenwei Pi (1):
  hw/block/nvme: add smart_critical_warning property

 hw/block/nvme.c | 28 
 hw/block/nvme.h |  1 +
 2 files changed, 29 insertions(+)

-- 
2.25.1

Re: [PATCH v3 4/5] tests/tcg/s390x: Fix EXRL tests

[David Hildenbrand]

> Am 12.01.2021 um 08:41 schrieb Thomas Huth :
> 
> On 11/01/2021 17.38, David Hildenbrand wrote:
>> The current EXRL tests crash on real machines: we must not use r0 as a base
>> register for trt/trtr, otherwise the content gets ignored. Also, we must
>> not use r0 for exrl, otherwise it gets ignored.
>> Let's use the "a" constraint so we get a general purpose register != r0.
>> For op2, we can simply specify a memory operand directly via "Q" (Memory
>> reference without index register and with short displacement).
>> Fixes: ad8c851d2e77 ("target/s390x: add EX support for TRT and TRTR")
>> Signed-off-by: David Hildenbrand 
>> ---
>>  tests/tcg/s390x/exrl-trt.c  | 8 
>>  tests/tcg/s390x/exrl-trtr.c | 8 
>>  2 files changed, 8 insertions(+), 8 deletions(-)
>> diff --git a/tests/tcg/s390x/exrl-trt.c b/tests/tcg/s390x/exrl-trt.c
>> index 3c5323aecb..16711a3181 100644
>> --- a/tests/tcg/s390x/exrl-trt.c
>> +++ b/tests/tcg/s390x/exrl-trt.c
>> @@ -19,7 +19,7 @@ int main(void)
>>  }
>>  asm volatile(
>>  "j 2f\n"
>> -"1:  trt 0(1,%[op1]),0(%[op2])\n"
>> +"1:  trt 0(1,%[op1]),%[op2]\n"
>>  "2:  exrl %[op1_len],1b\n"
>>  "lgr %[r1],%%r1\n"
>>  "lgr %[r2],%%r2\n"
>> @@ -27,9 +27,9 @@ int main(void)
>>  : [r1] "+r" (r1),
>>[r2] "+r" (r2),
>>[cc] "=r" (cc)
>> -: [op1] "r" (),
>> -  [op1_len] "r" (5),
>> -  [op2] "r" ()
>> +: [op1] "a" (),
>> +  [op1_len] "a" (5),
> 
> I think op1_len could still stay with "r" instead of "a" ... OTOH "a" also 
> does not hurt here, so:
> 

No, otherwise exrl ignores the register content  if it ends up being r0.

Thanks!


> Reviewed-by: Thomas Huth 

[PATCH v2 1/1] hw/block/nvme: add smart_critical_warning property

[zhenwei pi]

There is a very low probability that hitting physical NVMe disk
hardware critical warning case, it's hard to write & test a monitor
agent service.

For debugging purposes, add a new 'smart_critical_warning' property
to emulate this situation.

The orignal version of this change is implemented by adding a fixed
property which could be initialized by QEMU command line. Suggested
by Philippe & Klaus, rework like current version.

Test with this patch:
1, change smart_critical_warning property for a running VM:
 #virsh qemu-monitor-command nvme-upstream '{ "execute": "qom-set",
  "arguments": { "path": "/machine/peripheral-anon/device[0]",
  "property": "smart_critical_warning", "value":16 } }'
2, run smartctl in guest
 #smartctl -H -l error /dev/nvme0n1

  === START OF SMART DATA SECTION ===
  SMART overall-health self-assessment test result: FAILED!
  - volatile memory backup device has failed

Signed-off-by: zhenwei pi 
---
 hw/block/nvme.c | 28 
 hw/block/nvme.h |  1 +
 2 files changed, 29 insertions(+)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 27d2c72716..a98757b6a1 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1214,6 +1214,7 @@ static uint16_t nvme_smart_info(NvmeCtrl *n, uint8_t rae, 
uint32_t buf_len,
 }
 
 trans_len = MIN(sizeof(smart) - off, buf_len);
+smart.critical_warning = n->smart_critical_warning;
 
 smart.data_units_read[0] = cpu_to_le64(DIV_ROUND_UP(stats.units_read,
 1000));
@@ -2827,6 +2828,29 @@ static Property nvme_props[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+
+static void nvme_get_smart_warning(Object *obj, Visitor *v, const char *name,
+   void *opaque, Error **errp)
+{
+NvmeCtrl *s = NVME(obj);
+uint8_t value = s->smart_critical_warning;
+
+visit_type_uint8(v, name, , errp);
+}
+
+static void nvme_set_smart_warning(Object *obj, Visitor *v, const char *name,
+   void *opaque, Error **errp)
+{
+NvmeCtrl *s = NVME(obj);
+uint8_t value;
+
+if (!visit_type_uint8(v, name, , errp)) {
+return;
+}
+
+s->smart_critical_warning = value;
+}
+
 static const VMStateDescription nvme_vmstate = {
 .name = "nvme",
 .unmigratable = 1,
@@ -2857,6 +2881,10 @@ static void nvme_instance_init(Object *obj)
   "bootindex", "/namespace@1,0",
   DEVICE(obj));
 }
+
+object_property_add(obj, "smart_critical_warning", "uint8",
+nvme_get_smart_warning,
+nvme_set_smart_warning, NULL, NULL);
 }
 
 static const TypeInfo nvme_info = {
diff --git a/hw/block/nvme.h b/hw/block/nvme.h
index e080a2318a..64e3497244 100644
--- a/hw/block/nvme.h
+++ b/hw/block/nvme.h
@@ -139,6 +139,7 @@ typedef struct NvmeCtrl {
 uint64_ttimestamp_set_qemu_clock_ms;/* QEMU clock time */
 uint64_tstarttime_ms;
 uint16_ttemperature;
+uint8_t smart_critical_warning;
 
 HostMemoryBackend *pmrdev;
 
-- 
2.25.1

Re: [PATCH v2] hvf: guard xgetbv call.

[Roman Bolshakov]

On Mon, Jan 11, 2021 at 09:44:40PM -0800, Hill Ma wrote:
> On Sun, Jan 10, 2021 at 8:38 PM Roman Bolshakov  wrote:
> > I'm not sure if eax should be modified with mask because the mask has no
> > value per se. I.e. eax &= supp_xcr0 from below should be placed inside
> > the if. It'd express clearly that eax is not modified unless xgetbv is
> > supported.
> 
> Like this?
> 
> -uint64_t host_xcr0 = xgetbv(0);
> -uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
> XSTATE_SSE_MASK |
> +uint64_t host_xcr0;
> +if (xgetbv(ecx, 0, _xcr0)) {
> +uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
> XSTATE_SSE_MASK |
>XSTATE_YMM_MASK | XSTATE_BNDREGS_MASK |
>XSTATE_BNDCSR_MASK | XSTATE_OPMASK_MASK |
>XSTATE_ZMM_Hi256_MASK |
> XSTATE_Hi16_ZMM_MASK);
> -eax &= supp_xcr0;
> +eax &= supp_xcr0;
> +}

Yes.

Thanks,
Roman

Re: [PULL v2 00/15] Testing, CI and bsd-user patches

[Thomas Huth]

On 11/01/2021 15.40, Philippe Mathieu-Daudé wrote:

On 1/11/21 3:06 PM, Thomas Huth wrote:

The following changes since commit 7b09f127738ae3d0e71716cea086fc8f847a5686:

   Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20210108' into staging (2021-01-08 
15:37:04 +)

are available in the Git repository at:

   https://gitlab.com/huth/qemu.git tags/pull-request-2021-01-11v2

for you to fetch changes up to b677001d70529df271a5d9314440bb201da40acf:

   fuzz: map all BARs and enable PCI devices (2021-01-11 14:59:21 +0100)


* Fuzzer improvements
* Add OpenSUSE leap to the gitlab-CI
* Some fixes to get our CI "green" again
* Some initial patches to update bsd-user



Doh, missed the Shippable-CI job reduction :/
https://www.mail-archive.com/qemu-devel@nongnu.org/msg771079.html


I don't have a shippable-CI account, so I can't test that one. I hope Alex 
can pick that up.


 Thomas

Re: [PATCH v3 4/5] tests/tcg/s390x: Fix EXRL tests

[Thomas Huth]

On 11/01/2021 17.38, David Hildenbrand wrote:

The current EXRL tests crash on real machines: we must not use r0 as a base
register for trt/trtr, otherwise the content gets ignored. Also, we must
not use r0 for exrl, otherwise it gets ignored.

Let's use the "a" constraint so we get a general purpose register != r0.
For op2, we can simply specify a memory operand directly via "Q" (Memory
reference without index register and with short displacement).

Fixes: ad8c851d2e77 ("target/s390x: add EX support for TRT and TRTR")
Signed-off-by: David Hildenbrand 
---
  tests/tcg/s390x/exrl-trt.c  | 8 
  tests/tcg/s390x/exrl-trtr.c | 8 
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tests/tcg/s390x/exrl-trt.c b/tests/tcg/s390x/exrl-trt.c
index 3c5323aecb..16711a3181 100644
--- a/tests/tcg/s390x/exrl-trt.c
+++ b/tests/tcg/s390x/exrl-trt.c
@@ -19,7 +19,7 @@ int main(void)
  }
  asm volatile(
  "j 2f\n"
-"1:  trt 0(1,%[op1]),0(%[op2])\n"
+"1:  trt 0(1,%[op1]),%[op2]\n"
  "2:  exrl %[op1_len],1b\n"
  "lgr %[r1],%%r1\n"
  "lgr %[r2],%%r2\n"
@@ -27,9 +27,9 @@ int main(void)
  : [r1] "+r" (r1),
[r2] "+r" (r2),
[cc] "=r" (cc)
-: [op1] "r" (),
-  [op1_len] "r" (5),
-  [op2] "r" ()
+: [op1] "a" (),
+  [op1_len] "a" (5),


I think op1_len could still stay with "r" instead of "a" ... OTOH "a" also 
does not hurt here, so:


Reviewed-by: Thomas Huth 

Re: [PATCH] machine: add missing doc for memory-backend option

[Michal Privoznik]

On 1/11/21 11:27 PM, Igor Mammedov wrote:

Add documentation for '-machine memory-backend' CLI option and
how to use it.

PS:
While at it add a comment to x-use-canonical-path-for-ramblock-id,
to make sure it won't go away by accident.

Signed-off-by: Igor Mammedov 
---
  backends/hostmem.c |  8 
  qemu-options.hx| 25 -
  2 files changed, 32 insertions(+), 1 deletion(-)


Reviewed-by: Michal Privoznik 

Michal

[PATCH] Dump NT_FILE note when generate coredump

[Kyle Zeng]

This patch adds support for adding NT_FILE note in the ELF coredump.
It follows what's defined in readelf.
Let me know if there is any issue with the patch.
The patch is attached in plaintext below

Thanks,
Kyle
-

>From 3c42074f9e99e6b5ca840b9ee9e965fb69122ef1 Mon Sep 17 00:00:00 2001
From: Kyle ZENG 
Date: Mon, 11 Jan 2021 21:54:09 -0700
Subject: [PATCH] add NT_FILE note for ELF core dump

Signed-off-by: Kyle ZENG 
---
 include/elf.h|  1 +
 linux-user/elfload.c | 92 ++--
 2 files changed, 90 insertions(+), 3 deletions(-)

diff --git a/include/elf.h b/include/elf.h
index 7a418ee..f701fd9 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -1645,6 +1645,7 @@ typedef struct elf64_shdr {
 #define NT_TASKSTRUCT 4
 #define NT_AUXV 6
 #define NT_PRXFPREG 0x46e62b7f  /* copied from
gdb5.1/include/elf/common.h */
+#define NT_FILE 0x46494c45  /* copied from
gdb/include/elf/common.h */
 #define NT_S390_GS_CB   0x30b   /* s390 guarded storage registers
*/
 #define NT_S390_VXRS_HIGH 0x30a /* s390 vector registers 16-31 */
 #define NT_S390_VXRS_LOW  0x309 /* s390 vector registers 0-15
(lower half) */
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a640507..c095c0c 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -3317,6 +3317,13 @@ struct target_elf_prpsinfo {
 charpr_psargs[ELF_PRARGSZ]; /* initial part of arg list */
 };

+struct target_ntfile_entry {
+abi_ulong   vm_start;
+abi_ulong   vm_end;
+abi_ulong   page_offset;
+char*path;
+};
+
 /* Here is the structure in which status of each thread is captured. */
 struct elf_thread_status {
 QTAILQ_ENTRY(elf_thread_status)  ets_link;
@@ -3677,6 +3684,84 @@ static void fill_auxv_note(struct memelfnote *note,
const TaskState *ts)
 }
 }

+static void fill_ntfile_note(struct memelfnote *note, TaskState *ts)
+{
+GSList *map_info = read_self_maps();
+GSList *s;
+int count = 0;
+int data_size = sizeof(abi_long)*2; // reserve space for num_map_entry
and page_size
+struct target_ntfile_entry *entries = NULL;
+
+// grab memory mapping first
+for (s = map_info; s; s = g_slist_next(s)) {
+MapInfo *e = (MapInfo *) s->data;
+
+if (h2g_valid(e->start)) {
+unsigned long min = e->start;
+unsigned long max = e->end;
+int flags = page_get_flags(h2g(min));
+const char *path;
+
+max = h2g_valid(max - 1) ?
+max : (uintptr_t) g2h(GUEST_ADDR_MAX) + 1;
+
+if (page_check_range(h2g(min), max - min, flags) == -1) {
+continue;
+}
+
+if (h2g(min) == ts->info->stack_limit) {
+path = "[stack]";
+} else {
+path = e->path;
+}
+
+count++;
+entries = realloc(entries, sizeof(struct
target_ntfile_entry)*count);
+struct target_ntfile_entry *entry = [count-1];
+memset(entry, 0, sizeof(*entry));
+
+data_size += sizeof(abi_long)*3 + strlen(path) + 1;
+entry->vm_start = h2g(min);
+entry->vm_end = h2g(max - 1) + 1;
+entry->page_offset = e->offset;
+entry->path = strdup(path);
+}
+}
+
+// prepare the memory mapping in NT_FILE format
+char *ptr;
+int idx = 0;
+ptr = (char *)g_malloc0(data_size);
+abi_long *long_ptr = (abi_long *)ptr;
+
+// memory mappings
+long_ptr[idx++] = count;// number of map entries
+long_ptr[idx++] = TARGET_PAGE_SIZE;   // target page size
+for(int i=0; ivm_start;
+long_ptr[idx++] = entry->vm_end;
+long_ptr[idx++] = entry->page_offset;
+}
+
+// path names
+idx *= sizeof(abi_long);
+for(int i=0; ipath);
+strcpy([idx], entry->path);
+idx += path_size + 1;
+free(entry->path);
+}
+
+// write it out
+fill_note(note, "CORE", NT_FILE, data_size, ptr);
+
+// cleanup
+free(entries);
+free_self_maps(map_info);
+}
+
 /*
  * Constructs name of coredump file.  We have following convention
  * for the name:
@@ -3807,7 +3892,7 @@ static void init_note_info(struct elf_note_info *info)
 static int fill_note_info(struct elf_note_info *info,
   long signr, const CPUArchState *env)
 {
-#define NUMNOTES 3
+#define NUMNOTES 4
 CPUState *cpu = env_cpu((CPUArchState *)env);
 TaskState *ts = (TaskState *)cpu->opaque;
 int i;
@@ -3824,7 +3909,7 @@ static int fill_note_info(struct elf_note_info *info,

 /*
  * First fill in status (and registers) of current thread
- * including process info & aux vector.
+ * including process info, aux vector & memory mapping.
  */
 fill_prstatus(info->prstatus, ts, signr);
 elf_core_copy_regs(>prstatus->pr_reg, env);
@@ -3834,7 +3919,8 @@ static int fill_note_info(struct elf_note_info *info,
 

Re: [RFC v3 16/16] target/riscv: rvb: support and turn on B-extension from command line

[Richard Henderson]

On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
> From: Kito Cheng 
> 
> B-extension is default off, use cpu rv32 or rv64 with x-b=true to
> enable B-extension.
> 
> Signed-off-by: Kito Cheng 
> Signed-off-by: Frank Chang 
> Reviewed-by: Alistair Francis 
> ---
>  target/riscv/cpu.c | 4 
>  target/riscv/cpu.h | 2 ++
>  2 files changed, 6 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [RFC v3 04/16] target/riscv: rvb: logic-with-negate

[Richard Henderson]

On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
> From: Kito Cheng 
> 
> Signed-off-by: Kito Cheng 
> Signed-off-by: Frank Chang 
> ---
>  target/riscv/insn32.decode  |  4 
>  target/riscv/insn_trans/trans_rvb.c.inc | 18 ++
>  2 files changed, 22 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [RFC v3 11/16] target/riscv: rvb: rotate (left/right)

[Richard Henderson]

On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
> From: Kito Cheng 
> 
> Signed-off-by: Kito Cheng 
> Signed-off-by: Frank Chang 
> ---
>  target/riscv/insn32-64.decode   |  3 +++
>  target/riscv/insn32.decode  |  3 +++
>  target/riscv/insn_trans/trans_rvb.c.inc | 36 +
>  target/riscv/translate.c| 36 +
>  4 files changed, 78 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [RFC v3 13/16] target/riscv: rvb: generalized or-combine

[Richard Henderson]

On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
> From: Frank Chang 
> 
> Signed-off-by: Frank Chang 
> ---
>  target/riscv/bitmanip_helper.c  | 31 +
>  target/riscv/helper.h   |  2 ++
>  target/riscv/insn32-64.decode   |  2 ++
>  target/riscv/insn32.decode  |  2 ++
>  target/riscv/insn_trans/trans_rvb.c.inc | 24 +++
>  target/riscv/translate.c|  6 +
>  6 files changed, 67 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v2] hvf: guard xgetbv call.

[Hill Ma]

On Sun, Jan 10, 2021 at 8:38 PM Roman Bolshakov  wrote:
> I'm not sure if eax should be modified with mask because the mask has no
> value per se. I.e. eax &= supp_xcr0 from below should be placed inside
> the if. It'd express clearly that eax is not modified unless xgetbv is
> supported.

Like this?

-uint64_t host_xcr0 = xgetbv(0);
-uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
XSTATE_SSE_MASK |
+uint64_t host_xcr0;
+if (xgetbv(ecx, 0, _xcr0)) {
+uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
XSTATE_SSE_MASK |
   XSTATE_YMM_MASK | XSTATE_BNDREGS_MASK |
   XSTATE_BNDCSR_MASK | XSTATE_OPMASK_MASK |
   XSTATE_ZMM_Hi256_MASK |
XSTATE_Hi16_ZMM_MASK);
-eax &= supp_xcr0;
+eax &= supp_xcr0;
+}

Re: [RFC v3 08/16] target/riscv: add gen_shifti() and gen_shiftiw() helper functions

[Frank Chang]

On Tue, Jan 12, 2021 at 12:54 PM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
> >  static bool trans_slli(DisasContext *ctx, arg_slli *a)
> >  {
> > -if (a->shamt >= TARGET_LONG_BITS) {
> > -return false;
> > -}
> > -
> >  if (a->rd != 0) {
> > -TCGv t = tcg_temp_new();
> > -gen_get_gpr(t, a->rs1);
> > -
> > -tcg_gen_shli_tl(t, t, a->shamt);
> > -
> > -gen_set_gpr(a->rd, t);
> > -tcg_temp_free(t);
> > +return gen_shifti(ctx, a, tcg_gen_shl_tl);
> >  } /* NOP otherwise */
> >  return true;
> >  }
> >
> >  static bool trans_srli(DisasContext *ctx, arg_srli *a)
> >  {
> > -if (a->shamt >= TARGET_LONG_BITS) {
> > -return false;
> > -}
> > -
> >  if (a->rd != 0) {
> > -TCGv t = tcg_temp_new();
> > -gen_get_gpr(t, a->rs1);
> > -
> > -tcg_gen_shri_tl(t, t, a->shamt);
> > -gen_set_gpr(a->rd, t);
> > -tcg_temp_free(t);
> > +return gen_shifti(ctx, a, tcg_gen_shr_tl);
> >  } /* NOP otherwise */
> >  return true;
> >  }
> >
> >  static bool trans_srai(DisasContext *ctx, arg_srai *a)
> >  {
> > -if (a->shamt >= TARGET_LONG_BITS) {
> > -return false;
> > -}
> > -
> >  if (a->rd != 0) {
> > -TCGv t = tcg_temp_new();
> > -gen_get_gpr(t, a->rs1);
> > -
> > -tcg_gen_sari_tl(t, t, a->shamt);
> > -gen_set_gpr(a->rd, t);
> > -tcg_temp_free(t);
> > +return gen_shifti(ctx, a, tcg_gen_sar_tl);
> >  } /* NOP otherwise */
> >  return true;
> >  }
>
> This removes the illegal instruction check for rd == 0.
>
> In general you don't need the rd != 0 check, because gen_set_gpr will
> handle it
> (and it'll be exceedingly rare, and therefore not worth checking by hand).
>

> r~
>

Sure, I'll remove a->rd != 0 check in the next patchset.
Thanks,

Frank Chang

Re: [RFC v3 09/16] target/riscv: rvb: single-bit instructions

[Richard Henderson]

On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
> From: Kito Cheng 
> 
> Signed-off-by: Kito Cheng 
> Signed-off-by: Frank Chang 
> ---
>  target/riscv/insn32-64.decode   |  8 +++
>  target/riscv/insn32.decode  |  9 +++
>  target/riscv/insn_trans/trans_rvb.c.inc | 90 +
>  target/riscv/translate.c| 61 +
>  4 files changed, 168 insertions(+)

Reviewed-by: Richard Henderson 


r~

[PATCH 2/4] target/riscv: Add CSR name in the CSR function table

[Bin Meng]

From: Bin Meng 

In preparation to generate the CSR register list for GDB stub
dynamically, let's add the CSR name in the CSR function table.

Signed-off-by: Bin Meng 
---

 target/riscv/cpu.h |   1 +
 target/riscv/csr.c | 332 +++--
 2 files changed, 249 insertions(+), 84 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 6f9e1cc..6684316 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -476,6 +476,7 @@ typedef int (*riscv_csr_op_fn)(CPURISCVState *env, int 
csrno,
 target_ulong *ret_value, target_ulong new_value, target_ulong write_mask);
 
 typedef struct {
+const char *name;
 riscv_csr_predicate_fn predicate;
 riscv_csr_read_fn read;
 riscv_csr_write_fn write;
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 507e8ee..fd2e636 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -1372,112 +1372,276 @@ int riscv_csrrw_debug(CPURISCVState *env, int csrno, 
target_ulong *ret_value,
 /* Control and Status Register function table */
 riscv_csr_operations csr_ops[CSR_TABLE_SIZE] = {
 /* User Floating-Point CSRs */
-[CSR_FFLAGS] =  { fs,   read_fflags,  write_fflags  },
-[CSR_FRM] = { fs,   read_frm, write_frm },
-[CSR_FCSR] ={ fs,   read_fcsr,write_fcsr},
+[CSR_FFLAGS]   = { "fflags",   fs, read_fflags,  write_fflags },
+[CSR_FRM]  = { "frm",  fs, read_frm, write_frm},
+[CSR_FCSR] = { "fcsr", fs, read_fcsr,write_fcsr   },
 /* Vector CSRs */
-[CSR_VSTART] =  { vs,   read_vstart,  write_vstart  },
-[CSR_VXSAT] =   { vs,   read_vxsat,   write_vxsat   },
-[CSR_VXRM] ={ vs,   read_vxrm,write_vxrm},
-[CSR_VL] =  { vs,   read_vl },
-[CSR_VTYPE] =   { vs,   read_vtype  },
+[CSR_VSTART]   = { "vstart",   vs, read_vstart,  write_vstart },
+[CSR_VXSAT]= { "vxsat",vs, read_vxsat,   write_vxsat  },
+[CSR_VXRM] = { "vxrm", vs, read_vxrm,write_vxrm   },
+[CSR_VL]   = { "vl",   vs, read_vl},
+[CSR_VTYPE]= { "vtype",vs, read_vtype },
 /* User Timers and Counters */
-[CSR_CYCLE] =   { ctr,  read_instret},
-[CSR_INSTRET] = { ctr,  read_instret},
-[CSR_CYCLEH] =  { ctr32,  read_instreth },
-[CSR_INSTRETH] ={ ctr32,  read_instreth },
-
-/* In privileged mode, the monitor will have to emulate TIME CSRs only if
- * rdtime callback is not provided by machine/platform emulation */
-[CSR_TIME] ={ ctr,  read_time   },
-[CSR_TIMEH] =   { ctr32,  read_timeh},
+[CSR_CYCLE]= { "cycle",ctr,read_instret  },
+[CSR_INSTRET]  = { "instret",  ctr,read_instret  },
+[CSR_CYCLEH]   = { "cycleh",   ctr32,  read_instreth },
+[CSR_INSTRETH] = { "instreth", ctr32,  read_instreth },
+
+/*
+ * In privileged mode, the monitor will have to emulate TIME CSRs only if
+ * rdtime callback is not provided by machine/platform emulation.
+ */
+[CSR_TIME]  = { "time",  ctr,   read_time  },
+[CSR_TIMEH] = { "timeh", ctr32, read_timeh },
 
 #if !defined(CONFIG_USER_ONLY)
 /* Machine Timers and Counters */
-[CSR_MCYCLE] =  { any,  read_instret},
-[CSR_MINSTRET] ={ any,  read_instret},
-[CSR_MCYCLEH] = { any32,  read_instreth },
-[CSR_MINSTRETH] =   { any32,  read_instreth },
+[CSR_MCYCLE]= { "mcycle",any,   read_instret  },
+[CSR_MINSTRET]  = { "minstret",  any,   read_instret  },
+[CSR_MCYCLEH]   = { "mcycleh",   any32, read_instreth },
+[CSR_MINSTRETH] = { "minstreth", any32, read_instreth },
 
 /* Machine Information Registers */
-[CSR_MVENDORID] =   { any,  read_zero   },
-[CSR_MARCHID] = { any,  read_zero   },
-[CSR_MIMPID] =  { any,  read_zero   },
-[CSR_MHARTID] = { any,  read_mhartid},
+[CSR_MVENDORID] = { "mvendorid", any,   read_zero},
+[CSR_MARCHID]   = { "marchid",   any,   read_zero},
+[CSR_MIMPID]= { "mimpid",any,   read_zero},
+[CSR_MHARTID]   = { "mhartid",   any,   read_mhartid },
 
 /* Machine Trap Setup */
-[CSR_MSTATUS] = { any,  read_mstatus, write_mstatus },
-[CSR_MISA] ={ any,  read_misa, 

Re: [RFC v3 08/16] target/riscv: add gen_shifti() and gen_shiftiw() helper functions

[Richard Henderson]

On 1/11/21 4:19 PM, frank.ch...@sifive.com wrote:
>  static bool trans_slli(DisasContext *ctx, arg_slli *a)
>  {
> -if (a->shamt >= TARGET_LONG_BITS) {
> -return false;
> -}
> -
>  if (a->rd != 0) {
> -TCGv t = tcg_temp_new();
> -gen_get_gpr(t, a->rs1);
> -
> -tcg_gen_shli_tl(t, t, a->shamt);
> -
> -gen_set_gpr(a->rd, t);
> -tcg_temp_free(t);
> +return gen_shifti(ctx, a, tcg_gen_shl_tl);
>  } /* NOP otherwise */
>  return true;
>  }
>  
>  static bool trans_srli(DisasContext *ctx, arg_srli *a)
>  {
> -if (a->shamt >= TARGET_LONG_BITS) {
> -return false;
> -}
> -
>  if (a->rd != 0) {
> -TCGv t = tcg_temp_new();
> -gen_get_gpr(t, a->rs1);
> -
> -tcg_gen_shri_tl(t, t, a->shamt);
> -gen_set_gpr(a->rd, t);
> -tcg_temp_free(t);
> +return gen_shifti(ctx, a, tcg_gen_shr_tl);
>  } /* NOP otherwise */
>  return true;
>  }
>  
>  static bool trans_srai(DisasContext *ctx, arg_srai *a)
>  {
> -if (a->shamt >= TARGET_LONG_BITS) {
> -return false;
> -}
> -
>  if (a->rd != 0) {
> -TCGv t = tcg_temp_new();
> -gen_get_gpr(t, a->rs1);
> -
> -tcg_gen_sari_tl(t, t, a->shamt);
> -gen_set_gpr(a->rd, t);
> -tcg_temp_free(t);
> +return gen_shifti(ctx, a, tcg_gen_sar_tl);
>  } /* NOP otherwise */
>  return true;
>  }

This removes the illegal instruction check for rd == 0.

In general you don't need the rd != 0 check, because gen_set_gpr will handle it
(and it'll be exceedingly rare, and therefore not worth checking by hand).


r~

[PATCH 0/4] target/riscv: Generate the GDB XML file for CSR registers dynamically

[Bin Meng]

From: Bin Meng 


At present QEMU RISC-V uses a hardcoded XML to report the feature
"org.gnu.gdb.riscv.csr" [1]. There are two major issues with the
approach being used currently:

- The XML does not specify the "regnum" field of a CSR entry, hence
  consecutive numbers are used by the remote GDB client to access
  CSRs. In QEMU we have to maintain a map table to convert the GDB
  number to the hardware number which is error prone.
- The XML contains some CSRs that QEMU does not implement at all,
  which causes an "E14" response sent to remote GDB client.

Change to generate the CSR register list dynamically, based on the
availability presented in the CSR function table. This new approach
will reflect a correct list of CSRs that QEMU actually implements.

[1] 
https://sourceware.org/gdb/current/onlinedocs/gdb/RISC_002dV-Features.html#RISC_002dV-Features


Bin Meng (4):
  target/riscv: Make csr_ops[CSR_TABLE_SIZE] external
  target/riscv: Add CSR name in the CSR function table
  target/riscv: Generate the GDB XML file for CSR registers dynamically
  target/riscv: Remove built-in GDB XML files for CSRs

 default-configs/targets/riscv32-linux-user.mak |   2 +-
 default-configs/targets/riscv32-softmmu.mak|   2 +-
 default-configs/targets/riscv64-linux-user.mak |   2 +-
 default-configs/targets/riscv64-softmmu.mak|   2 +-
 target/riscv/cpu.h |  11 +
 target/riscv/cpu.c |  12 +
 target/riscv/csr.c | 342 ++---
 target/riscv/gdbstub.c | 308 --
 gdb-xml/riscv-32bit-csr.xml| 250 --
 gdb-xml/riscv-64bit-csr.xml| 250 --
 10 files changed, 320 insertions(+), 861 deletions(-)
 delete mode 100644 gdb-xml/riscv-32bit-csr.xml
 delete mode 100644 gdb-xml/riscv-64bit-csr.xml

-- 
2.7.4

[PATCH v6 13/13] s390: Recognize confidential-guest-support option

[David Gibson]

At least some s390 cpu models support "Protected Virtualization" (PV),
a mechanism to protect guests from eavesdropping by a compromised
hypervisor.

This is similar in function to other mechanisms like AMD's SEV and
POWER's PEF, which are controlled by the "confidential-guest-support"
machine option.  s390 is a slightly special case, because we already
supported PV, simply by using a CPU model with the required feature
(S390_FEAT_UNPACK).

To integrate this with the option used by other platforms, we
implement the following compromise:

 - When the confidential-guest-support option is set, s390 will
   recognize it, verify that the CPU can support PV (failing if not)
   and set virtio default options necessary for encrypted or protected
   guests, as on other platforms.  i.e. if confidential-guest-support
   is set, we will either create a guest capable of entering PV mode,
   or fail outright.

 - If confidential-guest-support is not set, guests might still be
   able to enter PV mode, if the CPU has the right model.  This may be
   a little surprising, but shouldn't actually be harmful.

To start a guest supporting Protected Virtualization using the new
option use the command line arguments:
-object s390-pv-guest,id=pv0 -machine confidential-guest-support=pv0

Signed-off-by: David Gibson 
---
 docs/confidential-guest-support.txt |  3 ++
 docs/system/s390x/protvirt.rst  | 19 +++---
 hw/s390x/pv.c   | 58 +
 include/hw/s390x/pv.h   |  1 +
 target/s390x/kvm.c  |  3 ++
 5 files changed, 78 insertions(+), 6 deletions(-)

diff --git a/docs/confidential-guest-support.txt 
b/docs/confidential-guest-support.txt
index d466aa79d5..b4912f66c2 100644
--- a/docs/confidential-guest-support.txt
+++ b/docs/confidential-guest-support.txt
@@ -42,4 +42,7 @@ AMD Secure Encrypted Virtualization (SEV)
 
 POWER Protected Execution Facility (PEF)
 
+s390x Protected Virtualization (PV)
+docs/system/s390x/protvirt.rst
+
 Other mechanisms may be supported in future.
diff --git a/docs/system/s390x/protvirt.rst b/docs/system/s390x/protvirt.rst
index 712974ad87..0f481043d9 100644
--- a/docs/system/s390x/protvirt.rst
+++ b/docs/system/s390x/protvirt.rst
@@ -22,15 +22,22 @@ If those requirements are met, the capability 
`KVM_CAP_S390_PROTECTED`
 will indicate that KVM can support PVMs on that LPAR.
 
 
-QEMU Settings
--
+Running a Protected Virtual Machine
+---
 
-To indicate to the VM that it can transition into protected mode, the
+To run a PVM you will need to select a CPU model which includes the
 `Unpack facility` (stfle bit 161 represented by the feature
-`unpack`/`S390_FEAT_UNPACK`) needs to be part of the cpu model of
-the VM.
+`unpack`/`S390_FEAT_UNPACK`), and add these options to the command line::
+
+-object s390-pv-guest,id=pv0 \
+-machine confidential-guest-support=pv0
+
+Adding these options will:
+
+* Ensure the `unpack` facility is available
+* Enable the IOMMU by default for all I/O devices
+* Initialize the PV mechanism
 
-All I/O devices need to use the IOMMU.
 Passthrough (vfio) devices are currently not supported.
 
 Host huge page backings are not supported. However guests can use huge
diff --git a/hw/s390x/pv.c b/hw/s390x/pv.c
index ab3a2482aa..85592e100a 100644
--- a/hw/s390x/pv.c
+++ b/hw/s390x/pv.c
@@ -14,8 +14,11 @@
 #include 
 
 #include "cpu.h"
+#include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "sysemu/kvm.h"
+#include "qom/object_interfaces.h"
+#include "exec/confidential-guest-support.h"
 #include "hw/s390x/ipl.h"
 #include "hw/s390x/pv.h"
 
@@ -111,3 +114,58 @@ void s390_pv_inject_reset_error(CPUState *cs)
 /* Report that we are unable to enter protected mode */
 env->regs[r1 + 1] = DIAG_308_RC_INVAL_FOR_PV;
 }
+
+#define TYPE_S390_PV_GUEST "s390-pv-guest"
+#define S390_PV_GUEST(obj)  \
+OBJECT_CHECK(S390PVGuestState, (obj), TYPE_S390_PV_GUEST)
+
+typedef struct S390PVGuestState S390PVGuestState;
+
+/**
+ * S390PVGuestState:
+ *
+ * The S390PVGuestState object is basically a dummy used to tell the
+ * confidential guest support system to use s390's PV mechanism.
+ *
+ * # $QEMU \
+ * -object s390-pv-guest,id=pv0 \
+ * -machine ...,confidential-guest-support=pv0
+ */
+struct S390PVGuestState {
+Object parent_obj;
+};
+
+int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
+{
+if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
+return 0;
+}
+
+if (!s390_has_feat(S390_FEAT_UNPACK)) {
+error_setg(errp,
+   "CPU model does not support Protected Virtualization");
+return -1;
+}
+
+cgs->ready = true;
+
+return 0;
+}
+
+static const TypeInfo s390_pv_guest_info = {
+.parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
+.name = TYPE_S390_PV_GUEST,
+.instance_size = sizeof(S390PVGuestState),
+.interfaces = 

[PATCH v6 10/13] spapr: Add PEF based confidential guest support

[David Gibson]

Some upcoming POWER machines have a system called PEF (Protected
Execution Facility) which uses a small ultravisor to allow guests to
run in a way that they can't be eavesdropped by the hypervisor.  The
effect is roughly similar to AMD SEV, although the mechanisms are
quite different.

Most of the work of this is done between the guest, KVM and the
ultravisor, with little need for involvement by qemu.  However qemu
does need to tell KVM to allow secure VMs.

Because the availability of secure mode is a guest visible difference
which depends on having the right hardware and firmware, we don't
enable this by default.  In order to run a secure guest you need to
create a "pef-guest" object and set the confidential-guest-support
property to point to it.

Note that this just *allows* secure guests, the architecture of PEF is
such that the guest still needs to talk to the ultravisor to enter
secure mode.  Qemu has no directl way of knowing if the guest is in
secure mode, and certainly can't know until well after machine
creation time.

To start a PEF-capable guest, use the command line options:
-object pef-guest,id=pef0 -machine confidential-guest-support=pef0

Signed-off-by: David Gibson 
---
 docs/confidential-guest-support.txt |   2 +
 docs/papr-pef.txt   |  30 
 hw/ppc/meson.build  |   1 +
 hw/ppc/pef.c| 115 
 hw/ppc/spapr.c  |  10 +++
 include/hw/ppc/pef.h|  26 +++
 target/ppc/kvm.c|  18 -
 target/ppc/kvm_ppc.h|   6 --
 8 files changed, 184 insertions(+), 24 deletions(-)
 create mode 100644 docs/papr-pef.txt
 create mode 100644 hw/ppc/pef.c
 create mode 100644 include/hw/ppc/pef.h

diff --git a/docs/confidential-guest-support.txt 
b/docs/confidential-guest-support.txt
index 2790425b38..d466aa79d5 100644
--- a/docs/confidential-guest-support.txt
+++ b/docs/confidential-guest-support.txt
@@ -40,4 +40,6 @@ Currently supported confidential guest mechanisms are:
 AMD Secure Encrypted Virtualization (SEV)
 docs/amd-memory-encryption.txt
 
+POWER Protected Execution Facility (PEF)
+
 Other mechanisms may be supported in future.
diff --git a/docs/papr-pef.txt b/docs/papr-pef.txt
new file mode 100644
index 00..798e39f3ed
--- /dev/null
+++ b/docs/papr-pef.txt
@@ -0,0 +1,30 @@
+POWER (PAPR) Protected Execution Facility (PEF)
+===
+
+Protected Execution Facility (PEF), also known as Secure Guest support
+is a feature found on IBM POWER9 and POWER10 processors.
+
+If a suitable firmware including an Ultravisor is installed, it adds
+an extra memory protection mode to the CPU.  The ultravisor manages a
+pool of secure memory which cannot be accessed by the hypervisor.
+
+When this feature is enabled in qemu, a guest can use ultracalls to
+enter "secure mode".  This transfers most of its memory to secure
+memory, where it cannot be eavesdropped by a compromised hypervisor.
+
+Launching
+-
+
+To launch a guest which will be permitted to enter PEF secure mode:
+
+# ${QEMU} \
+-object pef-guest \
+-machine confidential-guest-support=pef0 \
+...
+
+Live Migration
+
+
+Live migration is not yet implemented for PEF guests.  For
+consistency, we currently prevent migration if the PEF feature is
+enabled, whether or not the guest has actuall entered secure mode.
diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
index ffa2ec37fa..218631c883 100644
--- a/hw/ppc/meson.build
+++ b/hw/ppc/meson.build
@@ -27,6 +27,7 @@ ppc_ss.add(when: 'CONFIG_PSERIES', if_true: files(
   'spapr_nvdimm.c',
   'spapr_rtas_ddw.c',
   'spapr_numa.c',
+  'pef.c',
 ))
 ppc_ss.add(when: 'CONFIG_SPAPR_RNG', if_true: files('spapr_rng.c'))
 ppc_ss.add(when: ['CONFIG_PSERIES', 'CONFIG_LINUX'], if_true: files(
diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
new file mode 100644
index 00..b227dc6905
--- /dev/null
+++ b/hw/ppc/pef.c
@@ -0,0 +1,115 @@
+/*
+ * PEF (Protected Execution Facility) for POWER support
+ *
+ * Copyright David Gibson, Redhat Inc. 2020
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "sysemu/kvm.h"
+#include "migration/blocker.h"
+#include "exec/confidential-guest-support.h"
+#include "hw/ppc/pef.h"
+
+#define TYPE_PEF_GUEST "pef-guest"
+#define PEF_GUEST(obj)  \
+OBJECT_CHECK(PefGuestState, (obj), TYPE_PEF_GUEST)
+
+typedef struct PefGuestState PefGuestState;
+
+/**
+ * PefGuestState:
+ *
+ * The PefGuestState object is used for creating and managing a PEF
+ * guest.
+ *
+ * # $QEMU \
+ * -object pef-guest,id=pef0 \
+ * -machine ...,confidential-guest-support=pef0
+ */
+struct PefGuestState {
+Object parent_obj;
+};
+
+#ifdef 

Re: [PATCH 5/5] net/tap: net_init_tap_one(): fix net-client leak on failure path

[Jason Wang]

On 2020/12/22 上午3:06, Vladimir Sementsov-Ogievskiy wrote:

net_tap_fd_init() allocates new NetClientState through
qemu_new_net_client(). We should free it on failure path.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

Attention: it's an intuitive patch.

I see, that net-client is leaked. May be it's still freed some tricky
way? And I don't understand the whole logic of qemu_del_net_client(),
it's just the only public interface to free net-client I found.



Your patch looks correct and it's indeed a leak.

I wonder whether it's better to do the cleanup in the free_fail label in 
net_init_tap(). The reason is that we need deal with case of multiqueue. 
Though qemu_del_net_client() can handle this but it's not clear if we do 
it in net_init_tap_one().


Thanks




  net/tap.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/tap.c b/net/tap.c
index 89ea04862b..ba4c34af3d 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -711,7 +711,7 @@ static void net_init_tap_one(const NetdevTapOptions *tap, 
NetClientState *peer,
  
  ret = tap_set_sndbuf(s->fd, tap, errp);

  if (ret < 0) {
-return;
+goto fail;
  }
  
  if (tap->has_fd || tap->has_fds) {

@@ -739,13 +739,20 @@ static void net_init_tap_one(const NetdevTapOptions *tap, 
NetClientState *peer,
  if (ret < 0) {
  if (tap->has_vhostforce && tap->vhostforce) {
  error_propagate(errp, err);
+goto fail;
  } else {
  warn_report_err(err);
  }
  }
  } else if (vhostfdname) {
  error_setg(errp, "vhostfd(s)= is not valid without vhost");
+goto fail;
  }
+
+return;
+
+fail:
+qemu_del_net_client(>nc);
  }
  
  static int get_fds(char *str, char *fds[], int max)

[PATCH v6 12/13] confidential guest support: Alter virtio default properties for protected guests

[David Gibson]

The default behaviour for virtio devices is not to use the platforms normal
DMA paths, but instead to use the fact that it's running in a hypervisor
to directly access guest memory.  That doesn't work if the guest's memory
is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.

So, if a confidential guest mechanism is enabled, then apply the
iommu_platform=on option so it will go through normal DMA mechanisms.
Those will presumably have some way of marking memory as shared with
the hypervisor or hardware so that DMA will work.

Signed-off-by: David Gibson 
Reviewed-by: Dr. David Alan Gilbert 
Reviewed-by: Cornelia Huck 
---
 hw/core/machine.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 5a742b..61ae363559 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -33,6 +33,8 @@
 #include "migration/global_state.h"
 #include "migration/vmstate.h"
 #include "exec/confidential-guest-support.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-pci.h"
 
 GlobalProperty hw_compat_5_2[] = {};
 const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
@@ -1204,6 +1206,17 @@ void machine_run_board_init(MachineState *machine)
  * areas.
  */
 machine_set_mem_merge(OBJECT(machine), false, _abort);
+
+/*
+ * Virtio devices can't count on directly accessing guest
+ * memory, so they need iommu_platform=on to use normal DMA
+ * mechanisms.  That requires also disabling legacy virtio
+ * support for those virtio pci devices which allow it.
+ */
+object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy",
+   "on", true);
+object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform",
+   "on", false);
 }
 
 machine_class->init(machine);
-- 
2.29.2

[PATCH v6 05/13] confidential guest support: Rework the "memory-encryption" property

[David Gibson]

Currently the "memory-encryption" property is only looked at once we
get to kvm_init().  Although protection of guest memory from the
hypervisor isn't something that could really ever work with TCG, it's
not conceptually tied to the KVM accelerator.

In addition, the way the string property is resolved to an object is
almost identical to how a QOM link property is handled.

So, create a new "confidential-guest-support" link property which sets
this QOM interface link directly in the machine.  For compatibility we
keep the "memory-encryption" property, but now implemented in terms of
the new property.

Signed-off-by: David Gibson 
---
 accel/kvm/kvm-all.c  |  5 +++--
 accel/kvm/sev-stub.c |  5 +++--
 hw/core/machine.c| 43 +--
 include/hw/boards.h  |  2 +-
 include/sysemu/sev.h |  2 +-
 target/i386/sev.c| 32 ++--
 6 files changed, 47 insertions(+), 42 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 260ed73ffe..28ab126f70 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2181,8 +2181,9 @@ static int kvm_init(MachineState *ms)
  * if memory encryption object is specified then initialize the memory
  * encryption context.
  */
-if (ms->memory_encryption) {
-ret = sev_guest_init(ms->memory_encryption);
+if (ms->cgs) {
+/* FIXME handle mechanisms other than SEV */
+ret = sev_kvm_init(ms->cgs);
 if (ret < 0) {
 goto err;
 }
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 5db9ab8f00..3d4787ae4a 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,7 +15,8 @@
 #include "qemu-common.h"
 #include "sysemu/sev.h"
 
-int sev_guest_init(const char *id)
+int sev_kvm_init(ConfidentialGuestSupport *cgs)
 {
-return -1;
+/* SEV can't be selected if it's not compiled */
+g_assert_not_reached();
 }
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 8909117d80..94194ab82d 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -32,6 +32,7 @@
 #include "hw/mem/nvdimm.h"
 #include "migration/global_state.h"
 #include "migration/vmstate.h"
+#include "exec/confidential-guest-support.h"
 
 GlobalProperty hw_compat_5_2[] = {};
 const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
@@ -427,16 +428,37 @@ static char *machine_get_memory_encryption(Object *obj, 
Error **errp)
 {
 MachineState *ms = MACHINE(obj);
 
-return g_strdup(ms->memory_encryption);
+if (ms->cgs) {
+return g_strdup(object_get_canonical_path_component(OBJECT(ms->cgs)));
+}
+
+return NULL;
 }
 
 static void machine_set_memory_encryption(Object *obj, const char *value,
 Error **errp)
 {
-MachineState *ms = MACHINE(obj);
+Object *cgs =
+object_resolve_path_component(object_get_objects_root(), value);
+
+if (!cgs) {
+error_setg(errp, "No such memory encryption object '%s'", value);
+return;
+}
 
-g_free(ms->memory_encryption);
-ms->memory_encryption = g_strdup(value);
+object_property_set_link(obj, "confidential-guest-support", cgs, errp);
+}
+
+static void machine_check_confidential_guest_support(const Object *obj,
+ const char *name,
+ Object *new_target,
+ Error **errp)
+{
+/*
+ * So far the only constraint is that the target has the
+ * TYPE_CONFIDENTIAL_GUEST_SUPPORT interface, and that's checked
+ * by the QOM core
+ */
 }
 
 static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -836,6 +858,15 @@ static void machine_class_init(ObjectClass *oc, void *data)
 object_class_property_set_description(oc, "suppress-vmdesc",
 "Set on to disable self-describing migration");
 
+object_class_property_add_link(oc, "confidential-guest-support",
+   TYPE_CONFIDENTIAL_GUEST_SUPPORT,
+   offsetof(MachineState, cgs),
+   machine_check_confidential_guest_support,
+   OBJ_PROP_LINK_STRONG);
+object_class_property_set_description(oc, "confidential-guest-support",
+  "Set confidential guest scheme to 
support");
+
+/* For compatibility */
 object_class_property_add_str(oc, "memory-encryption",
 machine_get_memory_encryption, machine_set_memory_encryption);
 object_class_property_set_description(oc, "memory-encryption",
@@ -1158,9 +1189,9 @@ void machine_run_board_init(MachineState *machine)
 cc->deprecation_note);
 }
 
-if (machine->memory_encryption) {
+if (machine->cgs) {
 /*
- * With memory encryption, the host can't see the real
+ * With confidential guests, the host can't see the real
  

[PATCH 4/4] target/riscv: Remove built-in GDB XML files for CSRs

[Bin Meng]

From: Bin Meng 

Now that we have switched to generate the RISC-V CSR XML dynamically,
remove the built-in hardcoded XML files.

Signed-off-by: Bin Meng 

---

 default-configs/targets/riscv32-linux-user.mak |   2 +-
 default-configs/targets/riscv32-softmmu.mak|   2 +-
 default-configs/targets/riscv64-linux-user.mak |   2 +-
 default-configs/targets/riscv64-softmmu.mak|   2 +-
 gdb-xml/riscv-32bit-csr.xml| 250 -
 gdb-xml/riscv-64bit-csr.xml| 250 -
 6 files changed, 4 insertions(+), 504 deletions(-)
 delete mode 100644 gdb-xml/riscv-32bit-csr.xml
 delete mode 100644 gdb-xml/riscv-64bit-csr.xml

diff --git a/default-configs/targets/riscv32-linux-user.mak 
b/default-configs/targets/riscv32-linux-user.mak
index dfb259e..07e6ca1 100644
--- a/default-configs/targets/riscv32-linux-user.mak
+++ b/default-configs/targets/riscv32-linux-user.mak
@@ -1,4 +1,4 @@
 TARGET_ARCH=riscv32
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
-TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-csr.xml 
gdb-xml/riscv-32bit-virtual.xml
+TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-virtual.xml
diff --git a/default-configs/targets/riscv32-softmmu.mak 
b/default-configs/targets/riscv32-softmmu.mak
index 9446d96..d8b71cd 100644
--- a/default-configs/targets/riscv32-softmmu.mak
+++ b/default-configs/targets/riscv32-softmmu.mak
@@ -1,5 +1,5 @@
 TARGET_ARCH=riscv32
 TARGET_BASE_ARCH=riscv
 TARGET_SUPPORTS_MTTCG=y
-TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-csr.xml 
gdb-xml/riscv-32bit-virtual.xml
+TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-virtual.xml
 TARGET_NEED_FDT=y
diff --git a/default-configs/targets/riscv64-linux-user.mak 
b/default-configs/targets/riscv64-linux-user.mak
index b13895f..191c2c4 100644
--- a/default-configs/targets/riscv64-linux-user.mak
+++ b/default-configs/targets/riscv64-linux-user.mak
@@ -1,4 +1,4 @@
 TARGET_ARCH=riscv64
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
-TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-csr.xml 
gdb-xml/riscv-64bit-virtual.xml
+TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-virtual.xml
diff --git a/default-configs/targets/riscv64-softmmu.mak 
b/default-configs/targets/riscv64-softmmu.mak
index d809bd6..7c0e7ee 100644
--- a/default-configs/targets/riscv64-softmmu.mak
+++ b/default-configs/targets/riscv64-softmmu.mak
@@ -1,5 +1,5 @@
 TARGET_ARCH=riscv64
 TARGET_BASE_ARCH=riscv
 TARGET_SUPPORTS_MTTCG=y
-TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-csr.xml 
gdb-xml/riscv-64bit-virtual.xml
+TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml 
gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-virtual.xml
 TARGET_NEED_FDT=y
diff --git a/gdb-xml/riscv-32bit-csr.xml b/gdb-xml/riscv-32bit-csr.xml
deleted file mode 100644
index da1bf19..000
--- a/gdb-xml/riscv-32bit-csr.xml
+++ /dev/null
@@ -1,250 +0,0 @@
-
-
-
-
-
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
diff --git a/gdb-xml/riscv-64bit-csr.xml b/gdb-xml/riscv-64bit-csr.xml
deleted file mode 100644
index 6aa4bed..000
--- a/gdb-xml/riscv-64bit-csr.xml
+++ /dev/null
@@ -1,250 +0,0 @@
-
-
-
-
-
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
- 

[PATCH 3/4] target/riscv: Generate the GDB XML file for CSR registers dynamically

[Bin Meng]

From: Bin Meng 

At present QEMU RISC-V uses a hardcoded XML to report the feature
"org.gnu.gdb.riscv.csr" [1]. There are two major issues with the
approach being used currently:

- The XML does not specify the "regnum" field of a CSR entry, hence
  consecutive numbers are used by the remote GDB client to access
  CSRs. In QEMU we have to maintain a map table to convert the GDB
  number to the hardware number which is error prone.
- The XML contains some CSRs that QEMU does not implement at all,
  which causes an "E14" response sent to remote GDB client.

Change to generate the CSR register list dynamically, based on the
availability presented in the CSR function table. This new approach
will reflect a correct list of CSRs that QEMU actually implements.

[1] 
https://sourceware.org/gdb/current/onlinedocs/gdb/RISC_002dV-Features.html#RISC_002dV-Features

Signed-off-by: Bin Meng 
---

 target/riscv/cpu.h |   2 +
 target/riscv/cpu.c |  12 ++
 target/riscv/gdbstub.c | 308 +++--
 3 files changed, 58 insertions(+), 264 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 6684316..f810169 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -272,6 +272,8 @@ struct RISCVCPU {
 CPUNegativeOffsetState neg;
 CPURISCVState env;
 
+char *dyn_csr_xml;
+
 /* Configuration Settings */
 struct {
 bool ext_i;
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index dfe5d4e..c0dd646 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -569,6 +569,17 @@ static gchar *riscv_gdb_arch_name(CPUState *cs)
 }
 }
 
+static const char *riscv_gdb_get_dynamic_xml(CPUState *cs, const char *xmlname)
+{
+RISCVCPU *cpu = RISCV_CPU(cs);
+
+if (strcmp(xmlname, "riscv-csr.xml") == 0) {
+return cpu->dyn_csr_xml;
+}
+
+return NULL;
+}
+
 static void riscv_cpu_class_init(ObjectClass *c, void *data)
 {
 RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
@@ -607,6 +618,7 @@ static void riscv_cpu_class_init(ObjectClass *c, void *data)
 cc->write_elf32_note = riscv_cpu_write_elf32_note;
 #endif
 cc->gdb_arch_name = riscv_gdb_arch_name;
+cc->gdb_get_dynamic_xml = riscv_gdb_get_dynamic_xml;
 #ifdef CONFIG_TCG
 cc->tcg_initialize = riscv_translate_init;
 cc->tlb_fill = riscv_cpu_tlb_fill;
diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index eba12a8..5f96b7e 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -20,256 +20,6 @@
 #include "exec/gdbstub.h"
 #include "cpu.h"
 
-/*
- * The GDB CSR xml files list them in documentation order, not numerical order,
- * and are missing entries for unnamed CSRs.  So we need to map the gdb numbers
- * to the hardware numbers.
- */
-
-static int csr_register_map[] = {
-CSR_USTATUS,
-CSR_UIE,
-CSR_UTVEC,
-CSR_USCRATCH,
-CSR_UEPC,
-CSR_UCAUSE,
-CSR_UTVAL,
-CSR_UIP,
-CSR_FFLAGS,
-CSR_FRM,
-CSR_FCSR,
-CSR_CYCLE,
-CSR_TIME,
-CSR_INSTRET,
-CSR_HPMCOUNTER3,
-CSR_HPMCOUNTER4,
-CSR_HPMCOUNTER5,
-CSR_HPMCOUNTER6,
-CSR_HPMCOUNTER7,
-CSR_HPMCOUNTER8,
-CSR_HPMCOUNTER9,
-CSR_HPMCOUNTER10,
-CSR_HPMCOUNTER11,
-CSR_HPMCOUNTER12,
-CSR_HPMCOUNTER13,
-CSR_HPMCOUNTER14,
-CSR_HPMCOUNTER15,
-CSR_HPMCOUNTER16,
-CSR_HPMCOUNTER17,
-CSR_HPMCOUNTER18,
-CSR_HPMCOUNTER19,
-CSR_HPMCOUNTER20,
-CSR_HPMCOUNTER21,
-CSR_HPMCOUNTER22,
-CSR_HPMCOUNTER23,
-CSR_HPMCOUNTER24,
-CSR_HPMCOUNTER25,
-CSR_HPMCOUNTER26,
-CSR_HPMCOUNTER27,
-CSR_HPMCOUNTER28,
-CSR_HPMCOUNTER29,
-CSR_HPMCOUNTER30,
-CSR_HPMCOUNTER31,
-CSR_CYCLEH,
-CSR_TIMEH,
-CSR_INSTRETH,
-CSR_HPMCOUNTER3H,
-CSR_HPMCOUNTER4H,
-CSR_HPMCOUNTER5H,
-CSR_HPMCOUNTER6H,
-CSR_HPMCOUNTER7H,
-CSR_HPMCOUNTER8H,
-CSR_HPMCOUNTER9H,
-CSR_HPMCOUNTER10H,
-CSR_HPMCOUNTER11H,
-CSR_HPMCOUNTER12H,
-CSR_HPMCOUNTER13H,
-CSR_HPMCOUNTER14H,
-CSR_HPMCOUNTER15H,
-CSR_HPMCOUNTER16H,
-CSR_HPMCOUNTER17H,
-CSR_HPMCOUNTER18H,
-CSR_HPMCOUNTER19H,
-CSR_HPMCOUNTER20H,
-CSR_HPMCOUNTER21H,
-CSR_HPMCOUNTER22H,
-CSR_HPMCOUNTER23H,
-CSR_HPMCOUNTER24H,
-CSR_HPMCOUNTER25H,
-CSR_HPMCOUNTER26H,
-CSR_HPMCOUNTER27H,
-CSR_HPMCOUNTER28H,
-CSR_HPMCOUNTER29H,
-CSR_HPMCOUNTER30H,
-CSR_HPMCOUNTER31H,
-CSR_SSTATUS,
-CSR_SEDELEG,
-CSR_SIDELEG,
-CSR_SIE,
-CSR_STVEC,
-CSR_SCOUNTEREN,
-CSR_SSCRATCH,
-CSR_SEPC,
-CSR_SCAUSE,
-CSR_STVAL,
-CSR_SIP,
-CSR_SATP,
-CSR_MVENDORID,
-CSR_MARCHID,
-CSR_MIMPID,
-CSR_MHARTID,
-CSR_MSTATUS,
-CSR_MISA,
-CSR_MEDELEG,
-CSR_MIDELEG,
-CSR_MIE,
-CSR_MTVEC,
-CSR_MCOUNTEREN,
-CSR_MSCRATCH,
-CSR_MEPC,
-CSR_MCAUSE,
-CSR_MTVAL,
-CSR_MIP,
-CSR_MTINST,
-CSR_MTVAL2,
-CSR_PMPCFG0,
-CSR_PMPCFG1,
-CSR_PMPCFG2,
-CSR_PMPCFG3,

[PATCH v6 11/13] spapr: PEF: prevent migration

[David Gibson]

We haven't yet implemented the fairly involved handshaking that will be
needed to migrate PEF protected guests.  For now, just use a migration
blocker so we get a meaningful error if someone attempts this (this is the
same approach used by AMD SEV).

Signed-off-by: David Gibson 
Reviewed-by: Dr. David Alan Gilbert 
---
 hw/ppc/pef.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
index b227dc6905..822668d9ae 100644
--- a/hw/ppc/pef.c
+++ b/hw/ppc/pef.c
@@ -38,6 +38,8 @@ struct PefGuestState {
 };
 
 #ifdef CONFIG_KVM
+static Error *pef_mig_blocker;
+
 static int kvmppc_svm_init(Error **errp)
 {
 if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
@@ -54,6 +56,11 @@ static int kvmppc_svm_init(Error **errp)
 }
 }
 
+/* add migration blocker */
+error_setg(_mig_blocker, "PEF: Migration is not implemented");
+/* NB: This can fail if --only-migratable is used */
+migrate_add_blocker(pef_mig_blocker, _fatal);
+
 return 0;
 }
 
-- 
2.29.2

[PATCH v6 06/13] sev: Add Error ** to sev_kvm_init()

[David Gibson]

This allows failures to be reported richly and idiomatically.

Signed-off-by: David Gibson 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Reviewed-by: Cornelia Huck 
---
 accel/kvm/kvm-all.c  |  4 +++-
 accel/kvm/sev-stub.c |  2 +-
 include/sysemu/sev.h |  2 +-
 target/i386/sev.c| 31 +++
 4 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 28ab126f70..c5b0750fd0 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2182,9 +2182,11 @@ static int kvm_init(MachineState *ms)
  * encryption context.
  */
 if (ms->cgs) {
+Error *local_err = NULL;
 /* FIXME handle mechanisms other than SEV */
-ret = sev_kvm_init(ms->cgs);
+ret = sev_kvm_init(ms->cgs, _err);
 if (ret < 0) {
+error_report_err(local_err);
 goto err;
 }
 }
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 3d4787ae4a..512e205f7f 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,7 +15,7 @@
 #include "qemu-common.h"
 #include "sysemu/sev.h"
 
-int sev_kvm_init(ConfidentialGuestSupport *cgs)
+int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
 /* SEV can't be selected if it's not compiled */
 g_assert_not_reached();
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 3b5b1aacf1..5c5a13c6ca 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -16,7 +16,7 @@
 
 #include "sysemu/kvm.h"
 
-int sev_kvm_init(ConfidentialGuestSupport *cgs);
+int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp);
 int sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp);
 int sev_inject_launch_secret(const char *hdr, const char *secret,
  uint64_t gpa, Error **errp);
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 5399a136ad..e2b41ef342 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -662,7 +662,7 @@ sev_vm_state_change(void *opaque, int running, RunState 
state)
 }
 }
 
-int sev_kvm_init(ConfidentialGuestSupport *cgs)
+int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
 SevGuestState *sev = SEV_GUEST(cgs);
 char *devname;
@@ -684,14 +684,14 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs)
 host_cbitpos = ebx & 0x3f;
 
 if (host_cbitpos != sev->cbitpos) {
-error_report("%s: cbitpos check failed, host '%d' requested '%d'",
- __func__, host_cbitpos, sev->cbitpos);
+error_setg(errp, "%s: cbitpos check failed, host '%d' requested '%d'",
+   __func__, host_cbitpos, sev->cbitpos);
 goto err;
 }
 
 if (sev->reduced_phys_bits < 1) {
-error_report("%s: reduced_phys_bits check failed, it should be >=1,"
- " requested '%d'", __func__, sev->reduced_phys_bits);
+error_setg(errp, "%s: reduced_phys_bits check failed, it should be 
>=1,"
+   " requested '%d'", __func__, sev->reduced_phys_bits);
 goto err;
 }
 
@@ -700,20 +700,19 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs)
 devname = object_property_get_str(OBJECT(sev), "sev-device", NULL);
 sev->sev_fd = open(devname, O_RDWR);
 if (sev->sev_fd < 0) {
-error_report("%s: Failed to open %s '%s'", __func__,
- devname, strerror(errno));
-}
-g_free(devname);
-if (sev->sev_fd < 0) {
+error_setg(errp, "%s: Failed to open %s '%s'", __func__,
+   devname, strerror(errno));
+g_free(devname);
 goto err;
 }
+g_free(devname);
 
 ret = sev_platform_ioctl(sev->sev_fd, SEV_PLATFORM_STATUS, ,
  _error);
 if (ret) {
-error_report("%s: failed to get platform status ret=%d "
- "fw_error='%d: %s'", __func__, ret, fw_error,
- fw_error_to_str(fw_error));
+error_setg(errp, "%s: failed to get platform status ret=%d "
+   "fw_error='%d: %s'", __func__, ret, fw_error,
+   fw_error_to_str(fw_error));
 goto err;
 }
 sev->build_id = status.build;
@@ -723,14 +722,14 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs)
 trace_kvm_sev_init();
 ret = sev_ioctl(sev->sev_fd, KVM_SEV_INIT, NULL, _error);
 if (ret) {
-error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
- __func__, ret, fw_error, fw_error_to_str(fw_error));
+error_setg(errp, "%s: failed to initialize ret=%d fw_error=%d '%s'",
+   __func__, ret, fw_error, fw_error_to_str(fw_error));
 goto err;
 }
 
 ret = sev_launch_start(sev);
 if (ret) {
-error_report("%s: failed to create encryption context", __func__);
+error_setg(errp, "%s: failed to create encryption context", __func__);
 goto err;
 }
 
-- 
2.29.2

[PATCH 1/4] target/riscv: Make csr_ops[CSR_TABLE_SIZE] external

[Bin Meng]

From: Bin Meng 

In preparation to generate the CSR register list for GDB stub
dynamically, change csr_ops[] to non-static so that it can be
referenced externally.

Signed-off-by: Bin Meng 
---

 target/riscv/cpu.h |  8 
 target/riscv/csr.c | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 2649949..6f9e1cc 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -482,6 +482,14 @@ typedef struct {
 riscv_csr_op_fn op;
 } riscv_csr_operations;
 
+/* CSR function table constants */
+enum {
+CSR_TABLE_SIZE = 0x1000
+};
+
+/* CSR function table */
+extern riscv_csr_operations csr_ops[];
+
 void riscv_get_csr_ops(int csrno, riscv_csr_operations *ops);
 void riscv_set_csr_ops(int csrno, riscv_csr_operations *ops);
 
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 10ab82e..507e8ee 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -23,14 +23,6 @@
 #include "qemu/main-loop.h"
 #include "exec/exec-all.h"
 
-/* CSR function table */
-static riscv_csr_operations csr_ops[];
-
-/* CSR function table constants */
-enum {
-CSR_TABLE_SIZE = 0x1000
-};
-
 /* CSR function table public API */
 void riscv_get_csr_ops(int csrno, riscv_csr_operations *ops)
 {
@@ -1378,7 +1370,7 @@ int riscv_csrrw_debug(CPURISCVState *env, int csrno, 
target_ulong *ret_value,
 }
 
 /* Control and Status Register function table */
-static riscv_csr_operations csr_ops[CSR_TABLE_SIZE] = {
+riscv_csr_operations csr_ops[CSR_TABLE_SIZE] = {
 /* User Floating-Point CSRs */
 [CSR_FFLAGS] =  { fs,   read_fflags,  write_fflags  },
 [CSR_FRM] = { fs,   read_frm, write_frm },
-- 
2.7.4

[PATCH v6 07/13] confidential guest support: Introduce cgs "ready" flag

[David Gibson]

The platform specific details of mechanisms for implementing
confidential guest support may require setup at various points during
initialization.  Thus, it's not really feasible to have a single cgs
initialization hook, but instead each mechanism needs its own
initialization calls in arch or machine specific code.

However, to make it harder to have a bug where a mechanism isn't
properly initialized under some circumstances, we want to have a
common place, relatively late in boot, where we verify that cgs has
been initialized if it was requested.

This patch introduces a ready flag to the ConfidentialGuestSupport
base type to accomplish this, which we verify just before the machine
specific initialization function.

Signed-off-by: David Gibson 
---
 hw/core/machine.c | 8 
 include/exec/confidential-guest-support.h | 2 ++
 target/i386/sev.c | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 94194ab82d..5a742b 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -1190,6 +1190,14 @@ void machine_run_board_init(MachineState *machine)
 }
 
 if (machine->cgs) {
+/*
+ * Where confidential guest support is initialized depends on
+ * the specific mechanism in use.  But, we need to make sure
+ * it's ready by now.  If it isn't, that's a bug in the
+ * implementation of that cgs mechanism.
+ */
+assert(machine->cgs->ready);
+
 /*
  * With confidential guests, the host can't see the real
  * contents of RAM, so there's no point in it trying to merge
diff --git a/include/exec/confidential-guest-support.h 
b/include/exec/confidential-guest-support.h
index f9cf170802..5f3e745e20 100644
--- a/include/exec/confidential-guest-support.h
+++ b/include/exec/confidential-guest-support.h
@@ -35,6 +35,8 @@
 
 struct ConfidentialGuestSupport {
 Object parent;
+
+bool ready;
 };
 
 typedef struct ConfidentialGuestSupportClass {
diff --git a/target/i386/sev.c b/target/i386/sev.c
index e2b41ef342..3d94635397 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -737,6 +737,8 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs, Error 
**errp)
 qemu_add_machine_init_done_notifier(_machine_done_notify);
 qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
 
+cgs->ready = true;
+
 return 0;
 err:
 sev_guest = NULL;
-- 
2.29.2

[PATCH v6 09/13] confidential guest support: Update documentation

[David Gibson]

Now that we've implemented a generic machine option for configuring various
confidential guest support mechanisms:
  1. Update docs/amd-memory-encryption.txt to reference this rather than
 the earlier SEV specific option
  2. Add a docs/confidential-guest-support.txt to cover the generalities of
 the confidential guest support scheme

Signed-off-by: David Gibson 
---
 docs/amd-memory-encryption.txt  |  2 +-
 docs/confidential-guest-support.txt | 43 +
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 docs/confidential-guest-support.txt

diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 80b8eb00e9..145896aec7 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryption.txt
@@ -73,7 +73,7 @@ complete flow chart.
 To launch a SEV guest
 
 # ${QEMU} \
--machine ...,memory-encryption=sev0 \
+-machine ...,confidential-guest-support=sev0 \
 -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
 
 Debugging
diff --git a/docs/confidential-guest-support.txt 
b/docs/confidential-guest-support.txt
new file mode 100644
index 00..2790425b38
--- /dev/null
+++ b/docs/confidential-guest-support.txt
@@ -0,0 +1,43 @@
+Confidential Guest Support
+==
+
+Traditionally, hypervisors such as qemu have complete access to a
+guest's memory and other state, meaning that a compromised hypervisor
+can compromise any of its guests.  A number of platforms have added
+mechanisms in hardware and/or firmware which give guests at least some
+protection from a compromised hypervisor.  This is obviously
+especially desirable for public cloud environments.
+
+These mechanisms have different names and different modes of
+operation, but are often referred to as Secure Guests or Confidential
+Guests.  We use the term "Confidential Guest Support" to distinguish
+this from other aspects of guest security (such as security against
+attacks from other guests, or from network sources).
+
+Running a Confidential Guest
+
+
+To run a confidential guest you need to add two command line parameters:
+
+1. Use "-object" to create a "confidential guest support" object.  The
+   type and parameters will vary with the specific mechanism to be
+   used
+2. Set the "confidential-guest-support" machine parameter to the ID of
+   the object from (1).
+
+Example (for AMD SEV)::
+
+qemu-system-x86_64 \
+ \
+-machine ...,confidential-guest-support=sev0 \
+-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
+
+Supported mechanisms
+
+
+Currently supported confidential guest mechanisms are:
+
+AMD Secure Encrypted Virtualization (SEV)
+docs/amd-memory-encryption.txt
+
+Other mechanisms may be supported in future.
-- 
2.29.2

[PATCH v6 04/13] confidential guest support: Move side effect out of machine_set_memory_encryption()

[David Gibson]

When the "memory-encryption" property is set, we also disable KSM
merging for the guest, since it won't accomplish anything.

We want that, but doing it in the property set function itself is
thereoretically incorrect, in the unlikely event of some configuration
environment that set the property then cleared it again before
constructing the guest.

More importantly, it makes some other cleanups we want more difficult.
So, instead move this logic to machine_run_board_init() conditional on
the final value of the property.

Signed-off-by: David Gibson 
Reviewed-by: Richard Henderson 
---
 hw/core/machine.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index de3b8f1b31..8909117d80 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -437,14 +437,6 @@ static void machine_set_memory_encryption(Object *obj, 
const char *value,
 
 g_free(ms->memory_encryption);
 ms->memory_encryption = g_strdup(value);
-
-/*
- * With memory encryption, the host can't see the real contents of RAM,
- * so there's no point in it trying to merge areas.
- */
-if (value) {
-machine_set_mem_merge(obj, false, errp);
-}
 }
 
 static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -1166,6 +1158,15 @@ void machine_run_board_init(MachineState *machine)
 cc->deprecation_note);
 }
 
+if (machine->memory_encryption) {
+/*
+ * With memory encryption, the host can't see the real
+ * contents of RAM, so there's no point in it trying to merge
+ * areas.
+ */
+machine_set_mem_merge(OBJECT(machine), false, _abort);
+}
+
 machine_class->init(machine);
 phase_advance(PHASE_MACHINE_INITIALIZED);
 }
-- 
2.29.2

[PATCH v6 02/13] confidential guest support: Introduce new confidential guest support class

[David Gibson]

Several architectures have mechanisms which are designed to protect guest
memory from interference or eavesdropping by a compromised hypervisor.  AMD
SEV does this with in-chip memory encryption and Intel's MKTME can do
similar things.  POWER's Protected Execution Framework (PEF) accomplishes a
similar goal using an ultravisor and new memory protection features,
instead of encryption.

To (partially) unify handling for these, this introduces a new
ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
but "confidential computing" seems to be the buzzword about these schemes,
and "secure" or "protected" are often used in connection to unrelated
things (such as hypervisor-from-guest or guest-from-guest security).

The "support" in the name is significant because in at least some of the
cases it requires the guest to take specific actions in order to protect
itself from hypervisor eavesdropping.

Signed-off-by: David Gibson 
---
 backends/confidential-guest-support.c | 30 +++
 backends/meson.build  |  1 +
 include/exec/confidential-guest-support.h | 46 +++
 include/qemu/typedefs.h   |  1 +
 target/i386/sev.c |  3 +-
 5 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 backends/confidential-guest-support.c
 create mode 100644 include/exec/confidential-guest-support.h

diff --git a/backends/confidential-guest-support.c 
b/backends/confidential-guest-support.c
new file mode 100644
index 00..2c7793c74f
--- /dev/null
+++ b/backends/confidential-guest-support.c
@@ -0,0 +1,30 @@
+/*
+ * QEMU Confidential Guest support
+ *
+ * Copyright: David Gibson, Red Hat Inc. 2020
+ *
+ * Authors:
+ *  David Gibson 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "exec/confidential-guest-support.h"
+
+static const TypeInfo confidential_guest_support_info = {
+.parent = TYPE_OBJECT,
+.name = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
+.class_size = sizeof(ConfidentialGuestSupportClass),
+.instance_size = sizeof(ConfidentialGuestSupport),
+};
+
+static void confidential_guest_support_register_types(void)
+{
+type_register_static(_guest_support_info);
+}
+
+type_init(confidential_guest_support_register_types)
diff --git a/backends/meson.build b/backends/meson.build
index 484456ece7..d4221831fc 100644
--- a/backends/meson.build
+++ b/backends/meson.build
@@ -6,6 +6,7 @@ softmmu_ss.add([files(
   'rng-builtin.c',
   'rng-egd.c',
   'rng.c',
+  'confidential-guest-support.c',
 ), numa])
 
 softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
diff --git a/include/exec/confidential-guest-support.h 
b/include/exec/confidential-guest-support.h
new file mode 100644
index 00..f9cf170802
--- /dev/null
+++ b/include/exec/confidential-guest-support.h
@@ -0,0 +1,46 @@
+/*
+ * QEMU Confidential Guest support
+ *   This interface describes the common pieces between various
+ *   schemes for protecting guest memory or other state against a
+ *   compromised hypervisor.  This includes memory encryption (AMD's
+ *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
+ *   or PV on s390x).
+ *
+ * Copyright: David Gibson, Red Hat Inc. 2020
+ *
+ * Authors:
+ *  David Gibson 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ *
+ */
+#ifndef QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
+#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
+
+#ifndef CONFIG_USER_ONLY
+
+#include "qom/object.h"
+
+#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
+#define CONFIDENTIAL_GUEST_SUPPORT(obj)\
+OBJECT_CHECK(ConfidentialGuestSupport, (obj),  \
+ TYPE_CONFIDENTIAL_GUEST_SUPPORT)
+#define CONFIDENTIAL_GUEST_SUPPORT_CLASS(klass)\
+OBJECT_CLASS_CHECK(ConfidentialGuestSupportClass, (klass), \
+   TYPE_CONFIDENTIAL_GUEST_SUPPORT)
+#define CONFIDENTIAL_GUEST_SUPPORT_GET_CLASS(obj)  \
+OBJECT_GET_CLASS(ConfidentialGuestSupportClass, (obj), \
+ TYPE_CONFIDENTIAL_GUEST_SUPPORT)
+
+struct ConfidentialGuestSupport {
+Object parent;
+};
+
+typedef struct ConfidentialGuestSupportClass {
+ObjectClass parent;
+} ConfidentialGuestSupportClass;
+
+#endif /* !CONFIG_USER_ONLY */
+
+#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 976b529dfb..33685c79ed 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -36,6 +36,7 @@ typedef struct BusState BusState;
 typedef struct Chardev Chardev;
 typedef struct CompatProperty CompatProperty;
 typedef struct CoMutex CoMutex;
+typedef struct 

[PATCH v6 01/13] qom: Allow optional sugar props

[David Gibson]

From: Greg Kurz 

Global properties have an @optional field, which allows to apply a given
property to a given type even if one of its subclasses doesn't support
it. This is especially used in the compat code when dealing with the
"disable-modern" and "disable-legacy" properties and the "virtio-pci"
type.

Allow object_register_sugar_prop() to set this field as well.

Signed-off-by: Greg Kurz 
Message-Id: <159738953558.377274.16617742952571083440.st...@bahia.lan>
Signed-off-by: David Gibson 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Cornelia Huck 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/qom/object.h |  3 ++-
 qom/object.c |  4 +++-
 softmmu/rtc.c|  3 ++-
 softmmu/vl.c | 17 +++--
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index d378f13a11..6721cd312e 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -638,7 +638,8 @@ bool object_apply_global_props(Object *obj, const GPtrArray 
*props,
Error **errp);
 void object_set_machine_compat_props(GPtrArray *compat_props);
 void object_set_accelerator_compat_props(GPtrArray *compat_props);
-void object_register_sugar_prop(const char *driver, const char *prop, const 
char *value);
+void object_register_sugar_prop(const char *driver, const char *prop,
+const char *value, bool optional);
 void object_apply_compat_props(Object *obj);
 
 /**
diff --git a/qom/object.c b/qom/object.c
index 2fa0119647..491823db4a 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -442,7 +442,8 @@ static GPtrArray *object_compat_props[3];
  * other than "-global".  These are generally used for syntactic
  * sugar and legacy command line options.
  */
-void object_register_sugar_prop(const char *driver, const char *prop, const 
char *value)
+void object_register_sugar_prop(const char *driver, const char *prop,
+const char *value, bool optional)
 {
 GlobalProperty *g;
 if (!object_compat_props[2]) {
@@ -452,6 +453,7 @@ void object_register_sugar_prop(const char *driver, const 
char *prop, const char
 g->driver = g_strdup(driver);
 g->property = g_strdup(prop);
 g->value = g_strdup(value);
+g->optional = optional;
 g_ptr_array_add(object_compat_props[2], g);
 }
 
diff --git a/softmmu/rtc.c b/softmmu/rtc.c
index e1e15ef613..5632684fc9 100644
--- a/softmmu/rtc.c
+++ b/softmmu/rtc.c
@@ -179,7 +179,8 @@ void configure_rtc(QemuOpts *opts)
 if (!strcmp(value, "slew")) {
 object_register_sugar_prop("mc146818rtc",
"lost_tick_policy",
-   "slew");
+   "slew",
+   false);
 } else if (!strcmp(value, "none")) {
 /* discard is default */
 } else {
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 7ddf405d76..3f7721b83e 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1663,16 +1663,20 @@ static int machine_set_property(void *opaque,
 return 0;
 }
 if (g_str_equal(qom_name, "igd-passthru")) {
-object_register_sugar_prop(ACCEL_CLASS_NAME("xen"), qom_name, value);
+object_register_sugar_prop(ACCEL_CLASS_NAME("xen"), qom_name, value,
+   false);
 return 0;
 }
 if (g_str_equal(qom_name, "kvm-shadow-mem")) {
-object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value);
+object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value,
+   false);
 return 0;
 }
 if (g_str_equal(qom_name, "kernel-irqchip")) {
-object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value);
-object_register_sugar_prop(ACCEL_CLASS_NAME("whpx"), qom_name, value);
+object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value,
+   false);
+object_register_sugar_prop(ACCEL_CLASS_NAME("whpx"), qom_name, value,
+   false);
 return 0;
 }
 
@@ -2297,9 +2301,10 @@ static void qemu_process_sugar_options(void)
 
 val = g_strdup_printf("%d",
  (uint32_t) 
qemu_opt_get_number(qemu_find_opts_singleton("smp-opts"), "cpus", 1));
-object_register_sugar_prop("memory-backend", "prealloc-threads", val);
+object_register_sugar_prop("memory-backend", "prealloc-threads", val,
+   false);
 g_free(val);
-object_register_sugar_prop("memory-backend", "prealloc", "on");
+object_register_sugar_prop("memory-backend", "prealloc", "on", false);
 }
 
 if (watchdog) {
-- 
2.29.2

[PATCH v6 08/13] confidential guest support: Move SEV initialization into arch specific code

[David Gibson]

While we've abstracted some (potential) differences between mechanisms for
securing guest memory, the initialization is still specific to SEV.  Given
that, move it into x86's kvm_arch_init() code, rather than the generic
kvm_init() code.

Signed-off-by: David Gibson 
---
 accel/kvm/kvm-all.c   | 14 --
 accel/kvm/sev-stub.c  |  4 ++--
 target/i386/kvm/kvm.c | 12 
 target/i386/sev.c |  7 ++-
 4 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index c5b0750fd0..adf27c1864 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2177,20 +2177,6 @@ static int kvm_init(MachineState *ms)
 
 kvm_state = s;
 
-/*
- * if memory encryption object is specified then initialize the memory
- * encryption context.
- */
-if (ms->cgs) {
-Error *local_err = NULL;
-/* FIXME handle mechanisms other than SEV */
-ret = sev_kvm_init(ms->cgs, _err);
-if (ret < 0) {
-error_report_err(local_err);
-goto err;
-}
-}
-
 ret = kvm_arch_init(ms, s);
 if (ret < 0) {
 goto err;
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 512e205f7f..9587d1b2a3 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -17,6 +17,6 @@
 
 int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
-/* SEV can't be selected if it's not compiled */
-g_assert_not_reached();
+/* If we get here, cgs must be some non-SEV thing */
+return 0;
 }
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 6dc1ee052d..e8b9dc48a2 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -42,6 +42,7 @@
 #include "hw/i386/intel_iommu.h"
 #include "hw/i386/x86-iommu.h"
 #include "hw/i386/e820_memory_layout.h"
+#include "sysemu/sev.h"
 
 #include "hw/pci/pci.h"
 #include "hw/pci/msi.h"
@@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 uint64_t shadow_mem;
 int ret;
 struct utsname utsname;
+Error *local_err = NULL;
+
+/*
+ * if memory encryption object is specified then initialize the
+ * memory encryption context (no-op otherwise)
+ */
+ret = sev_kvm_init(ms->cgs, _err);
+if (ret < 0) {
+error_report_err(local_err);
+return ret;
+}
 
 if (!kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) {
 error_report("kvm: KVM_CAP_IRQ_ROUTING not supported by KVM");
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 3d94635397..aa79cacabe 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -664,13 +664,18 @@ sev_vm_state_change(void *opaque, int running, RunState 
state)
 
 int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
-SevGuestState *sev = SEV_GUEST(cgs);
+SevGuestState *sev
+= (SevGuestState *)object_dynamic_cast(OBJECT(cgs), TYPE_SEV_GUEST);
 char *devname;
 int ret, fw_error;
 uint32_t ebx;
 uint32_t host_cbitpos;
 struct sev_user_data_status status = {};
 
+if (!sev) {
+return 0;
+}
+
 ret = ram_block_discard_disable(true);
 if (ret) {
 error_report("%s: cannot disable RAM discard", __func__);
-- 
2.29.2

[PATCH v6 03/13] sev: Remove false abstraction of flash encryption

[David Gibson]

When AMD's SEV memory encryption is in use, flash memory banks (which are
initialed by pc_system_flash_map()) need to be encrypted with the guest's
key, so that the guest can read them.

That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
state.. except, that it doesn't really abstract much at all.

For starters, the only called is in code specific to the 'pc' family of
machine types, so it's obviously specific to those and to x86 to begin
with.  But it makes a bunch of further assumptions that need not be true
about an arbitrary confidential guest system based on memory encryption,
let alone one based on other mechanisms:

 * it assumes that the flash memory is defined to be encrypted with the
   guest key, rather than being shared with hypervisor
 * it assumes that that hypervisor has some mechanism to encrypt data into
   the guest, even though it can't decrypt it out, since that's the whole
   point
 * the interface assumes that this encrypt can be done in place, which
   implies that the hypervisor can write into a confidential guests's
   memory, even if what it writes isn't meaningful

So really, this "abstraction" is actually pretty specific to the way SEV
works.  So, this patch removes it and instead has the PC flash
initialization code call into a SEV specific callback.

Signed-off-by: David Gibson 
---
 accel/kvm/kvm-all.c| 31 ++-
 accel/kvm/sev-stub.c   |  9 ++---
 accel/stubs/kvm-stub.c | 10 --
 hw/i386/pc_sysfw.c | 17 ++---
 include/sysemu/kvm.h   | 16 
 include/sysemu/sev.h   |  4 ++--
 target/i386/sev-stub.c |  5 +
 target/i386/sev.c  | 24 ++--
 8 files changed, 31 insertions(+), 85 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 389eaace72..260ed73ffe 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -120,10 +120,6 @@ struct KVMState
 KVMMemoryListener memory_listener;
 QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
 
-/* memory encryption */
-void *memcrypt_handle;
-int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
-
 /* For "info mtree -f" to tell if an MR is registered in KVM */
 int nr_as;
 struct KVMAs {
@@ -222,26 +218,6 @@ int kvm_get_max_memslots(void)
 return s->nr_slots;
 }
 
-bool kvm_memcrypt_enabled(void)
-{
-if (kvm_state && kvm_state->memcrypt_handle) {
-return true;
-}
-
-return false;
-}
-
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
-{
-if (kvm_state->memcrypt_handle &&
-kvm_state->memcrypt_encrypt_data) {
-return kvm_state->memcrypt_encrypt_data(kvm_state->memcrypt_handle,
-  ptr, len);
-}
-
-return 1;
-}
-
 /* Called with KVMMemoryListener.slots_lock held */
 static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
 {
@@ -2206,13 +2182,10 @@ static int kvm_init(MachineState *ms)
  * encryption context.
  */
 if (ms->memory_encryption) {
-kvm_state->memcrypt_handle = sev_guest_init(ms->memory_encryption);
-if (!kvm_state->memcrypt_handle) {
-ret = -1;
+ret = sev_guest_init(ms->memory_encryption);
+if (ret < 0) {
 goto err;
 }
-
-kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
 }
 
 ret = kvm_arch_init(ms, s);
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 4f97452585..5db9ab8f00 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,12 +15,7 @@
 #include "qemu-common.h"
 #include "sysemu/sev.h"
 
-int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+int sev_guest_init(const char *id)
 {
-abort();
-}
-
-void *sev_guest_init(const char *id)
-{
-return NULL;
+return -1;
 }
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 680e099463..0f17acfac0 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -81,16 +81,6 @@ int kvm_on_sigbus(int code, void *addr)
 return 1;
 }
 
-bool kvm_memcrypt_enabled(void)
-{
-return false;
-}
-
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
-{
-  return 1;
-}
-
 #ifndef CONFIG_USER_ONLY
 int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
 {
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 92e90ff013..11172214f1 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -38,6 +38,7 @@
 #include "sysemu/sysemu.h"
 #include "hw/block/flash.h"
 #include "sysemu/kvm.h"
+#include "sysemu/sev.h"
 
 #define FLASH_SECTOR_SIZE 4096
 
@@ -147,7 +148,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
 PFlashCFI01 *system_flash;
 MemoryRegion *flash_mem;
 void *flash_ptr;
-int ret, flash_size;
+int flash_size;
 
 assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
 
@@ -191,16 +192,10 @@ static void pc_system_flash_map(PCMachineState *pcms,
 flash_mem = 

[PATCH v6 00/13] Generalize memory encryption models

[David Gibson]

A number of hardware platforms are implementing mechanisms whereby the
hypervisor does not have unfettered access to guest memory, in order
to mitigate the security impact of a compromised hypervisor.

AMD's SEV implements this with in-cpu memory encryption, and Intel has
its own memory encryption mechanism.  POWER has an upcoming mechanism
to accomplish this in a different way, using a new memory protection
level plus a small trusted ultravisor.  s390 also has a protected
execution environment.

The current code (committed or draft) for these features has each
platform's version configured entirely differently.  That doesn't seem
ideal for users, or particularly for management layers.

AMD SEV introduces a notionally generic machine option
"machine-encryption", but it doesn't actually cover any cases other
than SEV.

This series is a proposal to at least partially unify configuration
for these mechanisms, by renaming and generalizing AMD's
"memory-encryption" property.  It is replaced by a
"confidential-guest-support" property pointing to a platform specific
object which configures and manages the specific details.

Note to Ram Pai: the documentation I've included for PEF is very
minimal.  If you could send a patch expanding on that, it would be
very helpful.

Changes since v5:
 * Renamed from "securable guest memory" to "confidential guest
   support"
 * Simpler reworking of x86 boot time flash encryption
 * Added a bunch of documentation
 * Fixed some compile errors on POWER
Changes since v4:
 * Renamed from "host trust limitation" to "securable guest memory",
   which I think is marginally more descriptive
 * Re-organized initialization, because the previous model called at
   kvm_init didn't work for s390
 * Assorted fixes to the s390 implementation; rudimentary testing
   (gitlab CI) only
Changes since v3:
 * Rebased
 * Added first cut at handling of s390 protected virtualization
Changes since RFCv2:
 * Rebased
 * Removed preliminary SEV cleanups (they've been merged)
 * Changed name to "host trust limitation"
 * Added migration blocker to the PEF code (based on SEV's version)
Changes since RFCv1:
 * Rebased
 * Fixed some errors pointed out by Dave Gilbert

David Gibson (12):
  confidential guest support: Introduce new confidential guest support
class
  sev: Remove false abstraction of flash encryption
  confidential guest support: Move side effect out of
machine_set_memory_encryption()
  confidential guest support: Rework the "memory-encryption" property
  sev: Add Error ** to sev_kvm_init()
  confidential guest support: Introduce cgs "ready" flag
  confidential guest support: Move SEV initialization into arch specific
code
  confidential guest support: Update documentation
  spapr: Add PEF based confidential guest support
  spapr: PEF: prevent migration
  confidential guest support: Alter virtio default properties for
protected guests
  s390: Recognize confidential-guest-support option

Greg Kurz (1):
  qom: Allow optional sugar props

 accel/kvm/kvm-all.c   |  38 ---
 accel/kvm/sev-stub.c  |  10 +-
 accel/stubs/kvm-stub.c|  10 --
 backends/confidential-guest-support.c |  30 ++
 backends/meson.build  |   1 +
 docs/amd-memory-encryption.txt|   2 +-
 docs/confidential-guest-support.txt   |  48 +
 docs/papr-pef.txt |  30 ++
 docs/system/s390x/protvirt.rst|  19 ++--
 hw/core/machine.c |  71 +++--
 hw/i386/pc_sysfw.c|  17 ++-
 hw/ppc/meson.build|   1 +
 hw/ppc/pef.c  | 122 ++
 hw/ppc/spapr.c|  10 ++
 hw/s390x/pv.c |  58 ++
 include/exec/confidential-guest-support.h |  48 +
 include/hw/boards.h   |   2 +-
 include/hw/ppc/pef.h  |  26 +
 include/hw/s390x/pv.h |   1 +
 include/qemu/typedefs.h   |   1 +
 include/qom/object.h  |   3 +-
 include/sysemu/kvm.h  |  16 ---
 include/sysemu/sev.h  |   4 +-
 qom/object.c  |   4 +-
 softmmu/rtc.c |   3 +-
 softmmu/vl.c  |  17 +--
 target/i386/kvm/kvm.c |  12 +++
 target/i386/sev-stub.c|   5 +
 target/i386/sev.c |  93 +++--
 target/ppc/kvm.c  |  18 
 target/ppc/kvm_ppc.h  |   6 --
 target/s390x/kvm.c|   3 +
 32 files changed, 540 insertions(+), 189 deletions(-)
 create mode 100644 backends/confidential-guest-support.c
 create mode 100644 docs/confidential-guest-support.txt
 create mode 100644 docs/papr-pef.txt
 create mode 100644 

[Bug 1782300] Re: COLO unable to failover to secondary VM

[Launchpad Bug Tracker]

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

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

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

Title:
  COLO unable to failover to secondary VM

Status in QEMU:
  Expired

Bug description:
  I test COLO feature on my host following docs/COLO-FT.txt in qemu folder, but 
fail to failover to secondary VM. 
  Is there any mistake in my execution steps?

  Execution environment:
  QEMU v2.12.0-rc4
  OS: Ubuntu 16.04.3 LTS
  Kernel: Linux 4.4.35
  Secondary VM IP: noted as "a.b.c.d"

  Execution steps:
  # Primary
  ${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \
  -enable-kvm \
  -m 512M \
  -smp 2 \
  -qmp stdio \
  -vnc :7 \
  -name primary \
  -device piix3-usb-uhci \
  -device usb-tablet \
  -netdev tap,id=tap0,vhost=off \
  -device virtio-net-pci,id=net-pci0,netdev=tap0 \
  -drive 
if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
  children.0.file.filename=${IMG_PATH},\
  children.0.driver=raw -S

  # Secondary
  ${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \
  -enable-kvm \
  -m 512M \
  -smp 2 \
  -qmp stdio \
  -vnc :8 \
  -name secondary \
  -device piix3-usb-uhci \
  -device usb-tablet \
  -netdev tap,id=tap1,vhost=off \
  -device virtio-net-pci,id=net-pci0,netdev=tap1 \
  -drive 
if=none,id=secondary-disk0,file.filename=${IMG_PATH},driver=raw,node-name=node0 
\
  -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
  file.driver=qcow2,top-id=active-disk0,\
  file.file.filename=$ACTIVE_DISK,\
  file.backing.driver=qcow2,\
  file.backing.file.filename=$HIDDEN_DISK,\
  file.backing.backing=secondary-disk0 \
  -incoming tcp:0:

  # Enter into Secondary:
  {'execute':'qmp_capabilities'}
  { 'execute': 'nbd-server-start',
  'arguments': {'addr': {'type': 'inet', 'data': {'host': 'a.b.c.d', 
'port': '8889'} } }
  }
  {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', 
'writable': true } }

  # Enter into Primary:
  {'execute':'qmp_capabilities'}
  {'execute': 'human-monitor-command',
  'arguments': {
  'command-line': 'drive_add -n buddy 
driver=replication,mode=primary,file.driver=nbd,file.host=a.b.c.d,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'
  }
  }
  { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 
'node': 'nbd_client0' } }
  { 'execute': 'migrate-set-capabilities',
  'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } 
] } }
  { 'execute': 'migrate', 'arguments': {'uri': 'tcp:a.b.c.d:' } }

  # To test failover
  Primary
  { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'primary-disk0', 
'child': 'children.1'}}
  { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del 
nbd_client0'}}

  Secondary
  { 'execute': 'nbd-server-stop' }

  Stop Primary
  Send ^C signal to terminate PVM.

  Secondary
  { "execute": "x-colo-lost-heartbeat" }

  
  # Result:
  Primary (Use ^C to terminate)
  qemu-system-x86_64: Can't receive COLO message: Input/output error
  qemu-system-x86_64: terminating on signal 2
  {"timestamp": {"seconds": 1531815575, "microseconds": 997696}, "event": 
"SHUTDOWN", "data": {"guest":false}}

  Secondary
  { 'execute': 'nbd-server-stop' }
  {"return": {}}
  { "execute": "x-colo-lost-heartbeat" }
  {"return": {}}
  qemu-system-x86_64: Can't receive COLO message: Input/output error
  Segmentation fault

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

[Bug 1782107] Re: Random errors when emulating armv7 and using dh

[Launchpad Bug Tracker]

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

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

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

Title:
  Random errors when emulating armv7 and using dh

Status in QEMU:
  Expired

Bug description:
  Howdy,
  I'm encountering random errors when using qemu to cross-package my project 
using dh. In previous iterations of my project it would only fail once every 
two attempts. Now it fails every time.

  Example error included.


  If you'd like to try and replicate this error, a version of my project is 
publicly available with simple instructions on how to package it (using qemu) 
here:
  https://github.com/Nadav-Ruskin/configsite

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

[Bug 1791947] Re: isochronous usb device forwarding with windows 10 and xhci freezes

[Launchpad Bug Tracker]

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

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

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

Title:
  isochronous usb device forwarding with windows 10 and xhci freezes

Status in QEMU:
  Expired

Bug description:
  When I try to forward isochronous usb devices (webcam, HID-Audio) via 
usbredir into the VM, the devices work for a few minutes then the device stops 
working and stays that way until a VM reboot or a windows driver reload.
  It does not matter if I use qemu-xhci or nec-xhci.
  I can gather more information, if its helpful!

  Windows build:
  windows 10 pro 1803 jun 2018

  Linux Version:
  Fedora 28
  $ uname -a
  Linux 4.17.19-200.fc28.x86_64 #1 SMP Fri Aug 24 15:47:41 UTC 2018 x86_64 
x86_64 x86_64 GNU/Linux

  Qemu Version:
  $ qemu-system-x86_64 -version
  QEMU emulator version 2.11.2(qemu-2.11.2-2.fc28)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  Qemu command line:
  /usr/bin/qemu-system-x86_64 -machine accel=kvm -name 
guest=win10,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-win10/master-key.aes
 -machine pc-q35-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu 
Skylake-Client-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,ssbd=on,xsaves=on,pdpe1gb=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
 -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 
38b1258e-fea4-41fe-9e21-07c426c5b2b2 -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win10/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet 
-no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot 
strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device 
pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device 
pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2
 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 
-device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 
-device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 
-device qemu-xhci,id=usb,bus=pci.3,addr=0x0 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 -drive 
file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-sata0-0-0
 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive 
file=/var/lib/libvirt/images/en_windows_10_multiple_editions_version_1803_jun_2018.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on
 -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -netdev 
tap,fd=25,id=hostnet0 -device 
e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:33:11,bus=pci.2,addr=0x1 -chardev 
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
 -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
 -chardev spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device 
virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -msg timestamp=on

  Cheers,
  Florian

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

[Bug 786208] Re: Missing checks for non-existent device in ide_exec_cmd

[Launchpad Bug Tracker]

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

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

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

Title:
  Missing checks for non-existent device in ide_exec_cmd

Status in QEMU:
  Expired

Bug description:
  Several calls in the ide_exec_cmd handler are missing checks for
  (!s->bs) or similar, resulting in NULL pointer dereferences, divide-
  by-zero, or possibly other badness if the guest performs operations on
  a non-existent IDE master.

  For example, the WIN_READ_NATIVE_MAX command does a 'ide_set_sector(s,
  s->nb_sectors - 1);', which does 'cyl = sector_num / (s->heads *
  s->sectors);', which will fail with a divide-by-zero if heads =
  sectors = 0.

  And WIN_MULTREAD also does not check for s->bs, but does a
  'ide_sector_read(s);', which will do 'bdrv_read(s->bs, sector_num,
  s->io_buffer, n);' on a NULL s->bs, leading to a segfault.

  I do not *believe* that a malicious guest can do anything more than
  cause a crash with these bugs.

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

[Bug 1626596] Re: Lockup with vhost network

[Launchpad Bug Tracker]

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

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

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

Title:
  Lockup with vhost network

Status in QEMU:
  Expired

Bug description:
  After using Qemu in this configuration successfully for quite a while, I 
changed two things:
  - moved the VM from a 8-core 4GHz host to a slower 2-core 1.6 Ghz machine
  - upgraded qemu from 2.1 to 2.5

  and almost immediately (in a couple hours) got hit with a vhost-
  related lockup.

  QEMU command line is:

  qemu-system-x86_64 -enable-kvm -daemonize -monitor
  unix:./monitor,server,nowait -cpu host -M q35 -balloon virtio -device
  virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd -drive
  
if=none,id=hd,cache=writeback,aio=native,format=raw,file=.img,discard=unmap
  ,detect-zeroes=unmap -device virtio-net-pci,netdev=net0,mac=
  -netdev tap,vhost=on,id=net0,script=.sh -usbdevice tablet -smp 2
  -m 512 -vnc :yz

  VM was running fine, except no network traffic was passed from/to it.
  Shutting down the VM, it hung at "Will now halt." The QEMU process was
  unkillable, so the only choice was to sysrq-b the entire box.

  dmesg with sysrq-w attached.

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

[Bug 1794950] Re: qemu hangs when guest is using linux kernel 4.16+

[Launchpad Bug Tracker]

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

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

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

Title:
  qemu hangs when guest is using linux kernel 4.16+

Status in QEMU:
  Expired

Bug description:
  I have been using qemu on daily basis 5+ years in order to do btrfs
  development and testing and it always worked perfectly, until I
  upgraded the linux kernel of the guests to 4.16. With 4.16+ kernels,
  when running all the fstests (previously called xfstests), the qemu
  process hangs (console unresponsive, can't ping or ssh the guest
  anymore, etc) and stays in a state Sl+ according to 'ps'.

  This happens on two different physical machines, one running openSUSE
  tumbleweed (which I don't access at the moment to check kernel
  version) and another running xubuntu (tried kernels 4.15.0-32-generic
  and vanilla 4.18.0). Using any kernel from 4.16 to 4.19-rc5 in the
  guests (they use different debian versions) makes qemu hang running
  the fstests suite (after about 30 to 40 minutes, either at test
  generic/299 or test generic/451).

  I tried different qemu versions, 2.11.2, 2.12.1 and 3.0.0, and it
  happens with all of them (all built from the sources available at
  https://www.qemu.org/download/#source).

  I built 3.0.0 with debug enabled, using the following parameters for
  'configure':

  --prefix=/home/fdmanana/qemu-3.0.0 --enable-tools --enable-linux-aio
  --enable-kvm --enable-vnc --enable-vnc-png --enable-debug --extra-
  cflags="-O0 -g3 -fno-omit-frame-pointer"

  And captured a coredump of the qemu process, available at:

  https://www.dropbox.com/s/d1tlsimahykwhla/core_dump_debug.tar.xz?dl=0

  the stack traces of all threads, for a quick look:

  https://friendpaste.com/zqkz2pD0WgSdeSKITHPDf

  qemu is being invoked with the following script:

  #!/bin/bash -x

  sudo modprobe tun
  sudo modprobe kvm
  sudo modprobe kvm-intel

  sudo tunctl -t tap5 -u fdmanana
  sudo ifconfig tap5 up
  sudo brctl addif br0 tap5

  sudo umount /mnt/tmp5
  sudo mkdir -p /mnt/tmp5
  sudo mount -t tmpfs -o size=14G tmpfs /mnt/tmp5
  for ((i = 2; i <= 7; i++)); do
  sudo qemu-img create -f qcow2 /mnt/tmp5/disk$i 13G
  done
  sudo chown fdmanana /mnt/tmp5/disk*

  qemu-system-x86_64 -m 4G \
  -device virtio-scsi-pci \
  -boot c \
  \
  -drive 
if=none,file=debian5.qcow2,cache=none,aio=native,cache.direct=on,format=qcow2,id=drive0,discard=on
 \
  -device scsi-hd,drive=drive0,bus=scsi.0 \
  \
  -drive 
if=none,file=/mnt/tmp5/disk2,cache=writeback,format=qcow2,id=drive1,discard=on \
  -device scsi-hd,drive=drive1,bus=scsi.0 \
  \
  -drive 
if=none,file=/mnt/tmp5/disk3,cache=writeback,format=qcow2,id=drive2,discard=on \
  -device scsi-hd,drive=drive2,bus=scsi.0 \
  \
  -drive 
if=none,file=/mnt/tmp5/disk4,cache=writeback,format=qcow2,id=drive3,discard=on \
  -device scsi-hd,drive=drive3,bus=scsi.0 \
  \
  -drive 
if=none,file=/mnt/tmp5/disk5,cache=writeback,format=qcow2,id=drive4,discard=on \
  -device scsi-hd,drive=drive4,bus=scsi.0 \
  \
  -drive 
if=none,file=/mnt/tmp5/disk6,cache=writeback,format=qcow2,id=drive5,discard=on \
  -device scsi-hd,drive=drive5,bus=scsi.0 \
  \
  -drive 
if=none,file=/mnt/tmp5/disk7,cache=writeback,format=qcow2,id=drive6,discard=on \
  -device scsi-hd,drive=drive6,bus=scsi.0 \
  \
  -drive 
if=none,file=disk8,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive7,discard=on
 \
  -device scsi-hd,drive=drive7,bus=scsi.0 \
  \
  -drive 
if=none,file=disk9,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive8,discard=on
 \
  -device scsi-hd,drive=drive8,bus=scsi.0 \
  \
  -drive 
if=none,file=disk10,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive9,discard=on
 \
  -device scsi-hd,drive=drive9,bus=scsi.0 \
  \
  -net nic,macaddr=52:54:00:12:34:fa -net 
tap,ifname=tap5,script=no,downscript=no \
  -rtc base=localtime -enable-kvm -machine accel=kvm -smp 4 -cpu host \
  -k pt -serial tcp:127.0.0.1:9997 -display vnc=:5


  Is there anything else I can provided to help debug this?

  Thanks.

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

[Bug 670769] Re: CDROM size not updated when changing image files

[Launchpad Bug Tracker]

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

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

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

Title:
  CDROM size not updated when changing image files

Status in QEMU:
  Expired

Bug description:
  I'm using qemu 13.0 with a plain Linux kernel using the ata_piix driver as 
the guest, and an initrd that starts a shell. When changing the image in the 
monitor and reading from the CDROM in the guest, the size is not updated. I'm 
using LInux 2.6.32.24
  as the host and I've tested 2.6.32.24, 2.6.35, and 2.6.36 as guests.  Both 
host and guest are 64-bit. Here is the command used to start the guest using 
the initrd:

  ./x86_64-softmmu/qemu-system-x86_64 -cdrom /spare2/cd1.img -kernel
  /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd
  /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu core2duo

  Additional info on this bug can be found here: 
http://marc.info/?l=kvm=128746013906820=2. Note: this is how I discovered 
  the bug, using 32-bit Slackware install CDs.

  I'm attaching the initrd I used in my tests: I created two different-sized 
fake CDROM images by dd'ing from /dev/zero. In my tests,
  cd1.img is smaller that cd2.img. In the monitor I executed 'change ide1-cd0 
/spare2/cd2.img' to load the new image. I checked 
  the size by cat'ing /sys/block/sr0/size in the guest after reading the CDROM. 
Reading the CDROM was done by typing
  'dd if=/dev/sr0 of=/dev/null bs=512 count=3'

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

[Bug 1626207] Re: -device usb-host failing with usbip_vudc-vhdi_hcd gadget

[Launchpad Bug Tracker]

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

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

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

Title:
  -device usb-host failing with usbip_vudc-vhdi_hcd gadget

Status in QEMU:
  Expired

Bug description:
  I must admit that I do not know if this is a Qemu or a Kernel issue,
  but I try reporting here:

  When I try to forward a copy of my USB mouse that I made with the new virtual 
USB device controller in kernel 4.7 I get the following in my log:
  [  +0.703256] usb 1-4: reset full-speed USB device number 3 using xhci_hcd
  [  +1.020776] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.855013] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.859052] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.857000] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.000141] usb 7-3: USB disconnect, device number 10
  [  +0.153056] usb 1-4: reset full-speed USB device number 3 using xhci_hcd
  [  +0.703746] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.855001] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.855006] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.855005] usb usb7-port3: Cannot enable. Maybe the USB cable is bad?
  [  +0.09] usb usb7-port3: unable to enumerate USB device

  the commands I use for makeing the virtual device are(after making a copy of 
the report description of my real mouse in /root/usb/kingston_report_desc):
  mkdir /sys/kernel/config/usb_gadget/winmouse
  cd /sys/kernel/config/usb_gadget/winmouse
  echo "0x047d" > idVendor
  echo "0x1020" > idProduct
  mkdir strings/0x409
  echo 2016 > strings/0x409/serialnumber
  echo Kensington > strings/0x409/manufacturer
  echo "Kensington Expert Mouse" > strings/0x409/product
  mkdir configs/c.1
  mkdir configs/c.1/strings/0x409
  mkdir functions/hid.usb2
  echo 2 > functions/hid.usb2/protocol
  echo 1 > functions/hid.usb2/subclass
  echo 4 > functions/hid.usb2/report_length
  cat /root/usb/kingston_report_desc > functions/hid.usb2/report_desc
  echo 0xa0 > configs/c.1/bmAttributes
  echo 100 > configs/c.1/MaxPower

  ln -s functions/hid.usb2 configs/c.1
  echo usbip-vudc.2 > UDC

  usbip attach -r localhost -d usbip-vudc.2

  The virtual mouse then shows up as Bus7,Dev10 and I use the option
  -device usb-host,hostbus=7,hostaddr=10,id=hostdev6,bus=usb.0,port=2 in
  Qemu to attach it.

  This is Qemu 2.7.0 on kernel 4.7.4

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

[Bug 1780815] Re: SDL Doesn't Rescale Image on Resolution Change

[Launchpad Bug Tracker]

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

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

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

Title:
  SDL Doesn't Rescale Image on Resolution Change

Status in QEMU:
  Expired

Bug description:
  Whilst in fullscreen mode, if the guest changes resolution for
  whatever reason, the screen doesn't update the scaling so you end up
  looking at only part of the screen, e.g. if the guest changes from
  640x480 to 1024x768, the image will still be fullscreen, but what
  you're actually looking at will be the top-left most 640x480 segment
  of the screen stretched out.

  Manually going out of fullscreen mode and then back in fixes the
  scaling, but you have to do that every time the guest changes
  resolution.

  QEmu 2.12.0 using qemu-system-x86_64 with Arch Linux host.

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

[Bug 1795369] Re: Record/replay (icount rr) causes emulation hang or exit with error about missing events in log

[Launchpad Bug Tracker]

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

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

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

Title:
  Record/replay (icount rr) causes emulation hang or exit with error
  about missing events in log

Status in QEMU:
  Expired

Bug description:
  Test case description:

  Guest image is Linux, which just powers off after kernel boots (instead of 
proceeding to user-space /init or /sbin/init).
  Base cmdline:
qemu-system-x86_64 \
  -nodefaults -nographic -machine pc,accel=tcg -m 2048 -cpu qemu64 \
  -kernel bzImage -initrd rootfs -append 'nokaslr console=ttyS0 
rdinit=/init_poweroff' \
  -serial SERIAL_VALUE \
  -rtc clock=vm,base=2000-01-01T00:00:00 \
  -icount 1,sleep=off,rr=RR_VALUE,rrfile=icount_rr_capture.bin

  Test 1.
  When SERIAL_VALUE=none
  Running with RR_VALUE=record completes successfully.
  Running with RR_VALUE=replay doesn't completes. qemu process just eating 
~100% cpu and memory usage doesn't grow after some moment. I don't see what 
happens because of problem no.2 (see below).

  Test 2.
  When SERIAL_VALUE=stdio
  Running with RR_VALUE=record completes successfully.
  Running with RR_VALUE=replay causes exit with error:
  "qemu-system-x86_64: Missing character write event in the replay log"

  Tests 3,4,5...
  SERIAL_VALUE=stdio. Playing with "-rtc" clock and base suboptions, "-icount" 
sleep suboptions produces non-repeatable results.
  In most cases running with RR_VALUE=record completes successfully (but may 
hang at very begining).
  Running with RR_VALUE=replay with combinations of removing "-rtc base=..." 
and "-icount sleep=..." goes better, but at different places of boot process it 
may either hang (as in test 1) or exit with error (as in test 2).
  When qemu "hangs", it may also happen differently: either it can be stopped 
by Ctrl-C, or have to be killed.

  
  Guest image uploaded here: 
https://drive.google.com/open?id=1SHG4HyBdcPutc5Au4pyhN8z9w52et51A

  QEMU built from master (commit 042938f46e1c477419d1931381fdadffaa49d45e) with:
  /configure --prefix= --target-list=x86_64-softmmu 
--enable-debug --disable-pie --enable-tcg --disable-tcg-interpreter 
--enable-virtfs --disable-docs --disable-guest-agent --disable-modules 
--disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl 
--disable-curses --disable-vnc --disable-vnc-sasl --disable-vnc-jpeg 
--disable-vnc-png --disable-cocoa --disable-xen --disable-xen-pci-passthrough 
--disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm 
--disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde 
--disable-netmap --disable-cap-ng --disable-spice --disable-rbd 
--disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb 
--disable-live-block-migration --disable-usb-redir --disable-glusterfs 
--disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 
--disable-opengl --disable-virglrenderer --disable-qom-cast-debug 
--disable-tools --disable-vxhs --disable-crypto-afalg --disable-capstone 
--disable-replication --disable-xfsctl --disable-seccomp --disable-pvrdma 
--disable-libpmem

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

[Bug 1779649] Re: Suspending a domain works with a 3.16 gues kernel but not with a 4.16 one

[Launchpad Bug Tracker]

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

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

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

Title:
  Suspending a domain works with a 3.16 gues kernel but not with a 4.16
  one

Status in QEMU:
  Expired

Bug description:
  Suspending a domain with `systemctl suspend` works with a guest 3.16 kernel 
(jessie), the domain goes into `pmsuspend` in libvirt but doesn't work anymore 
with a 4.16 one (sid) where:
   - With a QXL card: the spice display just goes black and the domain stays 
`running` in libvirt but is "dead"
   - With a VGA card: the screen goes black and comes back immediately, the 
domain stays fine

  Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b

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

[Bug 1781515] Re: Resolution switch leads to the screen/image being corrupted

[Launchpad Bug Tracker]

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

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

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

Title:
  Resolution switch leads to the screen/image being corrupted

Status in QEMU:
  Expired

Bug description:
  I am currently using QEMU on a Arch Linux host, the guest OS is also
  Arch Linux.

  The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the
  command line I'm using to fire an Arch VM is:

  $ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4

  The problem I'm currently having is, after firing the VM and running
  startx I want to change the resolution to the native resolution, which
  is 1366x768 on my ThinkPad T450, however, after changing the
  resolution the image on the guest gets corrupted and it's impossible
  to see anything.

  At this point I can only turn off the VM. The only workaround I found
  is to start the VM with -vga virtio.

  The problem in this case occurs with -vga std which is the default
  video driver.

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

[Bug 1793297] Re: windows's paint software cross-shadped cursor offset a pixel in guest windows which is generated by qemu-kvm

[Launchpad Bug Tracker]

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

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

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

Title:
  windows's paint software cross-shadped cursor offset a pixel in guest
  windows which is generated by qemu-kvm

Status in QEMU:
  Expired

Bug description:
  I have already tested lots of versions of QEMU. Since qemu-2.3.0 -- 
qemu-3.0.0. I find weird phenomena about windows's paint software cross-shaped 
cursor offset a pixel since qemu-2.10.0, but it is ok before the version of 
qemu-2.10.0. Only spice agent and service are running in guest windows since 
qemu-2.10.0, windows's paint software cross-shaped cursor offset a pixel is the 
same as the windows's paint software cross-shaped cursor focus point is the 
same as the true windows machine instead of virtual windows machine.
  What does QEMU change since qemu-2.10.0? It is the changes that result in 
windows's paint software cross-shaped cursor is not accurate with true windows 
machine for comparison.  
  The following is the full command line used to launch the QEMU guest:
  # /usr/bin/qemu-system-x86_64 -m 4096 -smp 2 -M pc -name win7-6904 -hda 
/home/win7_kvmgt.img -bios /usr/bin/bios.bin -enable-kvm -k en-us -vga qxl 
-display egl-headless -spice disable-ticketing,port=6904,streaming-video=all 
-machine kernel_irqchip=on,usb=on -global PIIX4_PM.disable_s3=1 -global 
PIIX4_PM.disable_s4=1 -cpu host -device usb-tablet

  BTW, guest windows display card is QXL driver.
  But the following full command line used to launch the QEMU guest is OK. For 
comparison, I pasted it below (Just add vdagent and spicevmc in the command 
line to make sure spice service and agent is running in the guest windows):
  # /usr/bin/qemu-system-x86_64 -m 4096 -smp 2 -M pc -name win7-6904 -hda 
/home/win7_kvmgt.img -bios /usr/bin/bios.bin -enable-kvm -k en-us -vga qxl 
-display egl-headless -spice disable-ticketing,port=6904,streaming-video=all 
-machine kernel_irqchip=on,usb=on -global PIIX4_PM.disable_s3=1 -global 
PIIX4_PM.disable_s4=1 -cpu host -device usb-tablet -device 
virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -chardev 
spicevmc,name=vdagent,id=vdagent -device 
virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0

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

[Bug 1779120] Re: disk missing in the guest contingently when hotplug several virtio scsi disks consecutively

[Launchpad Bug Tracker]

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

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

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

Title:
  disk missing in the guest contingently when hotplug several virtio
  scsi disks consecutively

Status in QEMU:
  Expired

Bug description:
  Hi, I found a bug that disk missing (not all disks missing ) in the
  guest contingently when hotplug several virtio scsi disks
  consecutively.  After rebooting the guest,the missing disks appear
  again.

  The guest is centos7.3 running on a centos7.3 host and the scsi
  controllers are configed with iothread.  The scsi controller xml is
  below:

  
    
    
    
  

  If the scsi controllers are configed without iothread,  disks are all
  can be seen in the guest when hotplug several virtio scsi disks
  consecutively.

  I think the biggest difference between them is that scsi controllers
  with iothread call virtio_notify_irqfd to notify guest and scsi
  controllers without iothread call virtio_notify instead.  What make it
  difference? Will interrupts are lost when call virtio_notify_irqfd
  due to  race condition for some unknow reasons? Maybe guys more
  familiar with scsi dataplane can help. Thanks for your reply!

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

[Bug 1794285] Re: 100% Host CPU usage while guest idling

[Launchpad Bug Tracker]

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

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

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

Title:
  100% Host CPU usage while guest idling

Status in QEMU:
  Expired

Bug description:
  Hi,

  We have an appliance that runs a FreeBSD guest on a Yocto-based host via 
qemu-system-x86_64.
  Everything functions fine however the host uses n00% of the CPU (where n = 
#smp) and RAM allocated to it whilst the 1 guest is sat nearing idle.

  Host:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  4406root  20   0 16.7g  16g  26m S  500 53.0  17958:38 qemu-system-x86

  Guest:
  CPU 0:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
  CPU 1:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
  CPU 2:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
  CPU 3:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
  CPU 4:  0.4% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.6% idle
  Mem: 43M Active, 4783M Inact, 1530M Wired, 911M Buf, 9553M Free
  Swap: 3072M Total, 3072M Free

  I have logged this with the appliance vendor and received the response:
  "This is expected behaviour and you will see the same in any case where a 
Guest OS runs over a Host OS.
  Host here has 5 CPUs and it has assigned all of them to Guest. 
  Since the Host is not being shared by any Guest OS; you will always see the 
500% (or the 5 CPUs) given to qemu-system-x86.
  I do see the same in lab and is very much expected"

  This feels fundamentally wrong to me.
  I'm somewhat limited by what can be tested due to the nature of this being an 
appliance rather than a mainstream distro.

  I'm looking for feedback that I can use to push the vendor into
  investigating this issue.

  Versions below.

  Many thanks,
  Gareth


  Host:
  Linux 204a-node 3.10.100-ovp-rt110-WR6.0.0.31_preempt-rt #1 SMP Fri
  Aug 3 01:59:01 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux

  Qemu:
  QEMU emulator version 1.7.2, Copyright (c) 2003-2008 Fabrice Bellard

  Command:
  (Vendor identifying information has been removed)

  /usr/bin/qemu-system-x86_64 \
  -name REMOVED \
  -S \
  -machine pc-i440fx-1.7,accel=kvm,usb=off \
  -m 16384 \
  -realtime mlock=on \
  -smp 5,sockets=5,cores=1,threads=1 \
  -uuid 76277b29-3bd4-4dd4-a705-ed34d6449d6d \
  -nographic \
  -no-user-config \
  -nodefaults \
  -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/REMOVED.monitor,server,nowait \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=utc \
  -no-shutdown \
  -boot strict=on \
  -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
  -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x17 \
  -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 \
  -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=REMOVED,bus=pci.0,addr=0x11 \
  -netdev 
tap,ifname=tap1,script=/etc/vehostd/XXX-em3-ifup,id=hostnet1,vhost=on,vhostfd=24
 \
  -device 
virtio-net-pci,netdev=hostnet1,id=net1,mac=REMOVED,bus=pci.0,addr=0x12 \
  -netdev 
tap,ifname=tap2,script=/etc/vehostd/REMOVED-em4-ifup-SUMMIT,id=hostnet2,vhost=on,vhostfd=25
 \
  -device 
virtio-net-pci,netdev=hostnet2,id=net2,mac=REMOVED,bus=pci.0,addr=0x1c \
  -netdev 
tap,ifname=tap3,script=/etc/vehostd/REMOVED-em4-re-re-ifup,id=hostnet3,vhost=on,vhostfd=26
 \
  -device 
virtio-net-pci,netdev=hostnet3,id=net3,mac=REMOVED,bus=pci.0,addr=0x1d \
  -chardev pty,id=charserial0 \
  -device isa-serial,chardev=charserial0,id=serial0 \
  -chardev tty,id=charserial1,path=/dev/ttyS1 \
  -device isa-serial,chardev=charserial1,id=serial1 \
  -chardev tty,id=charserial2,path=/dev/ttyS2 \
  -device isa-serial,chardev=charserial2,id=serial2 \
  -chardev tty,id=charserial3,path=/dev/ttyS3 \
  -device isa-serial,chardev=charserial3,id=serial3 \
  -device i6300esb,id=watchdog0,bus=pci.0,addr=0x10 \
  -watchdog-action reset \
  -object rng-random,id=rng0,filename=/dev/random \
  -device 
virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x1e \
  -smbios type=0,vendor="INSYDE 
Corp.",version=REMOVED,date=11/03/2017,release=1.00 \
  -smbios 
type=1,manufacturer=REMOVED,product=REMOVED,version=REMOVED,serial=VF-NET \
  -device REMOVED-pci,host=:1c:00.0 \
  -device kvm-pci-assign,host=:00:14.0 \
  -device pci-hgcommdev,vmindex=0,bus=pci.0,addr=0x16 \
  -drive 
file=/REMOVED/REMOVED-current.img,if=none,id=drive-virtio-disk0,format=raw,cache=directsync,aio=native
 \
  -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x13,drive=drive-virtio-disk0,id=virtio-disk0,config-wce=off,x-data-plane=on,bootindex=1
 \
  -drive 
file=/REMOVED/REMOVED-var-config.img,if=none,id=drive-virtio-disk1,format=raw,cache=directsync,aio=native
 \
  -device 

[Bug 1795799] Re: Cirrus video, graphical corruption, bad fonts

[Launchpad Bug Tracker]

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

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

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

Title:
  Cirrus video, graphical corruption, bad fonts

Status in QEMU:
  Expired

Bug description:
  The error
  ===

  I started qemu by

  `shell
  $ ./qemu-system-i386 -serial stdio -cdrom /dev/cdrom -vga cirrus
  S11S11S11S11▒*n*n*n*n
  `

  with the original suse7.0 cd 1 in the cdrom drive (I think
  https://archive.org/details/suse-7.0_release_i386 has the image).
  After some console output (that uses a vga framebuffer which seems to
  work fine) the suse installer is started. It is displayed mostly
  correct, but several text passages are completely garbled.

  I noticed the same type of corruption when trying to run an old XF86
  SVGA Server on a SuSE 6.2 System using the `-vga cirrus` option.

  Therefore I think that the cirrus emulation might not work as intended
  any more.

  Qemu version
  ===

  I used  qemu-w64-setup-20180815.exe provided by
  https://qemu.weilnetz.de/w64/

  ./qemu-system-i386 -version
  QEMU emulator version 3.0.0 (v3.0.0-11723-ge2ddcc5879-dirty)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  Hope you can fix it.

  Best regards!

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

[Bug 1793791] Re: Crash with nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed

[Launchpad Bug Tracker]

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

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

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

Title:
  Crash with nbd_reply_chunk_iter_receive: Assertion `chunk->flags &
  NBD_REPLY_FLAG_DONE' failed

Status in QEMU:
  Expired

Bug description:
  Qemu version on both sides: 2.12.1
  Host A Linux: 4.9.76
  Host B Linux: 4.14.67

  While calling from Host A:
  virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource 
--persistent --verbose --copy-storage-all

  I get a qemu crash with:

  2018-09-21 16:12:23.073+: 14428: info : virObjectUnref:350 : 
OBJECT_UNREF: obj=0x7f922c03d990
  qemu-system-x86_64: block/nbd-client.c:606: nbd_reply_chunk_iter_receive: 
Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed.
  2018-09-21 16:12:41.230+: shutting down, reason=crashed
  2018-09-21 16:12:52.900+: shutting down, reason=failed

  It doesn't do it every time, but most of the time.

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

[Bug 1792193] Re: AMD Athlon(tm) X2 Dual-Core QL-64 bug

[Launchpad Bug Tracker]

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

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

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

Title:
  AMD Athlon(tm) X2 Dual-Core QL-64 bug

Status in QEMU:
  Expired

Bug description:
  I upgrade my qemu 2.12.0-2 => 3.0.0-1. After that I can't load virtual 
machine with "-cpu host" option. Full command line is
  qemu-system-x86_64 \
-monitor stdio \
-enable-kvm \
-cpu host \
-smp cpus=2 \
-m 1G \
-vga virtio \
-display gtk,gl=on \
-soundhw ac97 \
-drive 
file=/ehdd/qemu/arch_hw_12_08_2018/arch_shrinked.raw,format=raw,if=virtio
  I have Arch Linux on virtual machine. When I start QEMU, GRUB tries to load 
initial ramdisk and stops. System doesn't load. If I try to start virtual 
machine with "-cpu athlon" option then get the same bug.
  I downgrade back to qemu 2.12.0-2 and virtual machine works fine, system 
loads.
  My processor is AMD Athlon(tm) X2 Dual-Core QL-64.

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

[Bug 1903833] Re: User mode qemu-aarch: SIGGSEGV signal handler works wrong

[Launchpad Bug Tracker]

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

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

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

Title:
  User mode qemu-aarch: SIGGSEGV signal handler works wrong

Status in QEMU:
  Expired

Bug description:
  I have a user mode qemu-aarch issue. Program with SIGSEGV signal handler 
works wrong under qemu-aarch: 
  once the progam handles the SEGV signal, qemu marks the program's page 
protected, and signal handler gets SEGV on each subsequent memory access 
instruction within a program.

  The issue is reproduced on WSL Ubuntu 20.04 under Windows 10, qemu-aarch64 
version 5.1.50
  The issue is also reproducible on the latest upstream qemu-aarch build.

  The following workaround disables mprotect call and fixes the issue:
  
https://github.com/BorisUlasevich/qemu/commit/3063d9a64f8395185d65c6b6710d28ee92cd8be5

  The issue can be reproduced on OpenJDK which reports SIGSEGV
  immediately after start. The small reproducer program is attached.

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

[Bug 1796816] Re: Wrong keyboard in QEMU Windows for OpenSUSE PowerPC

[Launchpad Bug Tracker]

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

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

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

Title:
  Wrong keyboard in QEMU Windows for OpenSUSE PowerPC

Status in QEMU:
  Expired

Bug description:
  I am trying to run an OpenSUSE PowerPC Little Endian system under Microsoft 
Windows. I have an English UK keyboard. The keyboard is basically correct (I 
get a 'pound' sign when I press shift-3) but some of the keys are rendered 
incorrectly. The wrong keys are
  \ renders as # (just right of left hand shift key)
  | renders as ~ (shift-\)
  ' renders as ` (2 keys right of l)
  @ renders as ¬ (shift-')
  # renders as ' (3 keys right of l)
  ~ renders as @ (shift-#)

  QEMU command line was
  >"\Program Files\qemu\qemu-system-ppc64.exe" -hda opensuse.qcow2

  OpenSUSE was installed from
  download.opensuse.org/ports/ppc/tumbleweed/iso/openSUSE-Tumbleweed-
  DVD-ppc64le-Current.iso .

  I am running OpenSUSE in runlevel 3 (no X11).

  I don't really know whether the problem is with QEMU, the Windows port
  of QEMU, or with OpenSUSE Tumbleweed.

  This is with QEMU for Windows 3.0.0 from https://qemu.weilnetz.de/w64/

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

Re: [PATCH] hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30

[David Gibson]

On Tue, Jan 12, 2021 at 02:25:58AM +0100, BALATON Zoltan wrote:
> On Tue, 12 Jan 2021, David Gibson wrote:
> > On Mon, Jan 11, 2021 at 09:30:07PM +, Peter Maydell wrote:
> > > In commit 34d0831f38fd8 the ppc-uic device was added, with a dcr-base
> > > property. The intention was that the default value of dcr-base should be
> > > the one that most of our boards need, so that in the common case they
> > > don't need to specify a property value.
> > > 
> > > All QEMU boards with a UIC use a dcr-base of 0xc0, with the exception of
> > > sam460ex which has four UICs and so puts them at 0xc0, 0xd0, 0xe0, 0xf0.
> > > So 0xc0 is the obvious right choice for the default dcr-base.
> > > 
> > > The board code conversions in commits 0270d74ef88623505 (bamboo) and
> > > c5ac9dc64fa552a6 (virtex_ml507) assumed that default was 0xc0. 
> > > Unfortunately
> > > the actual default in 34d0831f38fd8 was 0x30, by mistake, so the
> > > bamboo and virtex_ml507 boards were broken as they were converted
> > > away from ppcuic_init() (which always specifies the dcr_base property
> > > value explicitly).
> > > 
> > > Set the default dcr-base to 0xc0 as was intended, fixing bamboo and
> > > virtex_ml507.
> > > 
> > > Fixes: 34d0831f38fd8
> > > Reported-by: Nathan Chancellor 
> > > Suggested-by: BALATON Zoltan 
> > > Signed-off-by: Peter Maydell 
> > 
> > Applied, thanks.
> 
> Will you take my series too?
> 
> http://patchwork.ozlabs.org/project/qemu-devel/list/?series=223439

Huh.  I will now I've seen it.

> I've cc'd you but your DNS seems to not return an MX record most of the time
> still so these are bouncing back.

Ugh.  This is weird.  I know the DNS went out for a little while, but
some of your mails have come through, and AFAICT it's been working for
most people most of the time since that incident.  I'm wondering if
something on your side is negative caching for too long.

-- 
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: [for-6.0 v5 06/13] securable guest memory: Decouple kvm_memcrypt_*() helpers from KVM

[David Gibson]

On Mon, Jan 11, 2021 at 07:13:27PM +0100, Philippe Mathieu-Daudé wrote:
> On 12/4/20 6:44 AM, David Gibson wrote:
> > The kvm_memcrypt_enabled() and kvm_memcrypt_encrypt_data() helper functions
> > don't conceptually have any connection to KVM (although it's not possible
> > in practice to use them without it).
> > 
> > They also rely on looking at the global KVMState.  But the same information
> > is available from the machine, and the only existing callers have natural
> > access to the machine state.
> > 
> > Therefore, move and rename them to helpers in securable-guest-memory.h,
> > taking an explicit machine parameter.
> > 
> > Signed-off-by: David Gibson 
> > Reviewed-by: Richard Henderson 
> > ---
> >  accel/kvm/kvm-all.c   | 27 
> >  accel/stubs/kvm-stub.c| 10 
> >  hw/i386/pc_sysfw.c|  6 +++--
> >  include/exec/securable-guest-memory.h | 36 +++
> >  include/sysemu/kvm.h  | 17 -
> >  5 files changed, 40 insertions(+), 56 deletions(-)
> ...
> 
> > +static inline int securable_guest_memory_encrypt(MachineState *machine,
> > +  uint8_t *ptr, uint64_t len)
> > +{
> > +SecurableGuestMemory *sgm = machine->sgm;
> > +
> > +if (sgm) {
> > +SecurableGuestMemoryClass *sgmc = 
> > SECURABLE_GUEST_MEMORY_GET_CLASS(sgm);
> > +
> > +if (sgmc->encrypt_data) {
> 
> Can this ever happen? Maybe use assert(sgmc->encrypt_data) instead?

It's made moot by changes in the next spin.

> 
> Otherwise:
> Reviewed-by: Philippe Mathieu-Daudé 
> 
> > +return sgmc->encrypt_data(sgm, ptr, len);
> > +}
> > +}
> > +
> > +return 1;
> > +}
> 

-- 
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: [for-6.0 v5 03/13] securable guest memory: Handle memory encryption via interface

[David Gibson]

On Fri, Dec 04, 2020 at 02:10:05PM +0100, Cornelia Huck wrote:
> On Fri,  4 Dec 2020 16:44:05 +1100
> David Gibson  wrote:
> 
> > At the moment AMD SEV sets a special function pointer, plus an opaque
> > handle in KVMState to let things know how to encrypt guest memory.
> > 
> > Now that we have a QOM interface for handling things related to securable
> > guest memory, use a QOM method on that interface, rather than a bare
> > function pointer for this.
> > 
> > Signed-off-by: David Gibson 
> > Reviewed-by: Richard Henderson 
> > ---
> >  accel/kvm/kvm-all.c   |  36 +---
> >  accel/kvm/sev-stub.c  |   9 +-
> >  include/exec/securable-guest-memory.h |   2 +
> >  include/sysemu/sev.h  |   5 +-
> >  target/i386/monitor.c |   1 -
> >  target/i386/sev.c | 116 ++
> >  6 files changed, 77 insertions(+), 92 deletions(-)
> > 
> 
> > @@ -224,7 +224,7 @@ int kvm_get_max_memslots(void)
> >  
> >  bool kvm_memcrypt_enabled(void)
> >  {
> > -if (kvm_state && kvm_state->memcrypt_handle) {
> > +if (kvm_state && kvm_state->sgm) {
> 
> If we want to generalize the concept, maybe check for encrypt_data in
> sgm here? There's probably room for different callbacks in the sgm
> structure.

Actually, I've realised this isn't even as general as it pretends to
be now, so I've taken a different approach for the next spin.

> 
> >  return true;
> >  }
> >  
> 

-- 
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: [for-6.0 v5 00/13] Generalize memory encryption models

[David Gibson]

On Fri, Dec 04, 2020 at 09:50:05AM +, Daniel P. Berrangé wrote:
> On Fri, Dec 04, 2020 at 04:44:02PM +1100, David Gibson wrote:
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security impact of a compromised hypervisor.
> > 
> > AMD's SEV implements this with in-cpu memory encryption, and Intel has
> > its own memory encryption mechanism.  POWER has an upcoming mechanism
> > to accomplish this in a different way, using a new memory protection
> > level plus a small trusted ultravisor.  s390 also has a protected
> > execution environment.
> > 
> > The current code (committed or draft) for these features has each
> > platform's version configured entirely differently.  That doesn't seem
> > ideal for users, or particularly for management layers.
> > 
> > AMD SEV introduces a notionally generic machine option
> > "machine-encryption", but it doesn't actually cover any cases other
> > than SEV.
> > 
> > This series is a proposal to at least partially unify configuration
> > for these mechanisms, by renaming and generalizing AMD's
> > "memory-encryption" property.  It is replaced by a
> > "securable-guest-memory" property pointing to a platform specific
> > object which configures and manages the specific details.
> 
> There's no docs updated or added in this series.
> 
> docs/amd-memory-encryption.txt needs an update at least, and
> there ought to be a doc added describing how this series is
> to be used for s390/ppc

Fair point, I've made a bunch of doc updates for the next spin.

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

[PATCH 2/2] hw/mips/loongson3_virt: Add TCG SMP support

[Jiaxun Yang]

loongson3_virt has KVM SMP support in kenrel.
This patch adds TCG SMP support by enable IPI controller
for machine.

Note that TCG SMP can only support up to 4 CPUs as we
didn't implement multi-node support.

Signed-off-by: Jiaxun Yang 
---
 hw/mips/Kconfig   |  1 +
 hw/mips/loongson3_bootp.h |  1 +
 hw/mips/loongson3_virt.c  | 20 +++-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
index aadd436bf4..4fb0cc49e8 100644
--- a/hw/mips/Kconfig
+++ b/hw/mips/Kconfig
@@ -39,6 +39,7 @@ config LOONGSON3V
 select SERIAL
 select GOLDFISH_RTC
 select LOONGSON_LIOINTC
+select LOONGSON_IPI if TCG
 select PCI_DEVICES
 select PCI_EXPRESS_GENERIC_BRIDGE
 select MSI_NONBROKEN
diff --git a/hw/mips/loongson3_bootp.h b/hw/mips/loongson3_bootp.h
index 09f8480abf..4756aa44f6 100644
--- a/hw/mips/loongson3_bootp.h
+++ b/hw/mips/loongson3_bootp.h
@@ -210,6 +210,7 @@ enum {
 VIRT_PCIE_ECAM,
 VIRT_BIOS_ROM,
 VIRT_UART,
+VIRT_IPIS,
 VIRT_LIOINTC,
 VIRT_PCIE_MMIO,
 VIRT_HIGHMEM
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
index d4a82fa536..0684a035b0 100644
--- a/hw/mips/loongson3_virt.c
+++ b/hw/mips/loongson3_virt.c
@@ -35,6 +35,7 @@
 #include "hw/boards.h"
 #include "hw/char/serial.h"
 #include "hw/intc/loongson_liointc.h"
+#include "hw/intc/loongson_ipi.h"
 #include "hw/mips/mips.h"
 #include "hw/mips/cpudevs.h"
 #include "hw/mips/fw_cfg.h"
@@ -59,6 +60,7 @@
 
 #define PM_CNTL_MODE  0x10
 
+#define LOONGSON_TCG_MAX_VCPUS  4
 #define LOONGSON_MAX_VCPUS  16
 
 /*
@@ -71,6 +73,7 @@
 #define UART_IRQ0
 #define RTC_IRQ 1
 #define PCIE_IRQ_BASE   2
+#define IPI_REG_SPACE   0x100
 
 const struct MemmapEntry virt_memmap[] = {
 [VIRT_LOWMEM] =  { 0x,0x1000 },
@@ -81,6 +84,7 @@ const struct MemmapEntry virt_memmap[] = {
 [VIRT_PCIE_ECAM] =   { 0x1a00, 0x200 },
 [VIRT_BIOS_ROM] ={ 0x1fc0,  0x20 },
 [VIRT_UART] ={ 0x1fe001e0,   0x8 },
+[VIRT_IPIS] ={ 0x3ff01000, 0x400 },
 [VIRT_LIOINTC] = { 0x3ff01400,  0x64 },
 [VIRT_PCIE_MMIO] =   { 0x4000,0x4000 },
 [VIRT_HIGHMEM] = { 0x8000,   0x0 }, /* Variable */
@@ -495,6 +499,10 @@ static void mips_loongson3_virt_init(MachineState *machine)
 error_report("Loongson-3/TCG needs cpu type Loongson-3A1000");
 exit(1);
 }
+if (machine->smp.cpus > LOONGSON_TCG_MAX_VCPUS) {
+error_report("Loongson-3/TCG supports up to 4 CPUs");
+exit(1);
+}
 } else {
 if (!machine->cpu_type) {
 machine->cpu_type = MIPS_CPU_TYPE_NAME("Loongson-3A4000");
@@ -545,7 +553,17 @@ static void mips_loongson3_virt_init(MachineState *machine)
 qemu_register_reset(main_cpu_reset, cpu);
 
 if (i >= 4) {
-continue; /* Only node-0 can be connected to LIOINTC */
+continue; /* Only node-0 can be connected to LIOINTC and IPI */
+}
+
+if (!kvm_enabled()) {
+/* IPI is handled by kernel for KVM */
+DeviceState *ipi;
+ipi = qdev_new(TYPE_LOONGSON_IPI);
+sysbus_realize_and_unref(SYS_BUS_DEVICE(ipi), _fatal);
+sysbus_mmio_map(SYS_BUS_DEVICE(ipi), 0,
+virt_memmap[VIRT_IPIS].base + IPI_REG_SPACE * i);
+sysbus_connect_irq(SYS_BUS_DEVICE(ipi), 0, cpu->env.irq[6]);
 }
 
 for (ip = 0; ip < 4 ; ip++) {
-- 
2.30.0

[PATCH 1/2] hw/intc: Add Loongson Inter Processor Interrupt controller

[Jiaxun Yang]

Loongson IPI controller is a MMIO based simple level triggered
interrupt controller. It will trigger IRQ to it's upstream
processor when set register is written.

It also has 8 32bit mailboxes to pass boot information to
secondary processor.

Signed-off-by: Jiaxun Yang 
---
 hw/intc/Kconfig|   3 +
 hw/intc/loongson_ipi.c | 146 +
 hw/intc/meson.build|   1 +
 include/hw/intc/loongson_ipi.h |  20 +
 4 files changed, 170 insertions(+)
 create mode 100644 hw/intc/loongson_ipi.c
 create mode 100644 include/hw/intc/loongson_ipi.h

diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig
index c18d11142a..0e15102662 100644
--- a/hw/intc/Kconfig
+++ b/hw/intc/Kconfig
@@ -59,6 +59,9 @@ config RX_ICU
 config LOONGSON_LIOINTC
 bool
 
+config LOONGSON_IPI
+bool
+
 config SIFIVE_CLINT
 bool
 
diff --git a/hw/intc/loongson_ipi.c b/hw/intc/loongson_ipi.c
new file mode 100644
index 00..7246f05f9e
--- /dev/null
+++ b/hw/intc/loongson_ipi.c
@@ -0,0 +1,146 @@
+/*
+ * QEMU Loongson Inter Processor Interrupt Controller
+ *
+ * Copyright (c) 2020-2021 Jiaxun Yang 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "qemu/module.h"
+#include "qemu/log.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/intc/loongson_ipi.h"
+
+#define R_ISR   0
+#define R_IEN   1
+#define R_SET   2
+#define R_CLR   3
+/* No register between 0x10~0x20 */
+#define R_MBOX0 8
+#define NUM_MBOX8
+#define R_END   16
+
+struct loongson_ipi {
+SysBusDevice parent_obj;
+
+MemoryRegion mmio;
+qemu_irq parent_irq;
+
+uint32_t isr;
+uint32_t ien;
+uint32_t mbox[NUM_MBOX];
+};
+
+static uint64_t
+ipi_read(void *opaque, hwaddr addr, unsigned int size)
+{
+struct loongson_ipi *p = opaque;
+uint64_t r = 0;
+
+addr >>= 2;
+switch (addr) {
+case R_ISR:
+r = p->isr;
+break;
+case R_IEN:
+r = p->ien;
+break;
+case R_MBOX0 ... (R_END - 1):
+r = p->mbox[addr - R_MBOX0];
+break;
+default:
+break;
+}
+
+qemu_log_mask(CPU_LOG_INT,
+  "%s: size=%d, addr=%"HWADDR_PRIx", val=%"PRIx64"\n",
+  __func__, size, addr, r);
+
+return r;
+}
+
+static void
+ipi_write(void *opaque, hwaddr addr,
+  uint64_t val64, unsigned int size)
+{
+struct loongson_ipi *p = opaque;
+uint32_t value = val64;
+
+addr >>= 2;
+switch (addr) {
+case R_ISR:
+/* Do nothing */
+break;
+case R_IEN:
+p->ien = value;
+break;
+case R_SET:
+p->isr |= value;
+break;
+case R_CLR:
+p->isr &= ~value;
+break;
+case R_MBOX0 ... (R_END - 1):
+p->mbox[addr - R_MBOX0] = value;
+break;
+default:
+break;
+}
+p->isr &= p->ien;
+
+qemu_log_mask(CPU_LOG_INT,
+  "%s: size=%d, addr=%"HWADDR_PRIx", val=%"PRIx32"\n",
+  __func__, size, addr, value);
+
+qemu_set_irq(p->parent_irq, !!p->isr);
+}
+
+static const MemoryRegionOps pic_ops = {
+.read = ipi_read,
+.write = ipi_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid = {
+.min_access_size = 4,
+.max_access_size = 4
+}
+};
+
+static void loongson_ipi_init(Object *obj)
+{
+struct loongson_ipi *p = LOONGSON_IPI(obj);
+
+sysbus_init_irq(SYS_BUS_DEVICE(obj), >parent_irq);
+
+memory_region_init_io(>mmio, obj, _ops, p, "loongson.ipi",
+  R_END * 4);
+sysbus_init_mmio(SYS_BUS_DEVICE(obj), >mmio);
+}
+
+static const TypeInfo loongson_ipi_info = {
+.name  = TYPE_LOONGSON_IPI,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(struct loongson_ipi),
+.instance_init = loongson_ipi_init,
+};
+
+static void loongson_ipi_register_types(void)
+{
+type_register_static(_ipi_info);
+}
+
+type_init(loongson_ipi_register_types)
diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 53cba11569..5257c5fb94 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -36,6 +36,7 @@ specific_ss.add(when: 'CONFIG_GRLIB', if_true: 
files('grlib_irqmp.c'))
 specific_ss.add(when: 'CONFIG_IBEX', if_true: files('ibex_plic.c'))
 specific_ss.add(when: 

[PATCH 0/2] hw/mips/loongson3_virt: Add TCG SMP support

[Jiaxun Yang]

Now it can boot with SMP.
TCG SMP appears to be extremely slow that the boot time
extended for about 3 times.
Also I tried to enable MTTCG for mips64el but system get
stucked at boot.

Jiaxun Yang (2):
  hw/intc: Add Loongson Inter Processor Interrupt controller
  hw/mips/loongson3_virt: Add TCG SMP support

 hw/intc/Kconfig|   3 +
 hw/intc/loongson_ipi.c | 146 +
 hw/intc/meson.build|   1 +
 hw/mips/Kconfig|   1 +
 hw/mips/loongson3_bootp.h  |   1 +
 hw/mips/loongson3_virt.c   |  20 -
 include/hw/intc/loongson_ipi.h |  20 +
 7 files changed, 191 insertions(+), 1 deletion(-)
 create mode 100644 hw/intc/loongson_ipi.c
 create mode 100644 include/hw/intc/loongson_ipi.h

-- 
2.30.0

Re: [PATCH] scsi: allow user to set werror as report

[Zihao Chang]

Ping again? Another month has passed, whose tree should it go via?
Or did I miss any response?

Thanks
Zihao

On 2020/12/3 17:53, Philippe Mathieu-Daudé wrote:
> On 12/3/20 3:55 AM, Zihao Chang wrote:
>> Ping? This is a fix patch which has been reviewed, whose tree should it go 
>> via?
> 
> The change itself is in-between 'Block layer' and 'SCSI'
> subsystems, so either Paolo or Kevin (Cc'ing qemu-block@).
> 
>>
>> Thanks
>> Zihao
>>
>> On 2020/11/3 22:03, Zihao Chang wrote:
>>>
>>>
>>> On 2020/11/3 18:52, Fam Zheng wrote:
 On Tue, 2020-11-03 at 14:12 +0800, Zihao Chang wrote:
> 'enospc' is the default for -drive, but qemu allows user to set
> drive option werror. If werror of scsi-generic is set to 'report'
> by user, qemu will not allow vm to start.
>
> This patch allow user to set werror as 'report' for scsi-generic.
>
> Signed-off-by: Zihao Chang 
> ---
>  hw/scsi/scsi-generic.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
> index 2cb23ca891..2730e37d63 100644
> --- a/hw/scsi/scsi-generic.c
> +++ b/hw/scsi/scsi-generic.c
> @@ -664,7 +664,8 @@ static void scsi_generic_realize(SCSIDevice *s,
> Error **errp)
>  return;
>  }
>  
> -if (blk_get_on_error(s->conf.blk, 0) !=
> BLOCKDEV_ON_ERROR_ENOSPC) {
> +if (blk_get_on_error(s->conf.blk, 0) != BLOCKDEV_ON_ERROR_ENOSPC
> &&
> +blk_get_on_error(s->conf.blk, 0) !=
> BLOCKDEV_ON_ERROR_REPORT) {
>  error_setg(errp, "Device doesn't support drive option
> werror");
>  return;
>  }

 Accepting the report sounds sane to me, it matches what we actually
 (always) do. Is the idea to allow users to spell it out explicitly in
 the command line?

>>> Actually, qemu supports user to spell it out explicitly in the command
>>> line like "enospc", "report" & "action". This patch just allows user to
>>> set werror as "report" for scsi-generic, which is a common scenario.
>>>
 Reviewed-by: Fam Zheng 

 .

>>
> 
> .
> 

[RFC v3 12/16] target/riscv: rvb: generalized reverse

[frank . chang]

From: Frank Chang 

Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/bitmanip_helper.c  | 71 +
 target/riscv/helper.h   |  7 +++
 target/riscv/insn32-64.decode   |  2 +
 target/riscv/insn32.decode  |  2 +
 target/riscv/insn_trans/trans_rvb.c.inc | 29 ++
 target/riscv/meson.build|  1 +
 target/riscv/translate.c| 28 ++
 7 files changed, 140 insertions(+)
 create mode 100644 target/riscv/bitmanip_helper.c

diff --git a/target/riscv/bitmanip_helper.c b/target/riscv/bitmanip_helper.c
new file mode 100644
index 000..1d3235bc0d6
--- /dev/null
+++ b/target/riscv/bitmanip_helper.c
@@ -0,0 +1,71 @@
+/*
+ * RISC-V Bitmanip Extension Helpers for QEMU.
+ *
+ * Copyright (c) 2020 Kito Cheng, kito.ch...@sifive.com
+ * Copyright (c) 2020 Frank Chang, frank.ch...@sifive.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/host-utils.h"
+#include "exec/exec-all.h"
+#include "exec/helper-proto.h"
+#include "tcg/tcg.h"
+
+static const uint64_t adjacent_masks[] = {
+dup_const(MO_8, 0x55),
+dup_const(MO_8, 0x33),
+dup_const(MO_8, 0x0f),
+dup_const(MO_16, 0xff),
+dup_const(MO_32, 0x),
+#ifdef TARGET_RISCV64
+UINT32_MAX
+#endif
+};
+
+static inline target_ulong do_swap(target_ulong x, uint64_t mask, int shift)
+{
+return ((x & mask) << shift) | ((x & ~mask) >> shift);
+}
+
+static target_ulong do_grev(target_ulong rs1,
+target_ulong rs2,
+int bits)
+{
+target_ulong x = rs1;
+int i, shift;
+
+for (i = 0, shift = 1; shift < bits; i++, shift <<= 1) {
+if (rs2 & shift) {
+x = do_swap(x, adjacent_masks[i], shift);
+}
+}
+
+return x;
+}
+
+target_ulong HELPER(grev)(target_ulong rs1, target_ulong rs2)
+{
+return do_grev(rs1, rs2, TARGET_LONG_BITS);
+}
+
+/* RV64-only instruction */
+#ifdef TARGET_RISCV64
+
+target_ulong HELPER(grevw)(target_ulong rs1, target_ulong rs2)
+{
+return do_grev(rs1, rs2, 32);
+}
+
+#endif
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index e3f3f41e891..db8b770f1aa 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -58,6 +58,13 @@ DEF_HELPER_FLAGS_2(fcvt_d_l, TCG_CALL_NO_RWG, i64, env, i64)
 DEF_HELPER_FLAGS_2(fcvt_d_lu, TCG_CALL_NO_RWG, i64, env, i64)
 DEF_HELPER_FLAGS_1(fclass_d, TCG_CALL_NO_RWG_SE, tl, i64)
 
+/* Bitmanip */
+DEF_HELPER_FLAGS_2(grev, TCG_CALL_NO_RWG_SE, tl, tl, tl)
+
+#if defined(TARGET_RISCV64)
+DEF_HELPER_FLAGS_2(grevw, TCG_CALL_NO_RWG_SE, tl, tl, tl)
+#endif
+
 /* Special functions */
 DEF_HELPER_3(csrrw, tl, env, tl, tl)
 DEF_HELPER_4(csrrs, tl, env, tl, tl, tl)
diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 8f9ba21b352..38ceadd4553 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -102,6 +102,7 @@ slow   001 .. 001 . 0111011 @r
 srow   001 .. 101 . 0111011 @r
 rorw   011 .. 101 . 0111011 @r
 rolw   011 .. 001 . 0111011 @r
+grevw  0110100 .. 101 . 0111011 @r
 
 bsetiw 0010100 .. 001 . 0011011 @sh5
 bclriw 0100100 .. 001 . 0011011 @sh5
@@ -109,3 +110,4 @@ binviw 0110100 .. 001 . 0011011 @sh5
 sloiw  001 .. 001 . 0011011 @sh5
 sroiw  001 .. 101 . 0011011 @sh5
 roriw  011 .. 101 . 0011011 @sh5
+greviw 0110100 .. 101 . 0011011 @sh5
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 6d1b604c800..fa4bba4f0ee 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -619,6 +619,7 @@ slo001 .. 001 . 0110011 @r
 sro001 .. 101 . 0110011 @r
 ror011 .. 101 . 0110011 @r
 rol011 .. 001 . 0110011 @r
+grev   0110100 .. 101 . 0110011 @r
 
 bseti  00101. ... 001 . 0010011 @sh
 bclri  01001. ... 001 . 0010011 @sh
@@ -627,3 +628,4 @@ bexti  01001. ... 101 . 0010011 @sh
 sloi   00100. ... 001 . 0010011 @sh
 sroi   00100. ... 101 . 0010011 @sh
 rori   01100. ... 

[RFC v3 10/16] target/riscv: rvb: shift ones

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32-64.decode   |  4 +++
 target/riscv/insn32.decode  |  4 +++
 target/riscv/insn_trans/trans_rvb.c.inc | 48 +
 target/riscv/translate.c| 14 
 4 files changed, 70 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index f6c63c31b03..8c3ed33077e 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -98,7 +98,11 @@ bsetw  0010100 .. 001 . 0111011 @r
 bclrw  0100100 .. 001 . 0111011 @r
 binvw  0110100 .. 001 . 0111011 @r
 bextw  0100100 .. 101 . 0111011 @r
+slow   001 .. 001 . 0111011 @r
+srow   001 .. 101 . 0111011 @r
 
 bsetiw 0010100 .. 001 . 0011011 @sh5
 bclriw 0100100 .. 001 . 0011011 @sh5
 binviw 0110100 .. 001 . 0011011 @sh5
+sloiw  001 .. 001 . 0011011 @sh5
+sroiw  001 .. 101 . 0011011 @sh5
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 64d2b057764..0ea92312372 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -615,8 +615,12 @@ bset   0010100 .. 001 . 0110011 @r
 bclr   0100100 .. 001 . 0110011 @r
 binv   0110100 .. 001 . 0110011 @r
 bext   0100100 .. 101 . 0110011 @r
+slo001 .. 001 . 0110011 @r
+sro001 .. 101 . 0110011 @r
 
 bseti  00101. ... 001 . 0010011 @sh
 bclri  01001. ... 001 . 0010011 @sh
 binvi  01101. ... 001 . 0010011 @sh
 bexti  01001. ... 101 . 0010011 @sh
+sloi   00100. ... 001 . 0010011 @sh
+sroi   00100. ... 101 . 0010011 @sh
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 0c41f135dc6..44f9f639240 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -155,6 +155,30 @@ static bool trans_bexti(DisasContext *ctx, arg_bexti *a)
 return gen_shifti(ctx, a, gen_bext);
 }
 
+static bool trans_slo(DisasContext *ctx, arg_slo *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_slo);
+}
+
+static bool trans_sloi(DisasContext *ctx, arg_sloi *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_slo);
+}
+
+static bool trans_sro(DisasContext *ctx, arg_sro *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_sro);
+}
+
+static bool trans_sroi(DisasContext *ctx, arg_sroi *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_sro);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -230,4 +254,28 @@ static bool trans_bextw(DisasContext *ctx, arg_bextw *a)
 return gen_shiftw(ctx, a, gen_bext);
 }
 
+static bool trans_slow(DisasContext *ctx, arg_slow *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_slo);
+}
+
+static bool trans_sloiw(DisasContext *ctx, arg_sloiw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_slo);
+}
+
+static bool trans_srow(DisasContext *ctx, arg_srow *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_sro);
+}
+
+static bool trans_sroiw(DisasContext *ctx, arg_sroiw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_sro);
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 7ea434ffa8d..678c3dca81f 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -776,6 +776,20 @@ static void gen_bext(TCGv ret, TCGv arg1, TCGv shamt)
 tcg_gen_andi_tl(ret, ret, 1);
 }
 
+static void gen_slo(TCGv ret, TCGv arg1, TCGv arg2)
+{
+tcg_gen_not_tl(ret, arg1);
+tcg_gen_shl_tl(ret, ret, arg2);
+tcg_gen_not_tl(ret, ret);
+}
+
+static void gen_sro(TCGv ret, TCGv arg1, TCGv arg2)
+{
+tcg_gen_not_tl(ret, arg1);
+tcg_gen_shr_tl(ret, ret, arg2);
+tcg_gen_not_tl(ret, ret);
+}
+
 #ifdef TARGET_RISCV64
 
 static void gen_ctzw(TCGv ret, TCGv arg1)
-- 
2.17.1

[RFC v3 15/16] target/riscv: rvb: add/shift with prefix zero-extend

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32-64.decode   |  3 +++
 target/riscv/insn_trans/trans_rvb.c.inc | 22 ++
 target/riscv/translate.c|  6 ++
 3 files changed, 31 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 2f80b0c07ae..01b28718af5 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -107,6 +107,7 @@ gorcw  0010100 .. 101 . 0111011 @r
 sh1add_uw  001 .. 010 . 0111011 @r
 sh2add_uw  001 .. 100 . 0111011 @r
 sh3add_uw  001 .. 110 . 0111011 @r
+add_uw 100 .. 000 . 0111011 @r
 
 bsetiw 0010100 .. 001 . 0011011 @sh5
 bclriw 0100100 .. 001 . 0011011 @sh5
@@ -116,3 +117,5 @@ sroiw  001 .. 101 . 0011011 @sh5
 roriw  011 .. 101 . 0011011 @sh5
 greviw 0110100 .. 101 . 0011011 @sh5
 gorciw 0010100 .. 101 . 0011011 @sh5
+
+slli_uw1. ... 001 . 0011011 @sh
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index ca987f2705f..94fcf822a36 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -390,4 +390,26 @@ GEN_TRANS_SHADD_UW(1)
 GEN_TRANS_SHADD_UW(2)
 GEN_TRANS_SHADD_UW(3)
 
+static bool trans_add_uw(DisasContext *ctx, arg_add_uw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, gen_add_uw);
+}
+
+static bool trans_slli_uw(DisasContext *ctx, arg_slli_uw *a)
+{
+TCGv source1 = tcg_temp_new();
+gen_get_gpr(source1, a->rs1);
+
+if (a->shamt < 32) {
+tcg_gen_deposit_z_i64(source1, source1, a->shamt, 32);
+} else {
+tcg_gen_shli_i64(source1, source1, a->shamt);
+}
+
+gen_set_gpr(a->rd, source1);
+tcg_temp_free(source1);
+return true;
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 7365e591eb7..dbcc15ed73f 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -930,6 +930,12 @@ GEN_SHADD_UW(1)
 GEN_SHADD_UW(2)
 GEN_SHADD_UW(3)
 
+static void gen_add_uw(TCGv ret, TCGv arg1, TCGv arg2)
+{
+tcg_gen_ext32u_tl(arg1, arg1);
+tcg_gen_add_tl(ret, arg1, arg2);
+}
+
 #endif
 
 static bool gen_arith(DisasContext *ctx, arg_r *a,
-- 
2.17.1

[RFC v3 09/16] target/riscv: rvb: single-bit instructions

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
---
 target/riscv/insn32-64.decode   |  8 +++
 target/riscv/insn32.decode  |  9 +++
 target/riscv/insn_trans/trans_rvb.c.inc | 90 +
 target/riscv/translate.c| 61 +
 4 files changed, 168 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index d28c0bcf2c1..f6c63c31b03 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -94,3 +94,11 @@ cpopw  011 00010 . 001 . 0011011 @r2
 
 packw  100 .. 100 . 0111011 @r
 packuw 0100100 .. 100 . 0111011 @r
+bsetw  0010100 .. 001 . 0111011 @r
+bclrw  0100100 .. 001 . 0111011 @r
+binvw  0110100 .. 001 . 0111011 @r
+bextw  0100100 .. 101 . 0111011 @r
+
+bsetiw 0010100 .. 001 . 0011011 @sh5
+bclriw 0100100 .. 001 . 0011011 @sh5
+binviw 0110100 .. 001 . 0011011 @sh5
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 938c23088eb..64d2b057764 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -611,3 +611,12 @@ min101 .. 100 . 0110011 @r
 minu   101 .. 101 . 0110011 @r
 max101 .. 110 . 0110011 @r
 maxu   101 .. 111 . 0110011 @r
+bset   0010100 .. 001 . 0110011 @r
+bclr   0100100 .. 001 . 0110011 @r
+binv   0110100 .. 001 . 0110011 @r
+bext   0100100 .. 101 . 0110011 @r
+
+bseti  00101. ... 001 . 0010011 @sh
+bclri  01001. ... 001 . 0010011 @sh
+binvi  01101. ... 001 . 0010011 @sh
+bexti  01001. ... 101 . 0010011 @sh
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 1496996a660..0c41f135dc6 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -107,6 +107,54 @@ static bool trans_sext_h(DisasContext *ctx, arg_sext_h *a)
 return gen_unary(ctx, a, tcg_gen_ext16s_tl);
 }
 
+static bool trans_bset(DisasContext *ctx, arg_bset *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_bset);
+}
+
+static bool trans_bseti(DisasContext *ctx, arg_bseti *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_bset);
+}
+
+static bool trans_bclr(DisasContext *ctx, arg_bclr *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_bclr);
+}
+
+static bool trans_bclri(DisasContext *ctx, arg_bclri *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_bclr);
+}
+
+static bool trans_binv(DisasContext *ctx, arg_binv *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_binv);
+}
+
+static bool trans_binvi(DisasContext *ctx, arg_binvi *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_binv);
+}
+
+static bool trans_bext(DisasContext *ctx, arg_bext *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_bext);
+}
+
+static bool trans_bexti(DisasContext *ctx, arg_bexti *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_bext);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -140,4 +188,46 @@ static bool trans_packuw(DisasContext *ctx, arg_packuw *a)
 return gen_arith(ctx, a, gen_packuw);
 }
 
+static bool trans_bsetw(DisasContext *ctx, arg_bsetw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_bset);
+}
+
+static bool trans_bsetiw(DisasContext *ctx, arg_bsetiw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_bset);
+}
+
+static bool trans_bclrw(DisasContext *ctx, arg_bclrw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_bclr);
+}
+
+static bool trans_bclriw(DisasContext *ctx, arg_bclriw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_bclr);
+}
+
+static bool trans_binvw(DisasContext *ctx, arg_binvw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_binv);
+}
+
+static bool trans_binviw(DisasContext *ctx, arg_binviw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_binv);
+}
+
+static bool trans_bextw(DisasContext *ctx, arg_bextw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_bext);
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 8459b6bcf54..7ea434ffa8d 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -734,6 +734,48 @@ static void gen_packh(TCGv ret, TCGv arg1, TCGv arg2)
 tcg_temp_free(t);
 }
 
+static void gen_sbop_mask(TCGv ret, TCGv shamt)
+{
+tcg_gen_movi_tl(ret, 1);
+tcg_gen_shl_tl(ret, ret, shamt);
+}
+
+static void gen_bset(TCGv ret, TCGv arg1, TCGv shamt)
+{
+TCGv t = tcg_temp_new();
+
+

[RFC v3 05/16] target/riscv: rvb: pack two words into one register

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32-64.decode   |  3 ++
 target/riscv/insn32.decode  |  3 ++
 target/riscv/insn_trans/trans_rvb.c.inc | 30 +++
 target/riscv/translate.c| 40 +
 4 files changed, 76 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 89498a9a28a..d28c0bcf2c1 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -91,3 +91,6 @@ hsv_d 0110111  .   . 100 0 1110011 @r2_s
 clzw   011 0 . 001 . 0011011 @r2
 ctzw   011 1 . 001 . 0011011 @r2
 cpopw  011 00010 . 001 . 0011011 @r2
+
+packw  100 .. 100 . 0111011 @r
+packuw 0100100 .. 100 . 0111011 @r
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index d0b3f109b4e..7f32b8c6d15 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -602,3 +602,6 @@ cpop   011000 10 . 001 . 0010011 @r2
 andn   010 .. 111 . 0110011 @r
 orn010 .. 110 . 0110011 @r
 xnor   010 .. 100 . 0110011 @r
+pack   100 .. 100 . 0110011 @r
+packu  0100100 .. 100 . 0110011 @r
+packh  100 .. 111 . 0110011 @r
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 73c4693a263..2d24dafac09 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -53,6 +53,24 @@ static bool trans_xnor(DisasContext *ctx, arg_xnor *a)
 return gen_arith(ctx, a, tcg_gen_eqv_tl);
 }
 
+static bool trans_pack(DisasContext *ctx, arg_pack *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, gen_pack);
+}
+
+static bool trans_packu(DisasContext *ctx, arg_packu *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, gen_packu);
+}
+
+static bool trans_packh(DisasContext *ctx, arg_packh *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, gen_packh);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -74,4 +92,16 @@ static bool trans_cpopw(DisasContext *ctx, arg_cpopw *a)
 return gen_unary(ctx, a, gen_cpopw);
 }
 
+static bool trans_packw(DisasContext *ctx, arg_packw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, gen_packw);
+}
+
+static bool trans_packuw(DisasContext *ctx, arg_packuw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, gen_packuw);
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 3a14bdba194..53c0c34ce16 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -711,6 +711,29 @@ static bool gen_arith_div_uw(DisasContext *ctx, arg_r *a,
 
 #endif
 
+static void gen_pack(TCGv ret, TCGv arg1, TCGv arg2)
+{
+tcg_gen_deposit_tl(ret, arg1, arg2,
+   TARGET_LONG_BITS / 2,
+   TARGET_LONG_BITS / 2);
+}
+
+static void gen_packu(TCGv ret, TCGv arg1, TCGv arg2)
+{
+TCGv t = tcg_temp_new();
+tcg_gen_shri_tl(t, arg1, TARGET_LONG_BITS / 2);
+tcg_gen_deposit_tl(ret, arg2, t, 0, TARGET_LONG_BITS / 2);
+tcg_temp_free(t);
+}
+
+static void gen_packh(TCGv ret, TCGv arg1, TCGv arg2)
+{
+TCGv t = tcg_temp_new();
+tcg_gen_ext8u_tl(t, arg2);
+tcg_gen_deposit_tl(ret, arg1, t, 8, TARGET_LONG_BITS - 8);
+tcg_temp_free(t);
+}
+
 #ifdef TARGET_RISCV64
 
 static void gen_ctzw(TCGv ret, TCGv arg1)
@@ -732,6 +755,23 @@ static void gen_cpopw(TCGv ret, TCGv arg1)
 tcg_gen_ctpop_tl(ret, arg1);
 }
 
+static void gen_packw(TCGv ret, TCGv arg1, TCGv arg2)
+{
+TCGv t = tcg_temp_new();
+tcg_gen_ext16s_i64(t, arg2);
+tcg_gen_deposit_i64(ret, arg1, t, 16, 48);
+tcg_temp_free(t);
+}
+
+static void gen_packuw(TCGv ret, TCGv arg1, TCGv arg2)
+{
+TCGv t = tcg_temp_new();
+tcg_gen_shri_i64(t, arg1, 16);
+tcg_gen_deposit_i64(ret, arg2, t, 0, 16);
+tcg_gen_ext32s_i64(ret, ret);
+tcg_temp_free(t);
+}
+
 #endif
 
 static bool gen_arith(DisasContext *ctx, arg_r *a,
-- 
2.17.1

[RFC v3 16/16] target/riscv: rvb: support and turn on B-extension from command line

[frank . chang]

From: Kito Cheng 

B-extension is default off, use cpu rv32 or rv64 with x-b=true to
enable B-extension.

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Alistair Francis 
---
 target/riscv/cpu.c | 4 
 target/riscv/cpu.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 8227d7aea9d..7379a0abc6c 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -472,6 +472,9 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 if (cpu->cfg.ext_h) {
 target_misa |= RVH;
 }
+if (cpu->cfg.ext_b) {
+target_misa |= RVB;
+}
 if (cpu->cfg.ext_v) {
 target_misa |= RVV;
 if (!is_power_of_2(cpu->cfg.vlen)) {
@@ -542,6 +545,7 @@ static Property riscv_cpu_properties[] = {
 DEFINE_PROP_BOOL("s", RISCVCPU, cfg.ext_s, true),
 DEFINE_PROP_BOOL("u", RISCVCPU, cfg.ext_u, true),
 /* This is experimental so mark with 'x-' */
+DEFINE_PROP_BOOL("x-b", RISCVCPU, cfg.ext_b, false),
 DEFINE_PROP_BOOL("x-h", RISCVCPU, cfg.ext_h, false),
 DEFINE_PROP_BOOL("x-v", RISCVCPU, cfg.ext_v, false),
 DEFINE_PROP_BOOL("Counters", RISCVCPU, cfg.ext_counters, true),
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 6339e848192..d5271906db4 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -72,6 +72,7 @@
 #define RVS RV('S')
 #define RVU RV('U')
 #define RVH RV('H')
+#define RVB RV('B')
 
 /* S extension denotes that Supervisor mode exists, however it is possible
to have a core that support S mode but does not have an MMU and there
@@ -282,6 +283,7 @@ struct RISCVCPU {
 bool ext_f;
 bool ext_d;
 bool ext_c;
+bool ext_b;
 bool ext_s;
 bool ext_u;
 bool ext_h;
-- 
2.17.1

[RFC v3 13/16] target/riscv: rvb: generalized or-combine

[frank . chang]

From: Frank Chang 

Signed-off-by: Frank Chang 
---
 target/riscv/bitmanip_helper.c  | 31 +
 target/riscv/helper.h   |  2 ++
 target/riscv/insn32-64.decode   |  2 ++
 target/riscv/insn32.decode  |  2 ++
 target/riscv/insn_trans/trans_rvb.c.inc | 24 +++
 target/riscv/translate.c|  6 +
 6 files changed, 67 insertions(+)

diff --git a/target/riscv/bitmanip_helper.c b/target/riscv/bitmanip_helper.c
index 1d3235bc0d6..389b52eccd9 100644
--- a/target/riscv/bitmanip_helper.c
+++ b/target/riscv/bitmanip_helper.c
@@ -69,3 +69,34 @@ target_ulong HELPER(grevw)(target_ulong rs1, target_ulong 
rs2)
 }
 
 #endif
+
+static target_ulong do_gorc(target_ulong rs1,
+target_ulong rs2,
+int bits)
+{
+target_ulong x = rs1;
+int i, shift;
+
+for (i = 0, shift = 1; shift < bits; i++, shift <<= 1) {
+if (rs2 & shift) {
+x |= do_swap(x, adjacent_masks[i], shift);
+}
+}
+
+return x;
+}
+
+target_ulong HELPER(gorc)(target_ulong rs1, target_ulong rs2)
+{
+return do_gorc(rs1, rs2, TARGET_LONG_BITS);
+}
+
+/* RV64-only instruction */
+#ifdef TARGET_RISCV64
+
+target_ulong HELPER(gorcw)(target_ulong rs1, target_ulong rs2)
+{
+return do_gorc(rs1, rs2, 32);
+}
+
+#endif
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index db8b770f1aa..7ddaea61798 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -60,9 +60,11 @@ DEF_HELPER_FLAGS_1(fclass_d, TCG_CALL_NO_RWG_SE, tl, i64)
 
 /* Bitmanip */
 DEF_HELPER_FLAGS_2(grev, TCG_CALL_NO_RWG_SE, tl, tl, tl)
+DEF_HELPER_FLAGS_2(gorc, TCG_CALL_NO_RWG_SE, tl, tl, tl)
 
 #if defined(TARGET_RISCV64)
 DEF_HELPER_FLAGS_2(grevw, TCG_CALL_NO_RWG_SE, tl, tl, tl)
+DEF_HELPER_FLAGS_2(gorcw, TCG_CALL_NO_RWG_SE, tl, tl, tl)
 #endif
 
 /* Special functions */
diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 38ceadd4553..894db5e3abf 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -103,6 +103,7 @@ srow   001 .. 101 . 0111011 @r
 rorw   011 .. 101 . 0111011 @r
 rolw   011 .. 001 . 0111011 @r
 grevw  0110100 .. 101 . 0111011 @r
+gorcw  0010100 .. 101 . 0111011 @r
 
 bsetiw 0010100 .. 001 . 0011011 @sh5
 bclriw 0100100 .. 001 . 0011011 @sh5
@@ -111,3 +112,4 @@ sloiw  001 .. 001 . 0011011 @sh5
 sroiw  001 .. 101 . 0011011 @sh5
 roriw  011 .. 101 . 0011011 @sh5
 greviw 0110100 .. 101 . 0011011 @sh5
+gorciw 0010100 .. 101 . 0011011 @sh5
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index fa4bba4f0ee..0756ea5cc28 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -620,6 +620,7 @@ sro001 .. 101 . 0110011 @r
 ror011 .. 101 . 0110011 @r
 rol011 .. 001 . 0110011 @r
 grev   0110100 .. 101 . 0110011 @r
+gorc   0010100 .. 101 . 0110011 @r
 
 bseti  00101. ... 001 . 0010011 @sh
 bclri  01001. ... 001 . 0010011 @sh
@@ -629,3 +630,4 @@ sloi   00100. ... 001 . 0010011 @sh
 sroi   00100. ... 101 . 0010011 @sh
 rori   01100. ... 101 . 0010011 @sh
 grevi  01101. ... 101 . 0010011 @sh
+gorci  00101. ... 101 . 0010011 @sh
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 286643cd183..a4181dbf0de 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -214,6 +214,18 @@ static bool trans_grevi(DisasContext *ctx, arg_grevi *a)
 return gen_grevi(ctx, a);
 }
 
+static bool trans_gorc(DisasContext *ctx, arg_gorc *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, gen_helper_gorc);
+}
+
+static bool trans_gorci(DisasContext *ctx, arg_gorci *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, gen_helper_gorc);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -343,4 +355,16 @@ static bool trans_greviw(DisasContext *ctx, arg_greviw *a)
 return gen_shiftiw(ctx, a, gen_grevw);
 }
 
+static bool trans_gorcw(DisasContext *ctx, arg_gorcw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_gorcw);
+}
+
+static bool trans_gorciw(DisasContext *ctx, arg_gorciw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_gorcw);
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index cb040a15003..e845b311a3d 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -892,6 +892,12 @@ static void gen_grevw(TCGv ret, TCGv arg1, TCGv arg2)
 gen_helper_grev(ret, arg1, arg2);
 

[RFC v3 03/16] target/riscv: rvb: count bits set

[frank . chang]

From: Frank Chang 

Signed-off-by: Kito Cheng 
Reviewed-by: Richard Henderson 
Signed-off-by: Frank Chang 
---
 target/riscv/insn32-64.decode   |  1 +
 target/riscv/insn32.decode  |  1 +
 target/riscv/insn_trans/trans_rvb.c.inc | 12 
 target/riscv/translate.c|  6 ++
 4 files changed, 20 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index f4c42720fc7..89498a9a28a 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -90,3 +90,4 @@ hsv_d 0110111  .   . 100 0 1110011 @r2_s
 # *** RV64B Standard Extension (in addition to RV32B) ***
 clzw   011 0 . 001 . 0011011 @r2
 ctzw   011 1 . 001 . 0011011 @r2
+cpopw  011 00010 . 001 . 0011011 @r2
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 8fe838cf0d0..0e321da37f4 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -597,3 +597,4 @@ vsetvl  100 . . 111 . 1010111  @r
 # *** RV32B Standard Extension ***
 clz011000 00 . 001 . 0010011 @r2
 ctz011000 01 . 001 . 0010011 @r2
+cpop   011000 10 . 001 . 0010011 @r2
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 76788c2f353..dbbd94e1015 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -29,6 +29,12 @@ static bool trans_ctz(DisasContext *ctx, arg_ctz *a)
 return gen_unary(ctx, a, gen_ctz);
 }
 
+static bool trans_cpop(DisasContext *ctx, arg_cpop *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, tcg_gen_ctpop_tl);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -44,4 +50,10 @@ static bool trans_ctzw(DisasContext *ctx, arg_ctzw *a)
 return gen_unary(ctx, a, gen_ctzw);
 }
 
+static bool trans_cpopw(DisasContext *ctx, arg_cpopw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, gen_cpopw);
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index fac111d465c..3a14bdba194 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -726,6 +726,12 @@ static void gen_clzw(TCGv ret, TCGv arg1)
 tcg_gen_subi_i64(ret, ret, 32);
 }
 
+static void gen_cpopw(TCGv ret, TCGv arg1)
+{
+tcg_gen_ext32u_tl(arg1, arg1);
+tcg_gen_ctpop_tl(ret, arg1);
+}
+
 #endif
 
 static bool gen_arith(DisasContext *ctx, arg_r *a,
-- 
2.17.1

[RFC v3 07/16] target/riscv: rvb: sign-extend instructions

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Reviewed-by: Richard Henderson 
Signed-off-by: Frank Chang 
---
 target/riscv/insn32.decode  |  2 ++
 target/riscv/insn_trans/trans_rvb.c.inc | 12 
 2 files changed, 14 insertions(+)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index d64326fd864..938c23088eb 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -598,6 +598,8 @@ vsetvl  100 . . 111 . 1010111  @r
 clz011000 00 . 001 . 0010011 @r2
 ctz011000 01 . 001 . 0010011 @r2
 cpop   011000 10 . 001 . 0010011 @r2
+sext_b 011000 000100 . 001 . 0010011 @r2
+sext_h 011000 000101 . 001 . 0010011 @r2
 
 andn   010 .. 111 . 0110011 @r
 orn010 .. 110 . 0110011 @r
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 2aa4515fe31..1496996a660 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -95,6 +95,18 @@ static bool trans_maxu(DisasContext *ctx, arg_maxu *a)
 return gen_arith(ctx, a, tcg_gen_umax_tl);
 }
 
+static bool trans_sext_b(DisasContext *ctx, arg_sext_b *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, tcg_gen_ext8s_tl);
+}
+
+static bool trans_sext_h(DisasContext *ctx, arg_sext_h *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, tcg_gen_ext16s_tl);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
-- 
2.17.1

[RFC v3 14/16] target/riscv: rvb: address calculation

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32-64.decode   |  3 +++
 target/riscv/insn32.decode  |  3 +++
 target/riscv/insn_trans/trans_rvb.c.inc | 23 ++
 target/riscv/translate.c| 32 +
 4 files changed, 61 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 894db5e3abf..2f80b0c07ae 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -104,6 +104,9 @@ rorw   011 .. 101 . 0111011 @r
 rolw   011 .. 001 . 0111011 @r
 grevw  0110100 .. 101 . 0111011 @r
 gorcw  0010100 .. 101 . 0111011 @r
+sh1add_uw  001 .. 010 . 0111011 @r
+sh2add_uw  001 .. 100 . 0111011 @r
+sh3add_uw  001 .. 110 . 0111011 @r
 
 bsetiw 0010100 .. 001 . 0011011 @sh5
 bclriw 0100100 .. 001 . 0011011 @sh5
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 0756ea5cc28..b90c1c0a350 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -621,6 +621,9 @@ ror011 .. 101 . 0110011 @r
 rol011 .. 001 . 0110011 @r
 grev   0110100 .. 101 . 0110011 @r
 gorc   0010100 .. 101 . 0110011 @r
+sh1add 001 .. 010 . 0110011 @r
+sh2add 001 .. 100 . 0110011 @r
+sh3add 001 .. 110 . 0110011 @r
 
 bseti  00101. ... 001 . 0010011 @sh
 bclri  01001. ... 001 . 0010011 @sh
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index a4181dbf0de..ca987f2705f 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -226,6 +226,17 @@ static bool trans_gorci(DisasContext *ctx, arg_gorci *a)
 return gen_shifti(ctx, a, gen_helper_gorc);
 }
 
+#define GEN_TRANS_SHADD(SHAMT) \
+static bool trans_sh##SHAMT##add(DisasContext *ctx, arg_sh##SHAMT##add *a) \
+{  \
+REQUIRE_EXT(ctx, RVB); \
+return gen_arith(ctx, a, gen_sh##SHAMT##add);  \
+}
+
+GEN_TRANS_SHADD(1)
+GEN_TRANS_SHADD(2)
+GEN_TRANS_SHADD(3)
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -367,4 +378,16 @@ static bool trans_gorciw(DisasContext *ctx, arg_gorciw *a)
 return gen_shiftiw(ctx, a, gen_gorcw);
 }
 
+#define GEN_TRANS_SHADD_UW(SHAMT) \
+static bool trans_sh##SHAMT##add_uw(DisasContext *ctx,\
+arg_sh##SHAMT##add_uw *a) \
+{ \
+REQUIRE_EXT(ctx, RVB);\
+return gen_arith(ctx, a, gen_sh##SHAMT##add_uw);  \
+}
+
+GEN_TRANS_SHADD_UW(1)
+GEN_TRANS_SHADD_UW(2)
+GEN_TRANS_SHADD_UW(3)
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index e845b311a3d..7365e591eb7 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -812,6 +812,21 @@ static bool gen_grevi(DisasContext *ctx, arg_grevi *a)
 return true;
 }
 
+#define GEN_SHADD(SHAMT)   \
+static void gen_sh##SHAMT##add(TCGv ret, TCGv arg1, TCGv arg2) \
+{  \
+TCGv t = tcg_temp_new();   \
+   \
+tcg_gen_shli_tl(t, arg1, SHAMT);   \
+tcg_gen_add_tl(ret, t, arg2);  \
+   \
+tcg_temp_free(t);  \
+}
+
+GEN_SHADD(1)
+GEN_SHADD(2)
+GEN_SHADD(3)
+
 #ifdef TARGET_RISCV64
 
 static void gen_ctzw(TCGv ret, TCGv arg1)
@@ -898,6 +913,23 @@ static void gen_gorcw(TCGv ret, TCGv arg1, TCGv arg2)
 gen_helper_gorcw(ret, arg1, arg2);
 }
 
+#define GEN_SHADD_UW(SHAMT)   \
+static void gen_sh##SHAMT##add_uw(TCGv ret, TCGv arg1, TCGv arg2) \
+{ \
+TCGv t = tcg_temp_new();  \
+  \
+tcg_gen_ext32u_tl(t, arg1);   \
+  \
+tcg_gen_shli_tl(t, t, SHAMT); \
+tcg_gen_add_tl(ret, t, arg2); \
+  \
+

[RFC v3 11/16] target/riscv: rvb: rotate (left/right)

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
---
 target/riscv/insn32-64.decode   |  3 +++
 target/riscv/insn32.decode  |  3 +++
 target/riscv/insn_trans/trans_rvb.c.inc | 36 +
 target/riscv/translate.c| 36 +
 4 files changed, 78 insertions(+)

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 8c3ed33077e..8f9ba21b352 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -100,9 +100,12 @@ binvw  0110100 .. 001 . 0111011 @r
 bextw  0100100 .. 101 . 0111011 @r
 slow   001 .. 001 . 0111011 @r
 srow   001 .. 101 . 0111011 @r
+rorw   011 .. 101 . 0111011 @r
+rolw   011 .. 001 . 0111011 @r
 
 bsetiw 0010100 .. 001 . 0011011 @sh5
 bclriw 0100100 .. 001 . 0011011 @sh5
 binviw 0110100 .. 001 . 0011011 @sh5
 sloiw  001 .. 001 . 0011011 @sh5
 sroiw  001 .. 101 . 0011011 @sh5
+roriw  011 .. 101 . 0011011 @sh5
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 0ea92312372..6d1b604c800 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -617,6 +617,8 @@ binv   0110100 .. 001 . 0110011 @r
 bext   0100100 .. 101 . 0110011 @r
 slo001 .. 001 . 0110011 @r
 sro001 .. 101 . 0110011 @r
+ror011 .. 101 . 0110011 @r
+rol011 .. 001 . 0110011 @r
 
 bseti  00101. ... 001 . 0010011 @sh
 bclri  01001. ... 001 . 0010011 @sh
@@ -624,3 +626,4 @@ binvi  01101. ... 001 . 0010011 @sh
 bexti  01001. ... 101 . 0010011 @sh
 sloi   00100. ... 001 . 0010011 @sh
 sroi   00100. ... 101 . 0010011 @sh
+rori   01100. ... 101 . 0010011 @sh
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 44f9f639240..8a46fde4767 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -179,6 +179,24 @@ static bool trans_sroi(DisasContext *ctx, arg_sroi *a)
 return gen_shifti(ctx, a, gen_sro);
 }
 
+static bool trans_ror(DisasContext *ctx, arg_ror *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, tcg_gen_rotr_tl);
+}
+
+static bool trans_rori(DisasContext *ctx, arg_rori *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shifti(ctx, a, tcg_gen_rotr_tl);
+}
+
+static bool trans_rol(DisasContext *ctx, arg_rol *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shift(ctx, a, tcg_gen_rotl_tl);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
@@ -278,4 +296,22 @@ static bool trans_sroiw(DisasContext *ctx, arg_sroiw *a)
 return gen_shiftiw(ctx, a, gen_sro);
 }
 
+static bool trans_rorw(DisasContext *ctx, arg_rorw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_rorw);
+}
+
+static bool trans_roriw(DisasContext *ctx, arg_roriw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftiw(ctx, a, gen_rorw);
+}
+
+static bool trans_rolw(DisasContext *ctx, arg_rolw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_shiftw(ctx, a, gen_rolw);
+}
+
 #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 678c3dca81f..eee69e6bba9 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -828,6 +828,42 @@ static void gen_packuw(TCGv ret, TCGv arg1, TCGv arg2)
 tcg_temp_free(t);
 }
 
+static void gen_rorw(TCGv ret, TCGv arg1, TCGv arg2)
+{
+TCGv_i32 t1 = tcg_temp_new_i32();
+TCGv_i32 t2 = tcg_temp_new_i32();
+
+/* truncate to 32-bits */
+tcg_gen_trunc_tl_i32(t1, arg1);
+tcg_gen_trunc_tl_i32(t2, arg2);
+
+tcg_gen_rotr_i32(t1, t1, t2);
+
+/* sign-extend 64-bits */
+tcg_gen_ext_i32_tl(ret, t1);
+
+tcg_temp_free_i32(t1);
+tcg_temp_free_i32(t2);
+}
+
+static void gen_rolw(TCGv ret, TCGv arg1, TCGv arg2)
+{
+TCGv_i32 t1 = tcg_temp_new_i32();
+TCGv_i32 t2 = tcg_temp_new_i32();
+
+/* truncate to 32-bits */
+tcg_gen_trunc_tl_i32(t1, arg1);
+tcg_gen_trunc_tl_i32(t2, arg2);
+
+tcg_gen_rotl_i32(t1, t1, t2);
+
+/* sign-extend 64-bits */
+tcg_gen_ext_i32_tl(ret, t1);
+
+tcg_temp_free_i32(t1);
+tcg_temp_free_i32(t2);
+}
+
 #endif
 
 static bool gen_arith(DisasContext *ctx, arg_r *a,
-- 
2.17.1

[RFC v3 04/16] target/riscv: rvb: logic-with-negate

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
---
 target/riscv/insn32.decode  |  4 
 target/riscv/insn_trans/trans_rvb.c.inc | 18 ++
 2 files changed, 22 insertions(+)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 0e321da37f4..d0b3f109b4e 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -598,3 +598,7 @@ vsetvl  100 . . 111 . 1010111  @r
 clz011000 00 . 001 . 0010011 @r2
 ctz011000 01 . 001 . 0010011 @r2
 cpop   011000 10 . 001 . 0010011 @r2
+
+andn   010 .. 111 . 0110011 @r
+orn010 .. 110 . 0110011 @r
+xnor   010 .. 100 . 0110011 @r
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index dbbd94e1015..73c4693a263 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -35,6 +35,24 @@ static bool trans_cpop(DisasContext *ctx, arg_cpop *a)
 return gen_unary(ctx, a, tcg_gen_ctpop_tl);
 }
 
+static bool trans_andn(DisasContext *ctx, arg_andn *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_andc_tl);
+}
+
+static bool trans_orn(DisasContext *ctx, arg_orn *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_orc_tl);
+}
+
+static bool trans_xnor(DisasContext *ctx, arg_xnor *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_eqv_tl);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
-- 
2.17.1

[RFC v3 01/16] target/riscv: reformat @sh format encoding for B-extension

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32.decode | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 84080dd18ca..3823b3ea800 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -22,7 +22,7 @@
 %rs1   15:5
 %rd7:5
 
-%sh1020:10
+%sh720:7
 %csr20:12
 %rm 12:3
 %nf 29:3 !function=ex_plus_1
@@ -58,7 +58,7 @@
 @u     . ...   imm=%imm_u  
%rd
 @j     . ...   imm=%imm_j  
%rd
 
-@sh  ..  .. .  ... . ...   shamt=%sh10  %rs1 
%rd
+@sh  ..  .. .  ... . ...   shamt=%sh7 %rs1 
%rd
 @csr    .  ... . ...   %csr %rs1 
%rd
 
 @atom_ld . aq:1 rl:1 .  . ...  rs2=0 %rs1 
%rd
@@ -122,9 +122,9 @@ sltiu . 011 . 0010011 @i
 xori  . 100 . 0010011 @i
 ori   . 110 . 0010011 @i
 andi  . 111 . 0010011 @i
-slli 00 ... 001 . 0010011 @sh
-srli 00 ... 101 . 0010011 @sh
-srai 01 ... 101 . 0010011 @sh
+slli 0. ... 001 . 0010011 @sh
+srli 0. ... 101 . 0010011 @sh
+srai 01000. ... 101 . 0010011 @sh
 add  000 .. 000 . 0110011 @r
 sub  010 .. 000 . 0110011 @r
 sll  000 .. 001 . 0110011 @r
-- 
2.17.1

[RFC v3 06/16] target/riscv: rvb: min/max instructions

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Reviewed-by: Richard Henderson 
Signed-off-by: Frank Chang 
---
 target/riscv/insn32.decode  |  4 
 target/riscv/insn_trans/trans_rvb.c.inc | 24 
 2 files changed, 28 insertions(+)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 7f32b8c6d15..d64326fd864 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -605,3 +605,7 @@ xnor   010 .. 100 . 0110011 @r
 pack   100 .. 100 . 0110011 @r
 packu  0100100 .. 100 . 0110011 @r
 packh  100 .. 111 . 0110011 @r
+min101 .. 100 . 0110011 @r
+minu   101 .. 101 . 0110011 @r
+max101 .. 110 . 0110011 @r
+maxu   101 .. 111 . 0110011 @r
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
index 2d24dafac09..2aa4515fe31 100644
--- a/target/riscv/insn_trans/trans_rvb.c.inc
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -71,6 +71,30 @@ static bool trans_packh(DisasContext *ctx, arg_packh *a)
 return gen_arith(ctx, a, gen_packh);
 }
 
+static bool trans_min(DisasContext *ctx, arg_min *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_smin_tl);
+}
+
+static bool trans_max(DisasContext *ctx, arg_max *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_smax_tl);
+}
+
+static bool trans_minu(DisasContext *ctx, arg_minu *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_umin_tl);
+}
+
+static bool trans_maxu(DisasContext *ctx, arg_maxu *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_arith(ctx, a, tcg_gen_umax_tl);
+}
+
 /* RV64-only instructions */
 #ifdef TARGET_RISCV64
 
-- 
2.17.1

[RFC v3 02/16] target/riscv: rvb: count leading/trailing zeros

[frank . chang]

From: Kito Cheng 

Signed-off-by: Kito Cheng 
Signed-off-by: Frank Chang 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32-64.decode   |  4 +++
 target/riscv/insn32.decode  |  7 +++-
 target/riscv/insn_trans/trans_rvb.c.inc | 47 +
 target/riscv/translate.c| 42 ++
 4 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 target/riscv/insn_trans/trans_rvb.c.inc

diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 8157dee8b7c..f4c42720fc7 100644
--- a/target/riscv/insn32-64.decode
+++ b/target/riscv/insn32-64.decode
@@ -86,3 +86,7 @@ fmv_d_x001  0 . 000 . 1010011 @r2
 hlv_wu0110100  1   . 100 . 1110011 @r2
 hlv_d 0110110  0   . 100 . 1110011 @r2
 hsv_d 0110111  .   . 100 0 1110011 @r2_s
+
+# *** RV64B Standard Extension (in addition to RV32B) ***
+clzw   011 0 . 001 . 0011011 @r2
+ctzw   011 1 . 001 . 0011011 @r2
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 3823b3ea800..8fe838cf0d0 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -40,6 +40,7 @@
 imm rs1 rd
 imm rd
 rd rs1 rs2
+   rd rs1
 imm rs1 rs2
 imm rd
  shamt rs1 rd
@@ -67,7 +68,7 @@
 @r4_rm   . ..  . . ... . ... %rs3 %rs2 %rs1 %rm %rd
 @r_rm...   . . ... . ... %rs2 %rs1 %rm %rd
 @r2_rm   ...   . . ... . ... %rs1 %rm %rd
-@r2  ...   . . ... . ... %rs1 %rd
+@r2  ...   . . ... . ...  %rs1 %rd
 @r2_nfvm ... ... vm:1 . . ... . ...  %nf %rs1 %rd
 @r2_vm   .. vm:1 . . ... . ...  %rs2 %rd
 @r1_vm   .. vm:1 . . ... . ... %rd
@@ -592,3 +593,7 @@ vcompress_vm010111 - . . 010 . 1010111 @r
 
 vsetvli 0 ... . 111 . 1010111  @r2_zimm
 vsetvl  100 . . 111 . 1010111  @r
+
+# *** RV32B Standard Extension ***
+clz011000 00 . 001 . 0010011 @r2
+ctz011000 01 . 001 . 0010011 @r2
diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
b/target/riscv/insn_trans/trans_rvb.c.inc
new file mode 100644
index 000..76788c2f353
--- /dev/null
+++ b/target/riscv/insn_trans/trans_rvb.c.inc
@@ -0,0 +1,47 @@
+/*
+ * RISC-V translation routines for the RVB Standard Extension.
+ *
+ * Copyright (c) 2020 Kito Cheng, kito.ch...@sifive.com
+ * Copyright (c) 2020 Frank Chang, frank.ch...@sifive.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+static bool trans_clz(DisasContext *ctx, arg_clz *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, gen_clz);
+}
+
+static bool trans_ctz(DisasContext *ctx, arg_ctz *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, gen_ctz);
+}
+
+/* RV64-only instructions */
+#ifdef TARGET_RISCV64
+
+static bool trans_clzw(DisasContext *ctx, arg_clzw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, gen_clzw);
+}
+
+static bool trans_ctzw(DisasContext *ctx, arg_ctzw *a)
+{
+REQUIRE_EXT(ctx, RVB);
+return gen_unary(ctx, a, gen_ctzw);
+}
+
+#endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 554d52a4be3..fac111d465c 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -711,6 +711,23 @@ static bool gen_arith_div_uw(DisasContext *ctx, arg_r *a,
 
 #endif
 
+#ifdef TARGET_RISCV64
+
+static void gen_ctzw(TCGv ret, TCGv arg1)
+{
+tcg_gen_ori_i64(ret, arg1, MAKE_64BIT_MASK(32, 32));
+tcg_gen_ctzi_i64(ret, ret, 64);
+}
+
+static void gen_clzw(TCGv ret, TCGv arg1)
+{
+tcg_gen_ext32u_i64(ret, arg1);
+tcg_gen_clzi_i64(ret, ret, 64);
+tcg_gen_subi_i64(ret, ret, 32);
+}
+
+#endif
+
 static bool gen_arith(DisasContext *ctx, arg_r *a,
   void(*func)(TCGv, TCGv, TCGv))
 {
@@ -747,6 +764,30 @@ static bool gen_shift(DisasContext *ctx, arg_r *a,
 return true;
 }
 
+static void gen_ctz(TCGv ret, TCGv arg1)
+{
+tcg_gen_ctzi_tl(ret, arg1, TARGET_LONG_BITS);
+}
+
+static void gen_clz(TCGv ret, TCGv arg1)
+{
+tcg_gen_clzi_tl(ret, arg1, TARGET_LONG_BITS);
+}
+
+static bool gen_unary(DisasContext *ctx, arg_r2 *a,
+  void(*func)(TCGv, TCGv))
+{
+TCGv source = tcg_temp_new();

[RFC v3 00/16] support subsets of bitmanip extension

[frank . chang]

From: Frank Chang 

This patchset implements RISC-V B-extension 0.93 version Zbb, Zbs and
Zba subset instructions. Some Zbp instructions are also implemented as
they have similar behavior with their Zbb-, Zbs- and Zba-family
instructions or for Zbb pseudo instructions (e.g. rev8, orc.b).

Specification:
https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.93.pdf

The port is available here:
https://github.com/sifive/qemu/tree/rvb-upstream-v3

To test rvb implementation, specify cpu argument with 'x-b=true' to
enable B-extension support.

Changelog:

v3:
 * Convert existing immediate shift instructions to use gen_shifti()
   and gen_shiftiw() interfaces.
 * Rename *u.w instructions to *.uw.
 * Rename sb* instructions to b*.
 * Rename pcnt* instructions to cpop*.

v2:
 * Add gen_shifti(), gen_shiftw(), gen_shiftiw() helper functions.
 * Remove addwu, subwu and addiwu instructions as they are not longer
   exist in latest draft.
 * Optimize implementation with cleaner tcg ops.

Frank Chang (4):
  target/riscv: rvb: count bits set
  target/riscv: add gen_shifti() and gen_shiftiw() helper functions
  target/riscv: rvb: generalized reverse
  target/riscv: rvb: generalized or-combine

Kito Cheng (12):
  target/riscv: reformat @sh format encoding for B-extension
  target/riscv: rvb: count leading/trailing zeros
  target/riscv: rvb: logic-with-negate
  target/riscv: rvb: pack two words into one register
  target/riscv: rvb: min/max instructions
  target/riscv: rvb: sign-extend instructions
  target/riscv: rvb: single-bit instructions
  target/riscv: rvb: shift ones
  target/riscv: rvb: rotate (left/right)
  target/riscv: rvb: address calculation
  target/riscv: rvb: add/shift with prefix zero-extend
  target/riscv: rvb: support and turn on B-extension from command line

 target/riscv/bitmanip_helper.c  | 102 ++
 target/riscv/cpu.c  |   4 +
 target/riscv/cpu.h  |   2 +
 target/riscv/helper.h   |   9 +
 target/riscv/insn32-64.decode   |  33 ++
 target/riscv/insn32.decode  |  54 ++-
 target/riscv/insn_trans/trans_rvb.c.inc | 415 
 target/riscv/insn_trans/trans_rvi.c.inc |  45 +--
 target/riscv/meson.build|   1 +
 target/riscv/translate.c| 314 ++
 10 files changed, 932 insertions(+), 47 deletions(-)
 create mode 100644 target/riscv/bitmanip_helper.c
 create mode 100644 target/riscv/insn_trans/trans_rvb.c.inc

--
2.17.1

[RFC v3 08/16] target/riscv: add gen_shifti() and gen_shiftiw() helper functions

[frank . chang]

From: Frank Chang 

Add gen_shifti() and gen_shiftiw() helper functions to reuse the same
interfaces for immediate shift instructions.

Signed-off-by: Frank Chang 
---
 target/riscv/insn_trans/trans_rvi.c.inc | 45 +++--
 target/riscv/translate.c| 43 +++
 2 files changed, 47 insertions(+), 41 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvi.c.inc 
b/target/riscv/insn_trans/trans_rvi.c.inc
index d04ca0394cf..678c8f07238 100644
--- a/target/riscv/insn_trans/trans_rvi.c.inc
+++ b/target/riscv/insn_trans/trans_rvi.c.inc
@@ -261,52 +261,24 @@ static bool trans_andi(DisasContext *ctx, arg_andi *a)
 }
 static bool trans_slli(DisasContext *ctx, arg_slli *a)
 {
-if (a->shamt >= TARGET_LONG_BITS) {
-return false;
-}
-
 if (a->rd != 0) {
-TCGv t = tcg_temp_new();
-gen_get_gpr(t, a->rs1);
-
-tcg_gen_shli_tl(t, t, a->shamt);
-
-gen_set_gpr(a->rd, t);
-tcg_temp_free(t);
+return gen_shifti(ctx, a, tcg_gen_shl_tl);
 } /* NOP otherwise */
 return true;
 }
 
 static bool trans_srli(DisasContext *ctx, arg_srli *a)
 {
-if (a->shamt >= TARGET_LONG_BITS) {
-return false;
-}
-
 if (a->rd != 0) {
-TCGv t = tcg_temp_new();
-gen_get_gpr(t, a->rs1);
-
-tcg_gen_shri_tl(t, t, a->shamt);
-gen_set_gpr(a->rd, t);
-tcg_temp_free(t);
+return gen_shifti(ctx, a, tcg_gen_shr_tl);
 } /* NOP otherwise */
 return true;
 }
 
 static bool trans_srai(DisasContext *ctx, arg_srai *a)
 {
-if (a->shamt >= TARGET_LONG_BITS) {
-return false;
-}
-
 if (a->rd != 0) {
-TCGv t = tcg_temp_new();
-gen_get_gpr(t, a->rs1);
-
-tcg_gen_sari_tl(t, t, a->shamt);
-gen_set_gpr(a->rd, t);
-tcg_temp_free(t);
+return gen_shifti(ctx, a, tcg_gen_sar_tl);
 } /* NOP otherwise */
 return true;
 }
@@ -369,16 +341,7 @@ static bool trans_addiw(DisasContext *ctx, arg_addiw *a)
 
 static bool trans_slliw(DisasContext *ctx, arg_slliw *a)
 {
-TCGv source1;
-source1 = tcg_temp_new();
-gen_get_gpr(source1, a->rs1);
-
-tcg_gen_shli_tl(source1, source1, a->shamt);
-tcg_gen_ext32s_tl(source1, source1);
-gen_set_gpr(a->rd, source1);
-
-tcg_temp_free(source1);
-return true;
+return gen_shiftiw(ctx, a, tcg_gen_shl_tl);
 }
 
 static bool trans_srliw(DisasContext *ctx, arg_srliw *a)
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 53c0c34ce16..8459b6bcf54 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -810,6 +810,49 @@ static bool gen_shift(DisasContext *ctx, arg_r *a,
 return true;
 }
 
+static bool gen_shifti(DisasContext *ctx, arg_shift *a,
+   void(*func)(TCGv, TCGv, TCGv))
+{
+if (a->shamt >= TARGET_LONG_BITS) {
+return false;
+}
+
+TCGv source1 = tcg_temp_new();
+TCGv source2 = tcg_temp_new();
+
+gen_get_gpr(source1, a->rs1);
+
+tcg_gen_movi_tl(source2, a->shamt);
+(*func)(source1, source1, source2);
+
+gen_set_gpr(a->rd, source1);
+tcg_temp_free(source1);
+tcg_temp_free(source2);
+return true;
+}
+
+#ifdef TARGET_RISCV64
+
+static bool gen_shiftiw(DisasContext *ctx, arg_shift *a,
+void(*func)(TCGv, TCGv, TCGv))
+{
+TCGv source1 = tcg_temp_new();
+TCGv source2 = tcg_temp_new();
+
+gen_get_gpr(source1, a->rs1);
+tcg_gen_movi_tl(source2, a->shamt);
+
+(*func)(source1, source1, source2);
+tcg_gen_ext32s_tl(source1, source1);
+
+gen_set_gpr(a->rd, source1);
+tcg_temp_free(source1);
+tcg_temp_free(source2);
+return true;
+}
+
+#endif
+
 static void gen_ctz(TCGv ret, TCGv arg1)
 {
 tcg_gen_ctzi_tl(ret, arg1, TARGET_LONG_BITS);
-- 
2.17.1

[PATCH] tests/acceptance: Test PMON with Loongson-3A1000 CPU

[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: usb_get_descriptor
console: 

Re: [PATCH] hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30

[BALATON Zoltan]

On Tue, 12 Jan 2021, David Gibson wrote:

On Mon, Jan 11, 2021 at 09:30:07PM +, Peter Maydell wrote:

In commit 34d0831f38fd8 the ppc-uic device was added, with a dcr-base
property. The intention was that the default value of dcr-base should be
the one that most of our boards need, so that in the common case they
don't need to specify a property value.

All QEMU boards with a UIC use a dcr-base of 0xc0, with the exception of
sam460ex which has four UICs and so puts them at 0xc0, 0xd0, 0xe0, 0xf0.
So 0xc0 is the obvious right choice for the default dcr-base.

The board code conversions in commits 0270d74ef88623505 (bamboo) and
c5ac9dc64fa552a6 (virtex_ml507) assumed that default was 0xc0. Unfortunately
the actual default in 34d0831f38fd8 was 0x30, by mistake, so the
bamboo and virtex_ml507 boards were broken as they were converted
away from ppcuic_init() (which always specifies the dcr_base property
value explicitly).

Set the default dcr-base to 0xc0 as was intended, fixing bamboo and
virtex_ml507.

Fixes: 34d0831f38fd8
Reported-by: Nathan Chancellor 
Suggested-by: BALATON Zoltan 
Signed-off-by: Peter Maydell 


Applied, thanks.


Will you take my series too?

http://patchwork.ozlabs.org/project/qemu-devel/list/?series=223439

I've cc'd you but your DNS seems to not return an MX record most of the 
time still so these are bouncing back.


Regards,
BALATON Zoltan


---
This is the right way to fix the bug I was trying to fix with
"hw/ppc/ppc400_bamboo: Set dcr-base correctly when creating UIC".

David: you probably want to put this patch in your ppc queue
before "hw/ppc/ppc405_uc: Drop use of ppcuic_init()", as that patch
also assumes the 0xc0 default.


Done.



 hw/intc/ppc-uic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/intc/ppc-uic.c b/hw/intc/ppc-uic.c
index b21951eea83..7171de7b355 100644
--- a/hw/intc/ppc-uic.c
+++ b/hw/intc/ppc-uic.c
@@ -274,7 +274,7 @@ static void ppc_uic_realize(DeviceState *dev, Error **errp)

 static Property ppc_uic_properties[] = {
 DEFINE_PROP_LINK("cpu", PPCUIC, cpu, TYPE_CPU, CPUState *),
-DEFINE_PROP_UINT32("dcr-base", PPCUIC, dcr_base, 0x30),
+DEFINE_PROP_UINT32("dcr-base", PPCUIC, dcr_base, 0xc0),
 DEFINE_PROP_BOOL("use-vectors", PPCUIC, use_vectors, true),
 DEFINE_PROP_END_OF_LIST()
 };


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

[PATCH] hw/intc/loongson_liointc: Fix per core ISR handling

[Jiaxun Yang]

Per core ISR is a set of 32-bit registers spaced by 8 bytes.
This patch fixed calculation of it's size and also added check
of alignment at reading & writing.

Signed-off-by: Jiaxun Yang 
---
 hw/intc/loongson_liointc.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/intc/loongson_liointc.c b/hw/intc/loongson_liointc.c
index f823d484e0..cc11b544cb 100644
--- a/hw/intc/loongson_liointc.c
+++ b/hw/intc/loongson_liointc.c
@@ -41,7 +41,7 @@
 #define R_IEN_CLR   0x2c
 #define R_ISR_SIZE  0x8
 #define R_START 0x40
-#define R_END   0x64
+#define R_END   (R_START + R_ISR_SIZE * NUM_CORES)
 
 struct loongson_liointc {
 SysBusDevice parent_obj;
@@ -125,7 +125,12 @@ liointc_read(void *opaque, hwaddr addr, unsigned int size)
 }
 
 if (addr >= R_START && addr < R_END) {
-int core = (addr - R_START) / R_ISR_SIZE;
+hwaddr offset = addr - R_START;
+int core = offset / R_ISR_SIZE;
+
+if (offset % R_ISR_SIZE) {
+goto out;
+}
 r = p->per_core_isr[core];
 goto out;
 }
@@ -169,7 +174,12 @@ liointc_write(void *opaque, hwaddr addr,
 }
 
 if (addr >= R_START && addr < R_END) {
-int core = (addr - R_START) / R_ISR_SIZE;
+hwaddr offset = addr - R_START;
+int core = offset / R_ISR_SIZE;
+
+if (offset % R_ISR_SIZE) {
+goto out;
+}
 p->per_core_isr[core] = value;
 goto out;
 }
-- 
2.30.0

Re: [PATCH] hw/block: m25p80: Fix fast read for SST flashes

[Bin Meng]

On Wed, Jan 6, 2021 at 10:21 PM Bin Meng  wrote:
>
> Hi Francisco,
>
> On Tue, Dec 22, 2020 at 9:40 AM Bin Meng  wrote:
> >
> > Hi Francisco,
> >
> > On Wed, Dec 16, 2020 at 6:11 PM Bin Meng  wrote:
> > >
> > > Hi Francisco,
> > >
> > > On Wed, Dec 16, 2020 at 12:40 AM Francisco Iglesias
> > >  wrote:
> > > >
> > > > Hello Bin,
> > > >
> > > > On [2020 Dec 12] Sat 17:44:27, Bin Meng wrote:
> > > > > Hi Francisco,
> > > > >
> > > > > On Sat, Dec 12, 2020 at 5:24 PM Francisco Iglesias
> > > > >  wrote:
> > > > > >
> > > > > > Hi bin,
> > > > > >
> > > > > > On [2020 Dec 12] Sat 16:16:59, Bin Meng wrote:
> > > > > > > Hi Francisco,
> > > > > > >
> > > > > > > On Sat, Dec 12, 2020 at 12:11 AM Francisco Iglesias
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Hello Bin,
> > > > > > > >
> > > > > > > > On [2020 Dec 11] Fri 23:29:16, Bin Meng wrote:
> > > > > > > > > Hi Francisco,
> > > > > > > > >
> > > > > > > > > On Fri, Dec 11, 2020 at 11:16 PM Francisco Iglesias
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hello Bin,
> > > > > > > > > >
> > > > > > > > > > On [2020 Dec 11] Fri 14:07:21, Bin Meng wrote:
> > > > > > > > > > > Hi Francisco,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 4, 2020 at 7:28 PM Francisco Iglesias
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello Bin,
> > > > > > > > > > > >
> > > > > > > > > > > > On [2020 Dec 04] Fri 18:52:50, Bin Meng wrote:
> > > > > > > > > > > > > Hi Francisco,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Dec 4, 2020 at 6:46 PM Francisco Iglesias
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hello Bin,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On [2020 Dec 04] Fri 15:52:12, Bin Meng wrote:
> > > > > > > > > > > > > > > Hi Francisco,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Dec 3, 2020 at 4:38 PM Francisco Iglesias
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Bin and Alistair,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On [2020 Dec 02] Wed 11:40:11, Alistair Francis 
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > On Sun, Nov 29, 2020 at 6:55 PM Bin Meng 
> > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > From: Bin Meng 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > SST flashes require a dummy byte after the 
> > > > > > > > > > > > > > > > > > address bits.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Signed-off-by: Bin Meng 
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I couldn't find a datasheet that says this... 
> > > > > > > > > > > > > > > > > But the actual code
> > > > > > > > > > > > > > > > > change looks fine, so:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Acked-by: Alistair Francis 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alistair
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >  hw/block/m25p80.c | 3 +++
> > > > > > > > > > > > > > > > > >  1 file changed, 3 insertions(+)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > diff --git a/hw/block/m25p80.c 
> > > > > > > > > > > > > > > > > > b/hw/block/m25p80.c
> > > > > > > > > > > > > > > > > > index 483925f..9b36762 100644
> > > > > > > > > > > > > > > > > > --- a/hw/block/m25p80.c
> > > > > > > > > > > > > > > > > > +++ b/hw/block/m25p80.c
> > > > > > > > > > > > > > > > > > @@ -825,6 +825,9 @@ static void 
> > > > > > > > > > > > > > > > > > decode_fast_read_cmd(Flash *s)
> > > > > > > > > > > > > > > > > >  s->needed_bytes = get_addr_length(s);
> > > > > > > > > > > > > > > > > >  switch (get_man(s)) {
> > > > > > > > > > > > > > > > > >  /* Dummy cycles - modeled with bytes 
> > > > > > > > > > > > > > > > > > writes instead of bits */
> > > > > > > > > > > > > > > > > > +case MAN_SST:
> > > > > > > > > > > > > > > > > > +s->needed_bytes += 1;
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1 dummy clk cycle is modelled as 1 byte write 
> > > > > > > > > > > > > > > > (see the comment above), so 1
> > > > > > > > > > > > > > > > dummy byte (8 dummy clk cycles) will need +8 
> > > > > > > > > > > > > > > > above.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think you were confused by the WINBOND codes. 
> > > > > > > > > > > > > > > The comments are
> > > > > > > > > > > > > > > correct. It is modeled with bytes instead of 
> > > > > > > > > > > > > > > bits, so we should +=1.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What the comment says is (perhaps not superclear) 
> > > > > > 

[Bug 1911075] [NEW] [OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines

[Alexander Bulekov]

Public bug reported:

=== Reproducer ===
while true; do cat << EOF; done | ./qemu-system-i386 -machine q35 -nodefaults 
-nographic -qtest stdio -accel qtest
outl 0xcf8 0x8000fa27
outl 0xcfc 0x37414537
outl 0xcf8 0x8000fa01
outl 0xcfc 0x4606ce74
writew 0x37000f01 0x215a
writeq 0x37000100 0xfffaf
writeq 0x37000115 0x373d27004037
outl 0xcf8 0x8000fa01
outl 0xcfc 0x4606ce74
writeq 0x37ff 0x3700011500
writeq 0x37000115 0xc41ff035a5a
outl 0xcf8 0x8000ea04
outb 0xcfc 0x15
outl 0xcf8 0x8000ea00
outw 0xcfc 0x5a1f
writeq 0x37000115 0x17765746972
writeq 0x37000115 0xbf00
outl 0xcf8 0x8000ea04
outb 0xcfc 0x15
outl 0xcf8 0x8000fa46
outb 0xcfc 0xff
clock_step
writeq 0x37000115 0xaf
writeq 0x37000115 0x6301275541af7415
writeq 0x37000115 0xafaf5a5a743715
outb 0x64 0xfe
EOF

=== Stack Trace ===
==887446==ERROR: UndefinedBehaviorSanitizer: stack-overflow on address 
0x7ffe567cae0c (pc 0x7fdd9100819e bp 0x7ffe567cb2b0 sp 0x7ffe567cad40 T887446)

#0 vfprintf
#1 fprintf
#2 ahci_mem_write /src/qemu/hw/ide/ahci.c:468:9
#3 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
#4 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
#5 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
#6 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
#7 flatview_write /src/qemu/softmmu/physmem.c:2799:14
#8 address_space_write /src/qemu/softmmu/physmem.c:2891:18
#9 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9
#10 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5
#11 map_page /src/qemu/hw/ide/ahci.c:249:9
#12 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5
#13 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14
#14 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9
#15 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9
#16 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
#17 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
#18 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
#19 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
#20 flatview_write /src/qemu/softmmu/physmem.c:2799:14
#21 address_space_write /src/qemu/softmmu/physmem.c:2891:18
#22 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9
#23 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5
#24 map_page /src/qemu/hw/ide/ahci.c:249:9
#25 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5
#26 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14
#27 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9
#28 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9
... Repeat until we run out of stack

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  [OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines

Status in QEMU:
  New

Bug description:
  === Reproducer ===
  while true; do cat << EOF; done | ./qemu-system-i386 -machine q35 -nodefaults 
-nographic -qtest stdio -accel qtest
  outl 0xcf8 0x8000fa27
  outl 0xcfc 0x37414537
  outl 0xcf8 0x8000fa01
  outl 0xcfc 0x4606ce74
  writew 0x37000f01 0x215a
  writeq 0x37000100 0xfffaf
  writeq 0x37000115 0x373d27004037
  outl 0xcf8 0x8000fa01
  outl 0xcfc 0x4606ce74
  writeq 0x37ff 0x3700011500
  writeq 0x37000115 0xc41ff035a5a
  outl 0xcf8 0x8000ea04
  outb 0xcfc 0x15
  outl 0xcf8 0x8000ea00
  outw 0xcfc 0x5a1f
  writeq 0x37000115 0x17765746972
  writeq 0x37000115 0xbf00
  outl 0xcf8 0x8000ea04
  outb 0xcfc 0x15
  outl 0xcf8 0x8000fa46
  outb 0xcfc 0xff
  clock_step
  writeq 0x37000115 0xaf
  writeq 0x37000115 0x6301275541af7415
  writeq 0x37000115 0xafaf5a5a743715
  outb 0x64 0xfe
  EOF

  === Stack Trace ===
  ==887446==ERROR: UndefinedBehaviorSanitizer: stack-overflow on address 
0x7ffe567cae0c (pc 0x7fdd9100819e bp 0x7ffe567cb2b0 sp 0x7ffe567cad40 T887446)

  #0 vfprintf
  #1 fprintf
  #2 ahci_mem_write /src/qemu/hw/ide/ahci.c:468:9
  #3 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
  #4 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
  #5 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
  #6 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
  #7 flatview_write /src/qemu/softmmu/physmem.c:2799:14
  #8 address_space_write /src/qemu/softmmu/physmem.c:2891:18
  #9 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9
  #10 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5
  #11 map_page /src/qemu/hw/ide/ahci.c:249:9
  #12 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5
  #13 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14
  #14 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9
  #15 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9
  #16 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
  #17 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
  #18 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
  #19 flatview_write_continue 

Re: [PULL 23/35] hw/intc: Rework Loongson LIOINTC

[Jiaxun Yang]

在 2021/1/11 下午6:35, Peter Maydell 写道:

On Mon, 11 Jan 2021 at 10:20, BALATON Zoltan  wrote:

On Mon, 11 Jan 2021, Jiaxun Yang wrote:

On Mon, Jan 11, 2021, at 8:36 AM, Huacai Chen wrote:

I think R_END should be 0x60, Jiaxun, what do you think?

U r right.
The manual is misleading.

The R_END constant is also used in loongson_liointc_init() for the length
of the memory region so you might want to revise that. If this is a 32 bit
register then you should decide what R_END means? Is it the end of the
memory region in which case the reg starts at R_END - 4 or is it the
address of the last reg in which case the memory region ends at R_END + 4.
 From the above I think it's the address of the last reg so you'll probably
need to add 4 in loongson_liointc_init() when creating the memory region.

Mmm, or check
   (addr >= R_START && addr < (R_START + R_ISR_SIZE * NUM_CORES))

Side note: R_ISR_SIZE is 8, but the code makes both the
32-bit addresses you can read/write in that 8-byte range
behave the same way. Is that really what the hardware does ?
Or does it actually have 1 32-bit register per core, spaced
8 bytes apart ?


Yes, the hardware was designed like that. It have 1 32-bit register
per core but spaced 8 bytes apart.

I assume they were planing to add more ISRs in the future but as the
product line have been ceased I'm not going to handle that.

I'll send a patch for fix.

Thanks.

- Jiaxun




thanks
-- PMM

Re: qemu bsd-user plans

[Warner Losh]

On Mon, Jan 11, 2021 at 6:27 AM Daniel P. Berrangé 
wrote:

> On Fri, Jan 08, 2021 at 12:41:30PM -0700, Warner Losh wrote:
> > The FreeBSD project has rewritten bsd-user. We've been working on this
> for
> > quite some time (the earliest commits date from 2013). Maybe a dozen
> people
> > have worked on this over time, and there's 3 or 4 active developers
> focused
> > on FreeBSD changes at the moment.
>
> The fact that you have 3-4 people involved in this work is will be very
> helpful to you going forward with a QEMU maintenance.
>
> The biggest problem with getting code merged into QEMU is an insufficient
> number of reviewers for the amount of patches sent. Since we have a rule
> that patches need a review from someone else who isn't the author, if there
> are two people with expertize to review patches in a given QEMU subsystem,
> then they can become self-sufficient and review each others patches on
> qemu-devel, which then makes merging much more productive.
>

Yes. That's my hope too. We've been doing this internally for changes we've
been landing lately, so I think expanding our process to also do this with
qemu upstream will be a natural progression...


> If anyone wants to be automatically CC'd on patches for bsd-user for the
> purposes of acting as a designated reviewer, they can added to MAINTAINERS
> file to, alongside the primary maintainer(s).
>

I'll be adding myself, at least, to MAINTAINERS and encouraging the others
that have been working on this to take the time to review when I post. They
are quite willing, but may lack the time, alas, so I'll do what I can to
time the patches such that at least one of them has the time in a
reasonable time frame...


> > So, my new plan is to rebase what changes I can to the tip of master and
> > submit those for review. I'll work with the developers on the FreeBSD
> side
> > to ensure they are included in reviews in addition to the normal
> qemu-devel
> > list. This will allow us to pare down the deltas between our code and
> > upstream to allow us to make progress. The changes will be held to the
> > standard 'makes things better'. Given how broken bsd-user is today in
> qemu
> > upstream, at first that will a very easy standard to make.
> >
> > The first patch I'll submit will be changing MAINTAINERS to point to me,
> > since I'm acting as the point person in this effort. I'll then re-submit
> > some other changes that I've submitted in the past, but CC the FreeBSD
> > folks that are currently active (they were only CC'd to former developers
> > who lack the time to review).
>
> > But before I get too far down this path, I thought I'd send out what's
> > going on to qemu-devel so I can get feedback and adjust the plan into
> > something that's mutually agreeable so time I put towards this is not
> > wasted.
>
> No objections from me. Since current bsd-user is orphaned, largely
> unusable, and you're volunteering your time to make it better, I'm
> supportive of whatever you believe is the most time efficient way
> to improve bsd-user.
>
> I presume some of the current QEMU maintainers knowledgable about
> linux-user will be able to review the patches, and as mentioned
> above, if other BSD devs currently active in bsd-user work can
> also provide reviews on qemu-devel that'll be useful long term.
>

Yes. Many of the patches are copied from there, as well as the initial
version coming largely from there as well (it seems, I wasn't around at the
time and base this entirely on code similarities).

The FreeBSD project makes such heavy use of this, that I really want to
find some way we can stay current and maybe even have better abstractions
that make all user-mode emulation easier...

Warner

Re: [PATCH 14/18] target/arm: secure stage 2 translation regime

[Richard Henderson]

On 12/18/20 12:37 AM, remi.denis.courm...@huawei.com wrote:
> @@ -11286,8 +11299,10 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
> uint64_t address,
>  
>  ap = extract32(attrs, 4, 2);
>  
> -if (mmu_idx == ARMMMUIdx_Stage2) {
> -ns = true;
> +if (mmu_idx == ARMMMUIdx_Stage2 || mmu_idx == ARMMMUIdx_Stage2_S) {
> +if (mmu_idx == ARMMMUIdx_Stage2) {
> +ns = true;
> +}
>  xn = extract32(attrs, 11, 2);

Does this want an unconditional

  ns = mmu_idx == ARMMMUIdx_Stage2;

When can ns be true and mmu_idx == ARMMMUIdx_Stage2_S?

Otherwise,

Reviewed-by: Richard Henderson 


r~

Re: [PATCH 14/18] target/arm: secure stage 2 translation regime

[Richard Henderson]

On 12/18/20 12:37 AM, remi.denis.courm...@huawei.com wrote:
> @@ -3586,10 +3586,10 @@ static void ats_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  /* fall through */
>  case 1:
>  if (ri->crm == 9 && (env->uncached_cpsr & CPSR_PAN)) {
> -mmu_idx = (secure ? ARMMMUIdx_SE10_1_PAN
> +mmu_idx = (secure ? ARMMMUIdx_Stage1_SE1_PAN
> : ARMMMUIdx_Stage1_E1_PAN);
>  } else {
> -mmu_idx = secure ? ARMMMUIdx_SE10_1 : ARMMMUIdx_Stage1_E1;
> +mmu_idx = secure ? ARMMMUIdx_Stage1_SE1 : 
> ARMMMUIdx_Stage1_E1;
>  }
>  break;

Was this a bug that we weren't treating SE10 properly vs two-stage lookup?  If
so, it warrants mentioning in the patch description.


r~

Re: [PATCH 2/2] sysemu: Let VMChangeStateHandler take boolean 'running' argument

[David Gibson]

On Mon, Jan 11, 2021 at 04:20:20PM +0100, Philippe Mathieu-Daudé wrote:
> The 'running' argument from VMChangeStateHandler does not require
> other value than 0 / 1. Make it a plain boolean.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

ppc parts
Acked-by: David Gibson 

> ---
>  include/sysemu/runstate.h   | 10 --
>  target/arm/kvm_arm.h|  2 +-
>  target/ppc/cpu-qom.h|  2 +-
>  accel/xen/xen-all.c |  2 +-
>  audio/audio.c   |  2 +-
>  block/block-backend.c   |  2 +-
>  gdbstub.c   |  2 +-
>  hw/block/pflash_cfi01.c |  2 +-
>  hw/block/virtio-blk.c   |  2 +-
>  hw/display/qxl.c|  2 +-
>  hw/i386/kvm/clock.c |  2 +-
>  hw/i386/kvm/i8254.c |  2 +-
>  hw/i386/kvmvapic.c  |  2 +-
>  hw/i386/xen/xen-hvm.c   |  2 +-
>  hw/ide/core.c   |  2 +-
>  hw/intc/arm_gicv3_its_kvm.c |  2 +-
>  hw/intc/arm_gicv3_kvm.c |  2 +-
>  hw/intc/spapr_xive_kvm.c|  2 +-
>  hw/misc/mac_via.c   |  2 +-
>  hw/net/e1000e_core.c|  2 +-
>  hw/nvram/spapr_nvram.c  |  2 +-
>  hw/ppc/ppc.c|  2 +-
>  hw/ppc/ppc_booke.c  |  2 +-
>  hw/s390x/tod-kvm.c  |  2 +-
>  hw/scsi/scsi-bus.c  |  2 +-
>  hw/usb/hcd-ehci.c   |  2 +-
>  hw/usb/host-libusb.c|  2 +-
>  hw/usb/redirect.c   |  2 +-
>  hw/vfio/migration.c |  2 +-
>  hw/virtio/virtio-rng.c  |  2 +-
>  hw/virtio/virtio.c  |  2 +-
>  net/net.c   |  2 +-
>  softmmu/memory.c|  2 +-
>  softmmu/runstate.c  |  2 +-
>  target/arm/kvm.c|  2 +-
>  target/i386/kvm/kvm.c   |  2 +-
>  target/i386/sev.c   |  2 +-
>  target/i386/whpx/whpx-all.c |  2 +-
>  target/mips/kvm.c   |  4 ++--
>  ui/gtk.c|  2 +-
>  ui/spice-core.c |  2 +-
>  41 files changed, 49 insertions(+), 43 deletions(-)
> 
> diff --git a/include/sysemu/runstate.h b/include/sysemu/runstate.h
> index 3ab35a039a0..a5356915734 100644
> --- a/include/sysemu/runstate.h
> +++ b/include/sysemu/runstate.h
> @@ -10,7 +10,7 @@ bool runstate_is_running(void);
>  bool runstate_needs_reset(void);
>  bool runstate_store(char *str, size_t size);
>  
> -typedef void VMChangeStateHandler(void *opaque, int running, RunState state);
> +typedef void VMChangeStateHandler(void *opaque, bool running, RunState 
> state);
>  
>  VMChangeStateEntry *qemu_add_vm_change_state_handler(VMChangeStateHandler 
> *cb,
>   void *opaque);
> @@ -20,7 +20,13 @@ VMChangeStateEntry 
> *qdev_add_vm_change_state_handler(DeviceState *dev,
>   VMChangeStateHandler 
> *cb,
>   void *opaque);
>  void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
> -void vm_state_notify(int running, RunState state);
> +/**
> + * vm_state_notify: Notify the state of the VM
> + *
> + * @running: whether the VM is running or not.
> + * @state: the #RunState of the VM.
> + */
> +void vm_state_notify(bool running, RunState state);
>  
>  static inline bool shutdown_caused_by_guest(ShutdownCause cause)
>  {
> diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
> index eb81b7059eb..68ec970c4f4 100644
> --- a/target/arm/kvm_arm.h
> +++ b/target/arm/kvm_arm.h
> @@ -352,7 +352,7 @@ void kvm_arm_get_virtual_time(CPUState *cs);
>   */
>  void kvm_arm_put_virtual_time(CPUState *cs);
>  
> -void kvm_arm_vm_state_change(void *opaque, int running, RunState state);
> +void kvm_arm_vm_state_change(void *opaque, bool running, RunState state);
>  
>  int kvm_arm_vgic_probe(void);
>  
> diff --git a/target/ppc/cpu-qom.h b/target/ppc/cpu-qom.h
> index 63b9e8632ca..118baf8d41f 100644
> --- a/target/ppc/cpu-qom.h
> +++ b/target/ppc/cpu-qom.h
> @@ -218,7 +218,7 @@ extern const VMStateDescription vmstate_ppc_timebase;
>  .offset = vmstate_offset_value(_state, _field, PPCTimebase),  \
>  }
>  
> -void cpu_ppc_clock_vm_state_change(void *opaque, int running,
> +void cpu_ppc_clock_vm_state_change(void *opaque, bool running,
> RunState state);
>  #endif
>  
> diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> index 878a4089d97..3756aca27be 100644
> --- a/accel/xen/xen-all.c
> +++ b/accel/xen/xen-all.c
> @@ -122,7 +122,7 @@ static void xenstore_record_dm_state(struct xs_handle 
> *xs, const char *state)
>  }
>  
>  
> -static void xen_change_state_handler(void *opaque, int running,
> +static void xen_change_state_handler(void *opaque, bool running,
>   RunState state)
>  {
>  if (running) {
> diff --git a/audio/audio.c b/audio/audio.c
> index b48471bb3f6..f2d56e7e57d 100644
> --- a/audio/audio.c
> +++ b/audio/audio.c
> @@ -1549,7 +1549,7 @@ static int audio_driver_init(AudioState *s, struct 
> audio_driver *drv,
>  }
>  }
>  
> -static void 

Re: [PATCH] hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30

[David Gibson]

On Mon, Jan 11, 2021 at 09:30:07PM +, Peter Maydell wrote:
> In commit 34d0831f38fd8 the ppc-uic device was added, with a dcr-base
> property. The intention was that the default value of dcr-base should be
> the one that most of our boards need, so that in the common case they
> don't need to specify a property value.
> 
> All QEMU boards with a UIC use a dcr-base of 0xc0, with the exception of
> sam460ex which has four UICs and so puts them at 0xc0, 0xd0, 0xe0, 0xf0.
> So 0xc0 is the obvious right choice for the default dcr-base.
> 
> The board code conversions in commits 0270d74ef88623505 (bamboo) and
> c5ac9dc64fa552a6 (virtex_ml507) assumed that default was 0xc0. Unfortunately
> the actual default in 34d0831f38fd8 was 0x30, by mistake, so the
> bamboo and virtex_ml507 boards were broken as they were converted
> away from ppcuic_init() (which always specifies the dcr_base property
> value explicitly).
> 
> Set the default dcr-base to 0xc0 as was intended, fixing bamboo and
> virtex_ml507.
> 
> Fixes: 34d0831f38fd8
> Reported-by: Nathan Chancellor 
> Suggested-by: BALATON Zoltan 
> Signed-off-by: Peter Maydell 

Applied, thanks.

> ---
> This is the right way to fix the bug I was trying to fix with
> "hw/ppc/ppc400_bamboo: Set dcr-base correctly when creating UIC".
> 
> David: you probably want to put this patch in your ppc queue
> before "hw/ppc/ppc405_uc: Drop use of ppcuic_init()", as that patch
> also assumes the 0xc0 default.

Done.

> 
>  hw/intc/ppc-uic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/intc/ppc-uic.c b/hw/intc/ppc-uic.c
> index b21951eea83..7171de7b355 100644
> --- a/hw/intc/ppc-uic.c
> +++ b/hw/intc/ppc-uic.c
> @@ -274,7 +274,7 @@ static void ppc_uic_realize(DeviceState *dev, Error 
> **errp)
>  
>  static Property ppc_uic_properties[] = {
>  DEFINE_PROP_LINK("cpu", PPCUIC, cpu, TYPE_CPU, CPUState *),
> -DEFINE_PROP_UINT32("dcr-base", PPCUIC, dcr_base, 0x30),
> +DEFINE_PROP_UINT32("dcr-base", PPCUIC, dcr_base, 0xc0),
>  DEFINE_PROP_BOOL("use-vectors", PPCUIC, use_vectors, true),
>  DEFINE_PROP_END_OF_LIST()
>  };

-- 
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: [PATCH 16/18] target/arm: add ARMv8.4-SEL2 extension

[Richard Henderson]

On 12/18/20 12:37 AM, remi.denis.courm...@huawei.com wrote:
> @@ -3297,7 +3301,7 @@ typedef ARMCPU ArchCPU;
>   * We put flags which are shared between 32 and 64 bit mode at the top
>   * of the word, and flags which apply to only one mode at the bottom.
>   *
> - *  31  201814  9  0
> + *  31  201914  9  0
>   * +--+-+-+--+--+
>   * |  | |   TBFLAG_A32   |  |
>   * |  | +-+--+  TBFLAG_AM32 |
> @@ -3346,6 +3350,7 @@ FIELD(TBFLAG_A32, HSTR_ACTIVE, 16, 1)
>   * the same thing as the current security state of the processor!
>   */
>  FIELD(TBFLAG_A32, NS, 17, 1)
> +FIELD(TBFLAG_A32, EEL2, 18, 1)

Note that via other in-flight patch sets we have run out of bits here.  I've
rearranged them in

https://patchew.org/QEMU/2021090113.303726-1-richard.hender...@linaro.org/

This should be nothing but a minor confict to fix up.


r~

Re: [PATCH 15/18] target/arm: set HPFAR_EL2.NS on secure stage 2 faults

[Richard Henderson]

On 12/18/20 12:37 AM, remi.denis.courm...@huawei.com wrote:
> From: Rémi Denis-Courmont 
> 
> Signed-off-by: Rémi Denis-Courmont 
> ---
>  target/arm/cpu.h| 2 ++
>  target/arm/helper.c | 6 ++
>  target/arm/internals.h  | 2 ++
>  target/arm/tlb_helper.c | 3 +++
>  4 files changed, 13 insertions(+)

Reviewed-by: Richard Henderson 


r~