[PATCH v1 0/3] ZynqMP / Versal: various fixes

Hi, Those are various simple fixes for ZynqMP: * 1: fixes a possible out of bound access in the SPI model. * 2: is a trivial fix for documentation url. * 3: is a log guest error fix for the CSU DMA. Best Regards, Fred Frederic Konrad (3): hw/ssi/xilinx_spips: fix an out of bound access

[PATCH v1 1/3] hw/ssi/xilinx_spips: fix an out of bound access

out of s->regs[addr] in xilinx_spips_write for spips and qspips. This fixes that wrong behavior. Reviewed-by: Luc Michel Signed-off-by: Frederic Konrad --- hw/ssi/xilinx_spips.c | 7 ++- include/hw/ssi/xilinx_spips.h | 3 +++ 2 files changed, 9 insertions(+), 1 deletion(-) d

[PATCH v1 2/3] fix some url for amd / xilinx models

It seems that the url changed a bit, and it triggers an error. Fix the URLs so the documentation can be reached again. Signed-off-by: Frederic Konrad --- hw/dma/xlnx_csu_dma.c | 2 +- include/hw/misc/xlnx-versal-cframe-reg.h | 2 +- include/hw/misc/xlnx-versal-cfu.h

[PATCH v1 3/3] hw/dma/xlnx_csu_dma: don't throw guest errors when stopping the SRC DMA

in that case. While at it remove the comment marking the SIZE register as write-only. See: https://docs.xilinx.com/r/en-US/ug1087-zynq-ultrascale-registers/CSUDMA_SRC_SIZE-CSUDMA-Register Signed-off-by: Frederic Konrad --- hw/dma/xlnx_csu_dma.c | 12 1 file changed, 8 insertions(+), 4

Re: hw/display/xlinx-dp: fixing comment

58ac482a66de09a7590f705e53fc6a3fb8a055e8 Author: Frederic Konrad Date:  Tue Jun 14 15:59:15 2016 +0100     introduce xlnx-dp     This is the implementation of the DisplayPort.     It has an aux-bus to access dpcd and edid. This commit has the following comment in it: +static void xlnx_dp_audio_callback(void

Re: Support for Gaisler multicore LEONx SoCs

Hi Gregg, AFAIK the leon3-generic can emulate the GR712RC with some little differences in the memorymap and / or timer / CPU count.  (You should be able to boot the Gaisler monocore linux with it). About the SMP support AdaCore had a few patches for it, I'll let Fabien answer. Regards,Fred

RE: [PATCH v3 0/4] xlnx-zcu102: fix the display port.

> -Original Message- > From: Peter Maydell > Sent: 06 June 2022 11:20 > To: Frederic Konrad > Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; > edgar.igles...@gmail.com; alist...@alistair23.me; Sai Pavan Boddu > ; Edgar Iglesias ; > fkon...@amd.com > Subje

RE: [PATCH v2 2/4] xlnx_dp: Introduce a vblank signal

> -Original Message- > From: Peter Maydell > Sent: 23 May 2022 14:52 > To: Frederic Konrad > Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; > edgar.igles...@gmail.com; alist...@alistair23.me; Sai Pavan Boddu > ; Edgar Iglesias ; Sai Pavan Boddu > ; Edgar

[PATCH v2 1/4] xlnx_dp: fix the wrong register size

xlnx-dp") Signed-off-by: Frederic Konrad Reviewed-by: Edgar E. Iglesias --- hw/display/xlnx_dp.c | 17 ++--- include/hw/display/xlnx_dp.h | 9 +++-- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/hw/display/xlnx_dp.c b/hw/display/xlnx_dp.c index

[PATCH v2 2/4] xlnx_dp: Introduce a vblank signal

From: Sai Pavan Boddu Add a periodic timer which raises vblank at a frequency of 30Hz. Signed-off-by: Sai Pavan Boddu Signed-off-by: Edgar E. Iglesias Changes by fkonrad: - Switched to transaction-based ptimer API. - Added the DP_INT_VBLNK_START macro. Signed-off-by: Frederic Konrad

[PATCH v2 0/4] xlnx-zcu102: fix the display port.

last patches. Tested by booting Petalinux with the framebuffer enabled. Best Regards, Fred v1 -> v2: * Better use of the ptimer API by using a correct POLICY as suggested by Peter Maydell (Patch 2). * Rebased on 78ac2eeb. Frederic Konrad (2): xlnx_dp: fix the wrong register s

[PATCH v2 3/4] xlnx_dp: Fix the interrupt disable logic

From: Sai Pavan Boddu Fix interrupt disable logic. Mask value 1 indicates that interrupts are disabled. Signed-off-by: Sai Pavan Boddu Reviewed-by: Edgar E. Iglesias Signed-off-by: Frederic Konrad --- hw/display/xlnx_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 4/4] xlnx-zynqmp: fix the irq mapping for the display port and its dma

