On 24/08/2021 11:09, Finn Thain wrote:
This code appears to be unnecessary.
Signed-off-by: Finn Thain
---
hw/misc/mos6522.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
index 1c57332b40..a478c1ca43 100644
--
On Mon, Aug 09, 2021 at 03:45:33PM +0200, Cédric Le Goater wrote:
> Our OCC model is very mininal and POWER10 can simply reuse the OCC
> model we introduced for POWER9.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
> ---
> include/hw/ppc/pnv.h | 1 +
> include/hw/ppc/pn
On Mon, Aug 09, 2021 at 03:45:36PM +0200, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
> ---
> include/hw/ppc/pnv.h | 10 ++
> include/hw/ppc/pnv_homer.h | 3 ++
> include/hw/ppc/pnv_xscom.h | 3 ++
> hw/ppc/pnv.c | 20 ++
On Mon, Aug 09, 2021 at 03:45:34PM +0200, Cédric Le Goater wrote:
> Still needs some refinements on the XSCOM registers.
>
> Signed-off-by: Cédric Le Goater
> ---
> include/hw/ppc/pnv.h | 3 +++
> hw/ppc/pnv.c | 34 ++
> 2 files changed, 37 insertions(+)
On Mon, Aug 09, 2021 at 03:45:31PM +0200, Cédric Le Goater wrote:
> The VP space is larger in XIVE2 (P10), 24 bits instead of 19bits on
> XIVE (P9), and the CAM line can use a 7bits or 8bits thread id.
>
> For now, we only use 7bits thread ids, same as P9, but because of the
> change of the size o
On Tue, Aug 24, 2021 at 6:12 AM Richard Henderson
wrote:
>
> Reviewed-by: Bin Meng
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/insn_trans/trans_rvd.c.inc | 125
> 1 file changed, 60 insertions(+), 65 deletions(-)
>
On Tue, Aug 24, 2021 at 6:04 AM Richard Henderson
wrote:
>
> Reviewed-by: Bin Meng
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/insn_trans/trans_rvf.c.inc | 146
> 1 file changed, 70 insertions(+), 76 deletions(-)
>
On Tue, Aug 24, 2021 at 6:09 AM Richard Henderson
wrote:
>
> Always use tcg_gen_deposit_z_tl; the special case for
> shamt >= 32 is handled there.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/insn_trans/trans_rvb.c.inc | 19 ++--
On Tue, Aug 24, 2021 at 6:08 AM Richard Henderson
wrote:
>
> We failed to write into *val for these read functions;
> replace them with read_zero. Only warn about unsupported
> non-zero value when writing a non-zero value.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Ali
On Tue, Aug 24, 2021 at 6:03 AM Richard Henderson
wrote:
>
> We distinguish write-only by passing ret_value as NULL.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/csr.c | 23 +++
> 1 file changed, 15 insertions(+), 8 dele
On Tue, Aug 24, 2021 at 6:05 AM Richard Henderson
wrote:
>
> These operations can be done in one instruction on some hosts.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/insn_trans/trans_rvi.c.inc | 14 --
> 1 file changed, 12 in
On Tue, Aug 24, 2021 at 6:07 AM Richard Henderson
wrote:
>
> Reviewed-by: Bin Meng
> Signed-off-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/insn_trans/trans_rva.c.inc | 47 ++---
> 1 file changed, 19 insertions(+), 28 deletions(-)
>
On Tue, Aug 24, 2021 at 6:10 AM Richard Henderson
wrote:
>
> Introduce csrr and csrw helpers, for read-only and write-only insns.
>
> Note that we do not properly implement this in riscv_csrrw, in that
> we cannot distinguish true read-only (rs1 == 0) from any other zero
> write_mask another sourc
On Thu, Aug 19, 2021 at 3:19 PM David Hoppenbrouwers wrote:
>
> `muldiv64` would overflow in cases where the final 96-bit value does not
> fit in a `uint64_t`. This would result in small values that cause an
> interrupt to be triggered much sooner than intended.
>
> The overflow can be detected in
On Tue, Aug 24, 2021 at 01:30:22PM -0300, Daniel Henrique Barboza wrote:
> The PMU is already counting cycles by calculating time elapsed in
> nanoseconds. Counting instructions is a different matter and requires
> another approach.
>
> This patch adds the capability of counting completed instruct
On Tue, Aug 24, 2021 at 01:30:21PM -0300, Daniel Henrique Barboza wrote:
> This patch enable all PMCs but PMC5 to count cycles. To do that we
> need to implement MMCR1 bits where the event are stored, retrieve
> them, see if the PMC was configured with a PM_CYC event, and
> calculate cycles if that
On Tue, Aug 24, 2021 at 01:30:26PM -0300, Daniel Henrique Barboza wrote:
> From: Gustavo Romero
>
> Following up the rfebb implementation, this patch adds the EBB exception
> support that are triggered by Performance Monitor alerts. This exception
> occurs when an enabled PMU condition or event h
On Tue, Aug 24, 2021 at 01:30:23PM -0300, Daniel Henrique Barboza wrote:
> PM_RUN_INST_CMPL, instructions completed with the run latch set, is
> the architected PowerISA v3.1 event defined with PMC4SEL = 0xFA.
>
> Implement it by checking for the CTRL RUN bit before incrementing the
> counter.
>
On Tue, Aug 24, 2021 at 01:30:20PM -0300, Daniel Henrique Barboza wrote:
> This patch adds the barebones of the PMU logic by enabling cycle
> counting, done via the performance monitor counter 6. The overall logic
> goes as follows:
>
> - a helper is added to control the PMU state on each MMCR0 wr
On 8/24/21 10:11 PM, matheus.fe...@eldorado.org.br wrote:
> From: Matheus Ferst
>
> The definition of struct Int128 is currently independent of the host
> endianness, causing different results when using the member s128 of
> union ppc_vsr_t in big-endian builds with CONFIG_INT128 or
> !CONFIG_INT
> On Tue, Aug 24, 2021 at 05:46:43PM -0400, Programmingkid wrote:
> > Hi, I recently tried using the edid feature in QEMU for my Mac OS 10.8
> > guest
> > like this: -device VGA,edid=on,xres=1280,yres=800. When the guest operating
> > system loaded there were no additional options available in t
On Tue, Aug 24, 2021 at 05:46:43PM -0400, Programmingkid wrote:
> Hi, I recently tried using the edid feature in QEMU for my Mac OS 10.8 guest
> like this: -device VGA,edid=on,xres=1280,yres=800. When the guest operating
> system loaded there were no additional options available in the Display
>
On Tue, Aug 24, 2021 at 01:30:17PM -0300, Daniel Henrique Barboza wrote:
> We're going to add PMU support for TCG PPC64 chips, based on IBM POWER8+
> emulation and following PowerISA v3.1.
>
> PowerISA v3.1 defines two PMU registers groups, A and B:
>
> - group A contains all performance monitor
On Tue, Aug 24, 2021 at 01:30:19PM -0300, Daniel Henrique Barboza wrote:
> From: Gustavo Romero
>
> Similar to the previous patch, user write on some PowerPC
> PMU regs, in this case, MMCR0, is limited. Create a new
> function to handle that.
Ok.. ok, this fixes my concern on the previous patch.
On Tue, Aug 24, 2021 at 01:30:18PM -0300, Daniel Henrique Barboza wrote:
> From: Gustavo Romero
>
> This patch adds handling of UMMCR0 and UMMCR2 user read which,
> according to PowerISA 3.1, has some bits ommited to the
Nit: One 'm' in "omited".
> userspace.
>
> CC: Gustavo Romero
> Signed-o
On Tue, Aug 24, 2021 at 09:48:35PM -0300, Daniel Henrique Barboza wrote:
> MEM_UNPLUG_ERROR is deprecated since the introduction of
> DEVICE_UNPLUG_GUEST_ERROR. Keep emitting both while the deprecation of
> MEM_UNPLUG_ERROR is pending.
>
> CC: Michael S. Tsirkin
> CC: Igor Mammedov
> Reviewed-by
On Tue, Aug 24, 2021 at 09:48:29PM -0300, Daniel Henrique Barboza wrote:
> qapi_event_send_mem_unplug_error() deals with @device being NULL by
> replacing it with an empty string ("") when emitting the event. Aside
> from the fact that this behavior (qapi visitor mapping NULL pointer to
> "") can b
On Tue, Aug 24, 2021 at 09:48:34PM -0300, Daniel Henrique Barboza wrote:
> Linux Kernel 5.12 is now unisolating CPU DRCs in the device_removal
> error path, signalling that the hotunplug process wasn't successful.
> This allow us to send a DEVICE_UNPLUG_GUEST_ERROR in drc_unisolate_logical()
> to s
On Tue, Aug 24, 2021 at 09:48:30PM -0300, Daniel Henrique Barboza wrote:
> As done in hw/acpi/memory_hotplug.c, pass an empty string if dev->id
> is NULL to qapi_event_send_mem_unplug_error() to avoid relying on
> a behavior that can be changed in the future.
>
> Suggested-by: Markus Armbruster
>
On Tue, Aug 24, 2021 at 11:50 PM Peter Xu wrote:
>
> On Tue, Aug 24, 2021 at 10:52:24AM +0800, Jason Wang wrote:
> > It looks to me this doesn't solve the issue of using virtio-mmio with vhost?
>
> No IOMMU supported for any of the MMIO devices, right? Or am I wrong?
> Thanks,
I guess virtio I
On Tue, Aug 24, 2021 at 09:48:31PM -0300, Daniel Henrique Barboza wrote:
> The error_report() call in drc_unisolate_logical() is not considering
> that drc->dev->id can be NULL, and the underlying functions error_report()
> calls to do its job (vprintf(), g_strdup_printf() ...) has undefined
> beha
On Tue, Aug 24, 2021 at 08:09:36PM +1000, Finn Thain wrote:
> This is a patch series that I started last year. The aim was to try to
> get a monotonic clocksource for Linux/m68k guests. That aim hasn't been
> achieved yet (for q800 machines) but I'm submitting the patch series as
> an RFC becaus
On Tue, Aug 24, 2021 at 09:48:33PM -0300, Daniel Henrique Barboza wrote:
> At this moment we only provide one event to report a hotunplug error,
> MEM_UNPLUG_ERROR. As of Linux kernel 5.12 and QEMU 6.0.0, the pseries
> machine is now able to report unplug errors for other device types, such
> as CP
On Tue, Aug 24, 2021 at 09:48:32PM -0300, Daniel Henrique Barboza wrote:
> Clarify that @device is optional and that 'path' is the device
> path from QOM.
>
> This change follows Markus' suggestion verbatim, provided in full
> context here:
>
> https://lists.gnu.org/archive/html/qemu-devel/2021-0
On Mon, Aug 23, 2021 at 12:02:35PM -0300, Luis Pires wrote:
> According to the ISA, CR should be set based on the source value, and
> not on the packed decimal result.
> The way this was implemented would cause GT, LT and EQ to be set
> incorrectly when the source value was too large and the 31 lea
On Tue, Aug 24, 2021 at 11:27:18AM -0300, Luis Pires wrote:
> From: Bruno Larsen
>
> Move REQUIRE_ALTIVEC to translate.c and rename it to REQUIRE_VECTOR.
>
> Signed-off-by: Bruno Larsen
> Signed-off-by: Matheus Ferst
> Signed-off-by: Fernando Valle
> Signed-off-by: Luis Pires
Reviewed-by:
On Tue, Aug 24, 2021 at 05:11:05PM -0300, matheus.fe...@eldorado.org.br wrote:
> From: Matheus Ferst
>
> These helpers shouldn't depend on the host endianness, as they only use
> shifts, &s, and int128_* methods.
>
> Fixes: 60caf2216bf0 ("target-ppc: add vextu[bhw][lr]x instructions")
> Signed-o
On Tue, Aug 24, 2021 at 11:27:19AM -0300, Luis Pires wrote:
> From: Fernando Valle
>
> Signed-off-by: Fernando Valle
> Signed-off-by: Luis Pires
Reviewed-by: David Gibson
> ---
> target/ppc/translate.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/target/ppc/translate.c
On Tue, Aug 24, 2021 at 05:11:03PM -0300, matheus.fe...@eldorado.org.br wrote:
> From: Matheus Ferst
>
> The definition of struct Int128 is currently independent of the host
> endianness, causing different results when using the member s128 of
> union ppc_vsr_t in big-endian builds with CONFIG_IN
On Tue, Aug 24, 2021 at 11:27:13AM -0300, Luis Pires wrote:
> Move abs64 to host-utils so it can be reused elsewhere.
> Also made it inline.
>
> Signed-off-by: Luis Pires
> ---
> hw/i386/kvm/i8254.c | 5 -
> include/qemu/host-utils.h | 8
> 2 files changed, 8 insertions(+), 5
Now that we have "acpi-pci-hotplug-with-bridge-support" PIIX4 PM property being
used for both q35 and i440fx machine types, it is better that we defined this
property string at a single place within a header file like other PIIX4
properties. We can then use this single definition at all the places
There is no need to use fresh typecasts to get references to pci device structs
when there is an existing reference to pci device struct. Use existing
reference.
Minor cleanup.
Signed-off-by: Ani Sinha
Reviewed-by: Philippe Mathieu-Daudé
---
hw/acpi/pcihp.c | 6 +++---
1 file changed, 3 insert
Since commit
36b79e3219d ("hw/acpi/Kconfig: Add missing Kconfig dependencies (build error)"),
ACPI_MEMORY_HOTPLUG and ACPI_NVDIMM is implicitly turned on when
ACPI_HW_REDUCED is selected. ACPI_HW_REDUCED is already enabled. No need to
turn on ACPI_MEMORY_HOTPLUG or ACPI_NVDIMM explicitly. This is a
I have developed an interest in this space and hopefully can lend some
helping hand to Igor and Michael in reviewing simpler patches.
Signed-off-by: Ani Sinha
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Igor Mammedov
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAI
commit c0e427d6eb5fefc538 ("hw/acpi/ich9: Enable ACPI PCI hot-plug") removed all
uses of find_i440fx() function. This has been replaced by the more generic call
acpi_get_i386_pci_host() which maybe able to find the root bus both for i440fx
machine type as well as for the q35 machine type. There see
Michael:
Now that Qemu 6.1.0 has been released, as per your suggestion, I am sending
all my reviewed and queued patches in this patch series for inclusion with
your next pull request.
[PATCH 1/5] hw/pci: remove all references to find_i440fx function
[PATCH 2/5] hw/acpi: use existing references to
. Add sid-map property to store non PCI/PCIe devices SID
. Create IOMMU memory regions for non PCI/PCIe devices based on their SID
. Update SID getting strategy for PCI/PCIe and non PCI/PCIe devices
Signed-off-by: Li, Chunming
---
hw/arm/smmuv3.c | 46 +
At this moment we only provide one event to report a hotunplug error,
MEM_UNPLUG_ERROR. As of Linux kernel 5.12 and QEMU 6.0.0, the pseries
machine is now able to report unplug errors for other device types, such
as CPUs.
Instead of creating a (device_type)_UNPLUG_ERROR for each new device,
create
Linux Kernel 5.12 is now unisolating CPU DRCs in the device_removal
error path, signalling that the hotunplug process wasn't successful.
This allow us to send a DEVICE_UNPLUG_GUEST_ERROR in drc_unisolate_logical()
to signal this error to the management layer.
We also have another error path in spa
MEM_UNPLUG_ERROR is deprecated since the introduction of
DEVICE_UNPLUG_GUEST_ERROR. Keep emitting both while the deprecation of
MEM_UNPLUG_ERROR is pending.
CC: Michael S. Tsirkin
CC: Igor Mammedov
Reviewed-by: Greg Kurz
Signed-off-by: Daniel Henrique Barboza
---
hw/acpi/memory_hotplug.c | 9
As done in hw/acpi/memory_hotplug.c, pass an empty string if dev->id
is NULL to qapi_event_send_mem_unplug_error() to avoid relying on
a behavior that can be changed in the future.
Suggested-by: Markus Armbruster
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/spapr.c | 2 +-
1 file changed,
The error_report() call in drc_unisolate_logical() is not considering
that drc->dev->id can be NULL, and the underlying functions error_report()
calls to do its job (vprintf(), g_strdup_printf() ...) has undefined
behavior when trying to handle "%s" with NULL arguments.
Besides, there is no utilit
Clarify that @device is optional and that 'path' is the device
path from QOM.
This change follows Markus' suggestion verbatim, provided in full
context here:
https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg01891.html
Suggested-by: Markus Armbruster
Reviewed-by: Greg Kurz
Reviewed-by:
qapi_event_send_mem_unplug_error() deals with @device being NULL by
replacing it with an empty string ("") when emitting the event. Aside
from the fact that this behavior (qapi visitor mapping NULL pointer to
"") can be patched/changed someday, there's also the lack of utility
that the event brings
Hi,
In this version the event was renamed and the optional 'msg'
attribute was removed. It also contains smaller changes based
on Markus' comments in v6.
changes from v6:
- patches 1 and 2:
* handle dev->id = NULL explicitly with empty string
- patch 3:
* added Markus' reviewed-by
- patch 4:
Make 'qemu-img commit' work on Windows.
Command 'commit' requires reopening backing file in RW mode. So,
add reopen prepare/commit/abort handlers and change dwShareMode
for CreateFile call in order to allow further read/write reopening.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/418
Signed-off-by: Eugene Huang
---
ui/egl-helpers.c | 4
1 file changed, 4 insertions(+)
diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
index ce0971422b..dee31c6fbb 100644
--- a/ui/egl-helpers.c
+++ b/ui/egl-helpers.c
@@ -346,6 +346,10 @@ EGLSurface qemu_egl_init_surface_x11(EGLContext ectx,
Signed-off-by: Eugene Huang
---
ui/egl-helpers.c | 41 +
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
index 6d0cb2b5cb..ce0971422b 100644
--- a/ui/egl-helpers.c
+++ b/ui/egl-helpers.c
@@ -1,6 +1,8 @@
/*
On Mon, Aug 16, 2021 at 04:15:46PM +0200, Paolo Bonzini wrote:
> Hi,
>
> first of all, thanks for posting this work and starting the discussion.
>
> However, I am not sure if the in-guest migration helper vCPUs should use
> the existing KVM support code. For example, they probably can just
> alwa
Hi, I recently tried using the edid feature in QEMU for my Mac OS 10.8 guest
like this: -device VGA,edid=on,xres=1280,yres=800. When the guest operating
system loaded there were no additional options available in the Display
settings. Would you know what is wrong?
Thank you.
On Mon, Aug 23, 2021 at 11:38 AM Peter Lieven wrote:
>
> Am 22.08.21 um 23:02 schrieb Ilya Dryomov:
> > On Tue, Aug 10, 2021 at 3:41 PM Peter Lieven wrote:
> >> the qemu rbd driver currently lacks support for bdrv_co_block_status.
> >> This results mainly in incorrect progress during block operat
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of
the QEMU 6.1.0 release. This release contains 3000+ commits from 221
authors.
You can grab the tarball from our download page here:
https://www.qemu.org/download/#source
The full list of changes are available at:
h
From: Matheus Ferst
These helpers shouldn't depend on the host endianness, as they only use
shifts, &s, and int128_* methods.
Fixes: 60caf2216bf0 ("target-ppc: add vextu[bhw][lr]x instructions")
Signed-off-by: Matheus Ferst
---
target/ppc/int_helper.c | 38 ++---
From: Matheus Ferst
Suggested-by: Peter Maydell
Signed-off-by: Matheus Ferst
---
include/qemu/int128.h | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/qemu/int128.h b/include/qemu/int128.h
index 64500385e3..e36c6e6db5 100644
--- a/include/qemu/i
From: Matheus Ferst
The definition of struct Int128 is currently independent of the host
endianness, causing different results when using the member s128 of
union ppc_vsr_t in big-endian builds with CONFIG_INT128 or
!CONFIG_INT128.
The only PPC instructions that seem to be affected by this issue
On Tue, Aug 24, 2021 at 06:24:27PM +0200, David Hildenbrand wrote:
> > > Not so much; here's the list of priorities and the devices using it:
> > >
> > > |+-|
> > > | priority | devices |
> > > |+-|
> > >
On Tue, Aug 24, 2021 at 10:04:19PM +0400, Marc-André Lureau wrote:
> Hi
Hello, Marc-Andre,
>
> On Tue, Aug 24, 2021 at 7:27 PM Peter Xu wrote:
>
> > Both dump-guest-memory and live migration caches vm state at the beginning.
> > Either of them entering the other one will cause race on the vm s
Hi, Peter, Gerd,
On Tue, Aug 24, 2021 at 02:01:53PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I was vaguely tossing an idea around in the back of my mind
> > about whether you could have a flag on devices that marked
> > them as "this device is currently involved in IO", such that
> > you could t
On Tue, Aug 24, 2021 at 7:27 PM Peter Xu wrote:
> An internal version that removes -only-migratable implications. It can be
> used
> for temporary migration blockers like dump-guest-memory.
>
> Signed-off-by: Peter Xu
>
Reviewed-by: Marc-André Lureau
---
> include/migration/blocker.h | 16 +
Hi
On Tue, Aug 24, 2021 at 7:27 PM Peter Xu wrote:
> Both dump-guest-memory and live migration caches vm state at the beginning.
> Either of them entering the other one will cause race on the vm state, and
> even
> more severe on that (please refer to the crash report in the bug link).
>
> Let's
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/xtensa/cpu_loop.c | 34 --
> 1 file changed, 12 insertions
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/sh4/cpu_loop.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
Rev
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/s390x/cpu_loop.c | 16 +---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/riscv/cpu_loop.c | 36 +++-
> 1 file changed, 7 insertions
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> The user-only version of ppc_cpu_tlb_fill does not distinguish
> between the various hw codes. Drop all of that and just use
> the new force_si
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/openrisc/cpu_loop.c | 37 +-
> 1 file changed, 10 insertio
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/mips/cpu_loop.c | 45 --
> 1 file changed, 14 insertio
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Fix a typo for ESR_EC_DIVZERO, which is integral not floating-point.
> Fix the if ladder for decoding floating-point exceptions.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/microblaze/cpu_loop.c | 20 +++-
> 1
On 8/22/21 5:55 AM, Richard Henderson wrote:
> Rename to do_tr_or_bp, as per the kernel function.
> Add a 'trap' argument, akin to the kernel's si_code, but clearer.
> The return value is always 0, so change the return value to void.
> Use force_sig and force_sig_fault.
>
> Signed-off-by: Richard
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Reduce the number of ifdefs within cpu_loop().
>
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> This si_code was changed in 75abf64287cab, for linux 4.17.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/syscall_defs.h | 1 +
> linux-user/hppa/cpu_loop.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/linux-user
On 8/22/21 5:55 AM, Richard Henderson wrote:
> From: Peter Maydell
>
> In many places in the linux-user code we need to queue a signal for
> the guest using the QEMU_SI_FAULT si_type. This requires that the
> caller sets up and passes us a target_siginfo, including setting the
> appropriate part
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> These si_codes have been properly set by the kernel since the beginning.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
The initial PMU support were made under the assumption that the counters
would be set before running the PMU and read after either freezing the
PMU manually or via a performance monitor alert.
Turns out that some EBB powerpc kernel tests set the counters after
unfreezing the counters. Setting a PM
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
>
> Signed-off-by: Richard Henderson
Commit message should mention behaviour changes.
Otherwise
Reviewed-by: Peter Maydell
thanks
-- PMM
Enabling counter negative overflow for the PMCs that are counting
instructions is simpler than when counting cycles. Instruction
counting is done via helper_insns_inc(), which is called every
time a TB ends.
Firing a performance monitor alert due to a counter negative overflow
in this case is a ma
This patch starts the counter negative EBB support by enabling PMC1
counter negative overflow when PMC1 is counting cycles.
A counter negative overflow happens when a performance monitor counter
reaches the value 0x8000. When that happens, if counter negative
condition events are enabled in th
An Event-Based Branch (EBB) allows applications to change the NIA when a
event-based exception occurs. Event-based exceptions are enabled by
setting the Branch Event Status and Control Register (BESCR). If the
event-based exception is enabled when the exception occurs, an EBB
happens.
The EBB will
All performance monitor counters can trigger a counter negative
condition if the proper MMCR0 bits are set. This patch does that
for all PMCs that can count cycles by doing the following:
- pmc_counter_negative_enabled() will check whether a given PMC is
eligible to trigger the counter negative al
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Replace the local gen_signal with the generic functions that
> match how the kernel raises signals.
>
> Signed-off-by: Richard Henderson
Mention behaviour changes in the commit message. Otherwise
Reviewed-by: Peter Maydell
thanks
-- PM
On 8/22/21 5:55 AM, Richard Henderson wrote:
> From: Peter Maydell
>
> Use the new force_sig_fault() function instead of setting up
> a target_siginfo_t and calling queue_signal().
>
> Signed-off-by: Peter Maydell
> Message-Id: <20210813131809.28655-7-peter.mayd...@linaro.org>
> Signed-off-by:
The current logic is only considering event-based exceptions triggered
by the performance monitor. This is true now, but we might want to add
support for external event-based exceptions in the future.
Let's make it a bit easier to do so by adding the bit logic that would
happen in case we were dea
On 8/22/21 5:55 AM, Richard Henderson wrote:
> From: Peter Maydell
>
> Use the new force_sig_fault() function instead of setting up
> a target_siginfo_t and calling queue_signal().
>
> Signed-off-by: Peter Maydell
> Message-Id: <20210813131809.28655-8-peter.mayd...@linaro.org>
> Signed-off-by:
PM_RUN_INST_CMPL, instructions completed with the run latch set, is
the architected PowerISA v3.1 event defined with PMC4SEL = 0xFA.
Implement it by checking for the CTRL RUN bit before incrementing the
counter.
Signed-off-by: Daniel Henrique Barboza
---
target/ppc/cpu.h| 3 +++
target
The PMU is already counting cycles by calculating time elapsed in
nanoseconds. Counting instructions is a different matter and requires
another approach.
This patch adds the capability of counting completed instructions
(Perf event PM_INST_CMPL) by counting the amount of instructions
translated in
This patch enable all PMCs but PMC5 to count cycles. To do that we
need to implement MMCR1 bits where the event are stored, retrieve
them, see if the PMC was configured with a PM_CYC event, and
calculate cycles if that's the case.
PowerISA v3.1 defines the following conditions to count cycles:
-
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new functions instead of setting up a target_siginfo_t
> and calling queue_signal.
Where this is changing behaviour to fix bugs you should mention
it in the commit message:
* address field for breakpoint trap
* si_code for align
This patch adds the barebones of the PMU logic by enabling cycle
counting, done via the performance monitor counter 6. The overall logic
goes as follows:
- a helper is added to control the PMU state on each MMCR0 write. This
allows for the PMU to start/stop as the frozen counter bit (MMCR0_FC)
is
1 - 100 of 315 matches
Mail list logo
