Please see inline
On 22/01/2024 01:17, Philippe Mathieu-Daudé wrote:
Hi Shlomo,
On 21/1/24 17:47, Shlomo Pongratz wrote:
From: Shlomo Pongratz
Hanlde wrap around when calculating the viewport size
caused by the fact that perior to version 460A the limit variable
was 32bit quan
Hi
On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
wrote:
>
> Since most encoders (invoked by Spice) may not work with tiled memory
> associated with a texture, we need to create another texture that has
> linear memory layout and use that instead.
>
> Note that, there does not seem to be a direc
Hi
On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
wrote:
>
> In the specific case where the display layer (virtio-gpu) is using
> dmabuf, and if remote clients are enabled (-spice gl=on,port=),
> it makes sense to limit the maximum (streaming) rate to 60 FPS
> using the GUI timer. This match
Hi
On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
wrote:
>
> Newer versions of Spice server should be able to accept dmabuf
> fds from Qemu for clients that are connected via the network.
> In other words, when this option is enabled, Qemu would share
> a dmabuf fd with Spice which would encode
Hi
On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
wrote:
>
> Giving users an option to choose a particular codec will enable
> them to make an appropriate decision based on their hardware and
> use-case.
>
> Cc: Gerd Hoffmann
> Cc: Marc-André Lureau
> Cc: Frediano Ziglio
> Cc: Dongwon Kim
>
On Fri, 19 Jan 2024 at 15:25, Thomas Huth wrote:
>
> The following changes since commit 88cf5fec91e50cd34bc002b633b4116228db0bc8:
>
> Merge tag 'pull-target-arm-20240118' of
> https://git.linaro.org/people/pmaydell/qemu-arm into staging (2024-01-18
> 12:48:17 +)
>
> are available in the Gi
On 22/01/2024 05.11, Junho wrote:
Hello,
I'm a QEMU user with PowerPc target architecture.
I have some personal modifications related to tb jmp cache and chaining
logic to improve the performance of a specific guest code. To verify the
safety, I have to guarantee that the page table on RAM doe
Gentle ping...
Please help to review and consider applying the patch series. (The KVM
part has been merged).
On 1/12/2024 2:00 PM, Binbin Wu wrote:
Linear-address masking (LAM) [1], modifies the checking that is applied to
*64-bit* linear addresses, allowing software to use of the untranslated
On Sun, 21 Jan 2024 at 16:48, Shlomo Pongratz wrote:
>
> From: Shlomo Pongratz
>
> Hanlde wrap around when calculating the viewport size
> caused by the fact that perior to version 460A the limit variable
> was 32bit quantity and not 64 bits quantity.
> In the i.MX 6Dual/6Quad App
Cc'ing Manos.
On 11/1/24 11:29, Mark Cave-Ayland wrote:
The nubus-virtio-mmio device is a Nubus card that contains a set of 32
virtio-mmio
devices and a goldfish PIC similar to the m68k virt machine that can be plugged
into the m68k q800 machine.
There are currently a number of drivers under d
On Mon, Jan 22, 2024 at 03:42:10PM +1000, Alistair Francis wrote:
> > > From memory the "debug" property is for the original debug spec:
> > > https://github.com/riscv/riscv-debug-spec/releases/tag/task_group_vote
> > >
> > > That was ratified and is an official extension. AFAIK this is what is
> >
The kernel had already support LSX and LASX [1],
but QEMU is disable LSX/LASX for kvm. This patch adds
kvm_check_cpucfg2() to check CPUCFG2.
[1]:
https://lore.kernel.org/all/cabgobfzhrf7e_7jk4uprmsyxty3eiuuywhc35jqncnl9s-z...@mail.gmail.com/
Signed-off-by: Song Gao
---
linux-headers/asm-loonga
On Fri, 19 Jan 2024 16:35:11 +
Peter Maydell wrote:
> Switch the s390x virtual-css bus from using BusClass::reset to the
> Resettable interface.
>
> This has no behavioural change, because the BusClass code to support
> subclasses that use the legacy BusClass::reset will call that method
> i
Features supported :
- the 8 STM32L4x5 GPIOs are initialized with their reset values
(except IDR, see below)
- input mode : setting a pin in input mode "externally" (using input
irqs) results in an out irq (transmitted to SYSCFG)
- output mode : setting a bit in ODR sets the corresponding o
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/arm/Kconfig | 3 +-
hw/arm/stm32l4x5_soc.c | 67 +++---
include/hw/arm/stm32l4x5_soc.h | 2 +
3 files changed, 58 insertions(+), 14 deletions(-)
diff --git a/hw/arm/Kconfig b/hw/
The testcase contains :
- `test_idr_reset_value()` :
Checks the reset values of MODER, OTYPER, PUPDR, ODR and IDR.
- `test_gpio_output_mode()` :
Checks that writing a bit in register ODR results in the corresponding
pin rising or lowering, if this pin is configured in output mode.
- `test_gpio_inpu
This patch adds a new device STM32L4x5 GPIO device and is part
of a series implementing the STM32L4x5 with a few peripherals.
Changes from RFC v1 :
- `stm32l4x5-gpio-test.c` : correct typos, make the test generic,
add a test for bitwise writing in register ODR
- `stm32l4x5_soc.c` : connect gpios t
Remove the command altogether from targets that do not have device tree support,
instead of leaving it nonfunctional.
Signed-off-by: Paolo Bonzini
---
meson.build| 2 --
qapi/machine.json | 2 +-
hmp-commands.hx| 2 +-
system/meson.build | 2 +-
4 files changed, 3 insertions(+), 5 d
Always allow -dtb in qemu-system-xtensa. Basically all other targets require
it if it can be used (including for example i386/x86_64).
Signed-off-by: Paolo Bonzini
---
configs/targets/xtensa-softmmu.mak | 1 +
configs/targets/xtensaeb-softmmu.mak | 1 +
hw/xtensa/xtfpga.c |
On Fri, Jan 19, 2024 at 08:39:18PM -0300, Fabiano Rosas wrote:
> We're currently allowing the process_incoming_migration_bh bottom-half
> to run without holding a reference to the 'current_migration' object,
> which leads to a segmentation fault if the BH is still live after
> migration_shutdown()
Jan Kiszka writes:
> On 19.01.24 12:24, Alex Bennée wrote:
>> Peter Maydell writes:
>>
>>> Convert the musicpal key input device to use
>>> qemu_add_kbd_event_handler(). This lets us simplify it because we no
>>> longer need to track whether we're in the middle of a PS/2 multibyte
>>> key seque
Akihiko Odaki writes:
> On 2024/01/18 20:38, Alex Bennée wrote:
>> Akihiko Odaki writes:
>>
>>> On 2024/01/16 19:48, Alex Bennée wrote:
We can only request a list of registers once the vCPU has been
initialised so the user needs to use either call the get function on
vCPU initial
On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
> Generate SMBIOS tables for the RISC-V mach-virt.
> Add CONFIG_SMBIOS=y to the RISC-V default config.
> Set the default processor family in the type 4 table.
>
> The implementation is based on the corresponding ARM and Loongson
On Fri, Dec 29, 2023 at 01:07:21PM +0100, Heinrich Schuchardt wrote:
> For RISC-V the SMBIOS standard requires specific values of the processor
> family value depending on the bitness of the CPU.
>
> Add a processor-family option for SMBIOS table 4.
>
> The value of processor-family may exceed 25
On Fri, Dec 29, 2023 at 01:07:22PM +0100, Heinrich Schuchardt wrote:
> Provide a function to set the default processor family.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> new patch
> ---
> hw/smbios/smbios.c | 7 +++
> include/hw/firmware/smbios.h | 1 +
> 2 files ch
On Fri, Dec 29, 2023 at 01:07:24PM +0100, Heinrich Schuchardt wrote:
> With SMBIOS support added for RISC-V we also should enable the command line
> option.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> new patch
> ---
> qemu-options.hx | 2 +-
> 1 file changed, 1 insertion(+), 1 de
On 1/18/24 20:20, Vivek Kasireddy wrote:
> Recent updates in OVMF and Seabios have resulted in MMIO regions
> being placed at the upper end of the physical address space. As a
> result, when a Host device is assigned to the Guest via VFIO, the
> following mapping failures occur when VFIO tries to m
18.01.2024 21:51, Matthew Rosato :
Commit ef1535901a0 (re-)introduced an issue where passthrough ISM devices
on s390x would enter an error state after reboot. This was previously fixed
by 03451953c79e, using device reset callbacks, however the change in
ef1535901a0 effectively triggers a cold re
On Mon, Jan 22, 2024 at 05:49:01PM +0800, Peter Xu wrote:
> On Fri, Jan 19, 2024 at 08:39:18PM -0300, Fabiano Rosas wrote:
> > We're currently allowing the process_incoming_migration_bh bottom-half
> > to run without holding a reference to the 'current_migration' object,
> > which leads to a segmen
On Fri, Jan 19, 2024 at 10:01:31AM -0300, Fabiano Rosas wrote:
> I mentioned this at the bottom of the commit message for patch 2/3. You
> need to push your tags. Otherwise your fork on gitlab won't have
> knowledge of v8.2.0.
Oops, my fault. Yeah it works now; I queued this into staging.
Thanks
22.01.2024 13:18, Michael Tokarev :
..
Is it this a material for -stable, or there's no need to bother?
Actually it's been Cc'd to qemu-stable@ already, I haven't noticed.
Still there's a question which branches should get which patches.
(changes 1 and 2 applies to 7.2 (while 2 fixes later ch
On Sat, Jan 20, 2024 at 01:18:14PM +0300, Michael Tokarev wrote:
> 08.01.2024 19:08, Gerd Hoffmann:
> > When running qemu with edk2 efi firmware on aarch64 the efi
> > variable store in pflash can get corrupted. qemu not doing
> > proper block writes -- flush all or nothing to storage -- is
> > a
On 22/01/2024 11.31, Michael Tokarev wrote:
22.01.2024 13:18, Michael Tokarev :
..
Is it this a material for -stable, or there's no need to bother?
Actually it's been Cc'd to qemu-stable@ already, I haven't noticed.
Still there's a question which branches should get which patches.
...
So all
Hi Paolo,
On 22/1/24 10:42, Paolo Bonzini wrote:
Always allow -dtb in qemu-system-xtensa. Basically all other targets require
it if it can be used (including for example i386/x86_64).
Signed-off-by: Paolo Bonzini
---
configs/targets/xtensa-softmmu.mak | 1 +
configs/targets/xtensaeb-soft
Am 20.01.2024 um 18:21 hat Peter Maydell geschrieben:
> On Fri, 19 Jan 2024 at 18:15, Kevin Wolf wrote:
> >
> > The following changes since commit 3f2a357b95845ea0bf7463eff6661e43b97d1afc:
> >
> > Merge tag 'hw-cpus-20240119' of https://github.com/philmd/qemu into
> > staging (2024-01-19 11:39:
The following changes since commit 3f2a357b95845ea0bf7463eff6661e43b97d1afc:
Merge tag 'hw-cpus-20240119' of https://github.com/philmd/qemu into staging
(2024-01-19 11:39:38 +)
are available in the Git repository at:
https://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to fetch
Hello Inès,
On 22/1/24 10:18, Inès Varhol wrote:
Features supported :
- the 8 STM32L4x5 GPIOs are initialized with their reset values
(except IDR, see below)
- input mode : setting a pin in input mode "externally" (using input
irqs) results in an out irq (transmitted to SYSCFG)
- outpu
Hi Inès,
On 22/1/24 10:18, Inès Varhol wrote:
Features supported :
- the 8 STM32L4x5 GPIOs are initialized with their reset values
(except IDR, see below)
- input mode : setting a pin in input mode "externally" (using input
irqs) results in an out irq (transmitted to SYSCFG)
- output m
On 20/1/24 22:45, Thomas Weißschuh wrote:
A process can opt-out of coredump creation by calling
prctl(PR_SET_DUMPABLE, 0).
linux-user passes this call from the guest through to the
operating system.
From there it can be read back again to avoid creating coredumps from
qemu-user itself if the gue
On 20/1/24 22:45, Thomas Weißschuh wrote:
Should getrlimit() fail the value of dumpsize.rlimit_cur may not be
initialized. Avoid reading garbage data by checking the return value of
getrlimit.
Reviewed-by: Richard Henderson
Signed-off-by: Thomas Weißschuh
---
linux-user/elfload.c | 4 ++--
On Mon, 22 Jan 2024 at 11:15, Kevin Wolf wrote:
>
> Am 20.01.2024 um 18:21 hat Peter Maydell geschrieben:
> > Got some compile failures on this one; looks like the compiler
> > on our s390 box didn't like this:
> >
> > https://gitlab.com/qemu-project/qemu/-/jobs/5973441293
> > https://gitlab.com/q
On Mon, Jan 22, 2024 at 03:24:19PM +1000, Alistair Francis wrote:
> On Wed, Jan 10, 2024 at 8:27 PM Conor Dooley wrote:
> >
> > From: Conor Dooley
> >
> > Making it a series to keep the standalone change to riscv_isa_string()
> > that Drew reported separate.
> >
> > Changes in v3:
> > - g_free()
On 22.01.24 10:57, Andrew Jones wrote:
On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
Generate SMBIOS tables for the RISC-V mach-virt.
Add CONFIG_SMBIOS=y to the RISC-V default config.
Set the default processor family in the type 4 table.
The implementation is based on the
A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a
full customized 32 bit CPU is desired, and users won't need to disable
defaults by hand as they would with the rv32 CPU. [1] has an example of
a situation that would be avoided with rv32i.
In fact, add bare bones CPUs for RVE
Hi,
This v3 has the same patches from v2 rebased with a newer
riscv-to-apply.next branch (@ 096b6b07298).
No other changes made. All patches acked.
v2 link:
https://lore.kernel.org/qemu-riscv/20240108161903.353648-1-dbarb...@ventanamicro.com/
Daniel Henrique Barboza (2):
target/riscv/cpu.c:
Next patch will add more bare CPUs. Their cpu_init() functions would be
glorified copy/pastes of rv64i_bare_cpu_init(), differing only by a
riscv_cpu_set_misa() call.
Add a new .instance_init for the TYPE_RISCV_BARE_CPU typ to avoid this
code repetition. While we're at it, add a better explanation
On 12/01/2024 12:52, Mark Cave-Ayland wrote:
The ESP SCSI chip fundamentally consists of a FIFO for transferring data to/from
the SCSI bus along with a command sequencer which automates various processes
such
as selection, message/command transfer and data transfer. What makes this chip
particu
On Mon, Jan 22, 2024 at 01:28:18PM +0100, Heinrich Schuchardt wrote:
> On 22.01.24 10:57, Andrew Jones wrote:
> > On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
...
> > > +#if defined(TARGET_RISCV32)
> > > +smbios_set_default_processor_family(0x200);
> > > +#elif defined(T
Provide a function to set the default processor family.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Andrew Jones
---
v3:
no change
v2:
new patch
---
hw/smbios/smbios.c | 7 +++
include/hw/firmware/smbios.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/h
Generate SMBIOS tables for the RISC-V mach-virt.
Add CONFIG_SMBIOS=y to the RISC-V default config.
With the series the following firmware tables are provided:
etc/smbios/smbios-anchor
etc/smbios/smbios-tables
Add processor-family to the '-smbios type=4' command line options.
v3:
For RISC-V the SMBIOS standard requires specific values of the processor
family value depending on the bitness of the CPU.
Add a processor-family option for SMBIOS table 4.
The value of processor-family may exceed 255 and therefore must be provided
in the Processor Family 2 field. Set the Process
Generate SMBIOS tables for the RISC-V mach-virt.
Add CONFIG_SMBIOS=y to the RISC-V default config.
Set the default processor family in the type 4 table.
The implementation is based on the corresponding ARM and Loongson code.
With the patch the following firmware tables are provided:
etc/smbi
With SMBIOS support added for RISC-V we also should enable the command line
option.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Daniel Henrique Barboza
Acked-by: Alistair Francis
Reviewed-by: Andrew Jones
---
v3:
no change
v2:
new patch
---
qemu-options.hx | 2 +-
1 file c
John Snow writes:
> On Tue, Jan 16, 2024 at 6:09 AM Markus Armbruster wrote:
>>
>> John Snow writes:
>>
>> > allow resolve_type to be used for both built-in and user-specified
>> > type definitions. In the event that the type cannot be resolved, assert
>> > that 'info' and 'what' were both prov
On 22.01.24 13:59, Andrew Jones wrote:
On Mon, Jan 22, 2024 at 01:28:18PM +0100, Heinrich Schuchardt wrote:
On 22.01.24 10:57, Andrew Jones wrote:
On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
...
+#if defined(TARGET_RISCV32)
+smbios_set_default_processor_family(0x2
Alright, right now there are 10 digits for ID, don't think a billion
snapshots are feasible anyway.
> Maybe what we should also do is decreasing the width of each field by
> one and instead writing a space character into the format string.
I'm assuming you are talking about adding spaces between
On 22/01/2024 10.24, Paolo Bonzini wrote:
Remove the command altogether from targets that do not have device tree support,
instead of leaving it nonfunctional.
Signed-off-by: Paolo Bonzini
---
meson.build| 2 --
qapi/machine.json | 2 +-
hmp-commands.hx| 2 +-
system/meson.bui
On Mon, Jan 22, 2024 at 2:40 PM Thomas Huth wrote:
>
> On 22/01/2024 10.24, Paolo Bonzini wrote:
> > Remove the command altogether from targets that do not have device tree
> > support,
> > instead of leaving it nonfunctional.
> >
> > Signed-off-by: Paolo Bonzini
> > ---
> > meson.build
On 22/01/2024 10.42, Paolo Bonzini wrote:
Always allow -dtb in qemu-system-xtensa. Basically all other targets require
it if it can be used (including for example i386/x86_64).
Signed-off-by: Paolo Bonzini
---
configs/targets/xtensa-softmmu.mak | 1 +
configs/targets/xtensaeb-softmmu.mak
On Mon, 22 Jan 2024 at 11:10, Philippe Mathieu-Daudé wrote:
> On 22/1/24 10:42, Paolo Bonzini wrote:
> > Always allow -dtb in qemu-system-xtensa. Basically all other targets
> > require
> > it if it can be used (including for example i386/x86_64).
> I've been wondering for some time why not req
Hello,
On 1/22/24 03:06, Peter Xu wrote:
Hi, Peter,
On Fri, Jan 19, 2024 at 04:35:07PM +, Peter Maydell wrote:
I wrote this ages ago and recently picked it back up because of a
recent PCI related reset ordering problem noted by Peter Xu. I'm not
sure if this patchset is necessary as a par
On 10/1/24 23:43, Richard Henderson wrote:
... and the inverse, CBZ for TSTEQ.
Suggested-by: Paolo Bonzini
Signed-off-by: Richard Henderson
---
tcg/aarch64/tcg-target.c.inc | 8
1 file changed, 8 insertions(+)
diff --git a/tcg/aarch64/tcg-target.c.inc b/tcg/aarch64/tcg-target.c.in
On 19.01.2024 17:35, Peter Maydell wrote:
Switch vmbus from using BusClass::reset to the Resettable interface.
This has no behavioural change, because the BusClass code to support
subclasses that use the legacy BusClass::reset will call that method
in the hold phase of 3-phase reset.
Signed-off
Hi David,
On 17.01.2024 14:55, David Hildenbrand wrote:
Reintroduce a modified region size check, after we would now allow some
configurations that don't make any sense (e.g., partial hugetlb pages,
1G+1byte DIMMs).
We have to take care of hv-balloon first, which was the case why we
remove that
Armv8.1+ CPUs have the Virtual Host Extension (VHE) which adds a
non-secure EL2 virtual timer. We implemented the timer itself in the
CPU model, but never wired up its IRQ line to the GIC.
Wire up the IRQ line (this is always safe whether the CPU has the
interrupt or not, since it always creates
Update the virt golden reference files to say that the FACP is ACPI
v6.3, and the GTDT table is a revision 3 table with space for the
virtual EL2 timer.
Diffs from iasl:
@@ -1,32 +1,32 @@
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20200925 (64-bit version)
* Cop
Allow changes to the virt GTDT -- we are going to add the IRQ
entry for a new timer to it.
Signed-off-by: Peter Maydell
---
tests/qtest/bios-tables-test-allowed-diff.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtest/bios-tables-tes
This patchset wires up the NS EL2 virtual timer IRQ on the virt
board, similarly to what commit 058262e0a8b2 did for the sbsa-ref board.
Version 1 was an RFC patchset, originally sent back in autumn:
https://patchew.org/QEMU/20230919101240.2569334-1-peter.mayd...@linaro.org/
The main reason for it
On Fri, Jan 19, 2024 at 05:39:40PM -0300, Cristian Rodríguez wrote:
> gcrypt by default uses an userspace RNG, which cannot know
> when it is time to discard/invalidate its buffer
> (suspend, resume, vm forks, other corner cases)
> as a "when to discard" event is unavailable to userspace.
So in th
From: Akihiko Odaki
The effective MXL value matters when booting.
Signed-off-by: Akihiko Odaki
Message-Id: <20240103173349.398526-23-alex.ben...@linaro.org>
Message-Id: <20231213-riscv-v7-1-a760156a3...@daynix.com>
Signed-off-by: Alex Bennée
---
hw/riscv/boot.c | 2 +-
1 file changed, 1 inser
From: Akihiko Odaki
misa_mxl_max is common for all instances of a RISC-V CPU class so they
are better put into class.
Signed-off-by: Akihiko Odaki
Message-Id: <20240103173349.398526-25-alex.ben...@linaro.org>
Message-Id: <20231213-riscv-v7-3-a760156a3...@daynix.com>
[AJB: fixed merge conflicts]
From: Akihiko Odaki
This is a tree-wide change to introduce GDBFeature parameter to
gdb_register_coprocessor(). The new parameter just replaces num_regs
and xml parameters for now. GDBFeature will be utilized to simplify XML
lookup in a following change.
Signed-off-by: Akihiko Odaki
Acked-by: A
Akihiko requested the register support not be merged in its current
state so it's time for another round of review. I've made a few tweaks
to simplify the register and CPU tracking code in execlog and removed
some stale API functions. However from my point of view its ready to
merge.
v3
--
- spl
From: Akihiko Odaki
misa_mxl_max is now a class member and initialized only once for each
class. This also moves the initialization of gdb_core_xml_file which
will be referenced before realization in the future.
Signed-off-by: Akihiko Odaki
Message-Id: <20240103173349.398526-26-alex.ben...@lina
From: Akihiko Odaki
In preparation for a change to use GDBFeature as a parameter of
gdb_register_coprocessor(), convert the internal representation of
dynamic feature from plain XML to GDBFeature.
Signed-off-by: Akihiko Odaki
Message-Id: <20240103173349.398526-29-alex.ben...@linaro.org>
Message
From: Akihiko Odaki
Align the parameters of gdb_get_reg_cb and gdb_set_reg_cb with the
gdb_read_register and gdb_write_register members of CPUClass to allow
to unify the logic to access registers of the core and coprocessors
in the future.
Signed-off-by: Akihiko Odaki
Reviewed-by: Alex Bennée
From: Akihiko Odaki
It is initialized with a simple assignment and there is little room for
error. In fact, the validation is even more complex.
Signed-off-by: Akihiko Odaki
Acked-by: LIU Zhiwei
Reviewed-by: Daniel Henrique Barboza
Acked-by: Alistair Francis
Message-Id: <20240103173349.39852
From: Akihiko Odaki
Now we know all instances of GDBFeature that is used in CPU so we can
traverse them to find XML. This removes the need for a CPU-specific
lookup function for dynamic XMLs.
Signed-off-by: Akihiko Odaki
Reviewed-by: Alex Bennée
Message-Id: <20240103173349.398526-33-alex.ben..
From: Akihiko Odaki
This avoids optimizations incompatible when reading registers.
Signed-off-by: Akihiko Odaki
Reviewed-by: Pierrick Bouvier
Message-Id: <20240103173349.398526-37-alex.ben...@linaro.org>
Message-Id: <20231213-gdb-v17-12-777047380...@daynix.com>
Signed-off-by: Alex Bennée
Revi
This makes them a bit more visible in the TCG emulation menu rather
than hiding them away bellow the ToC limit.
Message-Id: <20240103173349.398526-43-alex.ben...@linaro.org>
Reviewed-by: Pierrick Bouvier
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
---
docs/devel/tcg-plugins.
Expose an internal API to QEMU to return all the registers for a vCPU.
The list containing the details required to called gdb_read_register().
Based-on: <20231025093128.33116-15-akihiko.od...@daynix.com>
Cc: Akihiko Odaki
Message-Id: <20240103173349.398526-38-alex.ben...@linaro.org>
Signed-off-by
From: Akihiko Odaki
GDBFeature has the num_regs member so use it where applicable to
remove magic numbers.
Signed-off-by: Akihiko Odaki
Message-Id: <20240103173349.398526-34-alex.ben...@linaro.org>
Message-Id: <20231213-gdb-v17-8-777047380...@daynix.com>
Signed-off-by: Alex Bennée
---
include
While we attempt to hide implementation details from the plugin we
shouldn't be totally obtuse. Let the user know what they can and can't
expect with the various instrumentation options.
Message-Id: <20240103173349.398526-44-alex.ben...@linaro.org>
Reviewed-by: Pierrick Bouvier
Signed-off-by: Ale
From: Akihiko Odaki
This function is no longer used.
Signed-off-by: Akihiko Odaki
Reviewed-by: Alex Bennée
Message-Id: <20240103173349.398526-35-alex.ben...@linaro.org>
Message-Id: <20231213-gdb-v17-9-777047380...@daynix.com>
Signed-off-by: Alex Bennée
---
include/hw/core/cpu.h | 4
ta
From: Akihiko Odaki
In preparation for a change to use GDBFeature as a parameter of
gdb_register_coprocessor(), convert the internal representation of
dynamic feature from plain XML to GDBFeature.
Signed-off-by: Akihiko Odaki
Acked-by: Richard Henderson
Message-Id: <20240103173349.398526-27-al
With the new plugin register API we can now track changes to register
values. Currently the implementation is fairly dumb which will slow
down if a large number of register values are being tracked. This
could be improved by only instrumenting instructions which mention
registers we are interested
From: Akihiko Odaki
These members will be used to help plugins to identify registers.
The added members in instances of GDBFeature dynamically generated by
CPUs will be filled in later changes.
Signed-off-by: Akihiko Odaki
Message-Id: <20240103173349.398526-36-alex.ben...@linaro.org>
Message-Id
On 1/19/24 4:07 PM, Halil Pasic wrote:
> On Thu, 18 Jan 2024 13:51:51 -0500
> Matthew Rosato wrote:
>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index eaf61d3640..c99682b07d 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -118,6
We can't directly save the ephemeral imatch from argv as that memory
will get recycled.
Message-Id: <20240103173349.398526-40-alex.ben...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
---
contrib/plugins/execlog.c | 2 +-
1 file
Unless I'm missing something egregious, the jmp cache is only every
populated with a valid entry by the same thread that reads the cache.
Therefore, the contents of any valid entry are always consistent and
there is no need for any acquire/release magic.
Indeed ->tb has to be accessed with atomics
We can only request a list of registers once the vCPU has been
initialised so the user needs to use either call the get function on
vCPU initialisation or during the translation phase.
We don't expose the reg number to the plugin instead hiding it behind
an opaque handle. This allows for a bit of
On Sun, 21 Jan 2024 at 00:22, Richard Henderson
wrote:
>
> The following changes since commit 3f2a357b95845ea0bf7463eff6661e43b97d1afc:
>
> Merge tag 'hw-cpus-20240119' of https://github.com/philmd/qemu into staging
> (2024-01-19 11:39:38 +)
>
> are available in the Git repository at:
>
>
Refactor the memory prealloc threads support:
- Make memset context a global qlist
- Move the memset thread join/cleanup code to a separate routine
This is functionally equivalent and facilitates multiple memset contexts
(used in a subsequent patch).
Signed-off-by: Mark Kanda
---
util/oslib-pos
QEMU initializes preallocated backend memory as the objects are parsed from
the command line. This is not optimal in some cases (e.g. memory spanning
multiple NUMA nodes) because the memory objects are initialized in series.
Allow the initialization to occur in parallel. In order to ensure optimal
v2:
- require MADV_POPULATE_WRITE (simplify the implementation)
- require prealloc context threads to ensure optimal thread placement
- use machine phase 'initialized' to detremine when to allow parallel init
QEMU initializes preallocated backend memory when parsing the corresponding
objects from
From: Akihiko Odaki
Simplify GDBRegisterState by replacing num_regs and xml members with
one member that points to GDBFeature.
Signed-off-by: Akihiko Odaki
Reviewed-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20240103173349.398526-31-alex.ben...@linaro.org>
Message-Id: <2
The test-iov code uses usleep() with small values (<= 30) in some
nested loops with many iterations. This causes a small delay on OSes
like Linux that have a precise sleeping mechanism, but on systems
like NetBSD and OpenBSD, each usleep() call takes multiple microseconds,
which then sum up in a to
Unless I'm missing something egregious, the jmp cache is only every
populated with a valid entry by the same thread that reads the cache.
Therefore, the contents of any valid entry are always consistent and
there is no need for any acquire/release magic.
Indeed ->tb has to be accessed with atomics
pet...@redhat.com writes:
> From: Peter Xu
>
> The current article is not extremely easy to follow, and may contain too
> much information for someone looking for solutions on VMSD compatibility
> issues. Meanwhile, VMSD versioning is not discussed.
>
> I'm not yet sure whether we should just ob
Ilya Leoshkevich writes:
> Make sure that qemu gdbstub, like gdbserver, allows reading from and
> writing to PROT_NONE pages.
>
> Signed-off-by: Ilya Leoshkevich
Hmm I'm seeing the test hang and drop to the interactive python shell:
TESTbasic gdbstub support on aarch64
Failed to read
1 - 100 of 274 matches
Mail list logo
