[PATCH] docs: add precision about capstone for execlog plugin

2024-06-20 Thread Alexandre Iooss
Some people are wondering why they get an empty string as disassembly.
Most of the time, they configured QEMU without Capstone support.
Let's document this behaviour to help users.

Signed-off-by: Alexandre Iooss 
---
 docs/devel/tcg-plugins.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 9cc09d8c3d..f7d7b9e3a4 100644
--- a/docs/devel/tcg-plugins.rst
+++ b/docs/devel/tcg-plugins.rst
@@ -539,7 +539,9 @@ which will output an execution trace following this 
structure::
   0, 0xd34, 0xf9c8f000, "bl #0x10c8"
   0, 0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x20e4, RAM
 
-the output can be filtered to only track certain instructions or
+Please note that you need to configure QEMU with Capstone support to get 
disassembly.
+
+The output can be filtered to only track certain instructions or
 addresses using the ``ifilter`` or ``afilter`` options. You can stack the
 arguments if required::
 
-- 
2.30.2




Re: [PATCH] STM32F100: support different density lines

2023-06-26 Thread Alexandre IOOSS

On 6/20/23 00:18, Lucas Villa Real wrote:

This patch adds support for the emulation of different density lines
(low, medium, and high). A new class property stm32f100-soc.density=
has been introduced to allow users to state the desired configuration.
That property is recognized by a new machine, stm32f1-generic. The SOC
is configured according to the following:

density=low   32 KB FLASH, 2 SPIs
density=medium   128 KB FLASH, 2 SPIs
density=high 512 KB FLASH, 3 SPIs

With this code change we should be able to introduce richer features
to STM32F100, such as support for FSMC (so that a machine with more
RAM capacity can be properly emulated). FSMC is supported on high
density line devices only.


Thanks a lot for the patches!

STM32 families look very similar to each other, it makes great sense to 
take a generic approach rather than bloating QEMU with many machines.


You patch proposes to create a "stm32f1-generic" machine. I believe we 
should rather name this machine "stm32f100-generic":
  - STM32F101 has a XL-density line, STM32F100 does not have a 
XL-density line.
  - STM32F100 high density line does not have the same maximum SRAM 
size, timers, USART numbers, clock frequencies and CEC peripherals as 
the STM32F101 high density line.


Regarding the stm32vldiscovery machine, I am not against deprecating it 
if we warn users to use stm32f100-generic with density=medium. This 
makes sense as the development board does not add anything more than 
just some buttons and LED.
Maybe "stm32vldiscovery" could become an alias for stm32f100-generic 
machine ?
@Alistair: Do you have an opinion on aliasing the old machine? Is this 
something common in QEMU?


In the long run, we should maybe rename "stm32f100-soc.c" to 
"stm32f1-soc.c" and add another class property to choose the sub-family. 
This would highly reduce potential code duplication.

STM32F1 machines could take this structure:
 - stm32f100-generic machine
   - stm32f1-soc.family=f100 stm32f1-soc.density=low
   - stm32f1-soc.family=f100 stm32f1-soc.density=medium
 (alias stm32vldiscovery)
   - stm32f1-soc.family=f100 stm32f1-soc.density=high
 - stm32f101-generic machine
   - stm32f1-soc.family=f101 stm32f1-soc.density=low
   - stm32f1-soc.family=f101 stm32f1-soc.density=medium
   - stm32f1-soc.family=f101 stm32f1-soc.density=high
   - stm32f1-soc.family=f101 stm32f1-soc.density=xl
 - stm32f102-generic machine
   - stm32f1-soc.family=f102 stm32f1-soc.density=low
   - stm32f1-soc.family=f102 stm32f1-soc.density=medium
 - stm32f103-generic machine
   - stm32f1-soc.family=f103 stm32f1-soc.density=low
   - stm32f1-soc.family=f103 stm32f1-soc.density=medium
 (alias stm32-nucleo-f103rb)
   - stm32f1-soc.family=f103 stm32f1-soc.density=high
   - stm32f1-soc.family=f103 stm32f1-soc.density=xl
@Alistair: Would such modification make also sense regarding stm32f2 and 
stm32f4 families?


Thanks,
--
Alexandre


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] stm32vldiscovery: allow overriding of RAM size

2023-04-04 Thread Alexandre IOOSS

On 4/3/23 16:48, Lucas C. Villa Real wrote:
On Mon, Apr 3, 2023 at 10:54 AM Peter Maydell > wrote:


On Mon, 3 Apr 2023 at 13:51, Lucas Villa Real mailto:luca...@gmail.com>> wrote:
 >
 > stm32vldiscovery comes with 8KB of SRAM, which may be too low when
 > running some workloads on QEMU. The command line argument "-m
mem_size"
 > is not recognized by the current implementation, though, so one
cannot
 > easily override the default memory size.
 >
 > This patch fixes that by adding a memory subregion according to the
 > value provided on that command line argument. If absent, the default
 > value of 8KB still applies.
 >
 > Signed-off-by: Lucas Villa Real mailto:lu...@osdyne.com>>

Does the real hardware have (options for) more than 8K of SRAM here ?

thanks
-- PMM


Yes, it's possible to add more (p)SRAM via the STM32F10xxx's FSMC 
(flexible static memory controller). The new memory is mapped to FSMC 
bank 1 at 0x6000_, though (as opposed to the embedded SRAM's fixed 
address at 0x2000_), as I have now realized. I'm happy to send an 
updated patch so that "-m mem_size" creates a memory subregion at 
0x6000_ instead.


Best regards,
Lucas



Looking at the STM32F100xx reference manual page 494 
(https://www.st.com/resource/en/reference_manual/rm0041-stm32f100xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf), 
FSMC is only present on high-density value line devices only. This is 
not the case of the STM32VLDISCOVERY which uses a STM32F100RB 
(low/medium-density value line).


Correct me if I'm wrong, but I believe you cannot buy a STM32VLDISCOVERY 
that could support FSMC or have more than 8KB of on-chip SRAM.


However, could it be a good idea to implement a generic STM32F100xx 
machine in QEMU that is "high-density" by default and that could be 
configured using command line options ? This could cover a wide range of 
cases with a single machine.


Thanks,
--
Alexandre


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v1 2/2] plugins: extend execlog to filter matches

2022-04-03 Thread Alexandre IOOSS


On 3/28/22 17:26, Alex Bennée wrote:

Sometimes the whole execlog is just two much so add the ability to
filter by instruction opcode or address.

[AJB: this shows for example

  .qemu-system-aarch64 -display none -serial mon:stdio \
-M virt -cpu max \
-semihosting-config enable=on \
-kernel ./tests/tcg/aarch64-softmmu/memory-sve \
-plugin ./contrib/plugins/libexeclog.so,ifilter=st1w,afilter=0x40001808 -d 
plugin -D plugin.out

the st1w SVE instruction is not instrumenting its stores.]

Signed-off-by: Alex Bennée 
Cc: Robert Henry 
Cc: Aaron Lindsay 


Thanks!

Reviewed-by: Alexandre Iooss 

--
Alexandre


OpenPGP_signature
Description: OpenPGP digital signature


Re: [RFC PATCH 0/1] QEMU TCG plugin interface extensions

2021-08-21 Thread Alexandre IOOSS

On 8/21/21 11:45 AM, Florian Hauschild wrote:

Hi all,

I extended the plugin interface with additional functionalities.
I wrote the extensions for fault injection/exploration reasearch using
QEMU. The additional functionalities for a plugin are:
   * Read and write guest memory
   * Read and write guest registers
   * Allow plugin to force QEMU into single step mode
   * Flush TB cache from plugin


If something is added to read a register from a plugin, then execlog 
plugin could print the operands value of each instruction. This would 
definitely be helpful for side-channel analysis: the Hamming weight (sum 
of bits) of the last operand roughly models the power consumption 
side-channel leakage.


If I recall correctly, there are some concerns about allowing to access 
registers inside plugins. Past threads about reading/writing registers:

https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg08741.html
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg04588.html

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 19/25] hw/arm/msf2: Use Clock input to MSF2_SOC instead of m3clk property

2021-08-14 Thread Alexandre IOOSS


On 8/14/21 12:11 PM, Peter Maydell wrote:

On Sat, 14 Aug 2021 at 10:20, Alexandre IOOSS  wrote:



On 8/12/21 11:33 AM, Peter Maydell wrote:

Instead of passing the MSF2 SoC an integer property specifying the
CPU clock rate, pass it a Clock instead.  This lets us wire that
clock up to the armv7m object.

Signed-off-by: Peter Maydell 



@@ -72,7 +74,10 @@ static void emcraft_sf2_s2s010_init(MachineState *machine)
* in Libero. CPU clock is divided by APB0 and APB1 divisors for
* peripherals. Emcraft's SoM kit comes with these settings by default.
*/
-qdev_prop_set_uint32(dev, "m3clk", 142 * 100);
+/* This clock doesn't need migration because it is fixed-frequency */
+m3clk = clock_new(OBJECT(machine), "m3clk");
+clock_set_hz(m3clk, 142 * 100);


Maybe something could be added in the commit message to say that M3_CLK
is changed from 100MHz to 142MHz.


I'm not sure what you mean here? This commit doesn't change the frequency:
we previously set the m3clk property to "142 * 100" and now we set the
clock's hz setting to the same thing.


My bad, I did not realize the board was already setting the frequency to 
142MHz.


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 22/25] hw/arm/stellaris: Fix code style issues in GPTM code

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Fix the code style issues in the Stellaris general purpose timer
module code, so that when we move it to a different file in a
following patch checkpatch doesn't complain.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 19/25] hw/arm/msf2: Use Clock input to MSF2_SOC instead of m3clk property

2021-08-14 Thread Alexandre IOOSS
tem_memory();
  MemoryRegion *ddr = g_new(MemoryRegion, 1);
+Clock *m3clk;
  
  if (strcmp(machine->cpu_type, mc->default_cpu_type) != 0) {

  error_report("This board can only be used with CPU %s",
@@ -72,7 +74,10 @@ static void emcraft_sf2_s2s010_init(MachineState *machine)
   * in Libero. CPU clock is divided by APB0 and APB1 divisors for
   * peripherals. Emcraft's SoM kit comes with these settings by default.
   */
-qdev_prop_set_uint32(dev, "m3clk", 142 * 100);
+/* This clock doesn't need migration because it is fixed-frequency */
+m3clk = clock_new(OBJECT(machine), "m3clk");
+clock_set_hz(m3clk, 142 * 100);


Maybe something could be added in the commit message to say that M3_CLK 
is changed from 100MHz to 142MHz. I do not know the SmartFusion2 but the 
clocking guide seems to agree with 142MHz:

https://www.microsemi.com/document-portal/doc_download/132012-ug0449-smartfusion2-and-igloo2-clocking-resources-user-guide


+qdev_connect_clock_in(dev, "m3clk", m3clk);
  qdev_prop_set_uint32(dev, "apb0div", 2);
  qdev_prop_set_uint32(dev, "apb1div", 2);
  



Reviewed-by: Alexandre Iooss 

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 18/25] hw/arm/msf2_soc: Don't allocate separate MemoryRegions

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

In the realize method of the msf2-soc SoC object, we call g_new() to
create new MemoryRegion objects for the nvm, nvm_alias, and sram.
This is unnecessary; make these MemoryRegions member fields of the
device state struct instead.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre




OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 17/25] hw/arm/stellaris: Wire sysclk up to armv7m

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Connect the sysclk to the armv7m object.  This board's SoC does not
connect up the systick reference clock, so we don't need to connect a
refclk.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 16/25] hw/arm/stellaris: split stellaris_sys_init()

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Currently the stellaris_sys_init() function creates the
TYPE_STELLARIS_SYS object, sets its properties, realizes it, maps its
MMIO region and connects its IRQ.  In order to support wiring the
sysclk up to the armv7m object, we need to split this function apart,
because to connect the clock output of the STELLARIS_SYS object to
the armv7m object we need to create the STELLARIS_SYS object before
the armv7m object, but we can't wire up the IRQ until after we've
created the armv7m object.

Remove the stellaris_sys_init() function, and instead put the
create/configure/realize parts before we create the armv7m object and
the mmio/irq connection parts afterwards.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 15/25] hw/arm/nrf51: Wire up sysclk

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Wire up the sysclk input to the armv7m object.

Strictly this SoC should not have a systick device at all, but our
armv7m container object doesn't currently support disabling the
systick device.  For the moment, add a TODO comment, but note that
this is why we aren't wiring up a refclk (no need for one).

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 13/25] hw/arm/stm32f405: Wire up sysclk and refclk

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Wire up the sysclk and refclk for the stm32f405 SoC.  This SoC always
runs the systick refclk at 1/8 the frequency of the main CPU clock,
so the board code only needs to provide a single sysclk clock.

Because there is only one board using this SoC, we convert the SoC
and the board together, rather than splitting it into "add clock to
SoC; connect clock in board; add error check in SoC code that clock
is wired up".

When the systick device starts honouring its clock inputs, this will
fix an emulation inaccuracy in the netduinoplus2 board where the
systick reference clock was running at 1MHz rather than 21MHz.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 12/25] hw/arm/stm32f205: Wire up sysclk and refclk

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Wire up the sysclk and refclk for the stm32f205 SoC.  This SoC always
runs the systick refclk at 1/8 the frequency of the main CPU clock,
so the board code only needs to provide a single sysclk clock.

Because there is only one board using this SoC, we convert the SoC
and the board together, rather than splitting it into "add clock to
SoC; connect clock in board; add error check in SoC code that clock
is wired up".

When the systick device starts honouring its clock inputs, this will
fix an emulation inaccuracy in the netduino2 board where the systick
reference clock was running at 1MHz rather than 15MHz.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 11/25] hw/arm/stm32f100: Wire up sysclk and refclk

2021-08-14 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Wire up the sysclk and refclk for the stm32f100 SoC.  This SoC always
runs the systick refclk at 1/8 the frequency of the main CPU clock,
so the board code only needs to provide a single sysclk clock.

Because there is only one board using this SoC, we convert the SoC
and the board together, rather than splitting it into "add clock to
SoC; connect clock in board; add error check in SoC code that clock
is wired up".

When the systick device starts honouring its clock inputs, this will
fix an emulation inaccuracy in the stm32vldiscovery board where the
systick reference clock was running at 1MHz rather than 3MHz.

