On Sat May 18, 2024 at 8:48 PM AEST, Richard Henderson wrote:
> On 5/17/24 14:48, Nicholas Piggin wrote:
> > On Tue Apr 23, 2024 at 4:32 PM AEST, Chinmay Rath wrote:
> >> Moving the below instructions to decodetree specification :
> >>
> >>divd[u, e, eu][o][.]: XO-form
> >>mod{sd, ud}
On Sat May 18, 2024 at 9:05 PM AEST, Richard Henderson wrote:
> On 5/18/24 11:31, Nicholas Piggin wrote:
> > @@ -425,17 +426,17 @@ static void powerpc_set_excp_state(PowerPCCPU *cpu,
> > target_ulong vector,
> > env->reserve_addr = -1;
> > }
> >
> > -static void powerpc_mcheck_checkstop
On Sat May 18, 2024 at 9:07 PM AEST, Richard Henderson wrote:
> On 5/18/24 11:31, Nicholas Piggin wrote:
> > +static void gen_attn(DisasContext *ctx)
> > +{
> > +#if defined(CONFIG_USER_ONLY)
> > +GEN_PRIV(ctx);
> > +#else
> > +gen_helper_attn(tcg_env);
> > +#endif
> > +}
>
> You forgot to
On Sat May 18, 2024 at 9:26 PM AEST, Richard Henderson wrote:
> On 5/18/24 11:31, Nicholas Piggin wrote:
> > +void spr_core_write_generic32(DisasContext *ctx, int sprn, int gprn)
> > +{
> > +TCGv t0 = tcg_temp_new();
> > +if (!(ctx->flags & POWERPC_FLAG_SMT)) {
> > +spr_write_generi
On 5/18/24 15:26, Nicholas Piggin wrote:
The ibm,pi-features property has a bit to say whether or not
msgsndp should be used. Linux checks if it is being run under
KVM and avoids msgsndp anyway, but it would be preferable to
rely on this bit.
Signed-off-by: Nicholas Piggin
Reviewed-by: Har
>-Original Message-
>From: Liu, Yi L
>Subject: RE: [PATCH] intel_iommu: Use the latest fault reasons defined by
>spec
>
>> From: Duan, Zhenzhong
>> Sent: Monday, May 20, 2024 11:41 AM
>>
>>
>>
>> >-Original Message-
>> >From: Jason Wang
>> >Sent: Monday, May 20, 2024 8:44 AM
>>
On Mon May 20, 2024 at 7:06 AM AEST, Salil Mehta wrote:
> 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
> correspond
On Mon May 20, 2024 at 7:06 AM AEST, Salil Mehta wrote:
> 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.
Patches 6,7 seem okay to me. I would like to see a series w
Hi Mostafa,
On 5/16/24 17:20, Mostafa Saleh wrote:
> Hi Eric,
>
> On Wed, May 15, 2024 at 03:48:05PM +0200, Eric Auger wrote:
>> Hi Mostafa,
>>
>> On 4/29/24 05:23, Mostafa Saleh wrote:
>>> This patch adds support for nested(combined) TLB entries.
>> space between nested and (.
> Will do.
>>> The m
Hi Mostafa,
On 4/29/24 05:23, Mostafa Saleh wrote:
> In the previous patch, comine_tlb() was added which combines 2 TLB
> entries into one, which chooses the granule and level from the
> smallest entry.
>
> This means that a nested translation, an entry can be cached with the
> granule of stage-2
Hi,
Per Yi's suggestion, we sent some trivial changes separately so that
stage-1 emulation patchset can be simpler and more focused.
Thanks
Zhenzhong
Changelog:
v2:
- update version to 3.0 (Jason, Yi)
- s/pasidt/Pasid table/ (Clement, Yi)
Yu Zhang (1):
intel_iommu: Update version to 3.0 and a
From: Yu Zhang
The scalable mode was introduced in VTD spec 3.0, now that
the scalable mode is already supported, bump version to 3.0.
In spec 3.0 some more detailed fault reasons are defined
for scalable mode. So introduce them into emulation code,
see spec section 7.1.2 for details.
Guest ker
When guest configures Nested Translation(011b) or First-stage Translation only
(001b), type check passed unaccurately.
Fails the type check in those cases as their simulation isn't supported yet.
Fixes: fb43cf739e1 ("intel_iommu: scalable mode emulation")
Suggested-by: Yi Liu
Signed-off-by: Zhen
On Fri, May 17, 2024 at 10:08:08PM -0500, Eric Blake wrote:
> Adding a bit of self-review (in case you want to amend this before
> pushing, instead of waiting for me to get back online),
>
> On Fri, May 17, 2024 at 09:50:15PM GMT, Eric Blake wrote:
> > Prevent regressions when using NBD with TLS i
On Mon, 20 May 2024, 09:18 Nicholas Piggin, wrote:
> > That's another option, yes. The decodetree script will take multiple
> input files to
> > produce one output, so you could separate the insns by base vs 64-bit.
>
> Thinking about it a bit more, I guess the downside is that you
> would usual
Hi Mostafa,
On 4/29/24 05:23, Mostafa Saleh wrote:
> When nested translation is requested, do the following:
>
> - Translate stage-1 IPA using stage-2 to a physical address.
stage-1 table address IPA into PA through S2 stage
> - Translate stage-1 table walks using stage-2.
output of S1 stage (IPA
On 5/17/24 09:30, Nicholas Piggin wrote:
On Thu May 16, 2024 at 2:31 PM AEST, Harsh Prateek Bora wrote:
Hi Nick,
On 5/14/24 08:39, Nicholas Piggin wrote:
On Tue Apr 23, 2024 at 4:30 PM AEST, Harsh Prateek Bora wrote:
+ qemu-devel
On 4/23/24 11:40, Harsh Prateek Bora wrote:
On ppc64, the
The macio device has a container mmio region that embeds several other
devices. Some of these devices are not implemented but because of the
container region, the unassigned memory traces don't catch accesses to
these. To help debugging, add an unimplemented-device covering the
container region to
Hi Mostafa,
On 4/29/24 05:23, Mostafa Saleh wrote:
> Some commands need rework for nesting, as they used to assume S1
> and S2 are mutually exclusive:
>
> - CMD_TLBI_NH_ASID: Consider VMID if stage-2 is supported
> - CMD_TLBI_NH_ALL: Consider VMID if stage-2 is supported, otherwise
> invalidate
Hi Paolo,
As Daniel suggested, could you please take a look at this series ?
Thanks,
Chao
On 2024-04-16 17:25, Daniel Henrique Barboza wrote:
>
> On 4/9/24 06:43, Chao Du wrote:
> > Hi Daniel and all,
> >
> > The KVM patches have been reviewd and are in the queue.
> > https://lore.kernel.org/
This a set of misc ppc arch specific code improvements/optimizations.
Although there exists similar instances for potential improvements in
the legacy ppc code, however, that can be taken up later as well.
Harsh Prateek Bora (6):
target/ppc: use locally stored msr and avoid indirect access
tar
Historically, the registration of sprs have been inherited alongwith
every new Power arch support being added leading to a lot of code
duplication. It's time to do necessary cleanups now to avoid further
duplication with newer arch support being added.
Signed-off-by: Harsh Prateek Bora
---
targe
hreg_compute_hflags_value already stores msr locally to be used in most
of the logic in the routine however some instances are still using
env->msr which is unnecessary. Use locally stored value as available.
Signed-off-by: Harsh Prateek Bora
---
target/ppc/helper_regs.c | 4 ++--
1 file changed
Currently, p9 exception handling has multiple if-condition checks where
it does an indirect access to pending_interrupts via env. Cache the
value during entry and reuse later to avoid multiple indirect accesses.
Signed-off-by: Harsh Prateek Bora
---
target/ppc/excp_helper.c | 39
Cache env->spr[SPR_POWER_MMCR0] in a local variable as used in multiple
conditions to avoid multiple indirect accesses.
Signed-off-by: Harsh Prateek Bora
---
target/ppc/helper_regs.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/target/ppc/helper_regs.c b/target/pp
The second if-condition can be true only if the first one above is true.
Enclose the latter into the former to avoid un-necessary check if first
condition fails.
Signed-off-by: Harsh Prateek Bora
---
target/ppc/helper_regs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Power9/10 initialization code consists of a lot of logical OR of
various flag bits as supported by respective Power platform during its
initialization, most of which is duplicated and only selected bits are
added or removed as needed with each new platform support being added.
Remove the duplicate
Hi Mostafa,
On 4/29/24 05:23, Mostafa Saleh wrote:
> IOMMUTLBEvent only understands IOVA, for stage-2 only SMMUs keep
> the implementation, while only notify for stage-1 invalidation
> in case of nesting.
>
> Signed-off-by: Mostafa Saleh
> ---
> hw/arm/smmuv3.c | 23 +++
>
Hi Nick,
> From: Nicholas Piggin
> Sent: Monday, May 20, 2024 9:04 AM
> To: Salil Mehta ; qemu-devel@nongnu.org;
> qemu-...@nongnu.org
>
> On Mon May 20, 2024 at 7:06 AM AEST, Salil Mehta wrote:
> > KVM vCPU creation is done once during the vCPU realization when Qemu
> > vCPU thread is s
> From: Nicholas Piggin
> Sent: Monday, May 20, 2024 9:19 AM
>
> On Mon May 20, 2024 at 7:06 AM AEST, Salil Mehta wrote:
> > 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 th
On Mon, 20 May 2024, Harsh Prateek Bora wrote:
Cache env->spr[SPR_POWER_MMCR0] in a local variable as used in multiple
conditions to avoid multiple indirect accesses.
Signed-off-by: Harsh Prateek Bora
---
target/ppc/helper_regs.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
di
> From: Nicholas Piggin
> Sent: Monday, May 20, 2024 9:04 AM
>
> On Mon May 20, 2024 at 7:06 AM AEST, Salil Mehta wrote:
> > 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-unpl
On Mon, 20 May 2024, Harsh Prateek Bora wrote:
The second if-condition can be true only if the first one above is true.
Enclose the latter into the former to avoid un-necessary check if first
condition fails.
Signed-off-by: Harsh Prateek Bora
Reviewed-by: BALATON Zoltan
---
target/ppc/help
On Mon, 20 May 2024, Harsh Prateek Bora wrote:
Currently, p9 exception handling has multiple if-condition checks where
it does an indirect access to pending_interrupts via env. Cache the
value during entry and reuse later to avoid multiple indirect accesses.
Signed-off-by: Harsh Prateek Bora
--
On Mon, 20 May 2024, BALATON Zoltan wrote:
On Mon, 20 May 2024, Harsh Prateek Bora wrote:
Currently, p9 exception handling has multiple if-condition checks where
it does an indirect access to pending_interrupts via env. Cache the
value during entry and reuse later to avoid multiple indirect acce
On Mon, 20 May 2024, Harsh Prateek Bora wrote:
Historically, the registration of sprs have been inherited alongwith
every new Power arch support being added leading to a lot of code
duplication. It's time to do necessary cleanups now to avoid further
duplication with newer arch support being adde
Am 15. Mai 2024 07:52:32 UTC schrieb Richard Henderson
:
>Read from already translated pages, or saved mmio data.
>
>Reviewed-by: Philippe Mathieu-Daudé
>Signed-off-by: Richard Henderson
>---
> include/disas/disas.h | 5 +++--
> include/exec/translator.h | 4 ++--
> include/qemu/typedefs.
On Mon, 20 May 2024, Harsh Prateek Bora wrote:
Power9/10 initialization code consists of a lot of logical OR of
various flag bits as supported by respective Power platform during its
initialization, most of which is duplicated and only selected bits are
added or removed as needed with each new pl
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 'tsc2005_ti
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 IR
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
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 between
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 Yan
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
---
include/hw/virtio/virti
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 array
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 g
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 thi
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 V
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.
Thi
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 an
* 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 intentional?
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 bi
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.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 CPU
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: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, 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 type
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 n
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
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
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 the
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:
>
> 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 order
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 exampl
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
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
> > - hw/char/omap_uart.
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
> ---
> .editorco
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:
>
> 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 ?
> inde
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 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 corresp
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 missin
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 fly
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 revie
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
> Content-Leng
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 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" ta
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 En
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 address_space_write_rom_inter
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
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
Acce
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 following
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 x
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 CPUID_EXT_M
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 i
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:
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 wo
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 watchpoint
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 @@
#inc
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 (a
> -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
> -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 argu
> -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 fo
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 @@
#i
-- 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
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
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 https://bugs.launchpad.net/qemu/+bug/1907042
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 dev
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 mig
1 - 100 of 149 matches
Mail list logo