-off-by: Frederic Konrad Reviewed-by: Edgar E. Iglesias --- hw/arm/xlnx-zynqmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c index 375309e68e..383e177a00 100644 --- a/hw/arm/xlnx-zynqmp.c +++ b/hw/arm/xlnx-zynqmp.c @@ -60,10

RE: [PATCH v1 2/4] xlnx_dp: Introduce a vblank signal

> -Original Message- > From: Peter Maydell > Sent: 16 May 2022 10:57 > To: Frederic Konrad > Cc: qemu-devel@nongnu.org; alist...@alistair23.me; > edgar.igles...@gmail.com; qemu-...@nongnu.org; Sai Pavan Boddu > ; Edgar Iglesias ; > fkon...@amd.com; Sai Pava

RE: [PATCH v1 0/4] xlnx-zcu102: fix the display port.

.@alistair23.me; edgar.igles...@gmail.com; > peter.mayd...@linaro.org; qemu-...@nongnu.org; Sai Pavan Boddu > ; Edgar Iglesias ; > fkon...@amd.com > Subject: [PATCH v1 0/4] xlnx-zcu102: fix the display port. > > From: Frederic Konrad > > Hi, > > This patch set fixes so

RE: [PATCH v1 4/4] hw/arm: versal: Connect the CRL

@gmail.com; Francisco Eduardo Iglesias > ; Sai Pavan Boddu ; Frederic > Konrad ; Edgar Iglesias ; > edgar.igles...@amd.com > Subject: [PATCH v1 4/4] hw/arm: versal: Connect the CRL > > From: "Edgar E. Iglesias" > > Connect the CRL (Clock Reset LPD) to the Versal

RE: [PATCH v1 3/4] hw/misc: Add a model of the Xilinx Versal CRL

@gmail.com; Francisco Eduardo Iglesias > ; Sai Pavan Boddu ; Frederic > Konrad ; Edgar Iglesias ; > edgar.igles...@amd.com > Subject: [PATCH v1 3/4] hw/misc: Add a model of the Xilinx Versal CRL > > From: "Edgar E. Iglesias" > > Add a model of the Xilinx Versal

RE: [PATCH v1 2/4] hw/arm: versal: Add the Cortex-R5Fs

Iglesias ; Sai Pavan Boddu ; Frederic Konrad ; Edgar Iglesias ; edgar.igles...@amd.com Subject: [PATCH v1 2/4] hw/arm: versal: Add the Cortex-R5Fs From: "Edgar E. Iglesias" Add the Cortex-R5Fs of the Versal RPU (Real-time Processing Unit) subsystem. Signed-off-by: Edgar E. Iglesias -

RE: [PATCH v1 1/4] hw/arm: versal: Create an APU CPU Cluster

Iglesias ; Sai Pavan Boddu ; Frederic Konrad ; Edgar Iglesias ; edgar.igles...@amd.com Subject: [PATCH v1 1/4] hw/arm: versal: Create an APU CPU Cluster From: "Edgar E. Iglesias" Create an APU CPU Cluster. This is in preparation to add the RPU. Signed-off-by: Edgar E. Iglesias --- h

Re: [Qemu-devel] [PULL 28/30] introduce xlnx-dp

Le 4/7/22 à 12:32, Peter Maydell a écrit : On Tue, 14 Jun 2016 at 15:40, Peter Maydell wrote: From: KONRAD Frederic This is the implementation of the DisplayPort. It has an aux-bus to access dpcd and edid. Graphic plane is connected to the channel 3. Video plane is connected to the

[PATCH] MAINTAINERS: change Fred Konrad's email address

frederic.kon...@adacore.com and kon...@adacore.com will stop working starting 2022-04-01. Use my personal email instead. Signed-off-by: Frederic Konrad --- .mailmap| 3 ++- MAINTAINERS | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/.mailmap b/.mailmap index

[PATCH] hw/avr/atmega.c: use the avr51 cpu for atmega1280

o test.elf $ qemu-system-avr -serial mon:stdio -nographic -no-reboot -M mega \ -bios test.elf qemu-system-avr: Current machine: Arduino Mega (ATmega1280) with 'avr6' CPU qemu-system-avr: ELF image 'test.elf' is for 'avr51' CPU So this fixes the atmega1280 class to use an avr51 CPU. Si

[PATCH v1] target/m68k: fix gdb for m68xxx

From: KONRAD Frederic Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects a coldfire FPU instead of the default m68881 FPU. This is not OK because the m68881 floats registers are 96 bits wide

Re: [Qemu-devel] [PATCH V3 0/7] execute code from mmio area

Ping! This is mostly reviewed maybe the 6th patch needs a little look. Thanks, Fred On 04/28/2017 04:59 PM, fred.kon...@greensocs.com wrote: > From: KONRAD Frederic > > This series allows to execute code from mmio areas. > The main goal of this is to be able to run