Signed-off-by: Peter Maydell 


Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 14/25] hw/arm/stm32vldiscovery: Delete trailing blank line

2021-08-12 Thread Alexandre IOOSS


On 8/12/21 11:33 AM, Peter Maydell wrote:

Delete the trailing blank line at the end of the source file.

Signed-off-by: Peter Maydell 
---
  hw/arm/stm32vldiscovery.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c
index 07e401a818d..9b79004703b 100644
--- a/hw/arm/stm32vldiscovery.c
+++ b/hw/arm/stm32vldiscovery.c
@@ -65,4 +65,3 @@ static void stm32vldiscovery_machine_init(MachineClass *mc)
  }
  
  DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init)

-



Reviewed-by: Alexandre Iooss 

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 10/25] hw/arm: Don't allocate separate MemoryRegions in stm32 SoC realize

2021-08-12 Thread Alexandre IOOSS
nit_ram(>sram, NULL, "STM32F205.sram", SRAM_SIZE,
 _fatal);
-memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, sram);
+memory_region_add_subregion(system_memory, SRAM_BASE_ADDRESS, >sram);
  
  armv7m = DEVICE(>armv7m);

  qdev_prop_set_uint32(armv7m, "num-irq", 96);



Reviewed-by: Alexandre Iooss 

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 09/25] clock: Provide builtin multiplier/divider

2021-08-12 Thread Alexandre IOOSS
needed = muldiv_needed,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(multiplier, Clock),
+VMSTATE_UINT32(divider, Clock),
+},
+};
+
  const VMStateDescription vmstate_clock = {
  .name = "clock",
  .version_id = 0,
@@ -21,5 +39,9 @@ const VMStateDescription vmstate_clock = {
  .fields = (VMStateField[]) {
  VMSTATE_UINT64(period, Clock),
  VMSTATE_END_OF_LIST()
-}
+},
+.subsections = (const VMStateDescription*[]) {
+_muldiv,
+NULL
+},
  };
diff --git a/hw/core/clock.c b/hw/core/clock.c
index fc5a99683f8..c371b9e977a 100644
--- a/hw/core/clock.c
+++ b/hw/core/clock.c
@@ -64,6 +64,15 @@ bool clock_set(Clock *clk, uint64_t period)
  return true;
  }
  
+static uint64_t clock_get_child_period(Clock *clk)

+{
+/*
+ * Return the period to be used for child clocks, which is the parent
+ * clock period adjusted for for multiplier and divider effects.
+ */
+return muldiv64(clk->period, clk->multiplier, clk->divider);
+}
+
  static void clock_call_callback(Clock *clk, ClockEvent event)
  {
  /*
@@ -78,15 +87,16 @@ static void clock_call_callback(Clock *clk, ClockEvent 
event)
  static void clock_propagate_period(Clock *clk, bool call_callbacks)
  {
  Clock *child;
+uint64_t child_period = clock_get_child_period(clk);
  
  QLIST_FOREACH(child, >children, sibling) {

-if (child->period != clk->period) {
+if (child->period != child_period) {
  if (call_callbacks) {
  clock_call_callback(child, ClockPreUpdate);
  }
-child->period = clk->period;
+child->period = child_period;
  trace_clock_update(CLOCK_PATH(child), CLOCK_PATH(clk),
-   CLOCK_PERIOD_TO_HZ(clk->period),
+   CLOCK_PERIOD_TO_HZ(child->period),
 call_callbacks);
  if (call_callbacks) {
  clock_call_callback(child, ClockUpdate);
@@ -110,7 +120,7 @@ void clock_set_source(Clock *clk, Clock *src)
  
  trace_clock_set_source(CLOCK_PATH(clk), CLOCK_PATH(src));
  
-clk->period = src->period;

+clk->period = clock_get_child_period(src);
  QLIST_INSERT_HEAD(>children, clk, sibling);
  clk->source = src;
  clock_propagate_period(clk, false);
@@ -133,10 +143,21 @@ char *clock_display_freq(Clock *clk)
  return freq_to_str(clock_get_hz(clk));
  }
  
+void clock_set_mul_div(Clock *clk, uint32_t multiplier, uint32_t divider)

+{
+assert(divider != 0);
+
+clk->multiplier = multiplier;
+clk->divider = divider;
+}
+
  static void clock_initfn(Object *obj)
  {
  Clock *clk = CLOCK(obj);
  
+clk->multiplier = 1;

+clk->divider = 1;
+
  QLIST_INIT(>children);
  }
  



Reviewed-by: Alexandre Iooss 

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 03/25] arm: Move system PPB container handling to armv7m

2021-08-12 Thread Alexandre IOOSS
_OK;
-}
-
-static MemTxResult ppb_default_write(void *opaque, hwaddr addr,
- uint64_t value, unsigned size,
- MemTxAttrs attrs)
-{
-qemu_log_mask(LOG_UNIMP, "Write of unassigned area of PPB: offset 0x%x\n",
-  (uint32_t)addr);
-if (attrs.user) {
-return MEMTX_ERROR;
-}
-return MEMTX_OK;
-}
-
-static const MemoryRegionOps ppb_default_ops = {
-.read_with_attrs = ppb_default_read,
-.write_with_attrs = ppb_default_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
-.valid.min_access_size = 1,
-.valid.max_access_size = 8,
-};
-
  static int nvic_post_load(void *opaque, int version_id)
  {
  NVICState *s = opaque;
@@ -2770,66 +2686,13 @@ static void armv7m_nvic_realize(DeviceState *dev, Error 
**errp)
  s->num_prio_bits = arm_feature(>cpu->env, ARM_FEATURE_V7) ? 8 : 2;
  
  /*

- * This device provides a single sysbus memory region which
- * represents the whole of the "System PPB" space. This is the
- * range from 0xe000 to 0xe00f and includes the NVIC,
- * the System Control Space (system registers), the systick timer,
- * and for CPUs with the Security extension an NS banked version
- * of all of these.
- *
- * The default behaviour for unimplemented registers/ranges
- * (for instance the Data Watchpoint and Trace unit at 0xe0001000)
- * is to RAZ/WI for privileged access and BusFault for non-privileged
- * access.
- *
- * The NVIC and System Control Space (SCS) starts at 0xe000e000
- * and looks like this:
- *  0x004 - ICTR
- *  0x010 - 0xff - systick
- *  0x100..0x7ec - NVIC
- *  0x7f0..0xcff - Reserved
- *  0xd00..0xd3c - SCS registers
- *  0xd40..0xeff - Reserved or Not implemented
- *  0xf00 - STIR
- *
- * Some registers within this space are banked between security states.
- * In v8M there is a second range 0xe002e000..0xe002efff which is the
- * NonSecure alias SCS; secure accesses to this behave like NS accesses
- * to the main SCS range, and non-secure accesses (including when
- * the security extension is not implemented) are RAZ/WI.
- * Note that both the main SCS range and the alias range are defined
- * to be exempt from memory attribution (R_BLJT) and so the memory
- * transaction attribute always matches the current CPU security
- * state (attrs.secure == env->v7m.secure). In the nvic_sysreg_ns_ops
- * wrappers we change attrs.secure to indicate the NS access; so
- * generally code determining which banked register to use should
- * use attrs.secure; code determining actual behaviour of the system
- * should use env->v7m.secure.
- *
- * The container covers the whole PPB space. Within it the priority
- * of overlapping regions is:
- *  - default region (for RAZ/WI and BusFault) : -1
- *  - system register regions : 0
- *  - systick : 1
- * This is because the systick device is a small block of registers
- * in the middle of the other system control registers.
+ * This device provides a single memory region which covers the
+ * sysreg/NVIC registers from 0xE000E000 .. 0xE000EFFF, with the
+ * exception of the systick timer registers 0xE000E010 .. 0xE000E0FF.
   */
-memory_region_init(>container, OBJECT(s), "nvic", 0x10);
-memory_region_init_io(>defaultmem, OBJECT(s), _default_ops, s,
-  "nvic-default", 0x10);
-memory_region_add_subregion_overlap(>container, 0, >defaultmem, -1);
  memory_region_init_io(>sysregmem, OBJECT(s), _sysreg_ops, s,
"nvic_sysregs", 0x1000);
-memory_region_add_subregion(>container, 0xe000, >sysregmem);
-
-if (arm_feature(>cpu->env, ARM_FEATURE_V8)) {
-memory_region_init_io(>sysreg_ns_mem, OBJECT(s),
-  _sysreg_ns_ops, >sysregmem,
-  "nvic_sysregs_ns", 0x1000);
-    memory_region_add_subregion(>container, 0x2e000, >sysreg_ns_mem);
-}
-
-sysbus_init_mmio(SYS_BUS_DEVICE(dev), >container);
+sysbus_init_mmio(SYS_BUS_DEVICE(dev), >sysregmem);
  }
  
  static void armv7m_nvic_instance_init(Object *obj)




My review is week because I am new to this codebase.

Reviewed-by: Alexandre Iooss 

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH for-6.2 01/25] arm: Move M-profile RAS register block into its own device

2021-08-12 Thread Alexandre IOOSS
w/misc/meson.build
@@ -17,6 +17,8 @@ softmmu_ss.add(when: 'CONFIG_INTEGRATOR_DEBUG', if_true: 
files('arm_integrator_d
  softmmu_ss.add(when: 'CONFIG_A9SCU', if_true: files('a9scu.c'))
  softmmu_ss.add(when: 'CONFIG_ARM11SCU', if_true: files('arm11scu.c'))
  
+softmmu_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('armv7m_ras.c'))

+
  # Mac devices
  softmmu_ss.add(when: 'CONFIG_MOS6522', if_true: files('mos6522.c'))
  



Looks good to me! My review is weak because I am still new to QEMU codebase.

Reviewed-by: Alexandre Iooss 

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] docs/devel: fix missing antislash

2021-08-10 Thread Alexandre IOOSS

On 8/9/21 8:14 PM, Eduardo Habkost wrote:

On Mon, Aug 09, 2021 at 07:31:41PM +0200, Alexandre Iooss wrote:

Signed-off-by: Alexandre Iooss 
---
  docs/devel/qom.rst | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/devel/qom.rst b/docs/devel/qom.rst
index e5fe3597cd..b9568c0fb8 100644
--- a/docs/devel/qom.rst
+++ b/docs/devel/qom.rst
@@ -309,7 +309,7 @@ This is equivalent to the following:
 OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE)
 #define MY_DEVICE_CLASS(void *klass) \
 OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE)
-   #define MY_DEVICE(void *obj)
+   #define MY_DEVICE(void *obj) \
 OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE)


Oops, nice catch!

However, the code above is already going to be deleted by:
https://lore.kernel.org/qemu-devel/20210729175554.686474-9-ehabk...@redhat.com



Oh I was not aware of that new patch, it looks great while also solving 
the anti-slash problem!


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH] docs/devel: fix missing antislash

2021-08-09 Thread Alexandre Iooss
Signed-off-by: Alexandre Iooss 
---
 docs/devel/qom.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/devel/qom.rst b/docs/devel/qom.rst
index e5fe3597cd..b9568c0fb8 100644
--- a/docs/devel/qom.rst
+++ b/docs/devel/qom.rst
@@ -309,7 +309,7 @@ This is equivalent to the following:
OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE)
#define MY_DEVICE_CLASS(void *klass) \
OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE)
-   #define MY_DEVICE(void *obj)
+   #define MY_DEVICE(void *obj) \
OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE)
 
struct MyDeviceClass {
-- 
2.31.1




[PATCH v3 0/2] execlog TCG plugin to log instructions

2021-07-02 Thread Alexandre Iooss
execlog is a plugin that logs executed instructions with some useful
metadata including memory access.

The output of the plugin is designed to be usable with other tools. For
example it could be used with a side-channel leakage model to create
side-channel traces from QEMU for security evaluation.

Changes since v2:
 - Fix typo "tvg-plugins" to "tcg-plugins" in commit title.
 - Add warning about plugin output size in documentation.
 - Fix user mode tracing by using a dynamic list.
 - Fix last instructions not being logged.
 - Remove empty first line in plugin output.

Changes since v1:
 - The output is now easier to parse.
 - Use QEMU logging API rather than FILE* to write output.
 - Don't reject memory information in user mode.
 - Merge memory information with instruction execution. Now one line
   means one instruction.
 - Add documentation.

Alexandre Iooss (2):
  contrib/plugins: add execlog to log instruction execution and memory
access
  docs/devel: tcg-plugins: add execlog plugin description

 MAINTAINERS|   1 +
 contrib/plugins/Makefile   |   1 +
 contrib/plugins/execlog.c  | 153 +
 docs/devel/tcg-plugins.rst |  24 ++
 4 files changed, 179 insertions(+)
 create mode 100644 contrib/plugins/execlog.c

-- 
2.31.1




[PATCH v3 1/2] contrib/plugins: add execlog to log instruction execution and memory access

2021-07-02 Thread Alexandre Iooss
Log instruction execution and memory access to a file.
This plugin can be used for reverse engineering or for side-channel analysis
using QEMU.

Signed-off-by: Alexandre Iooss 
Reviewed-by: Alex Bennée 
---
 MAINTAINERS   |   1 +
 contrib/plugins/Makefile  |   1 +
 contrib/plugins/execlog.c | 153 ++
 3 files changed, 155 insertions(+)
 create mode 100644 contrib/plugins/execlog.c

diff --git a/MAINTAINERS b/MAINTAINERS
index cfbf7ef79b..709ae43864 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2978,6 +2978,7 @@ F: include/tcg/
 
 TCG Plugins
 M: Alex Bennée 
+R: Alexandre Iooss 
 S: Maintained
 F: docs/devel/tcg-plugins.rst
 F: plugins/
diff --git a/contrib/plugins/Makefile b/contrib/plugins/Makefile
index b9d7935e5e..51093acd17 100644
--- a/contrib/plugins/Makefile
+++ b/contrib/plugins/Makefile
@@ -13,6 +13,7 @@ include $(BUILD_DIR)/config-host.mak
 VPATH += $(SRC_PATH)/contrib/plugins
 
