Re: HTIF tohost symbol size check always fails

The solution was even easier: I forgot to load the proxy kernel. As soon as I replaced the command-line parameter "-kernel " with "-kernel -append ", everything was working as expected. Without your hint about my possibly misconfigured toolchain I would have probably continued to search for t

Re: [PATCH v2 1/2] accel/tcg: Add tlb_flush_page_bits_by_mmuidx*

On Fri, 16 Oct 2020 at 22:07, Richard Henderson wrote: > > On ARM, the Top Byte Ignore feature means that only 56 bits of > the address are significant in the virtual address. We are > required to give the entire 64-bit address to FAR_ELx on fault, > which means that we do not "clean" the top byt

[PATCH v3 1/5] [RISCV_PM] Add J-extension into RISC-V

Signed-off-by: Alexey Baturo --- 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 0bbfd7f457..fe6bab4a52 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -438,6 +438,9 @@ static void ris

[PATCH v3 0/5] RISC-V Pointer Masking implementation

Hi folks, This is third iteration of patches to support Pointer Masking for RISC-V. Most of suggestions have been addressed, however some of them not: - applying mask for return value while reading PM CSR has been kept to mask higher priv level bits - check_pm_current_disabled is not placed into

[PATCH v3 2/5] [RISCV_PM] Support CSRs required for RISC-V PM extension except for ones in hypervisor mode

Signed-off-by: Alexey Baturo --- target/riscv/cpu.c | 1 + target/riscv/cpu.h | 11 ++ target/riscv/cpu_bits.h | 66 ++ target/riscv/csr.c | 264 4 files changed, 342 insertions(+) diff --git a/target/riscv/cpu.c b/target/riscv/

[PATCH v3 5/5] [RISCV_PM] Implement address masking functions required for RISC-V Pointer Masking extension

From: Anatoly Parshintsev Signed-off-by: Anatoly Parshintsev --- target/riscv/cpu.h | 19 +++ target/riscv/translate.c | 34 -- 2 files changed, 51 insertions(+), 2 deletions(-) diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h index 21e

[PATCH v3 3/5] [RISCV_PM] Print new PM CSRs in QEMU logs

Signed-off-by: Alexey Baturo --- target/riscv/cpu.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index d63031eb08..6ba3e98508 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -255,6 +255,25 @@ static void riscv_cpu_dum

