Daniel Henrique Barboza writes:
> On 5/20/24 15:51, Björn Töpel wrote:
>> Daniel/David,
>>
>> Daniel Henrique Barboza writes:
>>
>>> On 5/18/24 16:50, David Hildenbrand wrote:
Hi,
>> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
>> index 4fdb66052587..16c2bdbfe6b6
在 2024/5/3 19:32, Shiyang Ruan 写道:
在 2024/4/24 2:40, Dan Williams 写道:
Shiyang Ruan wrote:
Currently driver only traces cxl events, poison creation (for both vmem
and pmem type) on cxl memdev is silent.
As it should be.
OS needs to be notified then it could handle poison pages in time.
On 21/05/2024 07.08, Thomas Huth wrote:
On 20/05/2024 19.47, Zide Chen wrote:
Both cpu-pm and mem-lock are related to system resource overcommit, but
they are separate from each other, in terms of how they are realized,
and of course, they are applied to different system resources.
It's
On 21/05/2024 05:11, Duan, Zhenzhong wrote:
> Caution: External email. Do not open attachments or click links, unless this
> email comes from a known sender and you know the content is safe.
>
>
>> -Original Message-
>> From: CLEMENT MATHIEU--DRIF
>> Subject: Re: [PATCH ats_vtd v2
On 20/05/2024 19.47, Zide Chen wrote:
Both cpu-pm and mem-lock are related to system resource overcommit, but
they are separate from each other, in terms of how they are realized,
and of course, they are applied to different system resources.
It's tempting to use separate command lines to
+ size >> 32, size);
qemu_fdt_setprop_string(ms->fdt, nodename, "device_type", "memory");
if (ms->numa_state && ms->numa_state->num_nodes) {
---
base-commit: 85ef20f1673feaa083f4acab8cf054df77b0dbed
change-id: 20240520-loongarch-fdt-memnode-e36c01ae9b6e
Best regards,
>-Original Message-
>From: CLEMENT MATHIEU--DRIF
>Subject: Re: [PATCH ats_vtd v2 20/25] intel_iommu: fill the PASID field when
>creating an instance of IOMMUTLBEntry
>
>
>On 17/05/2024 12:40, Duan, Zhenzhong wrote:
>> Caution: External email. Do not open attachments or click links,
On Tue, May 21, 2024 at 6:23 AM Fabiano Rosas wrote:
>
> Fiona Ebner writes:
>
> > Migration from an 8.2 or 9.0 binary to an 8.1 binary with machine
> > version 8.1 can fail with:
> >
> >> kvm: Features 0x1c0010130afffa7 unsupported. Allowed features:
> >> 0x10179bfffe7
> >> kvm: Failed to load
On Mon, May 20, 2024 at 12:15 PM Liu, Yi L wrote:
>
> > From: Duan, Zhenzhong
> > Sent: Monday, May 20, 2024 11:41 AM
> >
> >
> >
> > >-Original Message-
> > >From: Jason Wang
> > >Sent: Monday, May 20, 2024 8:44 AM
> > >To: Duan, Zhenzhong
> > >Cc: qemu-devel@nongnu.org; Liu, Yi L ;
Conference back then pto until today, so tomorrow will be my first working
day after those. Sorry Steve, will try my best to read it before next week.
I didn't dare to read too much my inbox yet. A bit scared but need to face
it tomorrow.
On Mon, May 20, 2024, 6:28 p.m. Fabiano Rosas wrote:
>
On Fri, May 17, 2024 at 3:54 PM Fiona Ebner wrote:
>
> Migration from an 8.2 or 9.0 binary to an 8.1 binary with machine
> version 8.1 can fail with:
>
> > kvm: Features 0x1c0010130afffa7 unsupported. Allowed features: 0x10179bfffe7
> > kvm: Failed to load virtio-net:virtio
> > kvm: error while
PPR32 provides access to the upper half of PPR.
Signed-off-by: Nicholas Piggin
---
target/ppc/cpu.h| 1 +
target/ppc/spr_common.h | 2 ++
target/ppc/cpu_init.c | 12
target/ppc/translate.c | 16
4 files changed, 31 insertions(+)
diff --git
Change the logging not to print to stderr as well, because a
checkstop is a guest error (or perhaps a simulated machine error)
rather than a QEMU error, so send it to the log.
Update the checkstop message, and log CPU registers too.
Signed-off-by: Nicholas Piggin
---
target/ppc/excp_helper.c |
AMOR, MMCRC, HRMOR, TSCR, HMEER, RPR SPRs are per-core or per-LPAR
registers with simple (generic) implementations.
Signed-off-by: Nicholas Piggin
---
target/ppc/cpu_init.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/target/ppc/cpu_init.c
LDBAR, TTR are a Power-specific SPRs. These simple implementations
are enough for IBM proprietary firmware for now.
Signed-off-by: Nicholas Piggin
---
target/ppc/cpu.h | 2 ++
target/ppc/cpu_init.c | 10 ++
2 files changed, 12 insertions(+)
diff --git a/target/ppc/cpu.h
An SPR can be either per-thread, per-core, or per-LPAR. Per-LPAR means
per-thread or per-core, depending on 1LPAR mode.
Signed-off-by: Nicholas Piggin
---
target/ppc/spr_common.h | 2 ++
target/ppc/translate.c | 28
2 files changed, 30 insertions(+)
diff --git
The DECAR SPR is 32-bits width.
Signed-off-by: Nicholas Piggin
---
target/ppc/cpu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index ee01415c32..927721d49a 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
msgsnd has a broadcast mode that sends hypervisor doorbells to all
threads belonging to the same core as the target. A "subcore" mode
sends to all or one thread depending on 1LPAR mode.
Signed-off-by: Nicholas Piggin
---
target/ppc/cpu.h | 6 +-
target/ppc/helper.h
attn is an implementation-specific instruction that on POWER (and G5/
970) can be enabled with a HID bit (disabled = illegal), and executing
it causes the host processor to stop and the service processor to be
notified. Generally used for debugging.
Implement attn and make it checkstop the
>From the Freescale PowerPC Architecture Primer:
Alternate time base APU. This APU, implemented on the e500v2, defines
a 64-bit time base counter that differs from the PowerPC defined time
base in that it is not writable and counts at a different, and
typically much higher, frequency. The
This implements the POWER SPRC/SPRD SPRs, and SCRATCH0-7 registers that
can be accessed via these indirect SPRs.
SCRATCH registers only provide storage, but they are used by firmware
for low level crash and progress data, so this implementation logs
writes to the registers to help with analysis.
PTCR is a per-core register.
Signed-off-by: Nicholas Piggin
---
target/ppc/misc_helper.c | 16 ++--
target/ppc/translate.c | 4
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/target/ppc/misc_helper.c b/target/ppc/misc_helper.c
index 6f419c9346..a67930d031
This is a bunch of instruction and register additions, improved SMT
support, etc. for TCG.
Since v1:
- Not reposting the trivial memop patches that got reviews.
- Fix checkstop reason printing (Richard)
- Fix the attn instruction checks (Richard)
- Don't allocate tcg temp before SMT and
checkstop state does not halt the system, interrupts continue to be
serviced, and other CPUs run. Make it stop the machine with
qemu_system_guest_panicked.
Signed-off-by: Nicholas Piggin
---
target/ppc/excp_helper.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff
> -Original Message-
> From: tech-server-...@lists.riscv.org On
> Behalf Of Andrew Jones
> Sent: Monday, May 20, 2024 11:56 PM
> To: Wu, Fei2
> Cc: pbonz...@redhat.com; pal...@dabbelt.com; alistair.fran...@wdc.com;
> Meng, Bin ; liwei1...@gmail.com;
> dbarb...@ventanamicro.com;
GED interface is used by many hotplug events like memory hotplug, NVDIMM hotplug
and non-hotplug events like system power down event. Each of these can be
selected using a bit in the 32 bit GED IO interface. A bit has been reserved for
the CPU hotplug event.
Signed-off-by: Salil Mehta
Add common function to help unregister the GDB register space. This shall be
done in context to the CPU unrealization.
Signed-off-by: Salil Mehta
Tested-by: Vishnu Pajjuri
Reviewed-by: Gavin Shan
Tested-by: Xianglai Li
Tested-by: Miguel Luis
Reviewed-by: Shaoqin Huang
Reviewed-by: Vishnu
Virtual CPU Hot-unplug leads to unrealization of a CPU object. This also
involves destruction of the CPU AddressSpace. Add common function to help
destroy the CPU AddressSpace.
Signed-off-by: Salil Mehta
Tested-by: Vishnu Pajjuri
Reviewed-by: Gavin Shan
Tested-by: Xianglai Li
Tested-by:
CPUs Control device(\\_SB.PCI0) register interface for the x86 arch is IO port
based and existing CPUs AML code assumes _CRS objects would evaluate to a system
resource which describes IO Port address. But on ARM arch CPUs control
device(\\_SB.PRES) register interface is memory-mapped hence _CRS
OSPM evaluates _EVT method to map the event. The CPU hotplug event eventually
results in start of the CPU scan. Scan figures out the CPU and the kind of
event(plug/unplug) and notifies it back to the guest. Update the GED AML _EVT
method with the call to \\_SB.CPUS.CSCN
Also, macro
CPU ctrl-dev MMIO region length could be used in ACPI GED and various other
architecture specific places. Move ACPI_CPU_HOTPLUG_REG_LEN macro to more
appropriate common header file.
Signed-off-by: Salil Mehta
Reviewed-by: Alex Bennée
Reviewed-by: Jonathan Cameron
Reviewed-by: Gavin Shan
ACPI GED (as described in the ACPI 6.4 spec) uses an interrupt listed in the
_CRS object of GED to intimate OSPM about an event. Later then demultiplexes the
notified event by evaluating ACPI _EVT method to know the type of event. Use
ACPI GED to also notify the guest kernel about any CPU
KVM vCPU creation is done once during the vCPU realization when Qemu vCPU thread
is spawned. This is common to all the architectures as of now.
Hot-unplug of vCPU results in destruction of the vCPU object in QOM but the
corresponding KVM vCPU object in the Host KVM is not destroyed as KVM doesn't
Virtual CPU hotplug support is being added across various architectures[1][3].
This series adds various code bits common across all architectures:
1. vCPU creation and Parking code refactor [Patch 1]
2. Update ACPI GED framework to support vCPU Hotplug [Patch 2,3]
3. ACPI CPUs AML code change
From: Cord Amfmgm
This changes the way the ohci emulation handles a Transfer Descriptor with
"Current Buffer Pointer" set to "Buffer End" + 1.
The OHCI spec 4.3.1.2 Table 4-2 allows td.cbp to be one byte more than td.be
to signal the buffer has zero length. Currently qemu only accepts
On Mon, May 20, 2024 at 6:24 PM David Hubbard wrote:
> From: Cord Amfmgm
>
> This changes the way the ohci emulation handles a Transfer Descriptor with
> "Current Buffer Pointer" set to "Buffer End" + 1.
>
Please disregard, this patch is no different from the previous one sent a
couple weeks
From: Cord Amfmgm
This changes the way the ohci emulation handles a Transfer Descriptor with
"Current Buffer Pointer" set to "Buffer End" + 1.
The OHCI spec 4.3.1.2 Table 4-2 allows td.cbp to be one byte more than td.be
to signal the buffer has zero length. Currently qemu only accepts
Steven Sistare writes:
> Hi Peter, Hi Fabiano,
>Will you have time to review the migration guts of this series any time
> soon?
> In particular:
>
> [PATCH V1 05/26] migration: precreate vmstate
> [PATCH V1 06/26] migration: precreate vmstate for exec
> [PATCH V1 12/26] migration: vmstate
On Mon, May 20, 2024 at 12:05 PM Peter Maydell
wrote:
> On Tue, 6 Feb 2024 at 13:25, Cord Amfmgm wrote:
> >
> > This changes the ohci validation to not assert if invalid
> > data is fed to the ohci controller. The poc suggested in
> > https://bugs.launchpad.net/qemu/+bug/1907042
> > and then
Fiona Ebner writes:
> Migration from an 8.2 or 9.0 binary to an 8.1 binary with machine
> version 8.1 can fail with:
>
>> kvm: Features 0x1c0010130afffa7 unsupported. Allowed features: 0x10179bfffe7
>> kvm: Failed to load virtio-net:virtio
>> kvm: error while loading state for instance 0x0 of
On Mon, May 20, 2024 at 11:55 AM Peter Maydell
wrote:
> On Thu, 9 May 2024 at 01:30, David Hubbard wrote:
> >
> > From: Cord Amfmgm
> >
> > This changes the ohci validation to not assert if invalid data is fed to
> the
> > ohci controller. The poc in
pe", "memory");
if (ms->numa_state && ms->numa_state->num_nodes) {
---
base-commit: 85ef20f1673feaa083f4acab8cf054df77b0dbed
change-id: 20240520-loongarch-fdt-memnode-e36c01ae9b6e
Best regards,
--
Jiaxun Yang
-- Forwarded message -
De: Marcos Jean Sampaio
Date: sáb., 18 de mai. de 2024 às 18:02
Subject: spapr-vlan hotplug
To: ,
Hello guys,
First, I would like to thank you for making this software possible! Many
thanks!
I just installed and ran AIX and PowerHA on QEMU successfully
On 5/20/24 15:51, Björn Töpel wrote:
Daniel/David,
Daniel Henrique Barboza writes:
On 5/18/24 16:50, David Hildenbrand wrote:
Hi,
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 4fdb66052587..16c2bdbfe6b6 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -53,6 +53,8 @@
> -Original Message-
> From: Anton Johansson
> Sent: Friday, May 10, 2024 9:53 AM
> To: qemu-devel@nongnu.org
> Cc: a...@rev.ng; ltaylorsimp...@gmail.com; bc...@quicinc.com
> Subject: [PATCH v2 3/4] target/hexagon: idef-parser fix leak of init_list
>
> gen_inst_init_args() is called
> -Original Message-
> From: Anton Johansson
> Sent: Friday, May 10, 2024 9:53 AM
> To: qemu-devel@nongnu.org
> Cc: a...@rev.ng; ltaylorsimp...@gmail.com; bc...@quicinc.com
> Subject: [PATCH v2 4/4] target/hexagon: idef-parser simplify predicate
init
>
> Only predicate instruction
> -Original Message-
> From: Matheus Tavares Bernardino
> Sent: Monday, May 20, 2024 10:53 AM
> To: qemu-devel@nongnu.org
> Cc: ltaylorsimp...@gmail.com; sidn...@quicinc.com; bc...@quicinc.com;
> richard.hender...@linaro.org; a...@rev.ng; a...@rev.ng
> Subject: [PATCH] Hexagon: fix HVX
On 5/20/24 15:33, Björn Töpel wrote:
Daniel,
Thanks for taking a look!
Daniel Henrique Barboza writes:
Hi Björj,
On 5/14/24 08:06, Björn Töpel wrote:
From: Björn Töpel
Virtio-based memory devices allows for dynamic resizing of virtual
machine memory, and requires proper hotplugging
Daniel/David,
Daniel Henrique Barboza writes:
> On 5/18/24 16:50, David Hildenbrand wrote:
>>
>> Hi,
>>
>>
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 4fdb66052587..16c2bdbfe6b6 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -53,6 +53,8 @@
Philippe, Peter,
Thank you for the comments. I am not even sure what the semantics of
putting a breakpoint or watchpoint
on device regions are supposed to be. I would imagine it is
architecture-specific as to whether this is even allowed.
It appears for example, that armv8-a allows
Daniel,
Thanks for taking a look!
Daniel Henrique Barboza writes:
> Hi Björj,
>
> On 5/14/24 08:06, Björn Töpel wrote:
>> From: Björn Töpel
>>
>> Virtio-based memory devices allows for dynamic resizing of virtual
>> machine memory, and requires proper hotplugging (add/remove) support
>> to
Hi Peter, Hi Fabiano,
Will you have time to review the migration guts of this series any time soon?
In particular:
[PATCH V1 05/26] migration: precreate vmstate
[PATCH V1 06/26] migration: precreate vmstate for exec
[PATCH V1 12/26] migration: vmstate factory object
[PATCH V1 18/26] migration:
On Mon, May 20, 2024 at 05:50:12PM +0100, Jonathan Cameron wrote:
> On Wed, 1 May 2024 15:29:31 -0700
> fan wrote:
>
> > From 873f59ec06c38645768ada452d9b18920a34723e Mon Sep 17 00:00:00 2001
> > From: Fan Ni
> > Date: Tue, 20 Feb 2024 09:48:31 -0800
> > Subject: [PATCH] hw/cxl/events: Add qmp
cpu_exec_realizefn which calls the accel-specific realizefn may expand
features. e.g., some accel-specific options may require extra features
to be enabled, and it's appropriate to expand these features in accel-
specific realizefn.
One such example is the cpu-pm option, which may add
Currently, if running "-overcommit cpu-pm=on" on hosts that don't
have MWAIT support, the MWAIT/MONITOR feature is advertised to the
guest and executing MWAIT/MONITOR on the guest triggers #UD.
Zide Chen (3):
vl: Allow multiple -overcommit commands
target/i386: call cpu_exec_realizefn before
Both cpu-pm and mem-lock are related to system resource overcommit, but
they are separate from each other, in terms of how they are realized,
and of course, they are applied to different system resources.
It's tempting to use separate command lines to specify their behavior.
e.g., in the
It seems not a good idea to expand features in host_cpu_realizefn,
which is for host CPU only. Additionally, cpu-pm option is KVM
specific, and it's cleaner to put it in kvm_cpu_realizefn(), together
with the WAITPKG code.
Fixes: f5cc5a5c1686 ("i386: split cpu accelerators from cpu.c, using
On 5/10/24 07:47, Frank Chang wrote:
Hi Daniel,
Daniel Henrique Barboza 於 2024年5月8日 週三 下午8:42寫道：
On 5/7/24 12:44, Peter Maydell wrote:
On Fri, 3 May 2024 at 13:43, Daniel Henrique Barboza
wrote:
Hi,
In this RFC I want to check with Gerd and others if it's ok to add a PCI
id for the
On Wed, 15 May 2024 at 13:49, Philippe Mathieu-Daudé wrote:
>
> Hi Perry,
>
> On 14/5/24 01:33, Perry Hung wrote:
> > Writes from GDB to memory-mapped IO regions are currently silently
> > dropped. cpu_memory_rw_debug() calls address_space_write_rom(), which
> > calls
On Tue, 6 Feb 2024 at 13:25, Cord Amfmgm wrote:
>
> This changes the ohci validation to not assert if invalid
> data is fed to the ohci controller. The poc suggested in
> https://bugs.launchpad.net/qemu/+bug/1907042
> and then migrated to bug #303 does the following to
> feed it a SETUP pid and
On Fri, May 17, 2024 at 9:14 AM Daniel P. Berrangé wrote:
>
> On Thu, May 16, 2024 at 07:24:04PM +0100, Daniel P. Berrangé wrote:
> > On Thu, May 16, 2024 at 05:52:43PM +0100, Camilla Conte wrote:
> > > Enables caching from the qemu-project repository.
> > >
> > > Uses a dedicated "$NAME-cache"
On Thu, 9 May 2024 at 01:30, David Hubbard wrote:
>
> From: Cord Amfmgm
>
> This changes the ohci validation to not assert if invalid data is fed to the
> ohci controller. The poc in https://bugs.launchpad.net/qemu/+bug/1907042 and
> migrated to bug #303 does the following to feed it a SETUP pid
On Wed, 1 May 2024 15:29:31 -0700
fan wrote:
> From 873f59ec06c38645768ada452d9b18920a34723e Mon Sep 17 00:00:00 2001
> From: Fan Ni
> Date: Tue, 20 Feb 2024 09:48:31 -0800
> Subject: [PATCH] hw/cxl/events: Add qmp interfaces to add/release dynamic
> capacity extents
> Status: RO
>
On 5/10/24 08:14, Frank Chang wrote:
Hi Daniel,
Thanks for the upstream work.
Sorry that it took a while for me to review the patchset.
Please let me know if you need any help from us to update the IOMMU model.
We would like to see it merged for QEMU 9.1.0.
Thanks for the help in the
On 5/20/2024 10:53 AM, Matheus Tavares Bernardino wrote:
At 09a7e7db0f (Hexagon (target/hexagon) Remove uses of
op_regs_generated.h.inc, 2024-03-06), we've changed the logic of
check_new_value() to use the new pre-calculated
packet->insn[...].dest_idx instead of calculating the index on the
Hi Frank,
On 5/16/24 04:13, Frank Chang wrote:
On Mon, May 13, 2024 at 8:37 PM Daniel Henrique Barboza mailto:dbarb...@ventanamicro.com>> wrote:
Hi Frank,
On 5/8/24 08:15, Daniel Henrique Barboza wrote:
> Hi Frank,
>
> I'll reply with that I've done so far. Still
On Tue, Mar 12, 2024 at 09:52:21PM GMT, Fei Wu wrote:
> The RISC-V Server Platform specification[1] defines a standardized set
> of hardware and software capabilities, that portable system software,
> such as OS and hypervisors can rely on being present in a RISC-V server
> platform.
>
> A
At 09a7e7db0f (Hexagon (target/hexagon) Remove uses of
op_regs_generated.h.inc, 2024-03-06), we've changed the logic of
check_new_value() to use the new pre-calculated
packet->insn[...].dest_idx instead of calculating the index on the fly
using opcode_reginfo[...]. The dest_idx index is calculated
On Mon, 13 May 2024 at 12:35, Alex Bennée wrote:
>
> We actually had the stubs to implement this. The main pain is getting
> the binary name into the program so we can validate the result.
Could you write the commit message so that it makes sense
without reading the Subject line, please ?
>
On Mon, 13 May 2024 at 12:35, Alex Bennée wrote:
>
> We shouldn't use for our own implementation. Also the base
> types we need live in as doesn't exist for the
> bare metal compilers.
>
> Signed-off-by: Alex Bennée
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Mon, 13 May 2024 at 12:35, Alex Bennée wrote:
>
> It's a pain when you come back to a code base you haven't touched in a
> while and realise whatever indent settings you were using having
> carried over. Add an editorconfig and be done with it.
>
> Signed-off-by: Alex Bennée
> ---
>
Sure! Thanks for the update.
~ Tanmay
On Mon, 20 May, 2024, 6:32 pm Peter Maydell,
wrote:
> On Wed, 8 May 2024 at 09:15, Tanmay Patil
> wrote:
> >
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/373
> >
> > Files changed:
> > - hw/arm/boot.c
> > -
On Tue, 7 May 2024 at 19:59, Inès Varhol wrote:
>
> Among implemented STM32L4x5 devices, USART, GPIO and SYSCFG
> have a clock source, but none has a corresponding test in QEMU.
>
> This patch makes sure that all 3 devices create a clock,
> have a QOM property to access the clock frequency,
> and
On Wed, 8 May 2024 at 22:27, Philippe Mathieu-Daudé wrote:
>
> On 8/5/24 19:46, Peter Maydell wrote:
> > On Wed, 8 May 2024 at 15:13, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Expose the clock frequency via the QOM 'freq-hz' property,
> >> as it might be useful for QTests.
> >>
> >> HMP
On Sun, 12 May 2024 at 11:20, Inès Varhol wrote:
>
> Up until now, the EXTI implementation had 16 inbound GPIOs connected to
> the 16 outbound GPIOs of STM32L4x5 SYSCFG.
> The EXTI actually handles 40 lines (namely 5 from STM32L4x5 USART
> devices which are already implemented in QEMU).
> In
On Sun, 12 May 2024 at 11:20, Inès Varhol wrote:
>
> The USART devices were previously connecting their outbound IRQs
> directly to the CPU because the EXTI wasn't handling direct lines
> interrupts.
> Now the USART connects to the EXTI inbound GPIOs, and the EXTI connects
> its IRQs to the CPU.
On Sun, 12 May 2024 at 11:20, Inès Varhol wrote:
>
> The previous implementation for EXTI interrupts only handled
> "configurable" interrupts, like those originating from STM32L4x5 SYSCFG
> (the only device currently connected to the EXTI up until now).
> In order to connect STM32L4x5 USART to
On Sun, 12 May 2024 at 10:00, Rayhan Faizel wrote:
>
> None of the RPi boards have ADC on-board. In real life, an external ADC chip
> is required to operate on analog signals.
>
> Signed-off-by: Rayhan Faizel
Applied to target-arm.next, thanks.
-- PMM
The board list in target-arm.rst is supposed to be in alphabetical
order by the title text of each file (which is not the same as
alphabetical order by filename). A few items had got out of order;
correct them.
The entry for
"Facebook Yosemite v3.5 Platform and CraterLake Server (fby35)"
remains
Add support for the VIRTIO_F_IN_ORDER feature across a variety of vhost
devices.
The inclusion of VIRTIO_F_IN_ORDER in the feature bits arrays for these
devices ensures that the backend is capable of offering and providing
support for this feature, and that it can be disabled if the backend
does
On Tue, Mar 12, 2024 at 09:52:20PM GMT, Wu, Fei2 wrote:
> The harts requirements of RISC-V server platform [1] require RVA23 ISA
> profile support, plus Sv48, Svadu, H, Sscofmpf etc. This patch provides
> a virt CPU type (rvsp-ref) as compliant as possible.
We should add the RVA23 profile cpu
On Tue, 7 May 2024 at 14:04, Sebastian Huber
wrote:
>
> The Zynq 7000 SoCs contain two Arm Cortex-A9 MPCore (the Zynq 7000S have only
> one core). Add support for up to two simulated cores.
>
> Signed-off-by: Sebastian Huber
> ---
> hw/arm/xilinx_zynq.c | 42
Hi Mostafa,
On 4/29/24 05:24, Mostafa Saleh wrote:
> SMMUv3 OAS is hardcoded to 44 bits, for nested configurations that
is currently hardcoded in the code.
> can be a problem as stage-2 might be shared with the CPU which might
> have different PARANGE, and according to SMMU manual ARM IHI 0070F.b:
On Tue, 7 May 2024 at 14:04, Sebastian Huber
wrote:
>
> The Zynq 7000 SoCs contain a CoreLink L2C-310 cache controller. Add the
> corresponding Qemu device to the xilinx-zynq-a9 machine.
>
> Signed-off-by: Sebastian Huber
> ---
> hw/arm/xilinx_zynq.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
On Tue, 7 May 2024 at 14:00, Sebastian Huber
wrote:
>
> According to the GICv2 specification section 4.3.12, "Interrupt Processor
> Targets Registers, GICD_ITARGETSRn":
>
> "Any change to a CPU targets field value:
> [...]
> * Has an effect on any pending interrupts. This means:
> - adding a
On 4/29/24 05:23, Mostafa Saleh wrote:
> QEMU doesn's support memory attributes, so FWB is NOP, this
> might change in the future if memory attributre would be supported.
if mem attributes get supported
>
> Signed-off-by: Mostafa Saleh
> ---
> hw/arm/smmuv3.c | 8
> 1 file changed, 8
On Tue, 7 May 2024 at 14:00, Sebastian Huber
wrote:
>
> According to the GICv2 specification section 4.3.7, "Interrupt Set-Pending
> Registers, GICD_ISPENDRn":
>
> "In a multiprocessor implementation, GICD_ISPENDR0 is banked for each
> connected
> processor. This register holds the Set-pending
* Dr. David Alan Gilbert (d...@treblig.org) wrote:
> This struct is unused since Peter's
> Commit b8ae597f0e6d ("linux-user/sparc: Fix errors in target_ucontext
> structures")
>
> However, hmm, I'm a bit confused since that commit modifies the
> structure and then removes it, was that
Hi Mostafa,
On 4/29/24 05:23, Mostafa Saleh wrote:
> Everything is in place, add the last missing bits:
> - Handle fault checking according to the actual PTW event and not the
> the translation stage.
missing the "why". Can't it be moved in a separate patch?
> - Consolidate parsing of STE cfg
Add VIRTIO_F_IN_ORDER feature support in virtqueue_split_pop and
virtqueue_packed_pop.
VirtQueueElements popped from the available/descritpor ring are added to
the VirtQueue's used_elems array in-order and in the same fashion as
they would be added the used and descriptor rings, respectively.
Add VIRTIO_F_IN_ORDER feature support for the virtqueue_flush operation.
The goal of the virtqueue_ordered_flush operation when the
VIRTIO_F_IN_ORDER feature has been negotiated is to write elements to
the used/descriptor ring in-order and then update used_idx.
The function iterates through the
On Wed, 8 May 2024 at 09:15, Tanmay Patil wrote:
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/373
>
> Files changed:
> - hw/arm/boot.c
> - hw/char/omap_uart.c
> - hw/gpio/zaurus.c
> - hw/input/tsc2005.c
>
> Signed-off-by: Tanmay Patil
Thanks for
The goal of these patches is to add support to a variety of virtio and
vhost devices for the VIRTIO_F_IN_ORDER transport feature. This feature
indicates that all buffers are used by the device in the same order in
which they were made available by the driver.
These patches attempt to implement a
Extend the virtio device property definitions to include the
VIRTIO_F_IN_ORDER feature.
The default state of this feature is disabled, allowing it to be
explicitly enabled where it's supported.
Tested-by: Lei Yang
Acked-by: Eugenio Pérez
Signed-off-by: Jonah Palmer
---
Add VIRTIO_F_IN_ORDER feature support for the virtqueue_fill operation.
The goal of the virtqueue_ordered_fill operation when the
VIRTIO_F_IN_ORDER feature has been negotiated is to search for this
now-used element, set its length, and mark the element as filled in
the VirtQueue's used_elems
Add the boolean 'in_order_filled' member to the VirtQueueElement structure.
The use of this boolean will signify whether the element has been processed
and is ready to be flushed (so long as the element is in-order). This
boolean is used to support the VIRTIO_F_IN_ORDER feature.
Tested-by: Lei
This series contains few miscellaneous fixes related to Virtual IRQs
and related code. The first patch changes CSR mask widths to 64bit
as AIA introduces half CSRs in case of 32bit systems.
Second patch fixes guest and core local IRQ overlap. Qemu creates
a single IRQ range which is shared
AIA extends the width of all IRQ CSRs to 64bit even
in 32bit systems by adding missing half CSRs.
This seems to be missed while adding support for
virtual IRQs. The whole logic seems to be correct
except the width of the masks.
Fixes: 1697837ed9 ("target/riscv: Add M-mode virtual interrupt and
Qemu maps IRQs 0:15 for core interrupts and 16 onward for
guest interrupts which are later translated to hgiep in
`riscv_cpu_set_irq()` function.
With virtual IRQ support added, software now can fully
use the whole local interrupt range without any actual
hardware attached.
This change moves the
On Wed, 8 May 2024 at 15:35, Philippe Mathieu-Daudé wrote:
>
> Check the function index is in range and use an unsigned
> variable to avoid the following warning with GCC 13.2.0:
>
> [666/5358] Compiling C object libcommon.fa.p/hw_input_tsc2005.c.o
> hw/input/tsc2005.c: In function
1 - 100 of 141 matches
Mail list logo