 NAMES :=
+NAMES += execlog
 NAMES += hotblocks
 NAMES += hotpages
 NAMES += howvec
diff --git a/contrib/plugins/execlog.c b/contrib/plugins/execlog.c
new file mode 100644
index 00..2de9f0d7d4
--- /dev/null
+++ b/contrib/plugins/execlog.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright (C) 2021, Alexandre Iooss 
+ *
+ * Log instruction execution with memory access.
+ *
+ * License: GNU GPL, version 2 or later.
+ *   See the COPYING file in the top-level directory.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+/* Store last executed instruction on each vCPU as a GString */
+GArray *last_exec;
+
+/**
+ * Add memory read or write information to current instruction log
+ */
+static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info,
+ uint64_t vaddr, void *udata)
+{
+GString *s;
+
+/* Find vCPU in array */
+g_assert(cpu_index < last_exec->len);
+s = g_array_index(last_exec, GString *, cpu_index);
+
+/* Indicate type of memory access */
+if (qemu_plugin_mem_is_store(info)) {
+g_string_append(s, ", store");
+} else {
+g_string_append(s, ", load");
+}
+
+/* If full system emulation log physical address and device name */
+struct qemu_plugin_hwaddr *hwaddr = qemu_plugin_get_hwaddr(info, vaddr);
+if (hwaddr) {
+uint64_t addr = qemu_plugin_hwaddr_phys_addr(hwaddr);
+const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
+g_string_append_printf(s, ", 0x%08"PRIx64", %s", addr, name);
+} else {
+g_string_append_printf(s, ", 0x%08"PRIx64, vaddr);
+}
+}
+
+/**
+ * Log instruction execution
+ */
+static void vcpu_insn_exec(unsigned int cpu_index, void *udata)
+{
+GString *s;
+
+/* Find or create vCPU in array */
+while (cpu_index >= last_exec->len) {
+s = g_string_new(NULL);
+g_array_append_val(last_exec, s);
+}
+s = g_array_index(last_exec, GString *, cpu_index);
+
+/* Print previous instruction in cache */
+if (s->len) {
+qemu_plugin_outs(s->str);
+qemu_plugin_outs("s\n");
+}
+
+/* Store new instruction in cache */
+/* vcpu_mem will add memory access information to last_exec */
+g_string_printf(s, "%u, ", cpu_index);
+g_string_append(s, (char *)udata);
+}
+
+/**
+ * On translation block new translation
+ *
+ * QEMU convert code by translation block (TB). By hooking here we can then 
hook
+ * a callback on each instruction and memory access.
+ */
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+struct qemu_plugin_insn *insn;
+uint64_t insn_vaddr;
+uint32_t insn_opcode;
+char *insn_disas;
+
+size_t n = qemu_plugin_tb_n_insns(tb);
+for (size_t i = 0; i < n; i++) {
+/*
+ * `insn` is shared between translations in QEMU, copy needed data 
here.
+ * `output` is never freed as it might be used multiple times during
+ * the emulation lifetime.
+ * We only consider the first 32 bits of the instruction, this may be
+ * a limitation for CISC architectures.
+ */
+insn = qemu_plugin_tb_get_insn(tb, i);
+insn_vaddr = qemu_plugin_insn_vaddr(insn);
+insn_opcode = *((uint32_t *)qemu_plugin_insn_data(insn));
+insn_disas = qemu_plugin_insn_disas(insn);
+char *output = g_strdup_printf("0x%"PRIx64", 0x%"PRIx32", \"%s\"",
+   insn_vaddr, insn_opcode, insn_disas);
+
+/* Register callback on memory read or write */
+qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem,
+ QEMU_PLUGIN_CB_NO_REGS,
+ QEMU_PLUGIN_MEM_RW, NULL);
+
+/* Register callback on instruction */
+qemu_plu

[PATCH v3 2/2] docs/devel: tcg-plugins: add execlog plugin description

2021-07-02 Thread Alexandre Iooss
This adds description of the execlog TCG plugin with an example.

Signed-off-by: Alexandre Iooss 
---
 docs/devel/tcg-plugins.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 18c6581d85..c1e589693c 100644
--- a/docs/devel/tcg-plugins.rst
+++ b/docs/devel/tcg-plugins.rst
@@ -319,3 +319,27 @@ the user to see what hardware is accessed how often. It 
has a number of options:
   off:001c, 1, 2
   off:0020, 1, 2
   ...
+
+- contrib/plugins/execlog.c
+
+The execlog tool traces executed instructions with memory access. It can be 
used
+for debugging and security analysis purposes.
+Please be aware that this will generate a lot of output.
+
+The plugin takes no argument::
+
+  qemu-system-arm $(QEMU_ARGS) \
+-plugin ./contrib/plugins/libexeclog.so -d plugin
+
+which will output an execution trace following this structure::
+
+  # vCPU, vAddr, opcode, disassembly[, load/store, memory addr, device]...
+  0, 0xa12, 0xf8012400, "movs r4, #0"
+  0, 0xa14, 0xf87f42b4, "cmp r4, r6"
+  0, 0xa16, 0xd206, "bhs #0xa26"
+  0, 0xa18, 0xfff94803, "ldr r0, [pc, #0xc]", load, 0x00010a28, RAM
+  0, 0xa1a, 0xf989f000, "bl #0xd30"
+  0, 0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee0, RAM, store, 
0x20003ee4, RAM
+  0, 0xd32, 0xf9893014, "adds r0, #0x14"
+  0, 0xd34, 0xf9c8f000, "bl #0x10c8"
+  0, 0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x20e4, RAM
-- 
2.31.1




Re: [PATCH v2 0/2] execlog TCG plugin to log instructions

2021-07-01 Thread Alexandre IOOSS



On 7/1/21 8:49 PM, Alex Bennée wrote:


Alexandre Iooss  writes:


execlog is a plugin that logs executed instructions with some useful
metadata including memory access.

The output of the plugin is designed to be usable with other tools. For
example it could be used with a side-channel leakage model to create
side-channel traces from QEMU for security evaluation.

Changes since v1:
  - The output is now easier to parse.
  - Use QEMU logging API rather than FILE* to write output.
  - Don't reject memory information in user mode.
  - Merge memory information with instruction execution. Now one line
means one instruction.
  - Add documentation.


Where you planning on posting v3? I'm just seeing if we can get this
merged before code freeze in a weeks time.



I had a deadline next week but I managed to move it later, so I can try 
to make the important changes tomorrow and send v3.


I think I will contribute the support for triggering the beginning and 
end of tracing in another patch as I believe that's something we don't 
want to rush.


Thanks,

-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v2 2/2] docs/devel: tvg-plugins: add execlog plugin description

2021-06-22 Thread Alexandre IOOSS

On 6/22/21 12:37 PM, Alex Bennée wrote:


Alexandre IOOSS  writes:


[[PGP Signed Part:Undecided]]
On 6/22/21 10:48 AM, Alex Bennée wrote:

Alexandre Iooss  writes:

[...]
+
+The execlog tool traces executed instructions with memory access. It can be 
used
+for debugging and security analysis purposes.

We should probably mention that this will generate a lot of output.
Running the admittedly memory heavy softmmu memory test:
./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \
  -plugin contrib/plugins/libexeclog.so  \
  -cpu max -serial mon:stdio -M virt \
  -display none -semihosting-config chardev=serial0 \
  -kernel ./tests/tcg/aarch64-softmmu/memory
generates a 8.6Gb text file. I suspect once this is merged you might
want to look at options to target the instrumentation at areas of
specific interest or abbreviate information.


Yes! In my downstream version I am triggering the beginning and the
end of trace acquisition by matching two virtual addresses of GPIO
device access. This works in my case because I'm also using the same
GPIO for triggering an oscilloscope, but maybe we would like to
upstream something more generic.

I'm still thinking about this (maybe for a later patch) but I believe
it would be nice to have the following:
  - If no argument is given to the plugin, log everything.
  - Allow the user to specify either a memory address, an instruction
virtual address or an opcode that would start the acquisition.
  - Same to stop the acquisition.


Sounds reasonable to me.


This would look like this to start/stop acquisition using GPIO PA8 on
STM32VLDISCOVERY:

   ./arm-softmmu/qemu-system-arm -M stm32vldiscovery \
 -kernel ./firmware.elf -d plugin \
 -plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424


I quite like the formats you can use for -dfilter, for example:

   0x1000+0x100,0x2100-0x100,0x3000..0x3100

it might even be worth exposing qemu_set_dfilter_ranges as a helper
function to plugins to avoid copy and paste.


We could expose "-dfilter", but maybe it is better to reserve it to 
filter the output of the plugin rather than triggering the tracing?


I could implement a format similar to dfilter to configure triggering. 
This would enable someone to start logging on any access to a memory range.




So what would your above command trigger? A write to 1073809424 would
start the trace and the next write to the same address would stop it?



Yes exactly. In this case the first access set the GPIO high, and the 
second access set it low.


I don't believe the plugin can access the value stored in memory (i.e. 
differentiating between setting a GPIO output high or low). I don't find 
this problematic in my case, but maybe it could be for someone else.


From the discussion I see the following possible patches:
1. Add an argument to trigger the beginning with one address (memory or 
instruction).
2. Add an argument to trigger the end with one address (memory or 
instruction).

3. Add the support for ranges (in "dfilter" style).
4. (maybe) Add the support to trigger on an opcode.
5. Add support for "-dfilter" to filter the logging output.

Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v2 2/2] docs/devel: tvg-plugins: add execlog plugin description

2021-06-22 Thread Alexandre IOOSS

On 6/22/21 10:48 AM, Alex Bennée wrote:

Alexandre Iooss  writes:

[...]
+
+The execlog tool traces executed instructions with memory access. It can be 
used
+for debugging and security analysis purposes.

We should probably mention that this will generate a lot of output.
Running the admittedly memory heavy softmmu memory test:

   ./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \
 -plugin contrib/plugins/libexeclog.so  \
 -cpu max -serial mon:stdio -M virt \
 -display none -semihosting-config chardev=serial0 \
 -kernel ./tests/tcg/aarch64-softmmu/memory

generates a 8.6Gb text file. I suspect once this is merged you might
want to look at options to target the instrumentation at areas of
specific interest or abbreviate information.


Yes! In my downstream version I am triggering the beginning and the end 
of trace acquisition by matching two virtual addresses of GPIO device 
access. This works in my case because I'm also using the same GPIO for 
triggering an oscilloscope, but maybe we would like to upstream 
something more generic.


I'm still thinking about this (maybe for a later patch) but I believe it 
would be nice to have the following:

 - If no argument is given to the plugin, log everything.
 - Allow the user to specify either a memory address, an instruction 
virtual address or an opcode that would start the acquisition.

 - Same to stop the acquisition.

This would look like this to start/stop acquisition using GPIO PA8 on 
STM32VLDISCOVERY:


  ./arm-softmmu/qemu-system-arm -M stm32vldiscovery \
-kernel ./firmware.elf -d plugin \
-plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424

I would like to hear other users opinion on this, because I fear I might 
implement something too specific.


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v2 1/2] contrib/plugins: add execlog to log instruction execution and memory access

2021-06-22 Thread Alexandre IOOSS

On 6/22/21 10:37 AM, Alex Bennée wrote:

We only allocate last_exec for system.max_vcpus here. You need to check
the system_emulation bool before using that information and error out if
it's not system emulation.


My bad, I did not test user mode emulation after converting last_exec to 
an array. Should I consider only one vCPU in user mode emulation?


-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH v2] docs/system: arm: Add nRF boards description

2021-06-21 Thread Alexandre Iooss
This adds the target guide for BBC Micro:bit.

Information is taken from https://wiki.qemu.org/Features/MicroBit
and from hw/arm/nrf51_soc.c.

Signed-off-by: Alexandre Iooss 
Reviewed-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS|  1 +
 docs/system/arm/nrf.rst| 51 ++
 docs/system/target-arm.rst |  1 +
 3 files changed, 53 insertions(+)
 create mode 100644 docs/system/arm/nrf.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 636bf2f536..7c54611cc2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1031,6 +1031,7 @@ F: hw/*/microbit*.c
 F: include/hw/*/nrf51*.h
 F: include/hw/*/microbit*.h
 F: tests/qtest/microbit-test.c
+F: docs/system/arm/nrf.rst
 
 AVR Machines
 -
diff --git a/docs/system/arm/nrf.rst b/docs/system/arm/nrf.rst
new file mode 100644
index 00..eda87bd760
--- /dev/null
+++ b/docs/system/arm/nrf.rst
@@ -0,0 +1,51 @@
+Nordic nRF boards (``microbit``)
+
+
+The `Nordic nRF`_ chips are a family of ARM-based System-on-Chip that
+are designed to be used for low-power and short-range wireless solutions.
+
+.. _Nordic nRF: https://www.nordicsemi.com/Products
+
+The nRF51 series is the first series for short range wireless applications.
+It is superseded by the nRF52 series.
+The following machines are based on this chip :
+
+- ``microbit``   BBC micro:bit board with nRF51822 SoC
+
+There are other series such as nRF52, nRF53 and nRF91 which are currently not
+supported by QEMU.
+
+Supported devices
+-
+
+ * ARM Cortex-M0 (ARMv6-M)
+ * Serial ports (UART)
+ * Clock controller
+ * Timers
+ * Random Number Generator (RNG)
+ * GPIO controller
+ * NVMC
+ * SWI
+
+Missing devices
+---
+
+ * Watchdog
+ * Real-Time Clock (RTC) controller
+ * TWI (i2c)
+ * SPI controller
+ * Analog to Digital Converter (ADC)
+ * Quadrature decoder
+ * Radio
+
+Boot options
+
+
+The Micro:bit machine can be started using the ``-device`` option to load a
+firmware in `ihex format`_. Example:
+
+.. _ihex format: https://en.wikipedia.org/wiki/Intel_HEX
+
+.. code-block:: bash
+
+  $ qemu-system-arm -M microbit -device loader,file=test.hex
diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst
index edd013c7bb..5277ac0242 100644
--- a/docs/system/target-arm.rst
+++ b/docs/system/target-arm.rst
@@ -87,6 +87,7 @@ undocumented; you can get a complete list by running
arm/digic
arm/musicpal
arm/gumstix
+   arm/nrf
arm/nseries
arm/nuvoton
arm/orangepi
-- 
2.25.1




Re: [PATCH] docs/system: arm: Add nRF boards description

2021-06-19 Thread Alexandre IOOSS

On 6/19/21 12:27 PM, Philippe Mathieu-Daudé wrote:

+Julia / Su / Steffen

On 6/19/21 11:57 AM, Alexandre Iooss wrote:

This adds the target guide for BBC Micro:bit.

Information is taken from https://wiki.qemu.org/Features/MicroBit
and from hw/arm/nrf51_soc.c.


Great idea :)



Signed-off-by: Alexandre Iooss 
---
  MAINTAINERS|  1 +
  docs/system/arm/nrf.rst| 49 ++
  docs/system/target-arm.rst |  1 +
  3 files changed, 51 insertions(+)
  create mode 100644 docs/system/arm/nrf.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 636bf2f536..7c54611cc2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1031,6 +1031,7 @@ F: hw/*/microbit*.c
  F: include/hw/*/nrf51*.h
  F: include/hw/*/microbit*.h
  F: tests/qtest/microbit-test.c
