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
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
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
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
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
>
> 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
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
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
>
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
>
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
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
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
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
>
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
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
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:
>
>
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
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, , and int128_* methods.
>
> Fixes: 60caf2216bf0 ("target-ppc: add vextu[bhw][lr]x instructions")
>
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
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
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
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
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
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
. 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,
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
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
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
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
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
>
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
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:
From: Matheus Ferst
These helpers shouldn't depend on the host endianness, as they only use
shifts, , 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
---
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
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
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
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).
>
>
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
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(-)
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
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
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
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
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 +++-
>
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
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
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
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
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
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
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
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
--
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
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 +++
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
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
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
On 8/22/21 5:55 AM, Richard Henderson wrote:
> From: Peter Maydell
>
> The target_siginfo_t we populate in force_sig() will eventually
> get copied onto the target's stack. Zero it out so that any extra
> padding in the sifields union is consistently zero when the guest
> sees it.
>
>
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.
CC: Gustavo Romero
Signed-off-by: Gustavo Romero
Signed-off-by: Daniel Henrique Barboza
---
target/ppc/cpu_init.c | 2 +-
Up until this moment we were assuming that the counter negative
enabled bits, PMC1CE and PMCjCE, would never be changed when the
PMU is already started.
Turns out that there is no such restriction in the PowerISA v3.1,
and software can enable/disable overflow conditions of the counters
at any
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 happens and both MMCR0_EBE
and BESCR_PME are set.
The supported PM alerts will
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
userspace.
CC: Gustavo Romero
Signed-off-by: Gustavo Romero
Signed-off-by: Daniel Henrique Barboza
---
target/ppc/cpu.h | 5 +
Hi,
This second version is considerably different than the first one.
All changes were made based on review comments from David and Richard,
along with some design changes I decided to make along the way.
Patches were rebased using current David's ppc-for-6.2 tree.
Changes from v1:
- all
We're missing two counter freeze bits that are used to further control
how the PMCs behaves: MMCR0_FC14 and MMCR0_FC56. These bits can frozen
PMCs separately: MMCR0_FC14 freezes PMCs 1 to 4 and MMCR0_FC56 freezes
PMCs 5 and 6.
Signed-off-by: Daniel Henrique Barboza
---
target/ppc/cpu.h|
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 counters (PMCs), MMCR0, MMCR2
and MMCRA;
- group B contains MMCR1, MMCR3, SIER,
On Thu, Aug 12, 2021 at 3:04 PM Daniel P. Berrangé wrote:
>
> This splits the CI docs into one file talking about job setup and usage
> and another file describing provisioning of custom runners.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/devel/ci-jobs.rst| 40 ++
>
On Sun, 22 Aug 2021 at 04:55, Richard Henderson
wrote:
>
> Use the new function instead of setting up a target_siginfo_t
> and calling queue_signal. Note that we were incorrectly using
> QEMU_SI_KILL instead of QEMU_SI_FAULT for raising SIGSEGV.
>
> Signed-off-by: Richard Henderson
> ---
>
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.
You should mention in the commit message that this fixes two bugs:
* SIGSEGV not distinguishing MAPERR from ACCERR
* SIGTRAP on breakpoint not
24.08.2021 18:51, Hanna Reitz wrote:
On 24.08.21 10:38, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
v8:
06: add Hanna's r-b
07: keep is_fleecing detection in _new() function
08,17,18: add Hanna's r-b
19: wording, s/6.1/6.2/, add Markus's a-b
25: new
29: add John's r-b
34: new
Patches without
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 were changed in 535906c684fca, for linux 4.17.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/syscall_defs.h | 1 +
> linux-user/alpha/cpu_loop.c | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
1 - 100 of 312 matches
Mail list logo
