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
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
> + *
>
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
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
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
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
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
> 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
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
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
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 +)
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
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
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
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
>
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(+)
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
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 ++
>
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
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;
> > -}
> > -
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
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,
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);
> -
> -
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
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
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
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.
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.
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
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 +-
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
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.
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 +-
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
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
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
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
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
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
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 |
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
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
[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
[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
[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:
[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
[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
[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
[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
[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
[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
[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:
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
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
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
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
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
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 +
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
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
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
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 |
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 +
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
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
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 +++
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
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 ++
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
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
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 ++
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
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
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
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
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 +
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).
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
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
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
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
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
> > >
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
在 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
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
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 ==
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)) {
> -
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
> ---
>
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
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
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,
1 - 100 of 362 matches
Mail list logo