+F: docs/system/arm/nrf.rst
  
  AVR Machines

  -
diff --git a/docs/system/arm/nrf.rst b/docs/system/arm/nrf.rst
new file mode 100644
index 00..e30aba8b06
--- /dev/null
+++ b/docs/system/arm/nrf.rst
@@ -0,0 +1,49 @@
+Nordic nRF boards (``microbit``)
+
+
+The `Nordic nRF`_ chips are a family of ARM-based System-on-Chip that
+are designed to be used for low-power and short-range wireless solutions.
+
+.. _Nordic nRF: https://www.nordicsemi.com/Products
+
+The nRF51 series is the first series for short range wireless applications.
+It is superseded by the nRF51 series.


Just noticed a typo here, it's "superseded by the nRF52 series". I will 
fix this in next version of this patch.



+The following machines are based on this chip :
+
+- ``microbit``   BBC micro:bit board with nRF51822 SoC
+
+There are other series such as nRF52, nRF53 and nRF91 which are currently not
+supported by QEMU.
+
+Supported devices
+-
+
+ * ARM Cortex-M0 (ARMv6-M)
+ * Serial ports (UART)
+ * Clock controller
+ * Timers
+ * Random Number Generator (RNG)
+ * GPIO controller
+ * NVMC
+ * SWI
+
+Missing devices
+---
+
+ * Watchdog
+ * Real-Time Clock (RTC) controller
+ * TWI (i2c)
+ * SPI controller
+ * Analog to Digital Converter (ADC)
+ * Quadrature decoder
+ * Radio
+
+Boot options
+
+
+The Micro:bit machine can be started using the ``-device`` option to load a
+firmware in hexadecimal format. Example:


I'd use "ihex format" instead of "hexadecimal format", see

https://en.wikipedia.org/wiki/Intel_HEX

and also commit e4a25ed91947af1ec87f23725de4ac86a3353b48:

 loader: Implement .hex file loader

 This patch adds Intel Hexadecimal Object File format support to the
 generic loader device.  The file format specification is available
 here: http://www.piclist.com/techref/fileext/hex/intel.htm

 This file format is often used with microcontrollers such as the
 micro:bit, Arduino, STM32, etc.  Users expect to be able to run .hex
 files directly with without first converting them to ELF.  Most
 micro:bit code is developed in web-based IDEs without direct user
 access to binutils so it is important for QEMU to handle this file
 format natively.

Otherwise:
Reviewed-by: Philippe Mathieu-Daudé 



I was not aware of the name of the format. I will apply the change and 
add a link to the Wikipedia page of Intel HEX.



+
+.. code-block:: bash
+
+  $ qemu-system-arm -M microbit -device loader,file=test.hex
diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst
index edd013c7bb..5277ac0242 100644
--- a/docs/system/target-arm.rst
+++ b/docs/system/target-arm.rst
@@ -87,6 +87,7 @@ undocumented; you can get a complete list by running
 arm/digic
 arm/musicpal
 arm/gumstix
+   arm/nrf
 arm/nseries
 arm/nuvoton
 arm/orangepi





Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH] docs/system: arm: Add nRF boards description

2021-06-19 Thread Alexandre Iooss
This adds the target guide for BBC Micro:bit.

Information is taken from https://wiki.qemu.org/Features/MicroBit
and from hw/arm/nrf51_soc.c.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS|  1 +
 docs/system/arm/nrf.rst| 49 ++
 docs/system/target-arm.rst |  1 +
 3 files changed, 51 insertions(+)
 create mode 100644 docs/system/arm/nrf.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 636bf2f536..7c54611cc2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1031,6 +1031,7 @@ F: hw/*/microbit*.c
 F: include/hw/*/nrf51*.h
 F: include/hw/*/microbit*.h
 F: tests/qtest/microbit-test.c
+F: docs/system/arm/nrf.rst
 
 AVR Machines
 -
diff --git a/docs/system/arm/nrf.rst b/docs/system/arm/nrf.rst
new file mode 100644
index 00..e30aba8b06
--- /dev/null
+++ b/docs/system/arm/nrf.rst
@@ -0,0 +1,49 @@
+Nordic nRF boards (``microbit``)
+
+
+The `Nordic nRF`_ chips are a family of ARM-based System-on-Chip that
+are designed to be used for low-power and short-range wireless solutions.
+
+.. _Nordic nRF: https://www.nordicsemi.com/Products
+
+The nRF51 series is the first series for short range wireless applications.
+It is superseded by the nRF51 series.
+The following machines are based on this chip :
+
+- ``microbit``   BBC micro:bit board with nRF51822 SoC
+
+There are other series such as nRF52, nRF53 and nRF91 which are currently not
+supported by QEMU.
+
+Supported devices
+-
+
+ * ARM Cortex-M0 (ARMv6-M)
+ * Serial ports (UART)
+ * Clock controller
+ * Timers
+ * Random Number Generator (RNG)
+ * GPIO controller
+ * NVMC
+ * SWI
+
+Missing devices
+---
+
+ * Watchdog
+ * Real-Time Clock (RTC) controller
+ * TWI (i2c)
+ * SPI controller
+ * Analog to Digital Converter (ADC)
+ * Quadrature decoder
+ * Radio
+
+Boot options
+
+
+The Micro:bit machine can be started using the ``-device`` option to load a
+firmware in hexadecimal format. Example:
+
+.. code-block:: bash
+
+  $ qemu-system-arm -M microbit -device loader,file=test.hex
diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst
index edd013c7bb..5277ac0242 100644
--- a/docs/system/target-arm.rst
+++ b/docs/system/target-arm.rst
@@ -87,6 +87,7 @@ undocumented; you can get a complete list by running
arm/digic
arm/musicpal
arm/gumstix
+   arm/nrf
arm/nseries
arm/nuvoton
arm/orangepi
-- 
2.25.1




Re: [PATCH v2 0/2] execlog TCG plugin to log instructions

2021-06-18 Thread Alexandre IOOSS

Supersedes: <20210614090116.816833-1-erdn...@crans.org>

On 6/18/21 11:10 AM, Alexandre Iooss wrote:

execlog is a plugin that logs executed instructions with some useful
metadata including memory access.

The output of the plugin is designed to be usable with other tools. For
example it could be used with a side-channel leakage model to create
side-channel traces from QEMU for security evaluation.

Changes since v1:
  - The output is now easier to parse.
  - Use QEMU logging API rather than FILE* to write output.
  - Don't reject memory information in user mode.
  - Merge memory information with instruction execution. Now one line
means one instruction.
  - Add documentation.

Alexandre Iooss (2):
   contrib/plugins: add execlog to log instruction execution and memory
 access
   docs/devel: tvg-plugins: add execlog plugin description

  MAINTAINERS|   1 +
  contrib/plugins/Makefile   |   1 +
  contrib/plugins/execlog.c  | 123 +
  docs/devel/tcg-plugins.rst |  22 +++
  4 files changed, 147 insertions(+)
  create mode 100644 contrib/plugins/execlog.c



--
Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH v2 1/2] contrib/plugins: add execlog to log instruction execution and memory access

2021-06-18 Thread Alexandre Iooss
Log instruction execution and memory access to a file.
This plugin can be used for reverse engineering or for side-channel analysis
using QEMU.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS   |   1 +
 contrib/plugins/Makefile  |   1 +
 contrib/plugins/execlog.c | 123 ++
 3 files changed, 125 insertions(+)
 create mode 100644 contrib/plugins/execlog.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd29042..65942d5802 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2974,6 +2974,7 @@ F: include/tcg/
 
 TCG Plugins
 M: Alex Bennée 
+R: Alexandre Iooss 
 S: Maintained
 F: docs/devel/tcg-plugins.rst
 F: plugins/
diff --git a/contrib/plugins/Makefile b/contrib/plugins/Makefile
index b9d7935e5e..51093acd17 100644
--- a/contrib/plugins/Makefile
+++ b/contrib/plugins/Makefile
@@ -13,6 +13,7 @@ include $(BUILD_DIR)/config-host.mak
 VPATH += $(SRC_PATH)/contrib/plugins
 
 NAMES :=
+NAMES += execlog
 NAMES += hotblocks
 NAMES += hotpages
 NAMES += howvec
diff --git a/contrib/plugins/execlog.c b/contrib/plugins/execlog.c
new file mode 100644
index 00..995c4477f9
--- /dev/null
+++ b/contrib/plugins/execlog.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2021, Alexandre Iooss 
+ *
+ * Log instruction execution with memory access.
+ *
+ * License: GNU GPL, version 2 or later.
+ *   See the COPYING file in the top-level directory.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+/* Store last executed instruction on each vCPU */
+GString **last_exec;
+
+/**
+ * Add memory read or write information to current instruction log
+ */
+static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info,
+ uint64_t vaddr, void *udata)
+{
+if (qemu_plugin_mem_is_store(info)) {
+g_string_append(last_exec[cpu_index], ", store");
+} else {
+g_string_append(last_exec[cpu_index], ", load");
+}
+
+/* If full system emulation log physical address and device name */
+struct qemu_plugin_hwaddr *hwaddr = qemu_plugin_get_hwaddr(info, vaddr);
+if (hwaddr) {
+uint64_t addr = qemu_plugin_hwaddr_phys_addr(hwaddr);
+const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
+g_string_append_printf(last_exec[cpu_index], ", 0x%08"PRIx64", %s",
+   addr, name);
+} else {
+g_string_append_printf(last_exec[cpu_index], ", 0x%08"PRIx64, vaddr);
+}
+}
+
+/**
+ * Log instruction execution
+ */
+static void vcpu_insn_exec(unsigned int cpu_index, void *udata)
+{
+/* Print previous instruction in cache */
+if (last_exec[cpu_index]->str) {
+qemu_plugin_outs(last_exec[cpu_index]->str);
+qemu_plugin_outs("\n");
+}
+
+/* Store new instruction in cache */
+/* vcpu_mem will add memory access information to last_exec */
+g_string_printf(last_exec[cpu_index], "%u, ", cpu_index);
+g_string_append(last_exec[cpu_index], (char *)udata);
+}
+
+/**
+ * On translation block new translation
+ *
+ * QEMU convert code by translation block (TB). By hooking here we can then 
hook
+ * a callback on each instruction and memory access.
+ */
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+struct qemu_plugin_insn *insn;
+uint64_t insn_vaddr;
+uint32_t insn_opcode;
+char *insn_disas;
+
+size_t n = qemu_plugin_tb_n_insns(tb);
+for (size_t i = 0; i < n; i++) {
+/*
+ * `insn` is shared between translations in QEMU, copy needed data 
here.
+ * `output` is never freed as it might be used multiple times during
+ * the emulation lifetime.
+ * We only consider the first 32 bits of the instruction, this may be
+ * a limitation for CISC architectures.
+ */
+insn = qemu_plugin_tb_get_insn(tb, i);
+insn_vaddr = qemu_plugin_insn_vaddr(insn);
+insn_opcode = *((uint32_t *)qemu_plugin_insn_data(insn));
+insn_disas = qemu_plugin_insn_disas(insn);
+char *output = g_strdup_printf("0x%"PRIx64", 0x%"PRIx32", \"%s\"",
+   insn_vaddr, insn_opcode, insn_disas);
+
+/* Register callback on memory read or write */
+qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem,
+ QEMU_PLUGIN_CB_NO_REGS,
+ QEMU_PLUGIN_MEM_RW, NULL);
+
+/* Register callback on instruction */
+qemu_plugin_register_vcpu_insn_exec_cb(insn, vcpu_insn_exec,
+   QEMU_PLUGIN_CB_NO_REGS, output);
+}
+}
+
+/**
+ * Install the plugin
+ */
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+   const qe

[PATCH v2 2/2] docs/devel: tvg-plugins: add execlog plugin description

2021-06-18 Thread Alexandre Iooss
This adds description of the execlog TCG plugin with an example.

Signed-off-by: Alexandre Iooss 
---
 docs/devel/tcg-plugins.rst | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 18c6581d85..02818a3327 100644
--- a/docs/devel/tcg-plugins.rst
+++ b/docs/devel/tcg-plugins.rst
@@ -319,3 +319,25 @@ the user to see what hardware is accessed how often. It 
has a number of options:
   off:001c, 1, 2
   off:0020, 1, 2
   ...
+
+- contrib/plugins/execlog.c
+
+The execlog tool traces executed instructions with memory access. It can be 
used
+for debugging and security analysis purposes.
+The plugin takes no argument::
+
+  qemu-system-arm $(QEMU_ARGS) \
+-plugin ./contrib/plugins/libexeclog.so -d plugin
+
+which will output an execution trace following this structure::
+
+  # vCPU, vAddr, opcode, disassembly[, load/store, memory addr, device]...
+  0, 0xa12, 0xf8012400, "movs r4, #0"
+  0, 0xa14, 0xf87f42b4, "cmp r4, r6"
+  0, 0xa16, 0xd206, "bhs #0xa26"
+  0, 0xa18, 0xfff94803, "ldr r0, [pc, #0xc]", load, 0x00010a28, RAM
+  0, 0xa1a, 0xf989f000, "bl #0xd30"
+  0, 0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee0, RAM, store, 
0x20003ee4, RAM
+  0, 0xd32, 0xf9893014, "adds r0, #0x14"
+  0, 0xd34, 0xf9c8f000, "bl #0x10c8"
+  0, 0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x20e4, RAM
-- 
2.25.1




[PATCH v2 0/2] execlog TCG plugin to log instructions

2021-06-18 Thread Alexandre Iooss
execlog is a plugin that logs executed instructions with some useful
metadata including memory access.