Re: [Qemu-devel] [PATCH] hw: dead code removal

Hi, On 03/20/2017 07:00 PM, Anton Volkov wrote: > Made functions *_exit in hw/ return void instead of int (they returned 0 all > the time) > and removed related return value checks > > Signed-off-by: Anton Volkov > --- > hw/audio/hda-codec.c | 3 +-- >

Re: [Qemu-devel] [PATCH v2 00/11] MTTCG fixups for 2.9

On 03/06/2017 10:43 AM, Alex Bennée wrote: > > Frederic Konrad <fred.kon...@greensocs.com> writes: > >> Hi All, >> >> I've a strangeness with the "drop iolock" patch. >> It seems it has an impact on the MMIO execution patch-set I'm workin

Re: [Qemu-devel] [PATCH v2 00/11] MTTCG fixups for 2.9

Hi All, I've a strangeness with the "drop iolock" patch. It seems it has an impact on the MMIO execution patch-set I'm working on: Basically modifying the memory tree is causing a Bad Ram Address error. I wonder if this can't happen with hotplug/unplug model as well. I'll look into this. Shoot

Re: [Qemu-devel] [PATCH v2 10/11] target/arm/helper: make it clear the EC field is also in hex

On 03/02/2017 08:53 PM, Alex Bennée wrote: > ..just like the rest of the displayed ESR register. Otherwise people > might scratch their heads if a not obviously hex number is displayed > for the EC field. > > Signed-off-by: Alex Bennée > --- > target/arm/helper.c | 2 +-

Re: [Qemu-devel] [PATCH v2 11/11] hw/intc/arm_gic: modernise the DPRINTF

Hi Alex, On 03/02/2017 08:53 PM, Alex Bennée wrote: > While I was debugging the icount issues I realised a bunch of the > messages look quite similar. I've fixed this by including __func__ in > the debug print. At the same time I move the a modern if (GATE) style > printf which ensures the

Re: [Qemu-devel] [PATCH V2 4/7] exec: allow to get a pointer for some mmio memory region

On 03/03/2017 02:44 PM, Edgar E. Iglesias wrote: > On Fri, Feb 17, 2017 at 09:17:10PM +0100, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> This introduces a special callback which allows to run code from some MMIO >> devices. >> >> SysBusDevice with a

Re: [Qemu-devel] [PATCH V2 0/7] execute code from mmio area

Hi All, Any feedback for the 4 last patches? Thanks, Fred On 02/17/2017 09:17 PM, fred.kon...@greensocs.com wrote: > From: KONRAD Frederic > > This series allows to execute code from mmio areas. > The main goal of this is to be able to run code for example from an

Re: [Qemu-devel] [PATCH V1 3/7] cputlb: fix the way get_page_addr_code fills the tlb

On 02/23/2017 01:31 AM, Richard Henderson wrote: > On 02/17/2017 01:30 AM, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> get_page_addr_code(..) does a cpu_ldub_code to fill the tlb: >> This can lead to some side effects if a device is mapped at this

Re: [Qemu-devel] Creating a dummy PCI device

Hi Peter, This won't be easy unfortunately, at least not clean :). The vendor_id device_id are part of the PCIDeviceClass. So I _think_ you can't use a qom parameter for that. But... it seems that these fields are used firstly in pci_qdev_realize (to be checked) so maybe it's okay to change them

Re: [Qemu-devel] [PATCH V1 0/7] execute code from mmio area

On 02/16/2017 03:39 PM, Paolo Bonzini wrote: > > > On 16/02/2017 15:30, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> This series allows to execute code from mmio areas. >> The main goal of this is to be able to run code for example from an SPI >>

Re: [Qemu-devel] [PATCH V1 0/7] execute code from mmio area

On 02/16/2017 03:39 PM, Paolo Bonzini wrote: > > > On 16/02/2017 15:30, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> This series allows to execute code from mmio areas. >> The main goal of this is to be able to run code for example from an SPI >>

Re: [Qemu-devel] Asking about USB for QEMU

Hi, If I understand right: You want to run a zynq qemu on a centos host? On 02/09/2017 09:25 AM, Wojciech Zebrowski wrote: > Hi > > I try connect my host linux centos USB to Qemu for Xilinx Zynq solution. > I do following step : > 1.Check usb vendor id , product id: lsusb > > > > > *Bus 001

Re: [Qemu-devel] [PATCH v4] nios2: Add Altera JTAG UART emulation

On 02/09/2017 09:53 PM, Bystricky, Juro wrote: > > >> On 02/09/2017 07:52 PM, Juro Bystricky wrote: >>> JTAG UART core eliminates the need for a separate RS-232 serial >>> connection to a host PC for character I/O. >> >> And how does this describe the content of this patch ? This patch adds a >>

Re: [Qemu-devel] [PATCH v4] nios2: Add Altera JTAG UART emulation

