How unsubscribe

Hello,How unsubscribe ?Dear 

support on risc-v 128bits

for begin ? peraps document best regard, jean-christophe P.S. why your ndd is nongnu.org ?

[PATCH v4 3/6] Add i.MX6UL missing devices.

* Add TZASC as unimplemented device. - Allow bare metal application to access this (unimplemented) device * Add CSU as unimplemented device. - Allow bare metal application to access this (unimplemented) device * Add 4 missing PWM devices Signed-off-by: Jean-Christophe Dubois Reviewed

[PATCH v4 5/6] Add i.MX7 missing TZ devices and memory regions

- ROM - CAAM Signed-off-by: Jean-Christophe Dubois Reviewed-by: Philippe Mathieu-Daudé --- hw/arm/fsl-imx7.c | 63 +++ include/hw/arm/fsl-imx7.h | 7 + 2 files changed, 70 insertions(+) diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c index

[PATCH v4 6/6] Add i.MX7 SRC device implementation

applications. Signed-off-by: Jean-Christophe Dubois Reviewed-by: Peter Maydell --- hw/arm/fsl-imx7.c | 8 +- hw/misc/imx7_src.c | 276 + hw/misc/meson.build| 1 + hw/misc/trace-events | 4 + include/hw/arm/fsl-imx7.h | 3

[PATCH v4 2/6] Refactor i.MX6UL processor code

* Add Addr and size definition for most i.MX6UL devices in i.MX6UL header file. * Use those newly defined named constants whenever possible. * Standardize the way we init a familly of unimplemented devices - SAI - PWM - CAN * Add/rework few comments Signed-off-by: Jean-Christophe Dubois

[PATCH v4 4/6] Refactor i.MX7 processor code

* Add Addr and size definition for all i.MX7 devices in i.MX7 header file. * Use those newly defined named constants whenever possible. * Standardize the way we init a familly of unimplemented devices - SAI - PWM - CAN * Add/rework few comments Signed-off-by: Jean-Christophe Dubois --- hw

[PATCH v4 1/6] Remove i.MX7 IOMUX GPR device from i.MX6UL

as an unimplemented device at the same bus adress and the 2 instantiations were actualy colliding. So we go back to the unimplemented device for now. Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx6ul.c | 11 --- include/hw/arm/fsl-imx6ul.h | 2 -- 2 files changed, 13

[PATCH v4 0/6] Complete i.MX6UL and i.MX7 processor for bare metal application.

w comments in code review. Jean-Christophe Dubois (6): Remove i.MX7 IOMUX GPR device from i.MX6UL Refactor i.MX6UL processor code Add i.MX6UL missing devices. Refactor i.MX7 processor code Add i.MX7 missing TZ devices and memory regions Add i.MX7 SRC device implementation hw/arm/fs

Re: [PATCH v3 1/5] Refactor i.MX6UL processor code

Le 02/08/2023 à 23:32, Philippe Mathieu-Daudé a écrit : Hi Jean-Christophe, On 2/8/23 23:08, Jean-Christophe Dubois wrote: * Add Addr and size definition for all i.MX6UL devices in i.MX6UL header file. I'm OK with your patch, but some addr/size are added, while other are changed. It is hard

[PATCH v3 3/5] Refactor i.MX7 processor code

* Add Addr and size definition for all i.MX7 devices in i.MX7 header file. * Use those newly defined named constants whenever possible. * Standardize the way we init a familly of unimplemented devices - SAI - PWM - CAN * Add/rework few comments Signed-off-by: Jean-Christophe Dubois --- hw

[PATCH v3 2/5] Add i.MX6UL TZ missing devices.

* Add TZASC as unimplemented device. - Allow bare metal application to access this (unimplemented) device * Add CSU as unimplemented device. - Allow bare metal application to access this (unimplemented) device Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx6ul.c | 12

[PATCH v3 5/5] Add i.MX7 SRC device implementation

application. Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx7.c | 8 +- hw/misc/imx7_src.c | 276 + hw/misc/meson.build| 1 + hw/misc/trace-events | 4 + include/hw/arm/fsl-imx7.h | 2 + include/hw/misc/imx7_src.h

[PATCH v3 0/5] Complete i.MX6UL and i.MX7 processor for bare metal application.

s since v1: * split the i.MX6UL patch into a refactor patch and an addon patch. * Split the i.MX7 patch into a refactor patch and an addon patch. * Fix SRC code after few comments in code review. Jean-Christophe Dubois (5): Refactor i.MX6UL processor code Add i.MX6UL TZ missing devices. Refa

[PATCH v3 4/5] Add i.MX7 missing TZ devices and memory regions

