On 09/11/2023 19:28, Philippe Mathieu-Daudé wrote:
Missing review: #10
Hi,
This series add support for (async) FIFO on the transmit path
of the PL011 UART.
Since v3:
- Document migration bits (Alex, Richard)
- Just check FIFO is not empty in pl011_xmit_fifo_state_needed (rth)
- In pl011_xmit
I think you're right, thanks.
I'll add a check for M-mode as well and I guess I'll have to rename the
function.
Any ideas on the proper and self-describing name?
Thanks
пт, 5 янв. 2024 г. в 03:46, Deepak Gupta :
> On Wed, Jan 3, 2024 at 10:59 AM Alexey Baturo
> wrote:
> > +
> > +bool riscv_cpu_
> +addr = addr << pmlen;
> +if (signext) {
> +addr = (target_long)addr >> pmlen;
> +} else {
> +addr = addr >> pmlen;
Could you please elaborate a bit more on your concern here?
I believe this code works as intended: https://godbolt.org/z/b9c7na13a
Thanks
пт, 5 янв. 20
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes t
Sure, I would do it in the next updated series.
пт, 5 янв. 2024 г. в 08:04, Alistair Francis :
> On Thu, Jan 4, 2024 at 6:33 AM Alexey Baturo
> wrote:
> >
> > From: Alexey Baturo
> >
> > Zjpm v0.8 is almost frozen and it's much simplier compared to the
> existing one:
> > The newer version does
I might be wrong here, but right now J in MISA is unused.
I think the J-letter extension is still a thing, but current extensions
like Zjpm and Zjid follow the Z ext scheme.
Do you think it should be removed?
пт, 5 янв. 2024 г. в 08:28, Alistair Francis :
> On Thu, Jan 4, 2024 at 4:58 AM Alexey
Hi All,
This is v4 series to support passthrough on Xen when dom0 is PVH.
v3->v4 changes:
* Add gsi into struct XenHostPCIDevice and use gsi number that read from gsi
sysfs if it exists, if there is no gsi sysfs, still use irq.
v2->v3 changes:
* du to changes in the implementation of the second p
On 1/5/24 06:24, Alistair Francis wrote:
On Fri, Dec 29, 2023 at 10:48 PM Heinrich Schuchardt
wrote:
For RISC-V the SMBIOS standard requires specific values of the processor
family value depending on the bitness of the CPU.
Can you provide some details of where this is described? I can't see
On Thu, Jan 4, 2024 at 5:18 PM Bin Meng wrote:
>
> Currently, the documentation outlines the process for building the
> S-mode U-Boot image using `make menuconfig` and manual actions within
> the menuconfig UI. However, this approach is fragile due to Kconfig
> options potentially changing across
On Thu, Jan 4, 2024 at 4:58 AM Alexey Baturo wrote:
>
> From: Alexey Baturo
>
> Signed-off-by: Alexey Baturo
> ---
> target/riscv/cpu.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 1e6571ce99..13389ddc55 100644
> --- a/target/r
On Fri, Dec 29, 2023 at 10:08 PM Heinrich Schuchardt
wrote:
>
> With SMBIOS support added for RISC-V we also should enable the command line
> option.
>
> Signed-off-by: Heinrich Schuchardt
Acked-by: Alistair Francis
Alistair
> ---
> v2:
> new patch
> ---
> qemu-options.hx | 2 +-
> 1
On Fri, Dec 29, 2023 at 10:48 PM Heinrich Schuchardt
wrote:
>
> For RISC-V the SMBIOS standard requires specific values of the processor
> family value depending on the bitness of the CPU.
Can you provide some details of where this is described? I can't seem to find it
Alistair
>
> Add a proces
On Thu, Jan 4, 2024 at 3:49 AM Daniel Henrique Barboza
wrote:
>
> Do the same thing we did with 'vlen' in the previous patch with 'elen'.
>
> Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.c | 44
On Tue, Dec 19, 2023 at 6:44 AM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> This version was rebased on top of Alistair's riscv-to-apply.next. A
> small tweak was needed in patch 4 due to changes in the branch.
>
> I took the chance to update linux-headers to 6.7-rc5, although the
> differences fro
On Thu, Jan 4, 2024 at 3:47 AM Daniel Henrique Barboza
wrote:
>
> The same rework did in 'priv_spec' is done for 'vext_spec'. This time is
> simpler, since we only accept one value ("v1.0") and we'll always have
> env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to
> convert st
On Sat, Dec 30, 2023 at 2:50 AM Inès Varhol
wrote:
>
> Signed-off-by: Arnaud Minier
> Signed-off-by: Inès Varhol
Acked-by: Alistair Francis
Alistair
> ---
> docs/system/arm/b-l475e-iot01a.rst | 2 +-
> hw/misc/Kconfig| 3 +
> hw/misc/meson.build| 1
On Thu, Jan 4, 2024 at 3:48 AM Daniel Henrique Barboza
wrote:
>
> Turning 'vlen' into a class property will allow its default value to be
> overwritten by cpu_init() later on, solving the issue we have now where
> CPU specific settings are getting overwritten by the default.
>
> Common validation
On Thu, Jan 4, 2024 at 6:33 AM Alexey Baturo wrote:
>
> From: Alexey Baturo
>
> Zjpm v0.8 is almost frozen and it's much simplier compared to the existing
> one:
> The newer version doesn't allow to specify custom mask or base for masking.
> Instead it allows only certain options for masking top
On Thu, Jan 4, 2024 at 4:53 AM Daniel Henrique Barboza
wrote:
>
> Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it
> that forbids 'pmp' to be changed in vendor CPUs, like we did with the
> 'mmu' option.
>
> We'll also have to manually set 'pmp = true' to generic CPUs that were
On Thu, Jan 4, 2024 at 3:43 AM Daniel Henrique Barboza
wrote:
>
> Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from
> riscv_cpu_init()") already did some of the work by making some
> cpu_init() functions to explictly enable their own 'mmu' default.
>
> The generic CPUs didn't get upda
On Thu, Jan 4, 2024 at 3:45 AM Daniel Henrique Barboza
wrote:
>
> The array is empty and can be removed.
>
> Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.c | 5 -
> target/riscv/cpu.h | 1 -
> target/riscv/kvm/kvm-
On Thu, Jan 4, 2024 at 4:56 AM Daniel Henrique Barboza
wrote:
>
> Do the same we did with 'cbom_blocksize' in the previous patch.
>
> Remove the now unused kvm_cpu_set_cbomz_blksize() setter.
>
> Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Alistair
> ---
> target/ris
On Thu, Jan 4, 2024 at 3:44 AM Daniel Henrique Barboza
wrote:
>
> After adding a KVM finalize() implementation, turn cbom_blocksize into a
> class property. Follow the same design we used with 'vlen' and 'elen'.
>
> The duplicated 'cbom_blocksize' KVM property can be removed from
> kvm_riscv_add_c
On Thu, Jan 4, 2024 at 3:46 AM Daniel Henrique Barboza
wrote:
>
> To turn cbom_blocksize and cboz_blocksize into class properties we need
> KVM specific changes.
>
> KVM is creating its own version of these options with a customized
> setter() that prevents users from picking an invalid value duri
On Thu, Jan 4, 2024 at 3:41 AM Daniel Henrique Barboza
wrote:
>
> 'priv_spec' and 'vext_spec' are two string options used as a fancy way
> of setting integers in the CPU state (cpu->env.priv_ver and
> cpu->env.vext_ver). It requires us to deal with string parsing and to
> store them in cpu_cfg.
>
On Thu, Jan 4, 2024 at 5:05 AM Daniel Henrique Barboza
wrote:
>
> Every property in riscv_cpu_options[] will be migrated to
> riscv_cpu_properties[]. This will make their default values init
> earlier, allowing cpu_init() functions to overwrite them. We'll also
> implement common getters and sette
On Thu, Jan 4, 2024 at 3:42 AM Daniel Henrique Barboza
wrote:
>
> We'll use this function in target/riscv/cpu.c to implement setters that
> won't allow vendor CPU options to be changed.
>
> Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu
On Thu, Jan 4, 2024 at 3:46 AM Daniel Henrique Barboza
wrote:
>
> user_spec, bext_spec and bext_ver aren't being used.
>
> Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.h | 1 -
> target/riscv/cpu_cfg.h | 2 --
> 2 files changed, 3
On Tue, Dec 26, 2023 at 3:29 PM Xu Lu wrote:
>
> The mcycle/minstret counter's stop flag is mistakenly updated on a copy
> on stack. Thus the counter increments even when the CY/IR bit in the
> mcountinhibit register is set. This commit corrects its behavior.
>
> Fixes: 3780e33732f88 (target/riscv
On Tue, Dec 26, 2023 at 3:29 PM Xu Lu wrote:
>
> The mcycle/minstret counter's stop flag is mistakenly updated on a copy
> on stack. Thus the counter increments even when the CY/IR bit in the
> mcountinhibit register is set. This commit corrects its behavior.
>
> Fixes: 3780e33732f88 (target/riscv
On Fri, Dec 29, 2023 at 12:08 PM Atish Patra wrote:
>
> From: Kaiwen Xue
>
> This adds the definitions for ISA extension smcntrpmf.
>
> Signed-off-by: Kaiwen Xue
> Signed-off-by: Atish Patra
> ---
> target/riscv/cpu.c | 1 -
> target/riscv/cpu.h | 6 ++
> target/riscv/cpu_bits.
On Fri, Dec 29, 2023 at 10:51 AM Atish Patra wrote:
>
> mhpmeventhX CSRs are available for RV32. The predicate function
> should check that first before checking sscofpmf extension.
>
> Fixes: 14664483457b ("target/riscv: Add sscofpmf extension support")
> Signed-off-by: Atish Patra
Reviewed-by:
On Mon, Dec 18, 2023 at 10:55 PM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> This is a merge of the two profile series:
>
> "[PATCH for-9.0 v12 00/18] riscv: rv64i/rva22u64 CPUs, RVA22U64 profile
> support"
> "[PATCH for-9.0 v2 0/8] target/riscv: implement RVA22S64 profile"
>
> I'm sending them to
On Mon, Dec 18, 2023 at 11:01 PM Daniel Henrique Barboza
wrote:
>
> Add a new profile CPU 'rva22s64' to work as an alias of
>
> -cpu rv64i,rva22s64
>
> Like the existing rva22u64 CPU already does with the RVA22U64 profile.
>
> Signed-off-by: Daniel Henrique Barboza
> Reviewed-by: Andrew Jones
R
On Mon, Dec 18, 2023 at 11:00 PM Daniel Henrique Barboza
wrote:
>
> The RVA22S64 profile consists of the following:
>
> - all mandatory extensions of RVA22U64;
> - priv spec v1.12.0;
> - satp mode sv39;
> - Ssccptr, a cache related named feature that we're assuming always
> enable since we don't
On Mon, Dec 18, 2023 at 11:00 PM Daniel Henrique Barboza
wrote:
>
> Certain S-mode profiles, like RVA22S64 and RVA23S64, mandate all the
> mandatory extensions of their respective U-mode profiles. RVA22S64
> includes all mandatory extensions of RVA22U64, and the same happens with
> RVA23 profiles.
On Thu, Jan 04, 2024 at 11:21:37AM -0300, Fabiano Rosas wrote:
> No change, just rebased on latest migration PR:
>
> [PULL 00/26] Migration 20240104 patches
> https://lore.kernel.org/r/20240104043213.431566-1-pet...@redhat.com
>
> v1:
> https://lore.kernel.org/r/20231
On Thu, Jan 04, 2024 at 05:48:18PM +0100, Philippe Mathieu-Daudé wrote:
> If there are no objections I'll queue this patch (fixing
> the typo reported by Zoltan).
Yes feel free to. Thanks,
--
Peter Xu
Introduce the target/loongarch/tcg directory. Its purpose is to hold the TCG
code that is selected by CONFIG_TCG
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Song Gao
Message-Id: <20240102020200.3462097-2-gaos...@loongson.cn>
---
target/loongarch/meson.build | 15 +---
The following changes since commit d328fef93ae757a0dd65ed786a4086e27952eef3:
Merge tag 'pull-20231230' of https://gitlab.com/rth7680/qemu into staging
(2024-01-04 10:23:34 +)
are available in the Git repository at:
https://gitlab.com/gaosong/qemu.git tags/pull-loongarch-20240105
for yo
gdbstub.c is not specific to TCG and can be used by
other accelerators, such as KVM accelerator
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Song Gao
Message-Id: <20240102020200.3462097-1-gaos...@loongson.cn>
---
target/loongarch/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 delet
> --- a/target/riscv/vector_helper.c
> +++ b/target/riscv/vector_helper.c
> @@ -94,6 +94,18 @@ static inline uint32_t vext_max_elems(uint32_t desc,
> uint32_t log2_esz)
>
> static inline target_ulong adjust_addr(CPURISCVState *env, target_ulong addr)
> {
> +RISCVPmPmm pmm = riscv_pm_get_pmm(
On Wed, Jan 3, 2024 at 10:59 AM Alexey Baturo wrote:
> +
> +bool riscv_cpu_bare_mode(CPURISCVState *env)
> +{
> +int satp_mode = 0;
> +#ifndef CONFIG_USER_ONLY
> +if (riscv_cpu_mxl(env) == MXL_RV32) {
> +satp_mode = get_field(env->satp, SATP32_MODE);
> +} else {
> +satp
On Mon, Dec 18, 2023 at 10:56 PM Daniel Henrique Barboza
wrote:
>
> 'satp_mode' is a requirement for supervisor profiles like RVA22S64.
> User-mode/application profiles like RVA22U64 doesn't care.
>
> Add 'satp_mode' to the profile description. If a profile requires it,
> set it during cpu_set_pro
On Mon, Dec 18, 2023 at 11:01 PM Daniel Henrique Barboza
wrote:
>
> Next patch will need to retrieve if a given RISCVCPU is 32 or 64 bit.
> The existing helper riscv_is_32bit() (hw/riscv/boot.c) will always check
> the first CPU of a given hart array, not any given CPU.
>
> Create a helper to retr
On Mon, Dec 18, 2023 at 10:56 PM Daniel Henrique Barboza
wrote:
>
> Profiles will need to validate satp_mode during their own finalize
> methods. This will occur inside riscv_tcg_cpu_finalize_features() for
> TCG. Given that satp_mode does not have any pre-req from the accelerator
> finalize() met
On Tue, Dec 19, 2023 at 12:23 AM Daniel Henrique Barboza
wrote:
>
> Some profiles, like RVA22S64, has a priv_spec requirement.
>
> Make this requirement explicit for all profiles. We'll validate this
> requirement finalize() time and, in case the user chooses an
> incompatible priv_spec while acti
On Mon, Dec 18, 2023 at 10:57 PM Daniel Henrique Barboza
wrote:
>
> 'svade' is a RVA22S64 profile requirement, a profile we're going to add
> shortly. It is a named feature (i.e. not a formal extension, not defined
> in riscv,isa DT at this moment) defined in [1] as:
>
> "Page-fault exceptions are
On Fri, Jan 5, 2024 at 12:12 AM Philippe Mathieu-Daudé
wrote:
>
> QDev objects created with qdev_new() need to manually add
> their parent relationship with object_property_add_child().
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> hw/arm/msf2-som.c
Do not go through the panning buffer unless the address wraps in the middle
of the line.
Signed-off-by: Paolo Bonzini
---
hw/display/vga-helpers.h | 12
1 file changed, 12 insertions(+)
diff --git a/hw/display/vga-helpers.h b/hw/display/vga-helpers.h
index 29933562c45..60ddb27d946
The constant-expression bswap is provided by const_le32(), and GET_PLANE()
can also be implemented using cpu_to_le32(). Remove the custom macros in
vga.c.
Signed-off-by: Paolo Bonzini
---
hw/display/vga.c | 67 +---
1 file changed, 18 insertions(+), 4
This allows setting the start address to a high value, and reading the
bottom of the screen from the beginning of VRAM. Commander Keen 4
("Goodbye, Galaxy!") relies on this behavior.
Signed-off-by: Paolo Bonzini
---
hw/display/vga-helpers.h | 9 +
hw/display/vga.c | 3 +++
2 fil
This implements horizontal pel panning, which is used by games such as
the Commander Keen series, and also reimplements word and odd/even modes
so that they work in graphics modes; this mostly fixes Jazz Jackrabbit's
graphics.
There are still some issues with Cirrus VGA, and also Keen expects the
Jazz Jackrabbit has a very unusual VGA setup, where it uses odd/even mode
with 256-color graphics. Probably, it wants to use fast VRAM-to-VRAM
copies without having to store 4 copies of the sprites as needed in mode
X, one for each mod-4 alignment; odd/even mode simplifies the code a
lot if it's o
The next patch will reuse latched memory access in text modes. Start with
a patch that moves the latched access code out of the "if".
Best reviewed with "git diff -b".
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Paolo Bonzini
---
hw/display/vga.c | 211 -
This implements smooth scrolling, as used for example by Commander Keen
and Second Reality.
Unfortunately, this is not enough to avoid tearing in Commander Keen,
because sometimes the wrong start address is used for a frame.
On real EGA, the panning register is sampled on every line, while
the dis
Jazz Jackrabbit uses odd/even mode with 256-color graphics. This is
probably so that it can do very fast blitting with a decent resolution
(two pixels, compared to four pixels for "regular" mode X).
Accesses still use all planes (reads go to the latches and the game uses
read mode 1 so that the C
The next patches will introduce more parameters that cause a full
refresh. Instead of adding arguments to get_offsets and lines to
update_basic_params, do everything through a struct.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Paolo Bonzini
---
hw/display/vga_int.h| 15
hw
On 04.01.24 08:15, 沈哲赟 wrote:
Traditional mmio in balloon makes Qemu do balloon inflation in the same
thread as vcpu thread. In a CPU overcommitment scenario, host may run
more than one vcpu threads on one host CPU, which makes
madvise_dontneed_free() wait for a long time due to the function
cond
Now we can take advantage of the new base class and make
vhost-user-i2c a much simpler boilerplate wrapper. Also as this
doesn't require any target specific hacks we only need to build the
stubs once.
Acked-by: Mark Cave-Ayland
Acked-by: Viresh Kumar
Signed-off-by: Alex Bennée
---
v7
- s/par
From: Leo Yan
This patch derives vhost-user-input from vhost-user-base class, so make
the input stub as a simpler boilerplate wrapper.
With the refactoring, vhost-user-input adds the property 'chardev', this
leads to conflict with the vhost-user-input-pci adds the same property.
To resolve the e
From: Leo Yan
The Virtio input device invokes set_config() callback for retrieving
the event configuration info, but the callback is not supported in
vhost-user-base.
This patch adds support set_config() callback in vhost-user-base.
Signed-off-by: Leo Yan
Reviewed-by: Marc-André Lureau
Messag
Make it clear the vhost-user-device is intended for expert use only.
Signed-off-by: Alex Bennée
---
v5
- split vhost-user-device out of the table
- sort the table alphabetically
- add sound and scmi devices
v6
- add note re vhost-user-device
v7
- fix patching description
---
docs/syst
We are about to convert at least one stubs which was using the async
teardown so lets use it for all the cases.
Signed-off-by: Alex Bennée
---
hw/virtio/vhost-user-base.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/hw/virtio/vhost-user-base.c b/hw/virtio
Now we can take advantage of our new base class and make
vhost-user-rng a much simpler boilerplate wrapper. Also as this
doesn't require any target specific hacks we only need to build the
stubs once.
Acked-by: Mark Cave-Ayland
Signed-off-by: Alex Bennée
---
v5
- don't remove the in-QEMU RNG
From: Leo Yan
vhost-user-input is in the input folder. On the other hand, the folder
'hw/virtio' maintains other virtio stubs (e.g. I2C, RNG, GPIO, etc).
This patch moves vhost-user-input into the virtio folder for better code
organization. No functionality change.
Signed-off-by: Leo Yan
Rev
Lets keep a cleaner split between the base class and the derived
vhost-user-device which we can use for generic vhost-user stubs. This
includes an update to introduce the vq_size property so the number of
entries in a virtq can be defined.
Signed-off-by: Alex Bennée
---
v5
- s/parent/parent_ob
From: Leo Yan
This adds basic documentation for vhost-user-input.
Signed-off-by: Leo Yan
Message-Id: <20231120043721.50555-3-leo@linaro.org>
Signed-off-by: Alex Bennée
---
MAINTAINERS | 1 +
docs/system/device-emulation.rst | 1 +
docs/system/devices
Now the new base class supports config handling we can take advantage
and make vhost-user-gpio a much simpler boilerplate wrapper. Also as
this doesn't require any target specific hacks we only need to build
the stubs once.
Acked-by: Mark Cave-Ayland
Acked-by: Viresh Kumar
Signed-off-by: Alex Be
From: Manos Pitsidianakis
Tested with rust-vmm vhost-user-sound daemon:
RUST_LOG=trace cargo run --bin vhost-user-sound -- --socket /tmp/snd.sock
--backend null
Invocation:
qemu-system-x86_64 \
-qmp unix:./qmp-sock,server,wait=off \
-m 4096 \
-num
A lot of our vhost-user stubs are large chunks of boilerplate that do
(mostly) the same thing. This series continues the cleanups by
splitting the vhost-user-base and vhost-user-generic implementations.
After adding a new vq_size property the rng, gpio and i2c vhost-user
devices become simple speci
Split out the function virtio_snd_pcm_set_active() from
virtio_snd_pcm_start_stop(). A later patch also needs this
new funcion. There is no functional change.
Signed-off-by: Volker Rümelin
---
hw/audio/virtio-snd.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
dif
So far, only rudimentary checks have been made to ensure that
the guest only performs state transitions permitted in
virtio-v1.2-csd01 5.14.6.6.1 PCM Command Lifecycle. Add a state
variable per audio stream and check all state transitions.
Because only permitted state transitions are possible, onl
With the involvement of a malicious guest, it's possible to reach
the error paths in the virtio_snd_handle_tx/rx_xfer handlers with
stream == NULL. This triggers a segmentation fault.
Move the queues for invalid messages from the stream structs to
the device struct and initialize the queues quite
When a running audio stream is migrated, on average half of a
recording stream buffer is lost or half of a playback stream
buffer is played twice. Add a placeholder for the write position
of the current stream buffer to the migrated data. Additional
program code is required to resolve the above iss
The virtio-sound device is currently not migratable. Add the
missing VMSTATE fields, enable migration and reconnect the audio
streams after migration.
The queue_inuse[] array variables mimic the inuse variable in
struct VirtQueue which is private. They are needed to restart
the virtio queues after
Split out virtio_snd_pcm_start_stop(). This is a preparation
for the next patch so that it doesn't become too big.
Signed-off-by: Volker Rümelin
---
hw/audio/trace-events | 3 ++-
hw/audio/virtio-snd.c | 57 ---
2 files changed, 39 insertions(+), 21 delet
The payload size returned by command VIRTIO_SND_R_PCM_INFO is
wrong. The code in process_cmd() assumes that all commands
return only a virtio_snd_hdr payload, but some commands like
VIRTIO_SND_R_PCM_INFO may return an additional payload.
Add a zero initialized payload_size variable to struct
virti
It is much easier to migrate an array of structs than individual
structs that are accessed via a pointer to a pointer to an array
of pointers to struct, where some pointers can also be NULL.
For this reason, the audio streams are already allocated during
the realization phase and all stream variab
Split out the function virtio_snd_pcm_open() from
virtio_snd_pcm_prepare(). A later patch also needs
the new function. There is no functional change.
Signed-off-by: Volker Rümelin
---
hw/audio/virtio-snd.c | 57 +++
1 file changed, 31 insertions(+), 26 del
All code in virtio-snd.c runs with the BQL held. Remove the
command queue mutex and the stream queue mutexes. The qatomic
functions are also not needed.
Signed-off-by: Volker Rümelin
---
hw/audio/virtio-snd.c | 294 +++---
include/hw/audio/virtio-snd.h | 3 -
Here is the first part of my virtio-sound patches. Most of them are a
preparation to make migration work. Patch 09/10 enables migration of the
virtio-sound device.
The second part isn't finished yet and will have to do with virtio-sound
jack and channel maps configuration and migration.
Volker Rü
On Thu, 4 Jan 2024, del...@kernel.org wrote:
From: Helge Deller
Limit IOR to the lower 32-bits on failure.
Keep patch short for easier backporting.
Signed-off-by: Helge Deller
---
target/hppa/op_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/hppa/op_helper.
04.01.2024 21:36, del...@kernel.org пишет:
From: Helge Deller
There were some regressions introduced with Qemu v8.2 on the hppa/hppa64
target, e.g.:
- 32-bit HP-UX crashes on B160L (32-bit) machine
- NetBSD boot failure due to power button in page zero
- NetBSD FPU detection failure
This smal
On 1/4/24 20:58, BALATON Zoltan wrote:
On Thu, 4 Jan 2024, del...@kernel.org wrote:
From: Helge Deller
The physical hardware allows DIMMs of 4 MB size and above, allowing up
to 3840 MB of memory, but is restricted by setup code to 3 GB.
Increase the limit to allow up to the maximum amount of m
On Thu, 4 Jan 2024, del...@kernel.org wrote:
From: Helge Deller
NetBSD accesses some astro and elroy registers which aren't accesses
Typo: accessed by Linux
Regards,
BALATON Zoltan
by Linux yet. Add emulation for those registers to allow NetBSD to
boot further.
Please note that this patch
On Thu, 4 Jan 2024, del...@kernel.org wrote:
From: Helge Deller
The physical hardware allows DIMMs of 4 MB size and above, allowing up
to 3840 MB of memory, but is restricted by setup code to 3 GB.
Increase the limit to allow up to the maximum amount of memory.
Btw. the memory area from 0xf000
On Fri, 29 Dec 2023 at 21:24, Richard Henderson
wrote:
>
> The following changes since commit 7425b6277f12e82952cede1f531bfc689bf77fb1:
>
> Merge tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu into
> staging (2023-12-27 05:15:32 -0500)
>
> are available in the Git repository at:
On 1/4/24 19:46, Michael Tokarev wrote:
04.01.2024 21:36, del...@kernel.org:
...
Not commenting on anything yet, but this one just draw my attention:
pc-bios/hppa-firmware.img | Bin 681388 -> 163316 bytes
This is quite a significant reduction in size, - more than 4 times.
Is that right?
04.01.2024 21:36, del...@kernel.org:
...
Not commenting on anything yet, but this one just draw my attention:
pc-bios/hppa-firmware.img | Bin 681388 -> 163316 bytes
This is quite a significant reduction in size, - more than 4 times.
Is that right?
/mjt
From: Helge Deller
Add support for the qemu --nodefaults option, which will disable the
following default devices:
- lsi53c895a SCSI controller,
- artist graphics card,
- LASI 82596 NIC,
- tulip PCI NIC,
- second serial PCI card,
- USB OHCI controller.
Adding this option is very useful to allow
From: Helge Deller
Fix the address translation for PDC space on PA2.0 if PSW.W=0.
Basically, for any address in the 32-bit PDC range from 0xf000 to
0xf100 keep the lower 32-bits and just set the upper 32-bits to
0xfff0.
This mapping fixes the emulated power button in PDC space for 32
From: Helge Deller
There were some regressions introduced with Qemu v8.2 on the hppa/hppa64
target, e.g.:
- 32-bit HP-UX crashes on B160L (32-bit) machine
- NetBSD boot failure due to power button in page zero
- NetBSD FPU detection failure
This small patch series fixes those known regressions
From: Helge Deller
NetBSD accesses some astro and elroy registers which aren't accesses
by Linux yet. Add emulation for those registers to allow NetBSD to
boot further.
Please note that this patch is not sufficient to completely boot up
NetBSD on the 64-bit C3700 machine yet.
Signed-off-by: Helg
From: Helge Deller
The value of unwind_breg may reference register %r0, but we need to avoid
accessing gr0 directly and use the value 0 instead.
At runtime I've seen unwind_breg being zero with the Linux kernel when
rfi is used to jump to smp_callin().
Signed-off-by: Helge Deller
---
target/h
From: Helge Deller
Limit IOR to the lower 32-bits on failure.
Keep patch short for easier backporting.
Signed-off-by: Helge Deller
---
target/hppa/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c
index 04de1689d7..bc30bfe4c7 100644
From: Helge Deller
The physical hardware allows DIMMs of 4 MB size and above, allowing up
to 3840 MB of memory, but is restricted by setup code to 3 GB.
Increase the limit to allow up to the maximum amount of memory.
Btw. the memory area from 0xf000. to 0x. is reserved by
the archite
From: Helge Deller
Limit IOR to the lower 32-bits on failure.
Keep patch short for easier backporting.
Signed-off-by: Helge Deller
---
target/hppa/op_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/hppa/op_helper.c b/target/hppa/op_helper.c
index 7f607c3afd.
From: Helge Deller
The various operating systems (e.g. Linux, NetBSD) have issues
mapping the power button when it's stored in page zero.
NetBSD even crashes, because it fails to map that page and then
accesses unmapped memory.
Since we now have a consistent memory mapping of PDC in 32-bit
and 6
On 4/1/24 19:03, Philippe Mathieu-Daudé wrote:
On 4/1/24 18:58, Philippe Mathieu-Daudé wrote:
On 15/11/23 00:55, Gavin Shan wrote:
'ev67' CPU class will be returned to match everything, which makes
no sense as mentioned in the comments. Remove the logic to fall
back to 'ev67' CPU class to match
1 - 100 of 204 matches
Mail list logo