Hi, On 02/09/2017 07:52 PM, Juro Bystricky wrote: > JTAG UART core eliminates the need for a separate RS-232 serial > connection to a host PC for character I/O. > > Hardware emulation based on: > https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf > (Please see "Register Map" on

Re: [Qemu-devel] question about binary translation on qemu

On 02/07/2017 02:53 PM, oussema ben khedher wrote: > hi > in my academic project i needed to know how qemu exactly translate an arm > instruction to the host assembly (in my case x86) so if you can help me to > know the function in the source code of qemu that tdo this work > thank you > Hi,

Re: [Qemu-devel] [PATCH V2 06/10] docs: add qemu-clock documentation

On 02/07/2017 05:13 PM, Peter Maydell wrote: > On 26 January 2017 at 09:47, wrote: >> From: KONRAD Frederic >> >> This adds the qemu-clock documentation. >> >> Signed-off-by: KONRAD Frederic >> >> V1 -> V2: >> *

Re: [Qemu-devel] [RFC 4/5] exec: allow to get a pointer for some mmio memory region

On 02/04/2017 02:59 PM, Frederic Konrad wrote: > On 02/04/2017 01:41 PM, Paolo Bonzini wrote: >> > ... >>> >>> Doesn't hotplug use dynamic MemoryRegion? In which case we better >>> make that work with MTTCG. I wonder if we can't simply handle that >&g

Re: [Qemu-devel] [PATCH V2 02/10] qemu-clk: allow to add a clock to a device

On 02/07/2017 10:31 AM, Cédric Le Goater wrote: > On 02/07/2017 10:22 AM, Frederic Konrad wrote: >>> I see how these routines are used in patch 10/10. But if we were >>> open coding device CRF_APB, I don't think we would need them at >>> all and it would make the code

Re: [Qemu-devel] [PATCH V2 03/10] qemu-clk: allow to bind two clocks together

On 02/06/2017 04:58 PM, Cédric Le Goater wrote: > Hello, > > On 01/26/2017 10:47 AM, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> This introduces the clock binding and the update part. >> When the qemu_clk_rate_update(qemu_clk, int) function is

Re: [Qemu-devel] [PATCH V2 02/10] qemu-clk: allow to add a clock to a device

On 02/06/2017 03:20 PM, Cédric Le Goater wrote: > On 01/26/2017 10:47 AM, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> This allows to add a clock to a DeviceState. >> Contrary to gpios, the clock pins are not contained in the DeviceState but >> with

Re: [Qemu-devel] [PATCH V2 01/10] qemu-clk: introduce qemu-clk qom object

>> # qapi >> diff --git a/include/qemu/qemu-clock.h b/include/qemu/qemu-clock.h >> new file mode 100644 >> index 000..e7acd68 >> --- /dev/null >> +++ b/include/qemu/qemu-clock.h >> @@ -0,0 +1,40 @@ >> +/* >>

Re: [Qemu-devel] [RFC 0/5] execute code from mmio area

On 02/04/2017 02:17 PM, Peter Maydell wrote: > On 4 February 2017 at 12:52, Frederic Konrad <fred.kon...@greensocs.com> > wrote: >> Is that the case that we might get a Bad RAM address error or some such >> if we are not on a page boundary (or too small

Re: [Qemu-devel] [RFC 4/5] exec: allow to get a pointer for some mmio memory region

On 02/04/2017 01:41 PM, Paolo Bonzini wrote: > ... >> >> Doesn't hotplug use dynamic MemoryRegion? In which case we better >> make that work with MTTCG. I wonder if we can't simply handle that >> with a safe_work for this case? > > Hot-unplug works because the backing memory is only freed when

Re: [Qemu-devel] [RFC 0/5] execute code from mmio area

On 02/04/2017 01:33 PM, Peter Maydell wrote: > On 3 February 2017 at 17:06, wrote: >> From: KONRAD Frederic >> >> This patch-set allows to execute code from mmio areas. >> The main goal of this is to be able to run code for example from an

Re: [Qemu-devel] [RFC 1/5] cputlb: cleanup get_page_addr_code to use VICTIM_TLB_HIT

On 02/04/2017 12:30 PM, Edgar E. Iglesias wrote: > On Fri, Feb 03, 2017 at 06:06:33PM +0100, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic >> >> This replaces env1 and page_index variables by env and index >> so we can use VICTIM_TLB_HIT macro later. >> > >

Re: [Qemu-devel] [RFC 4/5] exec: allow to get a pointer for some mmio memory region

On 02/03/2017 06:26 PM, Paolo Bonzini wrote: > > > On 03/02/2017 09:06, fred.kon...@greensocs.com wrote: >> +host = mr->ops->request_ptr(mr->opaque, addr - mr->addr, , >> ); >> + >> +if (!host || !size) { >> +memory_region_transaction_commit(); >> +return false; >> +

Re: [Qemu-devel] [PATCH V2 00/10] Clock framework API.

Ping! Thanks, Fred On 01/26/2017 10:47 AM, fred.kon...@greensocs.com wrote: > From: KONRAD Frederic > > Hi, > > This is the second version of the clock framework API it contains: > > * The first 6 patches which introduce the framework. > * The 7th patch which

Re: [Qemu-devel] implementing architectural timers using QEMU timers

On 01/09/2017 04:18 PM, Max Filippov wrote: > Hello, > > I'm trying to reimplement xtensa CCOUNT (cycle counter) and > CCOMPARE (CCOUNT-based timer interrupts) using QEMU > timers. That is CCOUNT value is derived from the > QEMU_CLOCK_VIRTUAL clock and CCOMPARE interrupts are > generated from the

Re: [Qemu-devel] [PATCH v2] i2c: Fix SMBus read transactions to avoid double events

On 06/28/2016 09:30 PM, miny...@acm.org wrote: > From: Corey Minyard > > Change 2293c27faddf (i2c: implement broadcast write) added broadcast > capability to the I2C bus, but it broke SMBus read transactions. > An SMBus read transaction does two i2c_start_transaction() calls

Re: [Qemu-devel] [PATCH for-2.7] aux: Rename aux.[ch] to auxbus.[ch] for the benefit of Windows

On 07/01/2016 02:45 PM, Peter Maydell wrote: > On Windows 'aux.*' is a reserved name and cannot be used for > filenames; see > > https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247(v=vs.85).aspx > > This prevents cloning the QEMU git repo on Windows: > > C:\Java\sources\kvm> git

Re: [Qemu-devel] Making all TB invalidation asynchronous (MTTCG safe_work)?

Hi Alex, We decided in Seattle to make this flag per tb (eg move it to the tb struct). On 24/02/2016 18:30, Alex Bennée wrote: > Hi, > > So I've been working on reducing MTTCG tb_lock contention and currently > have a tb_lock around the following code (in my cpu_exec): > > /* Note: we do

Re: [Qemu-devel] [RFC PATCH 0/3] (Resend) TranslationBlock annotation mechanism

Hi, Is there a git tree with this series somewhere? Looks nice. Thanks, Fred On 14/01/2016 11:55, Peer Adelt wrote: > Hey guys :) > > We have developed a generic concept to annotate TranslationBlocks during > runtime. The initial idea was to use it for time annotation with data from > static

Re: [Qemu-devel] [PATCH v2 11/16] qdev: Define qdev_get_gpio_out

On 19/01/2016 23:35, Alistair Francis wrote: > From: Peter Crosthwaite > > An API similar to the existing qdev_get_gpio_in() except gets outputs. > Useful for: > > 1: Implementing lightweight devices that don't want to keep pointers > to their own GPIOs. They can get

Re: [Qemu-devel] [PATCH v1 00/15] data-driven device registers

On 08/01/2016 11:40, Peter Maydell wrote: > On 8 January 2016 at 00:39, Alistair Francis > wrote: >> On Wed, Dec 16, 2015 at 8:33 AM, Alistair Francis >> wrote: >>> On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell

Re: [Qemu-devel] [PATCH V6 7/8] introduce xlnx-dp

play/xlnx_dp.c >> new file mode 100644 >> index 000..4238d69 >> --- /dev/null >> +++ b/hw/display/xlnx_dp.c >> @@ -0,0 +1,1361 @@ >> +/* >> + * xlnx_dp.c >> + * >> + * Copyright (C) 2015 : GreenSocs Ltd >> + * http://www.gr

Re: [Qemu-devel] [PATCH V6 8/8] arm: xlnx-zynqmp: Add xlnx-dp and xlnx-dpdma

On 16/01/2016 02:50, Alistair Francis wrote: > On Mon, Jan 4, 2016 at 10:25 AM, wrote: >> From: KONRAD Frederic >> >> This adds the DP and the DPDMA to the Zynq MP platform. >> >> Signed-off-by: KONRAD Frederic >>

Re: [Qemu-devel] [PATCH V6 0/8] Xilinx DisplayPort.

On 16/01/2016 01:33, Alistair Francis wrote: > On Mon, Jan 4, 2016 at 10:25 AM, wrote: >> From: KONRAD Frederic >> >> This is the 6th version of this patch-set of the implementation of the Xilinx >> DisplayPort and DPDMA. >> >> This 6th

Re: [Qemu-devel] [RFC v1 1/1] i2c: Factor our send() and recv() common logic

On 02/11/2015 10:09, Frederic Konrad wrote: > On 19/10/2015 06:09, Peter Crosthwaite wrote: >> Most of the control flow logic between send and recv (error checking >> etc) is the same. Factor this out into a common send_recv() API. >> This is then usable by clients, wh

Re: [Qemu-devel] [PATCH V5 7/8] introduce xlnx-dp

a/hw/display/xlnx_dp.c b/hw/display/xlnx_dp.c >> new file mode 100644 >> index 000..e91221c >> --- /dev/null >> +++ b/hw/display/xlnx_dp.c >> @@ -0,0 +1,1370 @@ >> +/* >> + * xlnx_dp.c >> + * >> + * Copyright (C) 2015 : GreenSocs Ltd >> + *

Re: [Qemu-devel] [PATCH V5 8/8] arm: xlnx-zynqmp: Add xlnx-dp and xlnx-dpdma

On 24/11/2015 04:42, Alistair Francis wrote: > On Mon, Nov 23, 2015 at 6:53 PM, KONRAD Frederic > wrote: >> >> Le 20/11/2015 13:21, Alistair Francis a écrit : >>> On Fri, Oct 16, 2015 at 7:11 PM, wrote: From: KONRAD Frederic

Re: [Qemu-devel] [RFC v1 1/1] i2c: Factor our send() and recv() common logic

On 19/10/2015 06:09, Peter Crosthwaite wrote: > Most of the control flow logic between send and recv (error checking > etc) is the same. Factor this out into a common send_recv() API. > This is then usable by clients, where the control logic for send > and receive differs only by a boolean. E.g.

Re: [Qemu-devel] [PATCH V5 2/8] introduce aux-bus

= aux.o >> diff --git a/hw/misc/aux.c b/hw/misc/aux.c >> new file mode 100644 >> index 000..bf300f7 >> --- /dev/null >> +++ b/hw/misc/aux.c >> @@ -0,0 +1,374 @@ >> +/* >> + * aux.c >> + * >> + * Copyright 2015 : GreenSocs Ltd >> + *

Re: [Qemu-devel] [PATCH v3 4/5] xlnx-zynqmp: Connect the SPI devices

On 29/10/2015 03:00, Peter Crosthwaite wrote: > On Wed, Oct 28, 2015 at 10:32 AM, Alistair Francis < > alistair.fran...@xilinx.com> wrote: > >> Connect the Xilinx SPI device to the ZynqMP model. >> >> > "devices" > > >> Signed-off-by: Alistair Francis >> --- >> V3: >>

Re: [Qemu-devel] [PATCH V5 0/8] Xilinx DisplayPort.

On 16/10/2015 23:57, Alistair Francis wrote: > On Fri, Oct 16, 2015 at 6:41 AM, wrote: >> From: KONRAD Frederic >> >> This is the fifth version of this patch-set of the implementation of the >> Xilinx >> DisplayPort and DPDMA. >> >> This

Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.

Hi Claudio, I'll rebase soon tomorrow with a bit of luck ;). Thanks, Fred On 07/10/2015 14:46, Claudio Fontana wrote: > Hello Frederic, > > On 11.08.2015 08:27, Frederic Konrad wrote: >> On 11/08/2015 08:15, Benjamin Herrenschmidt wrote: >>> On Mon, 2015-08-10

Re: [Qemu-devel] [PATCH V4 6/8] Introduce xilinx dpdma.

On 04/09/2015 01:34, Alistair Francis wrote: On Thu, Sep 3, 2015 at 12:28 AM, Frederic Konrad <fred.kon...@greensocs.com> wrote: On 02/09/2015 23:39, Alistair Francis wrote: On Tue, Jul 21, 2015 at 10:17 AM, <fred.kon...@greensocs.com> wrote: From: KONRAD Frederic <fred.kon..

Re: [Qemu-devel] [PATCH V4 1/8] i2cbus: remove unused dev field.

On 01/09/2015 22:58, Alistair Francis wrote: On Tue, Jul 21, 2015 at 10:17 AM, wrote: From: KONRAD Frederic Seems this field is not needed. The commit message should be updated to represent the patch. Hmmm what do you mean? It's not

Re: [Qemu-devel] [PATCH V4 4/8] introduce dpcd module.

l: i...@greensocs.com + * + * Developed by : + * Frederic Konrad <fred.kon...@greensocs.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the Lic

Re: [Qemu-devel] [PATCH V4 2/8] Introduce AUX bus.

reensocs.com/ , email: i...@greensocs.com + * + * Developed by : + * Frederic Konrad <fred.kon...@greensocs.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Softwar

Re: [Qemu-devel] MTTCG Tasks (kvmforum summary)

Hi Alex, On 04/09/2015 09:49, Alex Bennée wrote: Hi, At KVM Forum I sat down with Paolo and Frederic and we came up with the current outstanding tasks on MTTCG. This is not comprehensive but hopefully covers the big areas. They are sorted in rough order we'd like to get them up-streamed. *

Re: [Qemu-devel] [PATCH V4 6/8] Introduce xilinx dpdma.

a.h new file mode 100644 index 000..ae571a0 --- /dev/null +++ b/hw/dma/xlnx_dpdma.h @@ -0,0 +1,85 @@ +/* + * xlnx_dpdma.h + * + * Copyright (C) 2015 : GreenSocs Ltd + * http://www.greensocs.com/ , email: i...@greensocs.com + * + * Developed by : + * Frederic Konrad <fred.kon...@green

Re: [Qemu-devel] [PATCH 03/10] replace spinlock by QemuMutex.

On 28/08/2015 16:49, Peter Maydell wrote: On 12 August 2015 at 17:40, Paolo Bonzini pbonz...@redhat.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com spinlock is only used in two cases: * cpu-exec.c: to protect TranslationBlock * mem_helper.c: for lock helper in target-i386

[Qemu-devel] MTTCG next version?

Hi everybody, I'm trying to do the next version of the MTTCG work: I would like to rebase on Alvise atomic instruction branch: - Alvise can you rebase it on the 2.4.0 version without MTTCG support and then point me to the MTTCG specific changes so I can include them in my tree? I will

Re: [Qemu-devel] [RFC PATCH V7 07/19] protect TBContext with tb_lock.

On 12/08/2015 20:20, Alex Bennée wrote: Frederic Konrad fred.kon...@greensocs.com writes: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com This protects TBContext with tb_lock to make tb_* thread safe. We can still have issue

Re: [Qemu-devel] [PATCH 00/10] translate-all.c thread-safety

On 12/08/2015 18:40, Paolo Bonzini wrote: Hi, this is my attempt at 1) extracting upstreamable parts out of Fred's MTTCG, Can you take this one as well after the replace spinlock by QemuMutex: remove unused spinlock. Thanks, Fred and 2) documenting what's going on in user-mode MTTCG 3) fix

Re: [Qemu-devel] [PATCH 05/10] cpu-exec: elide more icount code if CONFIG_USER_ONLY

On 12/08/2015 18:40, Paolo Bonzini wrote: Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- cpu-exec.c | 6 ++ 1 file changed, 6 insertions(+) What about the icount part in CPUState and the tb_start/end ? Can't this be removed as well? Fred diff --git a/cpu-exec.c b/cpu-exec.c

Re: [Qemu-devel] [PATCH 12/10] tcg: protect TBContext with tb_lock.

On 12/08/2015 18:41, Paolo Bonzini wrote: From: KONRAD Frederic fred.kon...@greensocs.com This protects TBContext with tb_lock to make tb_* thread safe. We can still have issue with tb_flush in case of multithread TCG: another CPU can be executing code during a flush. This can be fixed later

Re: [Qemu-devel] [PATCH 12/10] tcg: protect TBContext with tb_lock.

On 13/08/2015 15:01, Paolo Bonzini wrote: +tb_lock(); tb = tb_gen_code(cpu, orig_tb-pc, orig_tb-cs_base, orig_tb-flags, max_cycles | CF_NOCACHE); tb_gen_code() calls tb_alloc() which calls tb_flush() we end in a double tb_lock here. But that's probably not

Re: [Qemu-devel] [PATCH 11/10] tcg: comment on which functions have to be called with tb_lock held

On 12/08/2015 18:41, Paolo Bonzini wrote: softmmu requires more functions to be thread-safe, because translation blocks can be invalidated from e.g. notdirty callbacks. Probably the same holds for user-mode emulation, it's just that no one has ever tried to produce a coherent locking there.

Re: [Qemu-devel] [PATCH 03/10] replace spinlock by QemuMutex.

On 13/08/2015 15:12, Paolo Bonzini wrote: On 13/08/2015 14:17, Frederic Konrad wrote: diff --git a/linux-user/main.c b/linux-user/main.c index fdee981..fd06ce9 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -107,7 +107,7 @@ static int pending_cpus; /* Make sure everything

Re: [Qemu-devel] [PATCH 02/10] cpus: remove tcg_halt_cond global variable.

On 12/08/2015 18:40, Paolo Bonzini wrote: From: KONRAD Frederic fred.kon...@greensocs.com This removes tcg_halt_cond global variable. We need one QemuCond per virtual cpu for multithread TCG. Signed-off-by: KONRAD Frederic fred.kon...@greensocs.com Message-Id:

Re: [Qemu-devel] [PATCH 03/10] replace spinlock by QemuMutex.

On 12/08/2015 18:40, Paolo Bonzini wrote: From: KONRAD Frederic fred.kon...@greensocs.com spinlock is only used in two cases: * cpu-exec.c: to protect TranslationBlock * mem_helper.c: for lock helper in target-i386 (which seems broken). It's a pthread_mutex_t in user-mode so better using

Re: [Qemu-devel] [PATCH 02/10] cpus: remove tcg_halt_cond global variable.

On 13/08/2015 15:08, Paolo Bonzini wrote: On 13/08/2015 15:05, Frederic Konrad wrote: This removes tcg_halt_cond global variable. We need one QemuCond per virtual cpu for multithread TCG. Signed-off-by: KONRAD Frederic fred.kon...@greensocs.com Message-Id: 1439220437-23957-9-git-send-email

Re: [Qemu-devel] [PATCH 11/10] tcg: comment on which functions have to be called with tb_lock held

On 13/08/2015 14:59, Paolo Bonzini wrote: On 13/08/2015 14:51, Frederic Konrad wrote: diff --git a/include/qom/cpu.h b/include/qom/cpu.h index 77bbff2..56b1f4d 100644 --- a/include/qom/cpu.h +++ b/include/qom/cpu.h @@ -285,7 +285,10 @@ struct CPUState { void *env_ptr; /* CPUArchState

Re: [Qemu-devel] [RFC PATCH V7 11/19] tcg: switch on multithread.

On 13/08/2015 13:17, Paolo Bonzini wrote: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: +while (!cpu-exit_request) { qemu_clock_enable(QEMU_CLOCK_VIRTUAL, (cpu-singlestep_enabled SSTEP_NOTIMER) == 0); @@ -1507,7 +1480,7 @@ static void

Re: [Qemu-devel] [RFC PATCH V7 11/19] tcg: switch on multithread.

On 13/08/2015 16:58, Paolo Bonzini wrote: On 13/08/2015 16:41, Frederic Konrad wrote: One issue here is that when tcg_cpu_exec returns EXCP_HALTED, the function keeps looping. There is no need to set cpu-exit_request in that case, since in fact there is no request pending, so the while loop

Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.

On 11/08/2015 15:59, Frederic Konrad wrote: On 11/08/2015 14:45, Paolo Bonzini wrote: On 10/08/2015 17:26, fred.kon...@greensocs.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com This is the 7th round of the MTTCG patch series. Thanks to look at this. Here is a list of issues

Re: [Qemu-devel] [RFC PATCH V7 09/19] Drop global lock during TCG code execution

On 12/08/2015 11:58, Paolo Bonzini wrote: On 11/08/2015 23:34, Frederic Konrad wrote: Also if qemu_cond_broadcast(qemu_io_proceeded_cond) is being dropped there is no point keeping the guff around in qemu_tcg_wait_io_event. Yes good point. BTW this leads to high consumption of host CPU eg

Re: [Qemu-devel] [RFC PATCH V7 16/19] translate-all: introduces tb_flush_safe.

On 12/08/2015 16:09, Paolo Bonzini wrote: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com tb_flush is not thread safe we definitely need to exit VCPUs to do that. This introduces tb_flush_safe which just creates an async safe work which

Re: [Qemu-devel] [RFC PATCH V7 07/19] protect TBContext with tb_lock.

On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com This protects TBContext with tb_lock to make tb_* thread safe. We can still have issue with tb_flush in case of multithread TCG: An other CPU can be executing code during a flush. This can

Re: [Qemu-devel] [RFC PATCH V7 09/19] Drop global lock during TCG code execution

On 11/08/2015 22:12, Alex Bennée wrote: Paolo Bonzini pbonz...@redhat.com writes: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: void qemu_mutex_lock_iothread(void) { -atomic_inc(iothread_requesting_mutex); -/* In the simple case there is no need to bump the VCPU thread out

Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.

On 11/08/2015 08:15, Benjamin Herrenschmidt wrote: On Mon, 2015-08-10 at 17:26 +0200, fred.kon...@greensocs.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com This is the 7th round of the MTTCG patch series. It can be cloned from: g...@git.greensocs.com:fkonrad/mttcg.git branch

Re: [Qemu-devel] [RFC PATCH V7 07/19] protect TBContext with tb_lock.

On 10/08/2015 18:36, Paolo Bonzini wrote: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: diff --git a/cpu-exec.c b/cpu-exec.c index f3358a9..a012e9d 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -131,6 +131,8 @@ static void init_delay_params(SyncClocks *sc, const CPUState *cpu) void

Re: [Qemu-devel] [RFC PATCH V7 09/19] Drop global lock during TCG code execution

On 10/08/2015 18:15, Paolo Bonzini wrote: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: void qemu_mutex_lock_iothread(void) { -atomic_inc(iothread_requesting_mutex); -/* In the simple case there is no need to bump the VCPU thread out of - * TCG code execution. - */

Re: [Qemu-devel] [RFC PATCH V7 02/19] cpus: add tcg_exec_flag.

On 11/08/2015 12:53, Paolo Bonzini wrote: On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: @@ -583,5 +587,6 @@ int cpu_exec(CPUState *cpu) /* fail safe : never use current_cpu outside cpu_exec() */ current_cpu = NULL; +tcg_cpu_allow_execution(cpu); I don't think this

Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.

On 11/08/2015 14:45, Paolo Bonzini wrote: On 10/08/2015 17:26, fred.kon...@greensocs.com wrote: From: KONRAD Frederic fred.kon...@greensocs.com This is the 7th round of the MTTCG patch series. Thanks to look at this. Here is a list of issues that I found: - tb_lock usage in tb_find_fast is

  1   2   3   >