- ROM - CAAM Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx7.c | 63 +++ include/hw/arm/fsl-imx7.h | 7 + 2 files changed, 70 insertions(+) diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c index 3bb0da6850..7ca105fd24 100644 --- a/hw

[PATCH v3 1/5] Refactor i.MX6UL processor code

-by: Jean-Christophe Dubois --- hw/arm/fsl-imx6ul.c | 149 +++ include/hw/arm/fsl-imx6ul.h | 150 +--- 2 files changed, 240 insertions(+), 59 deletions(-) diff --git a/hw/arm/fsl-imx6ul.c b/hw/arm/fsl-imx6ul.c index 2189dcbb72

[PATCH v2 3/5] Refactor i.MX7 processor code

Add Addr and size definition for all i.MX7 devices in i.MX7 header file. * Use those newly defined named constants whenever possible. * Standardize the way we init a familly of unimplemented devices - SAI - PWM - CAN * Add/rework few comments Signed-off-by: Jean-Christophe Dubois --- hw

[PATCH v2 4/5] Add i.MX7 missing TZ devices and memory regions

- ROM - CAAM Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx7.c | 63 +++ include/hw/arm/fsl-imx7.h | 7 + 2 files changed, 70 insertions(+) diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c index 3bb0da6850..7ca105fd24 100644 --- a/hw

[PATCH v2 5/5] Add i.MX7 SRC device implementation

application. Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx7.c | 8 +- hw/misc/imx7_src.c | 276 + hw/misc/meson.build| 1 + hw/misc/trace-events | 4 + include/hw/arm/fsl-imx7.h | 2 + include/hw/misc/imx7_src.h

[PATCH v2 2/5] Add i.MX6UL TZ missing devices.

* Add TZASC as unimplemented device. - Allow bare metal application to access this (unimplemented) device * Add CSU as unimplemented device. - Allow bare metal application to access this (unimplemented) device Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx6ul.c | 12

[PATCH v2 1/5] Refactor i.MX6UL processor code

-by: Jean-Christophe Dubois --- hw/arm/fsl-imx6ul.c | 149 include/hw/arm/fsl-imx6ul.h | 149 +--- 2 files changed, 239 insertions(+), 59 deletions(-) diff --git a/hw/arm/fsl-imx6ul.c b/hw/arm/fsl-imx6ul.c index 2189dcbb72

[PATCH v2 0/5] Complete i.MX6UL and i.MX7 processor for bare metal application.

the i.MX7 patch into a refactor patch and an addon patch. * Fix SRC code after few comments in code review. Jean-Christophe Dubois (5): Refactor i.MX6UL processor code Add i.MX6UL TZ missing devices. Refactor i.MX7 processor code Add i.MX7 missing TZ devices and memory regions Add i.MX7

[PATCH 2/3] Rework i.MX7 device implementation/instantiation

From: jcdubois * Add Addr and size definition for all i.MX7 devices in i.MX7 header file. * Use those newly defined named constants whenever possible. * Standardize the way we init a familly of unimplemented devices - SAI - PWM - CAN * Add TZASC as unimplemented device. - Allow bare

[PATCH 3/3] Add i.MX7 SRC device implementation