The output of the plugin is designed to be usable with other tools. For
example it could be used with a side-channel leakage model to create
side-channel traces from QEMU for security evaluation.

Changes since v1:
 - The output is now easier to parse.
 - Use QEMU logging API rather than FILE* to write output.
 - Don't reject memory information in user mode.
 - Merge memory information with instruction execution. Now one line
   means one instruction.
 - Add documentation.

Alexandre Iooss (2):
  contrib/plugins: add execlog to log instruction execution and memory
access
  docs/devel: tvg-plugins: add execlog plugin description

 MAINTAINERS|   1 +
 contrib/plugins/Makefile   |   1 +
 contrib/plugins/execlog.c  | 123 +
 docs/devel/tcg-plugins.rst |  22 +++
 4 files changed, 147 insertions(+)
 create mode 100644 contrib/plugins/execlog.c

-- 
2.25.1




[PATCH v3 0/4] STM32VLDISCOVERY Machine Model

2021-06-17 Thread Alexandre Iooss
This patch series adds the STM32VLDISCOVERY Machine to QEMU

Information on the board is available at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

v3:
 - Add test for STM32VLDISCOVERY USART1

v2:
 - Add documentation of STM32 boards
 - Fixed number of interrupts
 - Fixed Cortex-M3 name

Alexandre Iooss (4):
  stm32f100: Add the stm32f100 SoC
  stm32vldiscovery: Add the STM32VLDISCOVERY Machine
  docs/system: arm: Add stm32 boards description
  tests/boot-serial-test: Add STM32VLDISCOVERY board testcase

 MAINTAINERS |  13 ++
 default-configs/devices/arm-softmmu.mak |   1 +
 docs/system/arm/stm32.rst   |  66 +
 docs/system/target-arm.rst  |   1 +
 hw/arm/Kconfig  |  10 ++
 hw/arm/meson.build  |   2 +
 hw/arm/stm32f100_soc.c  | 182 
 hw/arm/stm32vldiscovery.c   |  66 +
 include/hw/arm/stm32f100_soc.h  |  57 
 tests/qtest/boot-serial-test.c  |  37 +
 10 files changed, 435 insertions(+)
 create mode 100644 docs/system/arm/stm32.rst
 create mode 100644 hw/arm/stm32f100_soc.c
 create mode 100644 hw/arm/stm32vldiscovery.c
 create mode 100644 include/hw/arm/stm32f100_soc.h

-- 
2.25.1




[PATCH v3 3/4] docs/system: arm: Add stm32 boards description

2021-06-17 Thread Alexandre Iooss
This adds the target guide for Netduino 2, Netduino Plus 2 and STM32VLDISCOVERY.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS|  1 +
 docs/system/arm/stm32.rst  | 66 ++
 docs/system/target-arm.rst |  1 +
 3 files changed, 68 insertions(+)
 create mode 100644 docs/system/arm/stm32.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 0aa8016936..47fb06e5fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -896,6 +896,7 @@ M: Alexandre Iooss 
 L: qemu-...@nongnu.org
 S: Maintained
 F: hw/arm/stm32vldiscovery.c
+F: docs/system/arm/stm32.rst
 
 Versatile Express
 M: Peter Maydell 
diff --git a/docs/system/arm/stm32.rst b/docs/system/arm/stm32.rst
new file mode 100644
index 00..508b92cf86
--- /dev/null
+++ b/docs/system/arm/stm32.rst
@@ -0,0 +1,66 @@
+STMicroelectronics STM32 boards (``netduino2``, ``netduinoplus2``, 
``stm32vldiscovery``)
+
+
+The `STM32`_ chips are a family of 32-bit ARM-based microcontroller by
+STMicroelectronics.
+
+.. _STM32: 
https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html
+
+The STM32F1 series is based on ARM Cortex-M3 core. The following machines are
+based on this chip :
+
+- ``stm32vldiscovery``  STM32VLDISCOVERY board with STM32F100RBT6 
microcontroller
+
+The STM32F2 series is based on ARM Cortex-M3 core. The following machines are
+based on this chip :
+
+- ``netduino2`` Netduino 2 board with STM32F205RFT6 microcontroller
+
+The STM32F4 series is based on ARM Cortex-M4F core. This series is pin-to-pin
+compatible with STM32F2 series. The following machines are based on this chip :
+
+- ``netduinoplus2`` Netduino Plus 2 board with STM32F405RGT6 
microcontroller
+
+There are many other STM32 series that are currently not supported by QEMU.
+
+Supported devices
+-
+
+ * ARM Cortex-M3, Cortex M4F
+ * Analog to Digital Converter (ADC)
+ * EXTI interrupt
+ * Serial ports (USART)
+ * SPI controller
+ * System configuration (SYSCFG)
+ * Timer controller (TIMER)
+
+Missing devices
+---
+
+ * Camera interface (DCMI)
+ * Controller Area Network (CAN)
+ * Cycle Redundancy Check (CRC) calculation unit
+ * Digital to Analog Converter (DAC)
+ * DMA controller
+ * Ethernet controller
+ * Flash Interface Unit
+ * GPIO controller
+ * I2C controller
+ * Inter-Integrated Sound (I2S) controller
+ * Power supply configuration (PWR)
+ * Random Number Generator (RNG)
+ * Real-Time Clock (RTC) controller
+ * Reset and Clock Controller (RCC)
+ * Secure Digital Input/Output (SDIO) interface
+ * USB OTG
+ * Watchdog controller (IWDG, WWDG)
+
+Boot options
+
+
+The STM32 machines can be started using the ``-kernel`` option to load a
+firmware. Example:
+
+.. code-block:: bash
+
+  $ qemu-system-arm -M stm32vldiscovery -kernel firmware.bin
diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst
index edd013c7bb..addd3d1613 100644
--- a/docs/system/target-arm.rst
+++ b/docs/system/target-arm.rst
@@ -96,6 +96,7 @@ undocumented; you can get a complete list by running
arm/collie
arm/sx1
arm/stellaris
+   arm/stm32
arm/virt
arm/xlnx-versal-virt
 
-- 
2.25.1




[PATCH v3 1/4] stm32f100: Add the stm32f100 SoC

2021-06-17 Thread Alexandre Iooss
This SoC is similar to stm32f205 SoC.
This will be used by the STM32VLDISCOVERY to create a machine.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS|   6 ++
 hw/arm/Kconfig |   6 ++
 hw/arm/meson.build |   1 +
 hw/arm/stm32f100_soc.c | 182 +
 include/hw/arm/stm32f100_soc.h |  57 +++
 5 files changed, 252 insertions(+)
 create mode 100644 hw/arm/stm32f100_soc.c
 create mode 100644 include/hw/arm/stm32f100_soc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd29042..62dfa31800 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -946,6 +946,12 @@ L: qemu-...@nongnu.org
 S: Maintained
 F: hw/arm/virt-acpi-build.c
 
+STM32F100
+M: Alexandre Iooss 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/arm/stm32f100_soc.c
+
 STM32F205
 M: Alistair Francis 
 M: Peter Maydell 
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 67723d9ea6..0bc3ee3e91 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -326,6 +326,12 @@ config RASPI
 select SDHCI
 select USB_DWC2
 
+config STM32F100_SOC
+bool
+select ARM_V7M
+select STM32F2XX_USART
+select STM32F2XX_SPI
+
 config STM32F205_SOC
 bool
 select ARM_V7M
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index be39117b9b..0e637e6a9e 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -39,6 +39,7 @@ arm_ss.add(when: 'CONFIG_STRONGARM', if_true: 
files('strongarm.c'))
 arm_ss.add(when: 'CONFIG_ALLWINNER_A10', if_true: files('allwinner-a10.c', 
'cubieboard.c'))
 arm_ss.add(when: 'CONFIG_ALLWINNER_H3', if_true: files('allwinner-h3.c', 
'orangepi.c'))
 arm_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_peripherals.c', 
'bcm2836.c', 'raspi.c'))
+arm_ss.add(when: 'CONFIG_STM32F100_SOC', if_true: files('stm32f100_soc.c'))
 arm_ss.add(when: 'CONFIG_STM32F205_SOC', if_true: files('stm32f205_soc.c'))
 arm_ss.add(when: 'CONFIG_STM32F405_SOC', if_true: files('stm32f405_soc.c'))
 arm_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx-zynqmp.c', 