[PATCH v3 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c/f/d/a types of instructions

Signed-off-by: Alexey Baturo --- target/riscv/insn_trans/trans_rva.c.inc | 3 +++ target/riscv/insn_trans/trans_rvd.c.inc | 2 ++ target/riscv/insn_trans/trans_rvf.c.inc | 2 ++ target/riscv/insn_trans/trans_rvi.c.inc | 2 ++ target/riscv/translate.c| 14 ++ 5 file

Re: [PATCH v3 0/5] RISC-V Pointer Masking implementation

Patchew URL: https://patchew.org/QEMU/20201016221138.10371-1-space.monkey.deliv...@gmail.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20201016221138.10371-1-space.monkey.deliv...@gmail.com Subject: [PATCH v3 0/5

Re: HTIF tohost symbol size check always fails

On Fri, Oct 16, 2020 at 2:35 PM Peer Adelt wrote: > > The solution was even easier: I forgot to load the proxy kernel. As soon as I > replaced the command-line parameter "-kernel " with "-kernel > -append ", everything was working as expected. Even better, you can skip the proxy kernel. You c

Re: [PATCH v3 5/5] [RISCV_PM] Implement address masking functions required for RISC-V Pointer Masking extension

On 10/16/20 3:11 PM, Alexey Baturo wrote: > From: Anatoly Parshintsev > > Signed-off-by: Anatoly Parshintsev > --- > target/riscv/cpu.h | 19 +++ > target/riscv/translate.c | 34 -- > 2 files changed, 51 insertions(+), 2 deletions(-) Review

Re: [PATCH v3 3/5] [RISCV_PM] Print new PM CSRs in QEMU logs

On 10/16/20 3:11 PM, Alexey Baturo wrote: > Signed-off-by: Alexey Baturo > --- > target/riscv/cpu.c | 19 +++ > 1 file changed, 19 insertions(+) Reviewed-by: Richard Henderson r~

Re: [PATCH v3 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c/f/d/a types of instructions

On 10/16/20 3:11 PM, Alexey Baturo wrote: > Signed-off-by: Alexey Baturo > --- > target/riscv/insn_trans/trans_rva.c.inc | 3 +++ > target/riscv/insn_trans/trans_rvd.c.inc | 2 ++ > target/riscv/insn_trans/trans_rvf.c.inc | 2 ++ > target/riscv/insn_trans/trans_rvi.c.inc | 2 ++ > target/risc

[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc

Anyone? Seriously, the problem really exists and we even made a case that reproduces it. Someone please take a look at this. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1891748 Title: qemu-arm-st

Re: [PATCH v3 2/5] [RISCV_PM] Support CSRs required for RISC-V PM extension except for ones in hypervisor mode

On 10/16/20 3:11 PM, Alexey Baturo wrote: > Signed-off-by: Alexey Baturo > --- > target/riscv/cpu.c | 1 + > target/riscv/cpu.h | 11 ++ > target/riscv/cpu_bits.h | 66 ++ > target/riscv/csr.c | 264 > 4 files changed, 342 insert

Re: [PATCH v3 1/5] [RISCV_PM] Add J-extension into RISC-V

On 10/16/20 3:11 PM, Alexey Baturo wrote: > Signed-off-by: Alexey Baturo > --- > target/riscv/cpu.c | 4 > target/riscv/cpu.h | 2 ++ > 2 files changed, 6 insertions(+) Reviewed-by: Richard Henderson r~

[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc

Plz take a look at this issue please. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1891748 Title: qemu-arm-static 5.1 can't run gcc Status in QEMU: New Bug description: Issue discovered whil

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[adding some more people who are interested in RNG stuff: Andy, Jason, Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this concerns some pretty fundamental API stuff related to RNG usage] On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin wrote: > - Background > > The VM Gen

[PATCH 1/4] target/s390x: Improve cc computation for ADD LOGICAL

The resulting cc is only dependent on the result and the carry-out. So save those things rather than the inputs. Carry-out for 64-bit inputs is had via tcg_gen_add2_i64 directly into cc_src. Carry-out for 32-bit inputs is had via extraction from a normal 64-bit add (with zero-extended inputs).

[PATCH 0/4] target/s390x: Improve carry computation

While testing the float128_muladd changes for s390x host, emulating under x86_64 of course, I noticed that the code we generate for strings of ALCGR and SLBGR is pretty awful. I realized that we were missing a trick: the output cc is based only on the output (result and carry) and so we don't need

[PATCH 2/4] target/s390x: Improve ADD LOGICAL WITH CARRY

Now that ADD LOGICAL outputs carry, we can use that as input directly. It also means we can re-use CC_OP_ZC and produce an output carry directly from ADD LOGICAL WITH CARRY. Signed-off-by: Richard Henderson --- target/s390x/internal.h| 2 -- target/s390x/cc_helper.c | 26 ---

[PATCH 4/4] target/s390x: Improve SUB LOGICAL WITH BORROW

Now that SUB LOGICAL outputs carry, we can use that as input directly. It also means we can re-use CC_OP_ZC and produce an output carry directly from SUB LOGICAL WITH BORROW. Signed-off-by: Richard Henderson --- target/s390x/internal.h| 2 -- target/s390x/cc_helper.c | 32

[PATCH 3/4] target/s390x: Improve cc computation for SUBTRACT LOGICAL

The resulting cc is only dependent on the result and the borrow-out. So save those things rather than the inputs. Borrow-out for 64-bit inputs is had via tcg_gen_sub2_i64 directly into cc_src. Borrow-out for 32-bit inputs is had via extraction from a normal 64-bit sub (with zero-extended inputs)

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote: > On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote: > > [adding some more people who are interested in RNG stuff: Andy, Jason, > > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this > > concerns some pretty fundamental

[PATCH v3 04/18] migration/rdma: add multifd_setup_ops for rdma

Signed-off-by: Chuan Zheng --- migration/multifd.c | 6 migration/multifd.h | 4 +++ migration/rdma.c| 82 + 3 files changed, 92 insertions(+) diff --git a/migration/multifd.c b/migration/multifd.c index 1f82307..0d494df 100644 --- a

[PATCH v3 07/18] migration/rdma: add rdma field into multifd send/recv param

Note we do want to export any rdma struct, take void * instead. Signed-off-by: Chuan Zheng --- migration/multifd.h | 8 1 file changed, 8 insertions(+) diff --git a/migration/multifd.h b/migration/multifd.h index 2f4e585..ff80bd5 100644 --- a/migration/multifd.h +++ b/migration/multifd

[PATCH v3 06/18] migration/rdma: export MultiFDSendParams/MultiFDRecvParams

MultiFDSendParams and MultiFDRecvParams is need for rdma, export it Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/multifd.c | 26 ++ migration/multifd.h | 2 ++ 2 files changed, 28 insertions(+) diff --git a/migration/multifd.c b/migration/multifd

[PATCH v3 01/18] migration/rdma: add the 'migrate_use_rdma_pin_all' function

Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/migration.c | 9 + migration/migration.h | 1 + 2 files changed, 10 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index 0575ecb..64ae417 100644 --- a/migration/migration.c +++ b/migration/migr

[PATCH v3 14/18] migration/rdma: register memory for multifd RDMA channels

Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/multifd.c | 3 ++ migration/rdma.c| 94 +++-- 2 files changed, 95 insertions(+), 2 deletions(-) diff --git a/migration/multifd.c b/migration/multifd.c index 9439b3c..c4d90ef

[PATCH v3 15/18] migration/rdma: only register the memory for multifd channels

All data is sent by multifd Channels, so we only register its for multifd channels and main channel don't register its. Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/rdma.c | 8 1 file changed, 8 insertions(+) diff --git a/migration/rdma.c b/migration/rdma.c inde

[PATCH v3 08/18] migration/rdma: export getQIOChannel to get QIOchannel in rdma

Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/qemu-file.c | 5 + migration/qemu-file.h | 1 + 2 files changed, 6 insertions(+) diff --git a/migration/qemu-file.c b/migration/qemu-file.c index be21518..37f6201 100644 --- a/migration/qemu-file.c +++ b/migration/qemu-file

[PATCH v3 00/18] Support Multifd for RDMA migration

Now I continue to support multifd for RDMA migration based on my colleague zhiming's work:) The previous RFC patches is listed below: v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg669455.html v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg679188.html As descried in previous

[PATCH v3 17/18] migration/rdma: send data for both rdma-pin-all and NOT rdma-pin-all mode

Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/rdma.c | 67 +++- 1 file changed, 62 insertions(+), 5 deletions(-) diff --git a/migration/rdma.c b/migration/rdma.c index 327f80f..519fa7a 100644 --- a/migration/rdma.c +++ b/

[PATCH v3 09/18] migration/rdma: add multifd_rdma_load_setup() to setup multifd rdma

Signed-off-by: Chuan Zheng --- migration/rdma.c | 52 1 file changed, 52 insertions(+) diff --git a/migration/rdma.c b/migration/rdma.c index ad4e4ba..2baa933 100644 --- a/migration/rdma.c +++ b/migration/rdma.c @@ -4010,6 +4010,48 @@ static v

[PATCH v3 10/18] migration/rdma: Create the multifd recv channels for RDMA

We still don't transmit anything through them, and we only build the RDMA connections. Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/rdma.c | 70 ++-- 1 file changed, 68 insertions(+), 2 deletions(-) diff --git a/migrati

[PATCH v3 02/18] migration/rdma: judge whether or not the RDMA is used for migration

Add enabled_rdma_migration into MigrationState to judge whether or not the RDMA is used for migration. Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/migration.c | 13 + migration/migration.h | 6 ++ 2 files changed, 19 insertions(+) diff --git a/migration

[PATCH v3 13/18] migration/rdma: Add the function for dynamic page registration

Add the 'qemu_rdma_registration' function, multifd send threads call it to register memory. Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/rdma.c | 51 +++ 1 file changed, 51 insertions(+) diff --git a/migration/rdma.c b/migr

[PATCH v3 12/18] migration/rdma: Create the multifd send channels for RDMA

Signed-off-by: Chuan Zheng --- migration/multifd.c | 4 ++-- migration/multifd.h | 2 ++ migration/rdma.c| 56 + 3 files changed, 60 insertions(+), 2 deletions(-) diff --git a/migration/multifd.c b/migration/multifd.c index 03f3a1e..9439b

[PATCH v3 11/18] migration/rdma: record host_port for multifd RDMA

Signed-off-by: Chuan Zheng --- migration/migration.c | 1 + migration/migration.h | 3 +++ migration/rdma.c | 3 +++ 3 files changed, 7 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index be6166a..7061410 100644 --- a/migration/migration.c +++ b/migration/migratio

[PATCH v3 05/18] migration/rdma: do not need sync main for rdma

Signed-off-by: Zhimin Feng Signed-off-by: Chuan Zheng --- migration/multifd.c | 8 1 file changed, 8 insertions(+) diff --git a/migration/multifd.c b/migration/multifd.c index 0d494df..8ccfd46 100644 --- a/migration/multifd.c +++ b/migration/multifd.c @@ -580,6 +580,10 @@ void multifd_

[PATCH v3 03/18] migration/rdma: create multifd_setup_ops for Tx/Rx thread

Create multifd_setup_ops for TxRx thread, no logic change. Signed-off-by: Chuan Zheng --- migration/multifd.c | 44 +++- migration/multifd.h | 7 +++ 2 files changed, 46 insertions(+), 5 deletions(-) diff --git a/migration/multifd.c b/migration/multi

[PATCH v3 18/18] migration/rdma: RDMA cleanup for multifd migration

Signed-off-by: Chuan Zheng --- migration/multifd.c | 6 ++ migration/multifd.h | 1 + migration/rdma.c| 16 +++- 3 files changed, 22 insertions(+), 1 deletion(-) diff --git a/migration/multifd.c b/migration/multifd.c index c4d90ef..f548122 100644 --- a/migration/multifd.c +

[PATCH v3 16/18] migration/rdma: add rdma_channel into Migrationstate field

Multifd RDMA is need to poll when we send data, record it. Signed-off-by: Chuan Zheng --- migration/migration.c | 1 + migration/migration.h | 1 + migration/rdma.c | 14 ++ 3 files changed, 16 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index 706

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh wrote: > On 16 Oct 2020, at 21:02, Jann Horn wrote: > > On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote: > > But in userspace, we just need a simple counter. There's no need for > > us to worry about anything else, like timestamps or whatever.

[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc

This has been fixed in mainline, probably commit 8ef618859c379fdce81c91bc93e0574e36ea76ff. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/18917

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote: > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote: > > Microsoft's documentation > > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM > > Generation ID that we get after a fork "is a 128-bit, > > cryptographically rando

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On 16 Oct 2020, at 22:01, Jann Horn wrote: On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh wrote: For user-space, even a single bit would do. We added MADVISE_WIPEONFORK so that userspace libraries can detect fork()/clone() robustly, for the same reasons. It just wipes a page as the in

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote: > [adding some more people who are interested in RNG stuff: Andy, Jason, > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this > concerns some pretty fundamental API stuff related to RNG usage] > > On Fri, Oct 16, 2020 at

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On 16 Oct 2020, at 21:02, Jann Horn wrote: On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote: But in userspace, we just need a simple counter. There's no need for us to worry about anything else, like timestamps or whatever. If we repeatedly fork a paused VM, the forked VMs will see the sam

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote: > Microsoft's documentation > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM > Generation ID that we get after a fork "is a 128-bit, > cryptographically random integer value". If multiple people use the > same image, it gu

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 07:52:48AM +0200, Jann Horn wrote: > On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote: > > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote: > > > Microsoft's documentation > > > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM > > > Generation I

Re: [PATCH v2 2/3] grackle: use qdev gpios for PCI IRQs

On Fri, Oct 16, 2020 at 07:53:10AM +0100, Mark Cave-Ayland wrote: > On 16/10/2020 07:45, Howard Spoelstra wrote: > > > Hi, > > > > I see compilation of the current ppc-for-5.2 branch fail with: > > > > ../hw/pci-host/grackle.c: In function ‘grackle_realize’: > > ../hw/pci-host/grackle.c:68:11: e

Re: [PATCH v2 1/3] macio: don't reference serial_hd() directly within the device

On Fri, Oct 16, 2020 at 08:00:06AM +0100, Mark Cave-Ayland wrote: > On 16/10/2020 01:16, David Gibson wrote: > > > On Tue, Oct 13, 2020 at 12:49:20PM +0100, Mark Cave-Ayland wrote: > > > Instead use qdev_prop_set_chr() to configure the ESCC serial chardevs at > > > the > > > Mac Old World and New

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sat, Oct 17, 2020 at 8:44 AM Willy Tarreau wrote: > On Sat, Oct 17, 2020 at 07:52:48AM +0200, Jann Horn wrote: > > On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote: > > > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote: > > > > Microsoft's documentation > > > > (http://go.microsof

<    1   2   3