7_src.c @@ -0,0 +1,289 @@ +/* + * IMX7 System Reset Controller + * + * Copyright (c) 2023 Jean-Christophe Dubois + * + * 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" +#incl

[PATCH 1/3] Rework i.MX6UL device implementation/instantiation

From: jcdubois * Add Addr and size definition for all i.MX6UL devices in i.MX6UL header file. * Use those newly defined named constants whenever possible. * Standardize the way we init a familly of unimplemented devices - SAI - PWM (add missing PWM instances) - CAN * Add TZASC as

[PATCH 0/3] Complete i.MX6UL and i.MX7 processor for bare metal application.

why Linux is using the 2 cores in Qemu even if the SRC is not implemented. This is not the case when running bare metal application (like u-boot itself) that do not rely on the PSCI service being available. Jean-Christophe Dubois (3): Rework i.MX6UL device implementation/instantiation Rework i.

[PATCH] i.MX7D: Connect IRQs to GPIO devices.

IRQs were not associated to the various GPIO devices inside i.MX7D. This patch brings the i.MX7D on par with i.MX6. Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx7.c | 31 ++- include/hw/arm/fsl-imx7.h | 15 +++ 2 files changed, 45

[PATCH] i.MX6UL: Add a specific GPT timer instance for the i.MX6UL

The i.MX6UL doesn't support CLK_HIGH ou CLK_HIGH_DIV clock source. Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx6ul.c| 2 +- hw/misc/imx6ul_ccm.c | 6 -- hw/timer/imx_gpt.c | 25 + include/hw/timer/imx_gpt.h | 1 + 4 files changed

[PATCH] i.MX7D: Connect GPT timers to IRQ

So far the GPT timers were unable to raise IRQs to the processor. Signed-off-by: Jean-Christophe Dubois --- hw/arm/fsl-imx7.c | 10 ++ include/hw/arm/fsl-imx7.h | 5 + 2 files changed, 15 insertions(+) diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c index cc6fdb9373

[PATCH] Fix i.MX GPT timers for i.MX6UL and i.MX7 processors

to the i.MX6UL GPT timer as its clock sources differ slightly from the i.MX7 version. Tested by running µCOS application on i.MX7D emulated processor. µCOS is using the GPT timer as its tick source. Jean-Christophe Dubois (3): i.MX7D: Connect GPT timers to IRQ i.MX7D: Compute clock frequency

[PATCH] i.MX7D: Compute clock frequency for the fixed frequency clocks.

CCM derived clocks will have to be added later. Signed-off-by: Jean-Christophe Dubois --- hw/misc/imx7_ccm.c | 49 +- 1 file changed, 40 insertions(+), 9 deletions(-) diff --git a/hw/misc/imx7_ccm.c b/hw/misc/imx7_ccm.c index 075159e497..f135ec7b7e

[PATCH] target/ppc: 603: fix restore of GPRs 0-3 on rfi

, but TGPR bit is not part of SRR1 and that bit is used for something else and is sometimes set to 1, leading to hreg_store_msr() not restoring GPRs. So, do the same way as for POW bit, force clearing it. Signed-off-by: Christophe Leroy Cc: Cedric Le Goater Cc: Fabiano Rosas --- target/ppc

Re: [PATCH 00/15] ppc/ppc405: decade cleanup

nterrupts for timer event device LOC: 0 Local timer interrupts for others SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts MCE: 0 Machine check exceptions Any idea what the problem can be ? How does QEMU generates timer interrupts ? Christophe

Re: [PATCH] hw/ppc/ppc405_boards: Change kernel load address

a very similar >>> address space layout. Change the kernel load address to match U-Boot >>> expectations and fix loading. >> >> You could additionally mention that U-Boot corrupts the kernel if it >> gets loaded to address 0. > > True. The first word is overwritten with zeros. I looked for it > in the code but could not find the reason. > Isn't it because U-boot unzips the kernel at address 0 ? Christophe

Re: [PATCH for-6.2] Revert "arm: tcg: Adhere to SMCCC 1.3 section 5.2"

ion executions regardless of function identifier value. This is too tricky to try to sort out before 6.2 is released; revert this commit so we can take the time to get it right in the 7.0 release. Signed-off-by: Peter Maydell --- Jean-Christophe: could you confirm that reverting this fixes the regressi

Re: Qemu and ARM secure state.

Le 09/11/2021 à 11:55, Peter Maydell a écrit : On Mon, 8 Nov 2021 at 22:09, Jean-Christophe DUBOIS wrote: OK, so one problem seems to be that PSCI-via-SMC is enabled on i.MX6UL when there is no built in PSCI related function on this processor. According the Linux DTS, i.MX7 (solo and dual

[PATCH] pci-host: Allow extended config space access for PowerNV PHB4 model

-by: Christophe Lombard --- hw/pci-host/pnv_phb4.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 5c375a9f28..40b793201a 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -1205,6 +1205,7 @@ static void pnv_phb4_realize(DeviceState

Re: Qemu and ARM secure state.

Le 08/11/2021 à 15:50, Peter Maydell a écrit : On Sat, 6 Nov 2021 at 18:11, Jean-Christophe DUBOIS wrote: One small question/remark: According to the the "Arm Power State Coordinate Interface" (DEN0022D.b) document (chapter 5) PSCI calls can only be issued by "normal wor

Re: Qemu and ARM secure state.

Le 08/11/2021 à 15:14, Alex Bennée a écrit : Jean-Christophe DUBOIS writes: One small question/remark: According to the the "Arm Power State Coordinate Interface" (DEN0022D.b) document (chapter 5) PSCI calls can only be issued by "normal world" (EL1 or EL2). Therefore,

Re: Qemu and ARM secure state.

psci_call() function? This would prevent calling the built-in Qemu PSCI function if SMC is issued  from secure state. Regards. JC Le 06/11/2021 à 14:04, Jean-Christophe DUBOIS a écrit : So it seems that what is needed is a way to choose on the command line if we want to enable the Qemu built-in

Re: Qemu and ARM secure state.

orm allows to dynamically choose one or the other. Other platforms seems to need the same feature. JC Le 06/11/2021 à 11:04, Jean-Christophe DUBOIS a écrit : So, I am trying to understand: Contrary to what I said, In my case the SMC instruction is not really a "no-op" as it sets

Re: Qemu and ARM secure state.

unknown PSCI request). Is there something I am missing? Regards JC Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit : Le 04/11/2021 à 12:11, Peter Maydell a écrit : On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS wrote: I have a little application that is designed to work on th

Re: Qemu and ARM secure state.

Le 04/11/2021 à 12:11, Peter Maydell a écrit : On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS wrote: I have a little application that is designed to work on the i.MX6UL processor. I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu. This application used to work

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

Le 28/10/2021 à 14:24, Luis Machado a écrit : On 10/20/21 10:16 AM, LEROY Christophe wrote: Le 20/10/2021 à 14:43, Cédric Le Goater a écrit : On 10/20/21 13:42, BALATON Zoltan wrote: On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote: On 10/5/21 14:29, Thomas Huth wrote: On 05/10/2021

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

, and I'm aiming at getting it back to work, just because I need it. By the way, were you able to re-test with CONFIG_MATH_EMULATION enabled after your last oops report which shows that you're trying to execute floating points instruction ? Thanks Christophe

Re: Deprecate the ppc405 boards in QEMU?

Le 21/10/2021 à 09:25, Thomas Huth a écrit : On 21/10/2021 08.48, Christophe Leroy wrote: Le 20/10/2021 à 15:16, Christophe Leroy a écrit : Le 20/10/2021 à 14:43, Cédric Le Goater a écrit : On 10/20/21 13:42, BALATON Zoltan wrote: On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

Le 20/10/2021 à 15:16, Christophe Leroy a écrit : Le 20/10/2021 à 14:43, Cédric Le Goater a écrit : On 10/20/21 13:42, BALATON Zoltan wrote: On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote: On 10/5/21 14:29, Thomas Huth wrote: On 05/10/2021 14.20, BALATON Zoltan wrote: On Tue, 5 Oct

Re: Deprecate the ppc405 boards in QEMU?

Le 20/10/2021 à 16:39, Cédric Le Goater a écrit : > On 10/20/21 15:27, LEROY Christophe wrote: >> I managed to get a kernel booting with the following change (and with >> CONFIG_ETHERNET removed) > > Looks good. > > Do you have a compatible builroot image ? >

Re: Deprecate the ppc405 boards in QEMU?

Le 20/10/2021 à 16:41, Cédric Le Goater a écrit : > init[1]: illegal instruction (4) at 10038380 nip 10038380 lr 10034be0 > code 1 in busybox[1000+61000] > init[1]: code: 6129c000 7f914840 419d0350 562be13e 380b 2b800020 > 409d0314 3d204330 > init[1]: code: 6c008000 91210018 3d201006

Re: Deprecate the ppc405 boards in QEMU?

Le 20/10/2021 à 12:10, Cédric Le Goater a écrit : > On 10/20/21 11:02, Christophe Leroy wrote: >> >> >> Le 19/10/2021 à 23:30, Cédric Le Goater a écrit : >>> On 10/19/21 18:12, Christophe Leroy wrote: >>>> >>>> >>>> Le 19/1

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

t; On Tue, 5 Oct 2021, Cédric Le Goater wrote: >>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote: >>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote: >>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit : >>>>>>>>> On

Re: Deprecate the ppc405 boards in QEMU?

Le 19/10/2021 à 23:30, Cédric Le Goater a écrit : On 10/19/21 18:12, Christophe Leroy wrote: Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10/2021 à 15:44, Christophe Leroy a écrit : There is something: => bootm 0 Wrong Image For

Re: Deprecate the ppc405 boards in QEMU?

Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10/2021 à 15:44, Christophe Leroy a écrit : There is something: => bootm 0 Wrong Image Format for bootm command ERROR: can't get kernel image! => md 0 : b497aae1 61

Re: Deprecate the ppc405 boards in QEMU?

Le 19/10/2021 à 15:44, Christophe Leroy a écrit : Le 19/10/2021 à 14:38, BALATON Zoltan a écrit : On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10/2021 à 13:11, Thomas Huth a écrit : On 19/10/2021 12.07, BALATON Zoltan wrote: On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10

Re: Deprecate the ppc405 boards in QEMU?

Le 19/10/2021 à 14:38, BALATON Zoltan a écrit : On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10/2021 à 13:11, Thomas Huth a écrit : On 19/10/2021 12.07, BALATON Zoltan wrote: On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10/2021 à 11:39, Thomas Huth a écrit : On 19/10/2021

Re: Deprecate the ppc405 boards in QEMU?

Le 19/10/2021 à 13:11, Thomas Huth a écrit : On 19/10/2021 12.07, BALATON Zoltan wrote: On Tue, 19 Oct 2021, Christophe Leroy wrote: Le 19/10/2021 à 11:39, Thomas Huth a écrit : On 19/10/2021 11.31, Christophe Leroy wrote: Le 11/10/2021 à 15:24, Thomas Huth a écrit : On 11/10/2021 11.20

Re: Deprecate the ppc405 boards in QEMU?

Le 19/10/2021 à 11:39, Thomas Huth a écrit : On 19/10/2021 11.31, Christophe Leroy wrote: Le 11/10/2021 à 15:24, Thomas Huth a écrit : On 11/10/2021 11.20, David Gibson wrote: On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: On 06/10/2021 09.25, Thomas Huth wrote: On 05/10

Re: Deprecate the ppc405 boards in QEMU?

ail history that you got that problem as well at some point. How did you fix it ? Thanks Christophe

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

Le 14/10/2021 à 12:34, Christophe Leroy a écrit : Le 14/10/2021 à 11:31, Thomas Huth a écrit :   Hi, I tried to build a current Linux kernel for the "bamboo" board and use it in QEMU, but QEMU then quickly aborts with:   pci.c:262: pci_bus_change_irq_level: Assertion `ir

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

race_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot); -return slot - 1; +return slot ? slot - 1 : slot; } static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level) --- It's probably no the final change, but at least it allows booting bamboo on qemu again. Christophe

Re: [Virtio-fs] [PATCH 11/13] virtiofsd: Shutdown notification queue in the end

/ > vu_dispatch_unlock(vud); > -fv_queue_cleanup_thread(vud, qidx); > + > +/* > + * If queue 0 is being shutdown, treat it as if device is being > + * shutdown and stop all queues. > + */ > +if (qidx == 0) { > + stop_all

Re: [Virtio-fs] [PATCH 12/13] virtiofsd: Implement blocking posix locks

access req after this. Once lock is > + * available, send a notification instead. > + */ > +if (sleep && lock->l_type != F_UNLCK) { > + /* > + * If notification queue is not enabled, can't support async > + * locks. > + */ > +if (!se->notify_enabled) { > +saverr = EOPNOTSUPP; > +goto out; > +} > +blocking_lock = true; > +unique = req->unique; > +fuse_reply_wait(req); > +} > + > /* TODO: Is it alright to modify flock? */ > lock->l_pid = 0; > -ret = fcntl(plock->fd, F_OFD_SETLK, lock); > +if (blocking_lock) { > +ret = fcntl(ofd, F_OFD_SETLKW, lock); > +} else { > +ret = fcntl(ofd, F_OFD_SETLK, lock); > +} > if (ret == -1) { > saverr = errno; > } > > out: > -pthread_mutex_unlock(>plock_mutex); > lo_inode_put(lo, ); > > -fuse_reply_err(req, saverr); > +if (!blocking_lock) { > +fuse_reply_err(req, saverr); > +} else { > +setlk_send_notification(se, unique, saverr); > +} > } > > static void lo_fsyncdir(fuse_req_t req, fuse_ino_t ino, int datasync, -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [Virtio-fs] [PATCH 06/13] vhost-user-fs: Use helpers to create/cleanup virtqueue

/* This will stop vhost backend if appropriate. */ > vuf_set_status(vdev, 0); > @@ -267,14 +290,8 @@ static void vuf_device_unrealize(DeviceState *dev) > > vhost_user_cleanup(>vhost_user); > > -virtio_delete_queue(fs->hiprio_vq); > -for (i = 0; i < fs->conf.num_request_queues; i++) { > -virtio_delete_queue(fs->req_vqs[i]); > -} > -g_free(fs->req_vqs); > +vuf_cleanup_vqs(vdev); > virtio_cleanup(vdev); > -g_free(fs->vhost_dev.vqs); > -fs->vhost_dev.vqs = NULL; > } > > static const VMStateDescription vuf_vmstate = { -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [Virtio-fs] [PATCH 09/13] virtiofsd: Specify size of notification buffer using config space

fscfg.notify_buf_size = notify_size; > +memcpy(config, , len); > +fuse_log(FUSE_LOG_DEBUG, "%s:Setting notify_buf_size=%d\n", __func__, > + fscfg.notify_buf_size); > +return 0; > +} > + > static const VuDevIface fv_iface = { > .get_features = fv_get_features, > .set_features = fv_set_features, > @@ -864,6 +893,8 @@ static const VuDevIface fv_iface = { > .queue_set_started = fv_queue_set_started, > > .queue_is_processed_in_order = fv_queue_order, > +.get_protocol_features = fv_get_protocol_features, > +.get_config = fv_get_config, > }; > > /* -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [Virtio-fs] [PATCH 07/13] virtiofsd: Release file locks using F_UNLCK

NLCK; > +flock.l_whence = SEEK_SET; > +/* Unlock whole file */ > +flock.l_start = flock.l_len = 0; > +fcntl(plock->fd, F_OFD_SETLK, ); > +} > + > pthread_mutex_unlock(>plock_mutex); > } > res = close(dup(lo_fi_fd(req, fi))); -- Cheers, Christophe de Dinechin (IRC c3d)

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