'xlnx-zcu102.c'))
diff --git a/hw/arm/stm32f100_soc.c b/hw/arm/stm32f100_soc.c
new file mode 100644
index 00..0c4a5c6645
--- /dev/null
+++ b/hw/arm/stm32f100_soc.c
@@ -0,0 +1,182 @@
+/*
+ * STM32F100 SoC
+ *
+ * Copyright (c) 2021 Alexandre Iooss 
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/module.h"
+#include "hw/arm/boot.h"
+#include "exec/address-spaces.h"
+#include "hw/arm/stm32f100_soc.h"
+#include "hw/qdev-properties.h"
+#include "hw/misc/unimp.h"
+#include "sysemu/sysemu.h"
+
+/* stm32f100_soc implementation is derived from stm32f205_soc */
+
+static const uint32_t usart_addr[STM_NUM_USARTS] = { 0x40013800, 0x40004400,
+0x40004800 };
+static const uint32_t spi_addr[STM_NUM_SPIS] = { 0x40013000, 0x40003800 };
+
+static const int usart_irq[STM_NUM_USARTS] = {37, 38, 39};
+static const int spi_irq[STM_NUM_SPIS] = {35, 36};
+
+static void stm32f100_soc_initfn(Object *obj)
+{
+STM32F100State *s = STM32F100_SOC(obj);
+int i;
+
+object_initialize_child(obj, "armv7m", >armv7m, TYPE_ARMV7M);
+
+for (i = 0; i < STM_NUM_USARTS; i++) {
+object_initialize_child(obj, "usart[*]", >usart[i],
+TYPE_STM32F2XX_USART);
+}
+
+for (i = 0; i < STM_NUM_SPIS; i++) {
+object_initialize_child(obj, "spi[*]", >spi[i], TYPE_STM32F2XX_SPI);
+}
+}
+
+static void stm32f100_soc_realize(DeviceState *dev_soc, Error **errp)
+{
+STM32F100State *s = STM32F100_SOC(dev_soc);
+DeviceState *dev, *armv7m;
+SysBusDevice *busdev;
+int i;
+
+MemoryRegion *system_memory = get_system_memory();
+MemoryRegion *sram = g_new(Memory

[PATCH v3 4/4] tests/boot-serial-test: Add STM32VLDISCOVERY board testcase

2021-06-17 Thread Alexandre Iooss
New mini-kernel test for STM32VLDISCOVERY USART1.

Signed-off-by: Alexandre Iooss 
---
 tests/qtest/boot-serial-test.c | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/tests/qtest/boot-serial-test.c b/tests/qtest/boot-serial-test.c
index d40adddafa..96849cec91 100644
--- a/tests/qtest/boot-serial-test.c
+++ b/tests/qtest/boot-serial-test.c
@@ -94,6 +94,41 @@ static const uint8_t kernel_nrf51[] = {
 0x1c, 0x25, 0x00, 0x40  /* 0x4000251c = UART TXD */
 };
 
+static const uint8_t kernel_stm32vldiscovery[] = {
+0x00, 0x00, 0x00, 0x00, /* Stack top address */
+0x1d, 0x00, 0x00, 0x00, /* Reset handler address */
+0x00, 0x00, 0x00, 0x00, /* NMI */
+0x00, 0x00, 0x00, 0x00, /* Hard fault */
+0x00, 0x00, 0x00, 0x00, /* Memory management fault */
+0x00, 0x00, 0x00, 0x00, /* Bus fault */
+0x00, 0x00, 0x00, 0x00, /* Usage fault */
+0x0b, 0x4b, /* ldr  r3, [pc, #44] Get RCC */
+0x44, 0xf2, 0x04, 0x02, /* movw r2, #16388 */
+0x1a, 0x60, /* str  r2, [r3] */
+0x0a, 0x4b, /* ldr  r3, [pc, #40] Get GPIOA */
+0x1a, 0x68, /* ldr  r2, [r3] */
+0x22, 0xf0, 0xf0, 0x02, /* bic  r2, r2, #240 */
+0x1a, 0x60, /* str  r2, [r3] */
+0x1a, 0x68, /* ldr  r2, [r3] */
+0x42, 0xf0, 0xb0, 0x02, /* orr  r2, r2, #176 */
+0x1a, 0x60, /* str  r2, [r3] */
+0x07, 0x4b, /* ldr  r3, [pc, #26] Get BAUD */
+0x45, 0x22, /* movs r2, #69 */
+0x1a, 0x60, /* str  r2, [r3] */
+0x06, 0x4b, /* ldr  r3, [pc, #24] Get ENABLE */
+0x42, 0xf2, 0x08, 0x02, /* movw r2, #8200 */
+0x1a, 0x60, /* str  r2, [r3] */
+0x05, 0x4b, /* ldr  r3, [pc, #20] Get TXD */
+0x54, 0x22, /* movs r2, 'T' */
+0x1a, 0x60, /* str  r2, [r3] */
+0xfe, 0xe7, /* b. */
+0x18, 0x10, 0x02, 0x40, /* 0x40021018 = RCC */
+0x04, 0x08, 0x01, 0x40, /* 0x40010804 = GPIOA */
+0x08, 0x38, 0x01, 0x40, /* 0x40013808 = USART1 BAUD */
+0x0c, 0x38, 0x01, 0x40, /* 0x4001380c = USART1 ENABLE */
+0x04, 0x38, 0x01, 0x40  /* 0x40013804 = USART1 TXD */
+};
+
 typedef struct testdef {
 const char *arch;   /* Target architecture */
 const char *machine;/* Name of the machine */
@@ -144,6 +179,8 @@ static testdef_t tests[] = {
 { "aarch64", "virt", "-cpu max", "TT", sizeof(kernel_aarch64),
   kernel_aarch64 },
 { "arm", "microbit", "", "T", sizeof(kernel_nrf51), kernel_nrf51 },
+{ "arm", "stm32vldiscovery", "", "T",
+  sizeof(kernel_stm32vldiscovery), kernel_stm32vldiscovery },
 
 { NULL }
 };
-- 
2.25.1




[PATCH v3 2/4] stm32vldiscovery: Add the STM32VLDISCOVERY Machine

2021-06-17 Thread Alexandre Iooss
This is a Cortex-M3 based machine. Information can be found at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS |  6 +++
 default-configs/devices/arm-softmmu.mak |  1 +
 hw/arm/Kconfig  |  4 ++
 hw/arm/meson.build  |  1 +
 hw/arm/stm32vldiscovery.c   | 66 +
 5 files changed, 78 insertions(+)
 create mode 100644 hw/arm/stm32vldiscovery.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 62dfa31800..0aa8016936 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -891,6 +891,12 @@ F: hw/*/stellaris*
 F: include/hw/input/gamepad.h
 F: docs/system/arm/stellaris.rst
 
+STM32VLDISCOVERY
+M: Alexandre Iooss 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/arm/stm32vldiscovery.c
+
 Versatile Express
 M: Peter Maydell 
 L: qemu-...@nongnu.org
diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 0500156a0c..cdc0e97f9d 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -18,6 +18,7 @@ CONFIG_CHEETAH=y
 CONFIG_SX1=y
 CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
+CONFIG_STM32VLDISCOVERY=y
 CONFIG_REALVIEW=y
 CONFIG_VERSATILE=y
 CONFIG_VEXPRESS=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 0bc3ee3e91..dc4e47b721 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -239,6 +239,10 @@ config STELLARIS
 select STELLARIS_ENET # ethernet
 select UNIMP
 
+config STM32VLDISCOVERY
+bool
+select STM32F100_SOC
+
 config STRONGARM
 bool
 select PXA2XX
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 0e637e6a9e..721a8eb8be 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -24,6 +24,7 @@ arm_ss.add(when: 'CONFIG_Z2', if_true: files('z2.c'))
 arm_ss.add(when: 'CONFIG_REALVIEW', if_true: files('realview.c'))
 arm_ss.add(when: 'CONFIG_SBSA_REF', if_true: files('sbsa-ref.c'))
 arm_ss.add(when: 'CONFIG_STELLARIS', if_true: files('stellaris.c'))
+arm_ss.add(when: 'CONFIG_STM32VLDISCOVERY', if_true: 
files('stm32vldiscovery.c'))
 arm_ss.add(when: 'CONFIG_COLLIE', if_true: files('collie.c'))
 arm_ss.add(when: 'CONFIG_VERSATILE', if_true: files('versatilepb.c'))
 arm_ss.add(when: 'CONFIG_VEXPRESS', if_true: files('vexpress.c'))
diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c
new file mode 100644
index 00..7e8191ebf5
--- /dev/null
+++ b/hw/arm/stm32vldiscovery.c
@@ -0,0 +1,66 @@
+/*
+ * ST STM32VLDISCOVERY machine
+ *
+ * Copyright (c) 2021 Alexandre Iooss 
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/qdev-properties.h"
+#include "qemu/error-report.h"
+#include "hw/arm/stm32f100_soc.h"
+#include "hw/arm/boot.h"
+
+/* stm32vldiscovery implementation is derived from netduinoplus2 */
+
+/* Main SYSCLK frequency in Hz (24MHz) */
+#define SYSCLK_FRQ 2400ULL
+
+static void stm32vldiscovery_init(MachineState *machine)
+{
+DeviceState *dev;
+
+/*
+ * TODO: ideally we would model the SoC RCC and let it handle
+ * system_clock_scale, including its ability to define different
+ * possible SYSCLK sources.
+ */
+system_clock_scale = NANOSECONDS_PER_SECOND / SYSCLK_FRQ;
+
+dev = qdev_new(TYPE_STM32F100_SOC);
+qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+
+armv7m_load_kernel(ARM_CPU(first_cpu),
+   machine->kernel_filename,
+   FLASH_SIZE);
+}
+
+static void stm32vldiscovery_machine_init(MachineClass *mc)
+{
+mc->desc = "ST STM32VLDISCOVERY (Cortex-M3)";
+mc->init = stm32vldiscovery_init;
+}
+
+DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init)
+
-- 
2.25.1




Re: [PATCH] contrib/plugins: add execlog to log instruction execution and memory access

2021-06-16 Thread Alexandre IOOSS

On 6/15/21 6:47 PM, Alexandre IOOSS wrote:

On 6/15/21 10:22 AM, Alex Bennée wrote:

Mahmoud Mandour  writes:

On 14/06/2021 11:01, Alexandre Iooss wrote:

+}
+
+/**
+ * Log instruction execution
+ */
+static void vcpu_insn_exec(unsigned int cpu_index, void *udata)
+{
+    char *insn_disas = (char *)udata;
+
+    /* Add data to execution log */
+    fprintf(output, "insn: %s\n", insn_disas);


   insn, 0x%08lx, disas

Currently however on a multi-threaded execution you will potentially
loose any synchronisation between the insn_exec and any memory operation
associated with it. If you really just care about what's tickling
hardware you could just drop the insn_exec callback and pass the
instruction information via udata to the vcpu_mem callback. You could
then dump everything in one line:

   0xPC, ld [x1], x2, 0xADDR, load|store

you wouldn't dump other instructions leading up to that though.


You are correct, this is indeed an issue and it's currently making my 
life really hard when I try to apply a side-channel model on the memory 
interactions.
I prefer to log all instructions, so I need to use vcpu_mem_cb when it's 
a memory instruction, or vcpu_insn_exec_cb if it's not.


If I always set vcpu_mem_cb and vcpu_insn_exec_cb, then an user can do a 
bit of postprocessing of the data to merge lines that correspond to 
memory interactions. Example of output (Cortex-M0 in Thumb mode):


```
# vaddr, opcode, disassembly, [load/store, memory addr, device]
0xa14, 0xf87f42b4, "cmp r4, r6"
0xa16, 0xd206, "bhs #0xa26"
0xa18, 0xfff94803, "ldr r0, [pc, #0xc]"
0xa18, 0xfff94803, "ldr r0, [pc, #0xc]", load, 0x00010a28, RAM
0xa1a, 0xf989f000, "bl #0xd30"
0xd30, 0xfff9b510, "push {r4, lr}"
0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee0, RAM
0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee4, RAM
0xd32, 0xf9893014, "adds r0, #0x14"
0xd34, 0xf9c8f000, "bl #0x10c8"
0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]"
0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x20e4, RAM
```

If we don't want to call `vcpu_insn_exec_cb` when `vcpu_mem_cb` is 
triggered, then I would have either to:


1. Implement load/store instructions matchers, similar to what is done 
in `howvec.c` plugin.
2. Implement instructions mnemonic matchers (using the output of 
qemu_plugin_insn_disas).

3. Use Capstone and disassemble a second time each instructions.

What is your opinion on these solutions? Maybe for a first version we 
can keep it simple?


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] contrib/plugins: add execlog to log instruction execution and memory access

2021-06-15 Thread Alexandre IOOSS

On 6/15/21 10:22 AM, Alex Bennée wrote:

Mahmoud Mandour  writes:


On 14/06/2021 11:01, Alexandre Iooss wrote:

Log instruction execution and memory access to a file.
This plugin can be used for reverse engineering or for side-channel analysis
using QEMU.

Signed-off-by: Alexandre Iooss 
---
   MAINTAINERS   |   1 +
   contrib/plugins/Makefile  |   1 +
   contrib/plugins/execlog.c | 112 ++
   3 files changed, 114 insertions(+)
   create mode 100644 contrib/plugins/execlog.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd29042..65942d5802 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2974,6 +2974,7 @@ F: include/tcg/
 TCG Plugins
   M: Alex Bennée 
+R: Alexandre Iooss 
   S: Maintained
   F: docs/devel/tcg-plugins.rst
   F: plugins/
diff --git a/contrib/plugins/Makefile b/contrib/plugins/Makefile
index b9d7935e5e..51093acd17 100644
--- a/contrib/plugins/Makefile
+++ b/contrib/plugins/Makefile
@@ -13,6 +13,7 @@ include $(BUILD_DIR)/config-host.mak
   VPATH += $(SRC_PATH)/contrib/plugins
 NAMES :=
+NAMES += execlog
   NAMES += hotblocks
   NAMES += hotpages
   NAMES += howvec
diff --git a/contrib/plugins/execlog.c b/contrib/plugins/execlog.c
new file mode 100644
index 00..80716e8eed
--- /dev/null
+++ b/contrib/plugins/execlog.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2021, Alexandre Iooss 
+ *
+ * Log instruction execution and memory access to a file.
+ * You may pass the output filename as argument.
+ *
+ * License: GNU GPL, version 2 or later.
+ *   See the COPYING file in the top-level directory.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+/* Execution trace buffer */
+FILE *output;


Is there a reason for using a regular FILE * instead of using
`qemu_plugin_outs()`?

I don't see a benefit and since there's an API for logging I guess
it's better to use it instead


I would prefer using qemu_plugin_outs unless there is a reason to have
multiple streams.


I was not aware of `-D` option in QEMU that does exactly what I need. So 
I am going to use qemu_plugin_outs for next version of this patch.



+
+/**
+ * Log memory read or write
+ */
+static void vcpu_mem(unsigned int vcpu_index, qemu_plugin_meminfo_t info,
+ uint64_t vaddr, void *udata)
+{
+struct qemu_plugin_hwaddr *hwaddr = qemu_plugin_get_hwaddr(info, vaddr);
+if (!hwaddr) {
+return;
+}


So you just reject all memory accesses in user mode? I think that it
equally useful

to log only the virtual address of a memory access in user-mode
emulation? However, we better

wait for Alex's opinion on all this since he had remarks about
introducing a new ad-hoc

tracing format...


It would be nice to integrate with the QEMU tracing support but
following Stefan's comments I think it will be fairly involved to work
out a way to do it. In the meantime using plain text logging will have
to do.


I will change this to log the vaddr in user mode without device name.


+
+/* Add data to execution log */
+const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
+uint64_t addr = qemu_plugin_hwaddr_phys_addr(hwaddr);
+if (qemu_plugin_mem_is_store(info)) {
+fprintf(output, "mem: %s store at 0x%08lx\n", name, addr);
+} else {
+fprintf(output, "mem: %s load at 0x%08lx\n", name, addr);
+}


I would consider a comma separated output to make the file easily
digestible by other tools. Maybe:

   memory, 0x%08lx, load|store



Agree, I will change this.


+}
+
+/**
+ * Log instruction execution
+ */
+static void vcpu_insn_exec(unsigned int cpu_index, void *udata)
+{
+char *insn_disas = (char *)udata;
+
+/* Add data to execution log */
+fprintf(output, "insn: %s\n", insn_disas);


   insn, 0x%08lx, disas

Currently however on a multi-threaded execution you will potentially
loose any synchronisation between the insn_exec and any memory operation
associated with it. If you really just care about what's tickling
hardware you could just drop the insn_exec callback and pass the
instruction information via udata to the vcpu_mem callback. You could
then dump everything in one line:

   0xPC, ld [x1], x2, 0xADDR, load|store

you wouldn't dump other instructions leading up to that though.


You are correct, this is indeed an issue and it's currently making my 
life really hard when I try to apply a side-channel model on the memory 
interactions.
I prefer to log all instructions, so I need to use vcpu_mem_cb when it's 
a memory instruction, or vcpu_insn_exec_cb if it's not.



+}
+
+/**
+ * On translation block new translation
+ *
+ * QEMU convert code by translation block (TB). By hooking here we can then 
hook
+ * a callback on each instruction and memory access.
+ */
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+size_t n = qemu_plugin_tb_n_ins

[PATCH v2 2/3] stm32vldiscovery: Add the STM32VLDISCOVERY Machine

2021-06-15 Thread Alexandre Iooss
This is a Cortex-M3 based machine. Information can be found at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS |  6 +++
 default-configs/devices/arm-softmmu.mak |  1 +
 hw/arm/Kconfig  |  4 ++
 hw/arm/meson.build  |  1 +
 hw/arm/stm32vldiscovery.c   | 66 +
 5 files changed, 78 insertions(+)
 create mode 100644 hw/arm/stm32vldiscovery.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 62dfa31800..0aa8016936 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -891,6 +891,12 @@ F: hw/*/stellaris*
 F: include/hw/input/gamepad.h
 F: docs/system/arm/stellaris.rst
 
+STM32VLDISCOVERY
+M: Alexandre Iooss 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/arm/stm32vldiscovery.c
+
 Versatile Express
 M: Peter Maydell 
 L: qemu-...@nongnu.org
diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 0500156a0c..cdc0e97f9d 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -18,6 +18,7 @@ CONFIG_CHEETAH=y
 CONFIG_SX1=y
 CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
+CONFIG_STM32VLDISCOVERY=y
 CONFIG_REALVIEW=y
 CONFIG_VERSATILE=y
 CONFIG_VEXPRESS=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 0bc3ee3e91..dc4e47b721 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -239,6 +239,10 @@ config STELLARIS
 select STELLARIS_ENET # ethernet
 select UNIMP
 
+config STM32VLDISCOVERY
+bool
+select STM32F100_SOC
+
 config STRONGARM
 bool
 select PXA2XX
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 0e637e6a9e..721a8eb8be 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -24,6 +24,7 @@ arm_ss.add(when: 'CONFIG_Z2', if_true: files('z2.c'))
 arm_ss.add(when: 'CONFIG_REALVIEW', if_true: files('realview.c'))
 arm_ss.add(when: 'CONFIG_SBSA_REF', if_true: files('sbsa-ref.c'))
 arm_ss.add(when: 'CONFIG_STELLARIS', if_true: files('stellaris.c'))
+arm_ss.add(when: 'CONFIG_STM32VLDISCOVERY', if_true: 
files('stm32vldiscovery.c'))
 arm_ss.add(when: 'CONFIG_COLLIE', if_true: files('collie.c'))
 arm_ss.add(when: 'CONFIG_VERSATILE', if_true: files('versatilepb.c'))
 arm_ss.add(when: 'CONFIG_VEXPRESS', if_true: files('vexpress.c'))
diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c
new file mode 100644
index 00..7e8191ebf5
--- /dev/null
+++ b/hw/arm/stm32vldiscovery.c
@@ -0,0 +1,66 @@
+/*
+ * ST STM32VLDISCOVERY machine
+ *
+ * Copyright (c) 2021 Alexandre Iooss 
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/qdev-properties.h"
+#include "qemu/error-report.h"
+#include "hw/arm/stm32f100_soc.h"
+#include "hw/arm/boot.h"
+
+/* stm32vldiscovery implementation is derived from netduinoplus2 */
+
+/* Main SYSCLK frequency in Hz (24MHz) */
+#define SYSCLK_FRQ 2400ULL
+
+static void stm32vldiscovery_init(MachineState *machine)
+{
+DeviceState *dev;
+
+/*
+ * TODO: ideally we would model the SoC RCC and let it handle
+ * system_clock_scale, including its ability to define different
+ * possible SYSCLK sources.
+ */
+system_clock_scale = NANOSECONDS_PER_SECOND / SYSCLK_FRQ;
+
+dev = qdev_new(TYPE_STM32F100_SOC);
+qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+
+armv7m_load_kernel(ARM_CPU(first_cpu),
+   machine->kernel_filename,
+   FLASH_SIZE);
+}
+
+static void stm32vldiscovery_machine_init(MachineClass *mc)
+{
+mc->desc = "ST STM32VLDISCOVERY (Cortex-M3)";
+mc->init = stm32vldiscovery_init;
+}
+
+DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init)
+
-- 
2.25.1




