From: Bin Meng
SiFive FU540 SoC supports booting from several sources, which are
controlled using the Mode Select (MSEL[3:0]) pins on the chip.
Typically, the boot process runs through several stages before it
begins execution of user-provided programs.
The SoC supports booting from memory-mappe
From: Bin Meng
Per the SiFive manual, all E/U series CPU cores' reset vector is
at 0x1004. Update our codes to match the hardware.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1592268641-7478-3-git-send-email-bmeng...@gmail.com
Message-Id: <1592268641-7478-3-git-send-email
This is the initial commit of the Ibex UART device. Serial TX is
working, while RX has been implemeneted but untested.
This is based on the documentation from:
https://docs.opentitan.org/hw/ip/uart/doc/
Signed-off-by: Alistair Francis
Reviewed-by: LIU Zhiwei
---
include/hw/char/ibex_uart.h | 11
From: Bin Meng
Current IBEX CPU init routine name seems to be too generic.
Since it uses a different reset vector from the generic one,
it merits a dedicated name.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1592268641-7478-2-git-send-email-bmeng...@gmail.com
Message-Id:
From: Bin Meng
Do various minor clean-ups to the exisiting codes for:
- coding convention conformance
- remove unnecessary blank lines
- spell SiFive correctly
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-6-git-send-email-bmeng...@gmail.com
Message-Id: <1
From: Bin Meng
On SiFive FU540 SoC, the value stored at physical address 0x1000
stores the MSEL pin state that is used to control the next boot
location that ROM codes jump to.
Add a new property msel to sifive_u machine for this.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-
From: Bin Meng
It is enough to simply map the SiFive FU540 DDR memory controller
into the MMIO space using create_unimplemented_device(), to make
the upstream U-Boot v2020.07 DDR memory initialization codes happy.
Note we do not generate device tree fragment for the DDR memory
controller. Since
From: Bin Meng
In prepration to add more properties to this machine, rename the
existing serial property get/set functions to a generic name.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-11-git-send-email-bmeng...@gmail.com
Message-Id: <1591625864-31494-11
From: Bin Meng
Upstream U-Boot v2020.07 codes switch to access SiFive FU540 OTP
based on device tree information. Let's generate the device tree
node for OTP.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-5-git-send-email-bmeng...@gmail.com
Message-Id: <159
From: Bin Meng
Move the flash and DRAM to the end of the SoC memmap table.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1592268641-7478-5-git-send-email-bmeng...@gmail.com
Message-Id: <1592268641-7478-5-git-send-email-bmeng...@gmail.com>
Signed-off-by: Alistair Francis
--
From: Bin Meng
The HiFive Unleashed board wires GPIO pin#10 to the input of the
system reset signal. Let's set up the GPIO pin#10 and insert a
"gpio-restart" device tree node so that reboot is now functional
with QEMU 'sifive_u' machine.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Me
From: Bin Meng
There is no need to retrieve all PLIC IRQ information in order to
just connect the GEM IRQ. Use qdev_get_gpio_in() directly like
what is done for other peripherals.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-4-git-send-email-bmeng...@gmail
Also correct the name of the VVMA instruction.
Signed-off-by: Alistair Francis
Reviewed-by: Richard Henderson
---
target/riscv/insn32.decode| 8 ++-
.../riscv/insn_trans/trans_privileged.inc.c | 38 -
target/riscv/insn_trans/trans_rvh.inc.c | 57
From: Bin Meng
At present the GPIO output IRQs are triggered each time any GPIO
register is written. However this is not correct. We should only
trigger the output IRQ when the pin is configured as output enable.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-3149
Call the helper_hyp_tlb_flush() function on hfence instructions which
will generate an illegal insruction execption if we don't have
permission to flush the Hypervisor level TLBs.
Signed-off-by: Alistair Francis
Reviewed-by: Richard Henderson
---
target/riscv/helper.h | 5 +++
From: Bin Meng
Adding a _ to keep some consistency among the CPU init routines.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-Id: <1591837729-27486-4-git-send-email-bmeng...@gmail.com>
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 8
1 file changed, 4 inse
From: Bin Meng
SiFive FU540 SoC integrates a GPIO controller with 16 GPIO lines.
This hooks the exsiting SiFive GPIO model to the SoC, and adds its
device tree data as well.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-8-git-send-email-bmeng...@gmail.com
M
Signed-off-by: Alistair Francis
Reported-by: Damien Hedde
---
hw/riscv/opentitan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
index f6776da8e9..011e4f7ee2 100644
--- a/hw/riscv/opentitan.c
+++ b/hw/riscv/opentitan.c
@@ -25,12
Signed-off-by: Alistair Francis
Reviewed-by: Richard Henderson
---
target/riscv/cpu_helper.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index eda7057663..75d2ae3434 100644
--- a/target/riscv/cpu_helper.c
+++
From: Bin Meng
Add a new property to represent the number of GPIO pins supported
by the GPIO controller.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-7-git-send-email-bmeng...@gmail.com
Message-Id: <1591625864-31494-7-git-send-email-bmeng...@gmail.com>
Sig
From: Bin Meng
There is no need to have two functions that have almost the same
codes for 32-bit and 64-bit imacu CPUs.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-Id: <1591837729-27486-3-git-send-email-bmeng...@gmail.com>
Signed-off-by: Alistair Francis
---
target/riscv/cp
Signed-off-by: Alistair Francis
Reviewed-by: Richard Henderson
---
target/riscv/cpu_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 62fe1ecc8f..eda7057663 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/
From: Bin Meng
This was done in the virt & sifive_u codes, but opentitan codes were
missed. Remove the riscv_ prefix of the machine* and soc* functions.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-3-git-send-email-bmeng...@gmail.com
Message-Id: <159162586
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
---
include/hw/riscv/opentitan.h | 3 +++
hw/riscv/opentitan.c | 14 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/include/hw/riscv/opentitan.h b/include/hw/riscv/
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
---
target/riscv/pmp.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index 0e6b640fbd..9418660f1b 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -233,12
From: Ian Jiang
The function that makes NaN-boxing when a 32-bit value is assigned
to a 64-bit FP register is split out to a helper gen_nanbox_fpr().
Then it is applied in translating of the FLW instruction.
Signed-off-by: Ian Jiang
Message-Id: <20200128003707.17028-1-ianjiang@gmail.com>
Re
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
---
include/hw/riscv/opentitan.h | 13 +
hw/riscv/opentitan.c | 25 +++--
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/include/hw/riscv/opentitan.
The Ibex core contains a PLIC that although similar to the RISC-V spec
is not RISC-V spec compliant.
This patch implements a Ibex PLIC in a somewhat generic way.
As the current RISC-V PLIC needs tidying up, my hope is that as the Ibex
PLIC move towards spec compliance this PLIC implementation can
From: Bin Meng
This was done in the virt & sifive_u codes, but sifive_e codes were
missed. Remove the riscv_ prefix of the machine* and soc* functions.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591625864-31494-2-git-send-email-bmeng...@gmail.com
Message-Id: <1591625864
From: Bin Meng
There is no need to have two functions that have exactly the same
codes for 32-bit and 64-bit base CPUs.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-id: 1591837729-27486-1-git-send-email-bmeng...@gmail.com
Message-Id: <1591837729-27486-1-git-send-email-bmeng...
From: Bin Meng
There is no need to have two functions that have almost the same
codes for 32-bit and 64-bit gcsu CPUs.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Message-Id: <1591837729-27486-2-git-send-email-bmeng...@gmail.com>
Signed-off-by: Alistair Francis
---
target/riscv/cpu
Signed-off-by: Alistair Francis
---
include/hw/riscv/sifive_e.h | 1 +
hw/riscv/sifive_e.c | 34 ++
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/include/hw/riscv/sifive_e.h b/include/hw/riscv/sifive_e.h
index d386ea9223..637414130b 10064
l-riscv-to-apply-20200618-1
for you to fetch changes up to fad6a8463510ff5e0fb31bb451a6c3218a45d179:
hw/riscv: sifive_u: Add a dummy DDR memory controller device (2020-06-18
23:09:16 -0700)
This is a range of patches for RISC-V.
On Thu, 18 Jun 2020 19:00:34 +0200
Aleksandar Markovic wrote:
> четвртак, 18. јун 2020., Cornelia Huck је написао/ла:
>
> > On Mon, 15 Jun 2020 15:18:48 -
> > Alex Bennée <1883...@bugs.launchpad.net> wrote:
> >
> > > Public bug reported:
> > >
> > > >From time to time I find check-tcg c
On Wed, Jun 17, 2020 at 10:08 PM Bin Meng wrote:
>
> Hi Alistair,
>
> On Thu, Jun 18, 2020 at 8:41 AM Bin Meng wrote:
> >
> > Hi Alistair,
> >
> > On Thu, Jun 18, 2020 at 12:40 AM Alistair Francis
> > wrote:
> > >
> > > On Mon, Jun 15, 2020 at 5:51 PM Bin Meng wrote:
> > > >
> > > > From: Bin
On 18/06/2020 21.04, Claudio Fontana wrote:
> refactoring of cpus.c continues with cpu timer state extraction.
>
> cpu-timers: responsible for the cpu timers state, and for access to
> cpu clocks and ticks.
>
> icount: counts the TCG instructions executed. As such it is specific to
> the TCG acce
On 18/06/2020 21.03, Claudio Fontana wrote:
> move arch_init, balloon, cpus, ioport, memory, memory_mapping, qtest.
>
> They are all specific to CONFIG_SOFTMMU.
>
> Signed-off-by: Claudio Fontana
> Reviewed-by: Alex Bennée
> ---
> MAINTAINERS | 12 ++--
On 18.06.2020 20:38, Peter Maydell wrote:
For -icount mode to work, there are requirements on the target/
code (notably around marking up "I/O" instructions). Unfortunately
we've never documented what these are, which makes it pretty rough
for people writing new targets or reviewing changes to
> On Jun 18, 2020, at 6:29 PM, Richard Henderson
> wrote:
>
> On 6/12/20 9:20 PM, Lijun Pan wrote:
>> +#define VMULH_DO(name, op, element, cast_orig, cast_temp) \
>> +void helper_vmulh##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
>> \
>> +{
> On Jun 18, 2020, at 6:27 PM, Richard Henderson
> wrote:
>
> On 6/12/20 9:20 PM, Lijun Pan wrote:
>> vmulld: Vector Multiply Low Doubleword.
>>
>> Signed-off-by: Lijun Pan
>> ---
>> target/ppc/helper.h | 1 +
>> target/ppc/int_helper.c | 1 +
>> target/ppc/translat
> On Jun 18, 2020, at 6:19 PM, Richard Henderson
> wrote:
>
> On 6/12/20 9:20 PM, Lijun Pan wrote:
>> POWER ISA 3.1 introduces following byte-reverse instructions:
>> brd: Byte-Reverse Doubleword X-form
>> brw: Byte-Reverse Word X-form
>> brh: Byte-Reverse Halfword X-form
>>
>> Signed-off-by
> On Jun 18, 2020, at 6:09 PM, Richard Henderson
> wrote:
>
> On 6/15/20 1:53 PM, Lijun Pan wrote:
+static inline void uint128_add(uint64_t ah, uint64_t al, uint64_t bh,
+ uint64_t bl, uint64_t *rh, uint64_t *rl, uint64_t *ca)
+{
+ __uint128_t a = (__uint128_t)ah
On Thu, Jun 18, 2020 at 08:55:53AM +0200, Markus Armbruster wrote:
> Either I'm confused (quite possible), or kvmppc_check_papr_resize_hpt()
> can leak an Error object on failure. Please walk through the code with
> me:
>
> kvmppc_check_papr_resize_hpt(&resize_hpt_err);
>
> This sets @re
On Thu, 18 Jun 2020 16:18:20 PDT (-0700), alistai...@gmail.com wrote:
On Thu, Jun 18, 2020 at 3:42 PM Palmer Dabbelt wrote:
On Wed, 10 Jun 2020 15:13:49 PDT (-0700), alistai...@gmail.com wrote:
> On Thu, May 28, 2020 at 11:13 AM Alistair Francis
wrote:
>>
>> On Thu, May 21, 2020 at 8:57 AM A
On 2020/6/18 下午10:05, no-re...@patchew.org wrote:
/tmp/qemu-test/src/tests/qht-bench.c:287:29: error: implicit conversion from
'unsigned long' to 'double' changes value from 18446744073709551615 to
18446744073709551616 [-Werror,-Wimplicit-int-float-conversion]
*threshold = rate * UIN
Patchew URL:
https://patchew.org/QEMU/20200619020602.118306-1-da...@gibson.dropbear.id.au/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin
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.
This allows failures to be reported richly and idiomatically.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/kvm/kvm-all.c | 4 +++-
include/exec/host-trust-limitation.h | 2 +-
target/i386/sev.c|
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
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
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 has a similar
mechanism. POWER's Protected Execution Framework (PEF) accomplishes a
similar g
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
---
target/ppc/pef
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 host trust
limitation, use a QOM method on that interface, rather than a bare function
pointer fo
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 th
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 reso
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
On Thu, Jun 18, 2020 at 1:03 AM Bin Meng wrote:
>
> On Wed, Jun 17, 2020 at 3:30 AM Atish Patra wrote:
> >
> > Currently, all riscv machines have identical reset vector code
> > implementations with memory addresses being different for all machines.
> > They can be easily combined into a single f
On Thu, Jun 18, 2020 at 1:26 AM Bin Meng wrote:
>
> On Wed, Jun 17, 2020 at 3:29 AM Atish Patra wrote:
> >
> > Currently, the fdt is copied to the ROM after the reset vector. The firmware
> > has to copy it to DRAM. Instead of this, directly copy the device tree to a
> > pre-computed dram address
On Wed, Jun 10, 2020 at 11:37:14PM +0200, Halil Pasic wrote:
> On Wed, 10 Jun 2020 14:25:54 +1000
> David Gibson wrote:
>
> > > > I'm going to definitely have a good look at that. What I think special
> > > > about s390 is that F_ACCESS_PLATFORM is hurting us because all IO needs
> > > > to go th
On Wed, Jun 10, 2020 at 03:57:03PM +0200, Halil Pasic wrote:
> On Wed, 10 Jun 2020 14:29:29 +1000
> David Gibson wrote:
>
> > On Tue, Jun 09, 2020 at 06:28:39PM +0200, Halil Pasic wrote:
> > > On Tue, 9 Jun 2020 17:47:47 +0200
> > > Claudio Imbrenda wrote:
> > >
> > > > On Tue, 9 Jun 2020 11:41
On Wed, Jun 10, 2020 at 03:19:22PM +0200, Viktor Mihajlovski wrote:
>
>
> On 6/10/20 12:24 PM, David Hildenbrand wrote:
> > On 10.06.20 12:07, David Gibson wrote:
> > > On Wed, Jun 10, 2020 at 09:22:45AM +0200, David Hildenbrand wrote:
> > > > On 10.06.20 06:31, David Gibson wrote:
> > > > > On T
On Wed, Jun 10, 2020 at 12:24:14PM +0200, David Hildenbrand wrote:
> On 10.06.20 12:07, David Gibson wrote:
> > On Wed, Jun 10, 2020 at 09:22:45AM +0200, David Hildenbrand wrote:
> >> On 10.06.20 06:31, David Gibson wrote:
> >>> On Tue, Jun 09, 2020 at 12:44:39PM -0400, Michael S. Tsirkin wrote:
>
Another way to reproduce this bug is with qemu-s390x and a cross-
compiled binary:
$ s390x-linux-gnu-gcc-5 -static -o bug-sqrtl-one-line.s390x bug-sqrtl-one-line.c
$ qemu-s390x bug-sqrtl-one-line.s390x
Segmentation fault (core dumped)
Find attached the binary.
** Attachment added: "statically co
On Mon, Jun 15, 2020 at 11:20:31AM +0200, Greg Kurz wrote:
> On Sat, 13 Jun 2020 17:18:04 +1000
> David Gibson wrote:
>
> > On Thu, Jun 11, 2020 at 03:40:33PM +0200, Greg Kurz wrote:
> > > Nested KVM-HV only works on POWER9.
> > >
> > > Signed-off-by: Greg Kurz
> > > Reviewed-by: Laurent Vivier
Public bug reported:
When I try to use -fsoption on OSX I receive this error:
-fsdev local,security_model=mapped,id=fsdev0,path=devel/dmos-example:
There is no option group 'fsdev'
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because yo
On 6/12/20 9:20 PM, Lijun Pan wrote:
> This patch series add several newly introduced 32/64-bit vector
> instructions in Power ISA 3.1. The newly added instructions are
> flagged as ISA300 temporarily in vmx-ops.inc.c and vmx-impl.inc.c
> to make them compile and function since Power ISA 3.1, toget
On 6/12/20 9:20 PM, Lijun Pan wrote:
> +#define VDIV_MOD_DO(name, op, element) \
> +void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b) \
> +{ \
> +int i;
On 6/12/20 9:20 PM, Lijun Pan wrote:
> The prototypes of muls64/mulu64 in host-utils.h should match the
> definitions in host-utils.c
>
> Signed-off-by: Lijun Pan
> ---
> include/qemu/host-utils.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Richard Henderson
CC: qe
On 6/12/20 9:20 PM, Lijun Pan wrote:
> +void helper_vmulhsd(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
> +{
> + int i;
> + uint64_t h64 = 0;
> + uint64_t l64 = 0;
> +
> + for (i = 0; i < 2; i++) {
> + muls64(&l64, &h64, a->s64[i], b->s64[i]);
> + r->s64[i] = h
On 6/12/20 9:20 PM, Lijun Pan wrote:
> +#define VMULH_DO(name, op, element, cast_orig, cast_temp)\
> +void helper_vmulh##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
> \
> +{
> \
> + int i;
On Thu, Jun 18, 2020 at 3:42 PM Palmer Dabbelt wrote:
>
> On Wed, 10 Jun 2020 15:13:49 PDT (-0700), alistai...@gmail.com wrote:
> > On Thu, May 28, 2020 at 11:13 AM Alistair Francis
> > wrote:
> >>
> >> On Thu, May 21, 2020 at 8:57 AM Alistair Francis
> >> wrote:
> >> >
> >> > On Wed, May 20,
On 6/12/20 9:20 PM, Lijun Pan wrote:
> vmulld: Vector Multiply Low Doubleword.
>
> Signed-off-by: Lijun Pan
> ---
> target/ppc/helper.h | 1 +
> target/ppc/int_helper.c | 1 +
> target/ppc/translate/vmx-impl.inc.c | 1 +
> target/ppc/translate/vmx-ops.inc.c | 1 +
>
On 6/12/20 9:20 PM, Lijun Pan wrote:
> POWER ISA 3.1 introduces following byte-reverse instructions:
> brd: Byte-Reverse Doubleword X-form
> brw: Byte-Reverse Word X-form
> brh: Byte-Reverse Halfword X-form
>
> Signed-off-by: Lijun Pan
> ---
> target/ppc/translate.c | 62
On 6/15/20 1:53 PM, Lijun Pan wrote:
>>> +static inline void uint128_add(uint64_t ah, uint64_t al, uint64_t bh,
>>> + uint64_t bl, uint64_t *rh, uint64_t *rl, uint64_t *ca)
>>> +{
>>> + __uint128_t a = (__uint128_t)ah << 64 | (__uint128_t)al;
>>> + __uint128_t b = (__uint128_t)bh << 6
Patchew URL:
https://patchew.org/QEMU/2020061858.23287-1-wall...@linux.ibm.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
e
On Wed, 10 Jun 2020 15:13:49 PDT (-0700), alistai...@gmail.com wrote:
On Thu, May 28, 2020 at 11:13 AM Alistair Francis wrote:
On Thu, May 21, 2020 at 8:57 AM Alistair Francis wrote:
>
> On Wed, May 20, 2020 at 4:08 PM Palmer Dabbelt wrote:
> >
> > On Thu, 14 May 2020 13:47:10 PDT (-0700), A
Of course it’s open source, I get that. When I say „xyz should be done“
then in the sense of „2+2 should be 4“ not in the sense of „you must
implement xyz right now“ ;)
Nonetheless, if you run e.g. on an ARM platform the command
qemu-system-x86_64 -cpu help
then it shouldn’t list a slew of CPUs
Patchew URL:
https://patchew.org/QEMU/2020061858.23287-1-wall...@linux.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v3 0/8] s390: Extended-Length SCCB & DIAGNOSE 0x318
Type: series
Message-id: 2020061858.2328
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, l
DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
of diagnostic information that is collected by the firmware in the case
of hardware/firmware service events.
QEMU handles the instruction by storing the info in the CPU state. A
subsequent register sync will communicate the da
The start of the CPU entry region in the Read SCP Info response data is
denoted by the offset_cpu field. As such, QEMU needs to begin creating
entries at this address. Note that the length of the Read SCP Info data
(data_len) denotes the same value as the cpu offset.
This is in preparation of when
Signed-off-by: Collin Walling
---
linux-headers/asm-s390/kvm.h | 5 -
linux-headers/linux/kvm.h| 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0138ccb0d8..98665dff19 100644
--- a/linux-headers/asm-s390/
Functions within read scp/cpu info will need access to the machine
state. Let's make a call to retrieve the machine state once and
pass the appropriate data to the respective functions.
Signed-off-by: Collin Walling
Reviewed-by: David Hildenbrand
Reviewed-by: Thomas Huth
---
hw/s390x/sclp.c |
The header of the SCCB contains the actual length of the SCCB. Instead
of using a static 4K size, let's allow for a variable size determined
by the value set in the header. The proper checks are already in place
to ensure the SCCB length is sufficent to store a full response, and
that the length do
Rework the SCLP boundary check to account for different SCLP commands
(eventually) allowing different boundary sizes.
Move the length check code into a separate function, and introduce a
new function to determine the length of the read SCP data (i.e. the size
from the start of the struct to where
The SCCB must be checked for a sufficient length before it is filled
with any data. If the length is insufficient, then the SCLP command
is suppressed and the proper response code is set in the SCCB header.
Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
Signed-off-by: Collin
Changelog:
v3
• Device IOCTLs removed
- diag 318 info is now communicated via sync_regs
• Reset code removed
- this is now handled in KVM
- diag318_info is stored within the CPU reset portion of the
S390CPUState
• Various cleanups for ELS prel
BTW: just because I bracket a report with why I think a matter is worth
fixing, shouldn’t make it „invalid“.
The instructions aren’t implemented, yet the CPUs are listed as
available, which is a bug in my book, as functionality is advertised
that is unavailable.
--
You received this bug notifica
The comments with the other reports were just in support of getting them
fixed, and providing a reason as to why that matters. Someone looking at
those reports may not read this one, and as the issues are symptoms of
the same larger issue, this report was filed as an overarching report,
as AVX is j
> On Jun 15, 2020, at 3:49 AM, Stefan Hajnoczi wrote:
>
>
> It's challenging to implement a fast and secure IOMMU. The simplest
> approach is secure but not fast: add protocol messages for
> DMA_READ(iova, length) and DMA_WRITE(iova, buffer, length).
>
We do have protocol messages f
Patchew URL: https://patchew.org/QEMU/20200618210649.22451-1-jrt...@jrtc27.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export
Claiming an interrupt and changing the source priority both potentially
affect whether an interrupt is pending, thus we must re-compute xEIP.
Note that we don't put the sifive_plic_update inside sifive_plic_claim
so that the logging of a claim (and the resulting IRQ) happens before
the state update
On 6/18/20 10:03 AM, Richard Henderson wrote:
> First, this could definitely be delayed to the follow-on linux-user patch set.
Bah, no, I need the function to be defined at least,
even if it isn't reachable yet.
r~
On 6/18/20 4:12 PM, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2020 at 07:59:51AM -0400, Stefan Berger wrote:
On 6/17/20 4:22 AM, Auger Eric wrote:
Hi Stefan,
On 6/16/20 10:57 PM, Stefan Berger wrote:
From: Stefan Berger
Move the TPM TIS IRQ to unused IRQ 13, which is the only one accepted b
Le 15/06/2020 à 15:03, Peter Maydell a écrit :
On Thu, 4 Jun 2020 at 13:39, Jean-Christophe Dubois
wrote:
improve the PHY implementation with more generic code.
This patch remove a lot of harcoded values to replace them with
generic symbols from header files.
Signed-off-by: Jean-Christophe D
On Thu, 18 Jun 2020 at 20:41, Aleksandar Markovic
wrote:
> четвртак, 18. јун 2020., Aleksandar Markovic
> је написао/ла:
>> You may recall that I signalled on couple of occasions that there are some
>> problems related to gcov builds in out-of-tree builds.
>>
>> It turned out that those problem
Patchew URL: https://patchew.org/QEMU/20200618202343.20455-1-jrt...@jrtc27.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export
On Thu, 18 Jun 2020 at 20:36, Gautam Bhat wrote:
> I am confused with the usage of PCI bus for connecting different
> peripherals. If I want to emulate an ARM board which doesn't have a
> PCI controller how can I emulate it to be as close to the real board
> as possible? Is there an ARM interconne
The source priorities can be used to order sources with respect to other
sources, not just as a way to enable/disable them based off a threshold.
We must therefore always claim the highest-priority source, rather than
the first source we find.
Signed-off-by: Jessica Clarke
---
Changes since v1:
>
>> 2. Unclear semantics. Alex tried to document what the actual semantics
>> of hinted pages are. Assume the following in the guest to a previously
>> hinted page
>>
>> /* page was hinted and is reused now */
>> if (page[x] != Y)
>>page[x] == Y;
>> /* migration ends, we now run on the d
1 - 100 of 371 matches
Mail list logo