Le 05/10/2021 à 02:48, David Gibson a écrit : On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote: On 01/10/2021 15.04, Christophe Leroy wrote: Le 01/10/2021 à 14:04, Thomas Huth a écrit : On 01/10/2021 13.12, Peter Maydell wrote: On Fri, 1 Oct 2021 at 10:43, Thomas Huth wrote

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

supported, see https://elixir.bootlin.com/linux/v5.15-rc3/source/arch/powerpc/kernel/cputable.c#L1300 Christophe ... to me this all sounds like these 405 boards are pretty dead code in QEMU right now, so if nobody has a clue how to use them, I'd suggest to mark them as deprecated and r

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

ally would like to be able to use them to validate Linux Kernel changes, hence looking for that missing BIOS. If we remove ppc405 from QEMU, we won't be able to do any regression tests of Linux Kernel on those processors. Christophe

Re: [PATCH 0/3] target/arm: Set FPSCR.LTPSIZE for user-mode

me over-exuberant ifdeffery in the > arm_cpu_reset() function. Patch 1 fixes that so that most of > the M-profile-specific reset handling is not ifdeffed, and > when we're in user mode we specifically set the FPU state up > cleanly. Patches 2 and 3 are just follow-on tidyup. > > Christophe,

[Bug 1883268] Re: random errors on aarch64 when executing __aarch64_cas8_acq_rel