[PATCH v2 1/3] stm32f100: Add the stm32f100 SoC

2021-06-15 Thread Alexandre Iooss
This SoC is similar to stm32f205 SoC.
This will be used by the STM32VLDISCOVERY to create a machine.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS|   6 ++
 hw/arm/Kconfig |   6 ++
 hw/arm/meson.build |   1 +
 hw/arm/stm32f100_soc.c | 182 +
 include/hw/arm/stm32f100_soc.h |  57 +++
 5 files changed, 252 insertions(+)
 create mode 100644 hw/arm/stm32f100_soc.c
 create mode 100644 include/hw/arm/stm32f100_soc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd29042..62dfa31800 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -946,6 +946,12 @@ L: qemu-...@nongnu.org
 S: Maintained
 F: hw/arm/virt-acpi-build.c
 
+STM32F100
+M: Alexandre Iooss 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/arm/stm32f100_soc.c
+
 STM32F205
 M: Alistair Francis 
 M: Peter Maydell 
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 67723d9ea6..0bc3ee3e91 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -326,6 +326,12 @@ config RASPI
 select SDHCI
 select USB_DWC2
 
+config STM32F100_SOC
+bool
+select ARM_V7M
+select STM32F2XX_USART
+select STM32F2XX_SPI
+
 config STM32F205_SOC
 bool
 select ARM_V7M
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index be39117b9b..0e637e6a9e 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -39,6 +39,7 @@ arm_ss.add(when: 'CONFIG_STRONGARM', if_true: 
files('strongarm.c'))
 arm_ss.add(when: 'CONFIG_ALLWINNER_A10', if_true: files('allwinner-a10.c', 
'cubieboard.c'))
 arm_ss.add(when: 'CONFIG_ALLWINNER_H3', if_true: files('allwinner-h3.c', 
'orangepi.c'))
 arm_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_peripherals.c', 
'bcm2836.c', 'raspi.c'))
+arm_ss.add(when: 'CONFIG_STM32F100_SOC', if_true: files('stm32f100_soc.c'))
 arm_ss.add(when: 'CONFIG_STM32F205_SOC', if_true: files('stm32f205_soc.c'))
 arm_ss.add(when: 'CONFIG_STM32F405_SOC', if_true: files('stm32f405_soc.c'))
 arm_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx-zynqmp.c', 
'xlnx-zcu102.c'))
diff --git a/hw/arm/stm32f100_soc.c b/hw/arm/stm32f100_soc.c
new file mode 100644
index 00..0c4a5c6645
--- /dev/null
+++ b/hw/arm/stm32f100_soc.c
@@ -0,0 +1,182 @@
+/*
+ * STM32F100 SoC
+ *
+ * Copyright (c) 2021 Alexandre Iooss 
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/module.h"
+#include "hw/arm/boot.h"
+#include "exec/address-spaces.h"
+#include "hw/arm/stm32f100_soc.h"
+#include "hw/qdev-properties.h"
+#include "hw/misc/unimp.h"
+#include "sysemu/sysemu.h"
+
+/* stm32f100_soc implementation is derived from stm32f205_soc */
+
+static const uint32_t usart_addr[STM_NUM_USARTS] = { 0x40013800, 0x40004400,
+0x40004800 };
+static const uint32_t spi_addr[STM_NUM_SPIS] = { 0x40013000, 0x40003800 };
+
+static const int usart_irq[STM_NUM_USARTS] = {37, 38, 39};
+static const int spi_irq[STM_NUM_SPIS] = {35, 36};
+
+static void stm32f100_soc_initfn(Object *obj)
+{
+STM32F100State *s = STM32F100_SOC(obj);
+int i;
+
+object_initialize_child(obj, "armv7m", >armv7m, TYPE_ARMV7M);
+
+for (i = 0; i < STM_NUM_USARTS; i++) {
+object_initialize_child(obj, "usart[*]", >usart[i],
+TYPE_STM32F2XX_USART);
+}
+
+for (i = 0; i < STM_NUM_SPIS; i++) {
+object_initialize_child(obj, "spi[*]", >spi[i], TYPE_STM32F2XX_SPI);
+}
+}
+
+static void stm32f100_soc_realize(DeviceState *dev_soc, Error **errp)
+{
+STM32F100State *s = STM32F100_SOC(dev_soc);
+DeviceState *dev, *armv7m;
+SysBusDevice *busdev;
+int i;
+
+MemoryRegion *system_memory = get_system_memory();
+MemoryRegion *sram = g_new(Memory

[PATCH v2 3/3] docs/system: arm: Add stm32 boards description

2021-06-15 Thread Alexandre Iooss
This adds the target guide for Netduino 2, Netduino Plus 2 and STM32VLDISCOVERY.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS|  1 +
 docs/system/arm/stm32.rst  | 66 ++
 docs/system/target-arm.rst |  1 +
 3 files changed, 68 insertions(+)
 create mode 100644 docs/system/arm/stm32.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 0aa8016936..47fb06e5fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -896,6 +896,7 @@ M: Alexandre Iooss 
 L: qemu-...@nongnu.org
 S: Maintained
 F: hw/arm/stm32vldiscovery.c
+F: docs/system/arm/stm32.rst
 
 Versatile Express
 M: Peter Maydell 
diff --git a/docs/system/arm/stm32.rst b/docs/system/arm/stm32.rst
new file mode 100644
index 00..508b92cf86
--- /dev/null
+++ b/docs/system/arm/stm32.rst
@@ -0,0 +1,66 @@
+STMicroelectronics STM32 boards (``netduino2``, ``netduinoplus2``, 
``stm32vldiscovery``)
+
+
+The `STM32`_ chips are a family of 32-bit ARM-based microcontroller by
+STMicroelectronics.
+
+.. _STM32: 
https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html
+
+The STM32F1 series is based on ARM Cortex-M3 core. The following machines are
+based on this chip :
+
+- ``stm32vldiscovery``  STM32VLDISCOVERY board with STM32F100RBT6 
microcontroller
+
+The STM32F2 series is based on ARM Cortex-M3 core. The following machines are
+based on this chip :
+
+- ``netduino2`` Netduino 2 board with STM32F205RFT6 microcontroller
+
+The STM32F4 series is based on ARM Cortex-M4F core. This series is pin-to-pin
+compatible with STM32F2 series. The following machines are based on this chip :
+
+- ``netduinoplus2`` Netduino Plus 2 board with STM32F405RGT6 
microcontroller
+
+There are many other STM32 series that are currently not supported by QEMU.
+
+Supported devices
+-
+
+ * ARM Cortex-M3, Cortex M4F
+ * Analog to Digital Converter (ADC)
+ * EXTI interrupt
+ * Serial ports (USART)
+ * SPI controller
+ * System configuration (SYSCFG)
+ * Timer controller (TIMER)
+
+Missing devices
+---
+
+ * Camera interface (DCMI)
+ * Controller Area Network (CAN)
+ * Cycle Redundancy Check (CRC) calculation unit
+ * Digital to Analog Converter (DAC)
+ * DMA controller
+ * Ethernet controller
+ * Flash Interface Unit
+ * GPIO controller
+ * I2C controller
+ * Inter-Integrated Sound (I2S) controller
+ * Power supply configuration (PWR)
+ * Random Number Generator (RNG)
+ * Real-Time Clock (RTC) controller
+ * Reset and Clock Controller (RCC)
+ * Secure Digital Input/Output (SDIO) interface
+ * USB OTG
+ * Watchdog controller (IWDG, WWDG)
+
+Boot options
+
+
+The STM32 machines can be started using the ``-kernel`` option to load a
+firmware. Example:
+
+.. code-block:: bash
+
+  $ qemu-system-arm -M stm32vldiscovery -kernel firmware.bin
diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst
index edd013c7bb..addd3d1613 100644
--- a/docs/system/target-arm.rst
+++ b/docs/system/target-arm.rst
@@ -96,6 +96,7 @@ undocumented; you can get a complete list by running
arm/collie
arm/sx1
arm/stellaris
+   arm/stm32
arm/virt
arm/xlnx-versal-virt
 
-- 
2.25.1




[PATCH v2 0/3] STM32VLDISCOVERY Machine Model

2021-06-15 Thread Alexandre Iooss
This patch series adds the STM32VLDISCOVERY Machine to QEMU

Information on the board is available at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

Alexandre Iooss (3):
  stm32f100: Add the stm32f100 SoC
  stm32vldiscovery: Add the STM32VLDISCOVERY Machine
  docs/system: arm: Add stm32 boards description

 MAINTAINERS |  13 ++
 default-configs/devices/arm-softmmu.mak |   1 +
 docs/system/arm/stm32.rst   |  66 +
 docs/system/target-arm.rst  |   1 +
 hw/arm/Kconfig  |  10 ++
 hw/arm/meson.build  |   2 +
 hw/arm/stm32f100_soc.c  | 182 
 hw/arm/stm32vldiscovery.c   |  66 +
 include/hw/arm/stm32f100_soc.h  |  57 
 9 files changed, 398 insertions(+)
 create mode 100644 docs/system/arm/stm32.rst
 create mode 100644 hw/arm/stm32f100_soc.c
 create mode 100644 hw/arm/stm32vldiscovery.c
 create mode 100644 include/hw/arm/stm32f100_soc.h

-- 
2.25.1




Re: [PATCH 1/2] stm32f100: Add the stm32f100 SoC

2021-06-15 Thread Alexandre IOOSS



On 6/15/21 10:04 AM, Alistair Francis wrote:

On Tue, Jun 15, 2021 at 5:50 PM Alexandre IOOSS  wrote:


On 6/15/21 9:41 AM, Alistair Francis wrote:

Aren't you missing some timers, like timer[5] 0x4000_0C00?

Alistair


I double-checked using the reference manual and the datasheet and there
is not timer[5]:
- page 36 of
https://www.st.com/resource/en/reference_manual/cd00246267-stm32f100xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf


Strange, https://www.st.com/resource/en/datasheet/stm32f100rc.pdf
describes Timer 5 and page 282 of the document you linked talks about
timer 5 as well.

Alistair


- page 30 of https://www.st.com/resource/en/datasheet/stm32f100cb.pdf

I believe ST is skipping numbers to guarantee that timer[n] will have a
consistent address on different STM32 SoC.

Thanks,
-- Alexandre



From what I understand from other STM32F100xx reference manuals:
I am implementing all peripherals in the STM32F100xx reference manual 
which match with what is actually in the STM32F100RB SoC (used in the 
STM32VLDISCOVERY).


STM32F100RC SoC implements more peripherals (more USART, more 
timers...). Adding these peripherals in stm32f100.c means that the 
STM32VLDISCOVERY machine would have peripherals that does not exist on 
the real target. Do we want to avoid that?


Should we keep stm32f100.c with the common subset of peripherals and 
extend it when a machine is using a variant with more peripherals?


I believe this issue is also linked with what Philippe proposed: we 
could abstract STM32 SoC in the same way ATMEGA is abstracted. This 
would make a lot of sense since the STM32 family has a lot of 
similarities and we don't want to bloat QEMU with N times the same code.


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 1/2] stm32f100: Add the stm32f100 SoC

2021-06-15 Thread Alexandre IOOSS

On 6/14/21 6:04 PM, Peter Maydell wrote:

Is this definitely right? The STM32F00 datasheet I found
thinks it only has 61 external interrupts.


Yes you are right, I don't really known what I have done here. I will 
fix this in next patchset version.


To double-check, it is described page 131 of 
https://www.st.com/resource/en/reference_manual/cd00246267-stm32f100xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 1/2] stm32f100: Add the stm32f100 SoC

2021-06-15 Thread Alexandre IOOSS

On 6/15/21 9:41 AM, Alistair Francis wrote:

Aren't you missing some timers, like timer[5] 0x4000_0C00?

Alistair


I double-checked using the reference manual and the datasheet and there 
is not timer[5]:
- page 36 of 
https://www.st.com/resource/en/reference_manual/cd00246267-stm32f100xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf

- page 30 of https://www.st.com/resource/en/datasheet/stm32f100cb.pdf

I believe ST is skipping numbers to guarantee that timer[n] will have a 
consistent address on different STM32 SoC.


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 2/2] stm32vldiscovery: Add the STM32VLDISCOVERY Machine

2021-06-15 Thread Alexandre IOOSS

On 6/14/21 5:52 PM, Peter Maydell wrote:

On Tue, 8 Jun 2021 at 17:10, Alexandre Iooss  wrote:


This is a Cortex-M3 based machine. Information can be found at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

Signed-off-by: Alexandre Iooss 


The commit message says this is Cortex-M3 based, but the
code gives it a Cortex-M4. Which is correct?


This is an typo. The board is Cortex-M3 so I will fix the machine code 
in next version of this patchset.



---
  MAINTAINERS |  6 +++
  default-configs/devices/arm-softmmu.mak |  1 +
  hw/arm/Kconfig  |  4 ++
  hw/arm/meson.build  |  1 +
  hw/arm/stm32vldiscovery.c   | 66 +
  5 files changed, 78 insertions(+)
  create mode 100644 hw/arm/stm32vldiscovery.c


Could you add some documentation for the new board, please?
This lives in docs/system/arm. Commit c9f8511ea8d2b807 gives
an example of adding docs for a board.

thanks
-- PMM



Should I rather:
1. Add `docs/system/arm/stm32vldiscovery.rst` to document only this new 
machine?
2. Add `docs/system/arm/stm32discovery.rst` to document this new machine 
and future STM32 Discovery boards?

3. Add `docs/system/arm/stm32.rst` to document all STM32-based boards?

STM32 boards share a lot in common so I believe option 3 is more 
appropriate, what is your opinion?
If we go with option 3, I can also try to document the Netduino Plus 2 
(maybe in another commit, or another patchset later).


Thanks,
-- Alexandre



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH] contrib/plugins: add execlog to log instruction execution and memory access

2021-06-14 Thread Alexandre Iooss
Log instruction execution and memory access to a file.
This plugin can be used for reverse engineering or for side-channel analysis
using QEMU.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS   |   1 +
 contrib/plugins/Makefile  |   1 +
 contrib/plugins/execlog.c | 112 ++
 3 files changed, 114 insertions(+)
 create mode 100644 contrib/plugins/execlog.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd29042..65942d5802 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2974,6 +2974,7 @@ F: include/tcg/
 
 TCG Plugins
 M: Alex Bennée 
+R: Alexandre Iooss 
 S: Maintained
 F: docs/devel/tcg-plugins.rst
 F: plugins/
diff --git a/contrib/plugins/Makefile b/contrib/plugins/Makefile
index b9d7935e5e..51093acd17 100644
--- a/contrib/plugins/Makefile
+++ b/contrib/plugins/Makefile
@@ -13,6 +13,7 @@ include $(BUILD_DIR)/config-host.mak
 VPATH += $(SRC_PATH)/contrib/plugins
 
 NAMES :=
+NAMES += execlog
 NAMES += hotblocks
 NAMES += hotpages
 NAMES += howvec
diff --git a/contrib/plugins/execlog.c b/contrib/plugins/execlog.c
new file mode 100644
index 00..80716e8eed
--- /dev/null
+++ b/contrib/plugins/execlog.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2021, Alexandre Iooss 
+ *
+ * Log instruction execution and memory access to a file.
+ * You may pass the output filename as argument.
+ *
+ * License: GNU GPL, version 2 or later.
+ *   See the COPYING file in the top-level directory.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+/* Execution trace buffer */
+FILE *output;
+
+/**
+ * Log memory read or write
+ */
+static void vcpu_mem(unsigned int vcpu_index, qemu_plugin_meminfo_t info,
+ uint64_t vaddr, void *udata)
+{
+struct qemu_plugin_hwaddr *hwaddr = qemu_plugin_get_hwaddr(info, vaddr);
+if (!hwaddr) {
+return;
+}
+
+/* Add data to execution log */
+const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
+uint64_t addr = qemu_plugin_hwaddr_phys_addr(hwaddr);
+if (qemu_plugin_mem_is_store(info)) {
+fprintf(output, "mem: %s store at 0x%08lx\n", name, addr);
+} else {
+fprintf(output, "mem: %s load at 0x%08lx\n", name, addr);
+}
+}
+
+/**
+ * Log instruction execution
+ */
+static void vcpu_insn_exec(unsigned int cpu_index, void *udata)
+{
+char *insn_disas = (char *)udata;
+
+/* Add data to execution log */
+fprintf(output, "insn: %s\n", insn_disas);
+}
+
+/**
+ * On translation block new translation
+ *
+ * QEMU convert code by translation block (TB). By hooking here we can then 
hook
+ * a callback on each instruction and memory access.
+ */
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+size_t n = qemu_plugin_tb_n_insns(tb);
+for (size_t i = 0; i < n; i++) {
+/* insn is shared between translations in QEMU, copy needed data here 
*/
+struct qemu_plugin_insn *insn = qemu_plugin_tb_get_insn(tb, i);
+char *insn_disas = qemu_plugin_insn_disas(insn);
+
+/* Register callback on memory read or write */
+qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem,
+ QEMU_PLUGIN_CB_NO_REGS,
+ QEMU_PLUGIN_MEM_RW, NULL);
+
+/* Register callback on instruction */
+qemu_plugin_register_vcpu_insn_exec_cb(
+insn, vcpu_insn_exec, QEMU_PLUGIN_CB_R_REGS, insn_disas);
+}
+}
+
+/**
+ * On plugin exit, close output file
+ */
+static void plugin_exit(qemu_plugin_id_t id, void *p)
+{
+fclose(output);
+}
+
+/**
+ * Install the plugin
+ */
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+   const qemu_info_t *info, int argc,
+   char **argv)
+{
+/* Parse arguments to get output name and open for writing */
+char *filename = "execution.log";
+if (argc > 0) {
+filename = argv[0];
+}
+output = fopen(filename, "w");
+if (output == NULL) {
+qemu_plugin_outs("Cannot open output file for writing.\n");
+return -1;
+}
+
+/* Register translation block and exit callbacks */
+qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
+qemu_plugin_register_atexit_cb(id, plugin_exit, NULL);
+
+return 0;
+}
-- 
2.25.1




[PATCH 0/2] STM32VLDISCOVERY Machine Model

2021-06-08 Thread Alexandre Iooss
This patch series adds the STM32VLDISCOVERY Machine to QEMU

Information on the board is available at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

Alexandre Iooss (2):
  stm32f100: Add the stm32f100 SoC
  stm32vldiscovery: Add the STM32VLDISCOVERY Machine

 MAINTAINERS |  12 ++
 default-configs/devices/arm-softmmu.mak |   1 +
 hw/arm/Kconfig  |  10 ++
 hw/arm/meson.build  |   2 +
 hw/arm/stm32f100_soc.c  | 182 
 hw/arm/stm32vldiscovery.c   |  66 +
 include/hw/arm/stm32f100_soc.h  |  58 
 7 files changed, 331 insertions(+)
 create mode 100644 hw/arm/stm32f100_soc.c
 create mode 100644 hw/arm/stm32vldiscovery.c
 create mode 100644 include/hw/arm/stm32f100_soc.h

-- 
2.25.1




[PATCH 1/2] stm32f100: Add the stm32f100 SoC

2021-06-08 Thread Alexandre Iooss
This SoC is similar to stm32f205 SoC.
This will be used by the STM32VLDISCOVERY to create a machine.

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS|   6 ++
 hw/arm/Kconfig |   6 ++
 hw/arm/meson.build |   1 +
 hw/arm/stm32f100_soc.c | 182 +
 include/hw/arm/stm32f100_soc.h |  58 +++
 5 files changed, 253 insertions(+)
 create mode 100644 hw/arm/stm32f100_soc.c
 create mode 100644 include/hw/arm/stm32f100_soc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd29042..62dfa31800 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -946,6 +946,12 @@ L: qemu-...@nongnu.org
 S: Maintained
 F: hw/arm/virt-acpi-build.c
 
+STM32F100
+M: Alexandre Iooss 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/arm/stm32f100_soc.c
+
 STM32F205
 M: Alistair Francis 
 M: Peter Maydell 
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 67723d9ea6..0bc3ee3e91 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -326,6 +326,12 @@ config RASPI
 select SDHCI
 select USB_DWC2
 
+config STM32F100_SOC
+bool
+select ARM_V7M
+select STM32F2XX_USART
+select STM32F2XX_SPI
+
 config STM32F205_SOC
 bool
 select ARM_V7M
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index be39117b9b..0e637e6a9e 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -39,6 +39,7 @@ arm_ss.add(when: 'CONFIG_STRONGARM', if_true: 
files('strongarm.c'))
 arm_ss.add(when: 'CONFIG_ALLWINNER_A10', if_true: files('allwinner-a10.c', 
'cubieboard.c'))
 arm_ss.add(when: 'CONFIG_ALLWINNER_H3', if_true: files('allwinner-h3.c', 
'orangepi.c'))
 arm_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_peripherals.c', 
'bcm2836.c', 'raspi.c'))
+arm_ss.add(when: 'CONFIG_STM32F100_SOC', if_true: files('stm32f100_soc.c'))
 arm_ss.add(when: 'CONFIG_STM32F205_SOC', if_true: files('stm32f205_soc.c'))
 arm_ss.add(when: 'CONFIG_STM32F405_SOC', if_true: files('stm32f405_soc.c'))
 arm_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx-zynqmp.c', 
'xlnx-zcu102.c'))
diff --git a/hw/arm/stm32f100_soc.c b/hw/arm/stm32f100_soc.c
new file mode 100644
index 00..4655aaf05a
--- /dev/null
+++ b/hw/arm/stm32f100_soc.c
@@ -0,0 +1,182 @@
+/*
+ * STM32F100 SoC
+ *
+ * Copyright (c) 2021 Alexandre Iooss 
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/module.h"
+#include "hw/arm/boot.h"
+#include "exec/address-spaces.h"
+#include "hw/arm/stm32f100_soc.h"
+#include "hw/qdev-properties.h"
+#include "hw/misc/unimp.h"
+#include "sysemu/sysemu.h"
+
+/* stm32f100_soc implementation is derived from stm32f205_soc */
+
+static const uint32_t usart_addr[STM_NUM_USARTS] = { 0x40013800, 0x40004400,
+0x40004800 };
+static const uint32_t spi_addr[STM_NUM_SPIS] = { 0x40013000, 0x40003800 };
+
+static const int usart_irq[STM_NUM_USARTS] = {37, 38, 39};
+static const int spi_irq[STM_NUM_SPIS] = {35, 36};
+
+static void stm32f100_soc_initfn(Object *obj)
+{
+STM32F100State *s = STM32F100_SOC(obj);
+int i;
+
+object_initialize_child(obj, "armv7m", >armv7m, TYPE_ARMV7M);
+
+for (i = 0; i < STM_NUM_USARTS; i++) {
+object_initialize_child(obj, "usart[*]", >usart[i],
+TYPE_STM32F2XX_USART);
+}
+
+for (i = 0; i < STM_NUM_SPIS; i++) {
+object_initialize_child(obj, "spi[*]", >spi[i], TYPE_STM32F2XX_SPI);
+}
+}
+
+static void stm32f100_soc_realize(DeviceState *dev_soc, Error **errp)
+{
+STM32F100State *s = STM32F100_SOC(dev_soc);
+DeviceState *dev, *armv7m;
+SysBusDevice *busdev;
+int i;
+
+MemoryRegion *system_memory = get_system_memory();
+MemoryRegion *sram = g_new(Memory

[PATCH 2/2] stm32vldiscovery: Add the STM32VLDISCOVERY Machine

2021-06-08 Thread Alexandre Iooss
This is a Cortex-M3 based machine. Information can be found at:
https://www.st.com/en/evaluation-tools/stm32vldiscovery.html

Signed-off-by: Alexandre Iooss 
---
 MAINTAINERS |  6 +++
 default-configs/devices/arm-softmmu.mak |  1 +
 hw/arm/Kconfig  |  4 ++
 hw/arm/meson.build  |  1 +
 hw/arm/stm32vldiscovery.c   | 66 +
 5 files changed, 78 insertions(+)
 create mode 100644 hw/arm/stm32vldiscovery.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 62dfa31800..0aa8016936 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -891,6 +891,12 @@ F: hw/*/stellaris*
 F: include/hw/input/gamepad.h
 F: docs/system/arm/stellaris.rst
 
+STM32VLDISCOVERY
+M: Alexandre Iooss 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/arm/stm32vldiscovery.c
+
 Versatile Express
 M: Peter Maydell 
 L: qemu-...@nongnu.org
diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 0500156a0c..cdc0e97f9d 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -18,6 +18,7 @@ CONFIG_CHEETAH=y
 CONFIG_SX1=y
 CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
+CONFIG_STM32VLDISCOVERY=y
 CONFIG_REALVIEW=y
 CONFIG_VERSATILE=y
 CONFIG_VEXPRESS=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 0bc3ee3e91..dc4e47b721 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -239,6 +239,10 @@ config STELLARIS
 select STELLARIS_ENET # ethernet
 select UNIMP
 
+config STM32VLDISCOVERY
+bool
+select STM32F100_SOC
+
 config STRONGARM
 bool
 select PXA2XX
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 0e637e6a9e..721a8eb8be 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -24,6 +24,7 @@ arm_ss.add(when: 'CONFIG_Z2', if_true: files('z2.c'))
 arm_ss.add(when: 'CONFIG_REALVIEW', if_true: files('realview.c'))
 arm_ss.add(when: 'CONFIG_SBSA_REF', if_true: files('sbsa-ref.c'))
 arm_ss.add(when: 'CONFIG_STELLARIS', if_true: files('stellaris.c'))
+arm_ss.add(when: 'CONFIG_STM32VLDISCOVERY', if_true: 
files('stm32vldiscovery.c'))
 arm_ss.add(when: 'CONFIG_COLLIE', if_true: files('collie.c'))
 arm_ss.add(when: 'CONFIG_VERSATILE', if_true: files('versatilepb.c'))
 arm_ss.add(when: 'CONFIG_VEXPRESS', if_true: files('vexpress.c'))
diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c
new file mode 100644
index 00..ab9297bc38
--- /dev/null
+++ b/hw/arm/stm32vldiscovery.c
@@ -0,0 +1,66 @@
+/*
+ * ST STM32VLDISCOVERY machine
+ *
+ * Copyright (c) 2021 Alexandre Iooss 
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/qdev-properties.h"
+#include "qemu/error-report.h"
+#include "hw/arm/stm32f100_soc.h"
+#include "hw/arm/boot.h"
+
+/* stm32vldiscovery implementation is derived from netduinoplus2 */
+
+/* Main SYSCLK frequency in Hz (24MHz) */
+#define SYSCLK_FRQ 2400ULL
+
+static void stm32vldiscovery_init(MachineState *machine)
+{
+DeviceState *dev;
+
+/*
+ * TODO: ideally we would model the SoC RCC and let it handle
+ * system_clock_scale, including its ability to define different
+ * possible SYSCLK sources.
+ */
+system_clock_scale = NANOSECONDS_PER_SECOND / SYSCLK_FRQ;
+
+dev = qdev_new(TYPE_STM32F100_SOC);
+qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m4"));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+
+armv7m_load_kernel(ARM_CPU(first_cpu),
+   machine->kernel_filename,
+   FLASH_SIZE);
+}
+
+static void stm32vldiscovery_machine_init(MachineClass *mc)
+{
+mc->desc = "ST STM32VLDISCOVERY (Cortex-M4)";
+mc->init = stm32vldiscovery_init;
+}
+
+DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init)
+
-- 
2.25.1