Opened ticket on gitlab: https://gitlab.com/qemu- project/qemu/-/issues/333 ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #333 https://gitlab.com/qemu-project/qemu/-/issues/333 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 *** https://bugs.launchpad.net/bugs/1921948 ** Attachment added: "libgcc_s.so.1" https://bugs.launchpad.net/qemu/+bug/1927530/+attachment/5495299/+files/libgcc_s.so.1 -- You received this bug notification because you are a member of qemu-

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 *** https://bugs.launchpad.net/bugs/1921948 Sorry, I didn't think about rpath when I tried to execute what I had extracted. Here are the additional libstdc++.so.6 and libgcc_s.so.1. I am using a more recent qemu version than 6.0, almost head:

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

I have re-tested at commit d45a5270d075ea589f0b0ddcf963a5fea1f500ac, and the build succeeded, so it looks like the problem has been fixed. ** Changed in: qemu Status: Incomplete => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Bug 1927530] [NEW] qemu-aarch64 MTE fails to report tag mismatch

Public bug reported: Hi, While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests). I am attaching: bitfield-2.exe ld-linux-aarch64.so.1 libc.so.6 libdl.so.2 libhwasan.so.0 libm.so.6 libpthread.so.0 librt.so.1 The

Re: [PATCH v2 2/9] backends/tpm: Replace qemu_mutex_lock calls with QEMU_LOCK_GUARD

<= 0) { > +return -1; > +} > } > } > > -ret = 0; > - > -end: > -qemu_mutex_unlock(>mutex); > -return ret; > +return 0; > } > > static int tpm_emulator_unix_tx_bufs(TPMEmulator *tpm_emu, I really like the improvement, but it looks like it does not belong to the top-level series (i.e. not related to replacing alloca() by g_malloc()). Reviewed-by: Christophe de Dinechin -- Cheers, Christophe de Dinechin (IRC c3d)

Re: vnc clipboard support

> On 1 Feb 2021, at 17:56, Daniel P. Berrangé wrote: > > On Mon, Feb 01, 2021 at 05:31:52PM +0100, Christophe de Dinechin wrote: >> >> >>> On 1 Feb 2021, at 16:51, Daniel P. Berrangé wrote: >>> >>> On Mon, Feb 01, 2021 a

Re: vnc clipboard support

> On 29 Jan 2021, at 16:04, Gerd Hoffmann wrote: > > Hi, > >> Unless we para-virtualize the keyboard? > > The main advantage of paste via key events is that it doesn't require > guest support. The main disadvantage, though, is that it does not work at all ;-) Imagine pasting Ademar's

Re: vnc clipboard support

> On 1 Feb 2021, at 16:51, Daniel P. Berrangé wrote: > > On Mon, Feb 01, 2021 at 04:27:43PM +0100, Christophe de Dinechin wrote: >> >> >>> On 29 Jan 2021, at 15:32, Daniel P. Berrangé wrote: >>> >>> On Fri, Jan 29, 2021 a

Re: vnc clipboard support

> On 29 Jan 2021, at 15:32, Daniel P. Berrangé wrote: > > On Fri, Jan 29, 2021 at 03:19:45PM +0100, Christophe de Dinechin wrote: >> >> >>> On 29 Jan 2021, at 12:08, Daniel P. Berrangé wrote: >>> >>> On Fri, Jan 29, 2021 a

Re: vnc clipboard support

> On 29 Jan 2021, at 12:08, Daniel P. Berrangé wrote: > > On Fri, Jan 29, 2021 at 11:50:10AM +0100, Christophe de Dinechin wrote: >> >> >>> On 29 Jan 2021, at 09:03, Gerd Hoffmann wrote: >>> >>> Hi, >>> >>>>> (1)

Re: vnc clipboard support

> On 29 Jan 2021, at 12:49, Gerd Hoffmann wrote: > > Hi, > >> - What I'm suggesting is that qemu-vnc could then switch to simply >> relaying VNC traffic to that in-guest server. You'd get the smart update >> algorithm that Apple has put in place to deal with transparency and the >> like, as

Re: vnc clipboard support

opy-paste the existing VNC code. Hope this sounds a bit less crazy explained that way… Thanks Christophe

Re: vnc clipboard support

Christophe (Typos are from my iPhone) > Le 28 janv. 2021 à 21:24, Marc-André Lureau a > écrit : > >  > Hi > >> On Thu, Jan 28, 2021 at 9:14 PM Gerd Hoffmann wrote: >> Hi folks, >> >> I'm looking for a good way to implement cut+paste support

Re: vnc clipboard support

> On 28 Jan 2021, at 18:12, Gerd Hoffmann wrote: > > Hi folks, > > I'm looking for a good way to implement cut+paste support for vnc. > > The vnc core protocol has support for text/plain cut+paste, and there > is an extension adding support for other formats. That'll cover one > part of

Re: [PATCH] x86/cpu: Add AVX512_FP16 cpu feature

X512_FP16 instruction */ > +#define CPUID_7_0_EDX_AVX512_FP16 (1U << 23) > /* Speculation Control */ > #define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) > /* Single Thread Indirect Branch Predictors */ -- Cheers, Christophe de Dinechin (IRC c3d)

Re: VFIO Migration

> On 3 Nov 2020, at 19:49, Dr. David Alan Gilbert wrote: > > * Stefan Hajnoczi (stefa...@redhat.com ) wrote: >> On Tue, Nov 03, 2020 at 12:17:09PM +, Dr. David Alan Gilbert wrote: >>> * Stefan Hajnoczi (stefa...@redhat.com) wrote: Device Models

Re: VFIO Migration

based on a version and/or configuration parameters: > * ``version=1`` - use the device configuration aliased by version 1 > * ``version=2,rx-filter-size=64`` - use version 1 and override > ``rx-filter-size`` > * ``rx-filter-size=0`` - directly set configuration parameters without using > a version > > Device creation fails if the version and/or configuration parameters are not > supported. > > There must be a mechanism to query the "latest" configuration for a device > model. It may simply report the ``version=5`` where 5 is the latest version > but > it could also report all configuration parameters instead of using a version > alias. Instead of "latest", we could have a query that lists the "supported" configurations. Again, vGPUs are a good example where this would be useful. A same card can be partitioned in a number of ways, and you can't really claim that "M10-2B" or "M10-0Q" is "latest". You could arguably assign a unique URI to each sub-model. Maybe that's how you were envisioning things? -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [RFC PATCH] contrib/gitdm: Add more individual contributors

Acked-by Jean-Christophe Dubois On 04/10/2020 20:25, Philippe Mathieu-Daudé wrote: These individual contributors have a number of contributions, add them to the 'individual' group map. Cc: Ahmed Karaman Cc: Aleksandar Markovic Cc: Alistair Francis Cc: Artyom Tarasenko Cc: David Carlier

Re: [PATCH v2 5/6] tools/virtiofsd: xattr name mappings: Map server xattr names

+in_index += in_len; > +} > +ret = out_index; > + if (ret == 0) { > +goto out; > +} > +} > fuse_reply_buf(req, value, ret); > } else { > +/* > + * xattrmap only ever shortens the result, > + * so we don't need to do anything clever with the > + * allocation length here. > + */ > fuse_reply_xattr(req, ret); > } > out_free: -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [PATCH v2 5/6] tools/virtiofsd: xattr name mappings: Map server xattr names

n_index += in_len; > +} > +ret = out_index; > +if (ret == 0) { > +goto out; > + } > +} > fuse_reply_buf(req, value, ret); > } else { > +/* > + * xattrmap only ever shortens the result, > + * so we don't need to do anything clever with the > + * allocation length here. > + */ I don't understand the comment above. We are in the !lo->xattrmap) case, no? > fuse_reply_xattr(req, ret); > } > out_free: -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [PATCH v2 3/6] tools/virtiofsd: xattr name mappings: Add option

= tmp + 1; > +/* End of rule - go around again for another rule */ > +} > + > +if (!nentries) { > +fuse_log(FUSE_LOG_ERR, "Empty xattr map\n"); > +exit(1); > +} > + > +/* Add a terminator to error in cases the user hasn't specified */ > +res = g_realloc_n(res, ++nentries, sizeof(XattrMapEntry)); > +res[nentries - 1].flags = XATTR_MAP_FLAG_ALL | XATTR_MAP_FLAG_END_BAD; > +res[nentries - 1].key = g_strdup(""); > +res[nentries - 1].prepend = g_strdup(""); > + > +return res; > +} > + > static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name, > size_t size) > { > @@ -2909,6 +3052,11 @@ int main(int argc, char *argv[]) > } else { > lo.source = strdup("/"); > } > + > +if (lo.xattrmap) { > +xattr_map_list = parse_xattrmap(lo.xattrmap); This is never freed. If you put the static in struct lo_data, you could naturally clean it up in fuse_lo_data_cleanup. > +} > + > if (!lo.timeout_set) { > switch (lo.cache) { > case CACHE_NONE: -- Cheers, Christophe de Dinechin (IRC c3d)

Re: Python docstrings and licensing/authorship

> On 16 Sep 2020, at 17:47, John Snow wrote: > > For some of the Python cleanup work I am doing, I am moving preamble comments > into docstrings. These docstrings are visible in interactive editors and may > be visible when using Sphinx to generate documentation manuals for Python > code.

Qemu web site down?

Hi Stefan, The link from https://wiki.qemu.org/Documentation pointing to https://qemu.weilnetz.de/doc/qemu-doc.html seems to be dead. Is the problem on your web site, or should the wiki be updated? Thanks Christophe

Re: [PATCH v2 2/3] trace: Add support for recorder back-end

On 2020-07-30 at 10:13 CEST, Markus Armbruster wrote... > Christophe de Dinechin writes: > >> On 2020-07-29 at 13:53 CEST, Markus Armbruster wrote... >>> Christophe de Dinechin writes: >>> >>>> On 2020-07-27 at 10:23 CEST, Markus Armbruster wro

Re: [PATCH 2/7] build: fix device module builds

On 2020-07-28 at 18:37 CEST, Philippe Mathieu-Daudé wrote... > On 7/23/20 7:46 PM, Christophe de Dinechin wrote: >> From: Gerd Hoffmann >> >> See comment. Feels quite hackish. Better ideas anyone? > > I don't understand this patch, how is it related to the r

Re: [PATCH v2 2/3] trace: Add support for recorder back-end

On 2020-07-29 at 13:53 CEST, Markus Armbruster wrote... > Christophe de Dinechin writes: > >> On 2020-07-27 at 10:23 CEST, Markus Armbruster wrote... >>> Christophe de Dinechin writes: >>> >>>> On 2020-07-23 at 16:06 CEST, Markus Armbruster wro

Re: Missing qapi_free_Type in error case for qapi generated code?

On 2020-07-29 at 10:34 CEST, Markus Armbruster wrote... > Eric Blake writes: > >> On 7/28/20 10:26 AM, Christophe de Dinechin wrote: >>> The qapi generated code for qmp_marshal_query_spice seems to be missing a >>> resource deallocation for "

Re: [PATCH v7 01/47] block: Add child access functions

QLIST_FOREACH(c, >children, next) { > if (c->role & BDRV_CHILD_PRIMARY) { > -return c; > +assert(!found); > +found = c; > } > } > > -return NULL; > +return c; Shouldn't that be "return found"? > } > > > with or without: > Reviewed-by: Vladimir Sementsov-Ogievskiy -- Cheers, Christophe de Dinechin (IRC c3d)

Missing qapi_free_Type in error case for qapi generated code?

i.e. I get "SpiceInfo *" and not "SpiceInfo". - If not, is there any good way to know if the type is a pointer type? (A quick look in cripts/qapi/types.py does not show anything obvious) -- Cheers, Christophe de Dinechin (IRC c3d)

Re: [PATCH v2 2/3] trace: Add support for recorder back-end

On 2020-07-27 at 10:23 CEST, Markus Armbruster wrote... > Christophe de Dinechin writes: > >> On 2020-07-23 at 16:06 CEST, Markus Armbruster wrote... >>> Christophe de Dinechin writes: >>> >>>> On 2020-06-30 at 15:02 CEST, Daniel P. Berrangé wrote..

  1   2   3   4   5   6   7   8   9   10   >