On Wed, 22 Dec 2021 16:39:23 +0100
Thomas Huth wrote:
> The user might have disabled the pc-i440fx machine type (or it's older
> versions, like done in downstream RHEL) in the QEMU binary, so let's
> better check whether the machine types are available before using them.
>
> Signed-off-by: Thoma
On 12/24/21 18:35, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
v2: rebase on master, fix iostest 283
Block jobs usually operate with several block nodes, and better to
handle them symmetrically, than use one from s->common.blk and one from
s->target (or something like this). Moreover, generic
Hi Paolo,
I am running qtest with --enable-modules, it fails with error
"qemu-system-x86_64: -accel qtest: invalid accelerator qtest"
Here are the steps:
1. ./configure --target-list=x86_64-softmmu --enable-kvm --enable-modules
2. make -j8 check-qtest-x86_64 V=1
I found that the problem happe
On Sonntag, 26. Dezember 2021 16:40:15 CET Volker Rümelin wrote:
> On Windows the jack_set_thread_creator() function and on MacOS the
> pthread_setname_np() function with a thread pointer paramater is
> not available. Use #ifdefs to remove the jack_set_thread_creator()
> function call and the qjack
On a Linux platform, user process could accesses /dev/videoX to
capture video frames.
We can run QEMU like this:
qemu-system-x86_64 ... -cameradev v4l2,path=/dev/video0,id=camera0
The basic logic of v4l2 driver:
stream on -> qbuf -> dqbuf(drive by POLLIN event) -> qbuf -> dqbuf
... ->
Web camera is an important port of a desktop instance, QEMU supports
USB passthrough and USB redirect to support for general cases.
Several problems we have hit:
1, the heavy bandwidth of network. a 1080*720@30FPS(MJPEG) uses
~5MB/s.
2, Issues of USB passthrough, Ex USB reset from guest si
Define USB class code for video&mescellaneous.
Signed-off-by: zhenwei pi
---
include/hw/usb.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/hw/usb.h b/include/hw/usb.h
index 33668dd0a9..8e3d30b9f4 100644
--- a/include/hw/usb.h
+++ b/include/hw/usb.h
@@ -77,9 +77,11 @@
#define US
Base on UVC specification 1.5, implement UVC device emulation(camera
only). Several changes in this patch:
1, define types and structures(in include/hw/usb/video.h)
2, a camera device with UVC chain: OT 3 <- PU 5 <- SU 4 <- IT
a, video control descriptor. (auto-detected bmControl in PU)
A device of USB video class usually uses larger desc structure, so
use larger buffer to avoid failure.
Signed-off-by: zhenwei pi
---
hw/usb/desc.c | 15 ---
hw/usb/desc.h | 1 +
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/usb/desc.c b/hw/usb/desc.c
index 8b6eae
1, The full picture of this patch set:
+-+ ++ +---+
|UVC(done)| |virtio(TODO)| |other HW device|
+-+ ++ +---+
| | |
|+
The possible variants for region type in /proc/self/maps are either
private "p" or shared "s". In the current implementation,
we mark shared regions as "-". It could break memory mapping parsers
such as included into ASan/HWASan sanitizers.
Signed-off-by: Andrey Kazmin
---
linux-user/syscall.c |
This is split out from a larger patch set for unaligned accesses.
The changes in target/ have no effect without the changes in tcg/,
but this allows the syscall to be handled separately.
Changes for v2:
* Added LOG_UNIMP to the default case.
* Use MO_ALIGN instead of 0 for target/sh.
r~
Ri
This requires extra work for each target, but adds the
common syscall code, and the necessary flag in CPUState.
Reviewed-by: Warner Losh
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
include/hw/core/cpu.h | 3 +++
lin
Create a list of subcodes that we want to pass on, a list of
subcodes that should not be passed on because they would affect
the running qemu itself, and a list that probably could be
implemented but require extra work. Do not pass on unknown subcodes.
Reviewed-by: Laurent Vivier
Reviewed-by: Phi
Since the prctl constants are supposed to be generic, supply
any that are not provided by the host.
Split out subroutines for PR_GET_FP_MODE, PR_SET_FP_MODE,
PR_GET_VL, PR_SET_VL, PR_RESET_KEYS, PR_SET_TAGGED_ADDR_CTRL,
PR_GET_TAGGED_ADDR_CTRL. Return EINVAL for guests that do
not support these o
Leave TARGET_ALIGNED_ONLY set, but use the new CPUState
flag to set MO_UNALN for the instructions that the kernel
handles in the unaligned trap.
Signed-off-by: Richard Henderson
---
linux-user/alpha/target_prctl.h | 2 +-
target/alpha/cpu.h | 5 +
target/alpha/translate.c
Leave TARGET_ALIGNED_ONLY set, but use the new CPUState
flag to set MO_UNALN for the instructions that the kernel
handles in the unaligned trap.
Signed-off-by: Richard Henderson
---
linux-user/hppa/target_prctl.h | 2 +-
target/hppa/cpu.h | 5 -
target/hppa/translate.c
Leave TARGET_ALIGNED_ONLY set, but use the new CPUState
flag to set MO_UNALN for the instructions that the kernel
handles in the unaligned trap.
The Linux kernel does not handle all memory operations: no
floating-point and no MAC.
Signed-off-by: Richard Henderson
---
linux-user/sh4/target_prctl
Le 27/12/2021 à 16:01, Richard Henderson a écrit :
Leave TARGET_ALIGNED_ONLY set, but use the new CPUState
flag to set MO_UNALN for the instructions that the kernel
handles in the unaligned trap.
Signed-off-by: Richard Henderson
---
linux-user/alpha/target_prctl.h | 2 +-
target/alpha/cpu.h
Le 27/12/2021 à 16:01, Richard Henderson a écrit :
Leave TARGET_ALIGNED_ONLY set, but use the new CPUState
flag to set MO_UNALN for the instructions that the kernel
handles in the unaligned trap.
Signed-off-by: Richard Henderson
---
linux-user/hppa/target_prctl.h | 2 +-
target/hppa/cpu.h
Le 27/12/2021 à 16:01, Richard Henderson a écrit :
Leave TARGET_ALIGNED_ONLY set, but use the new CPUState
flag to set MO_UNALN for the instructions that the kernel
handles in the unaligned trap.
The Linux kernel does not handle all memory operations: no
floating-point and no MAC.
Signed-off-by
Hi Eric,
Picking this up again after a stupidly long time...
On Mon, 04 Oct 2021 13:00:21 +0100,
Eric Auger wrote:
>
> Hi Marc,
>
> On 10/3/21 6:46 PM, Marc Zyngier wrote:
> > Currently, the highmem PCIe region is oddly keyed on the highmem
> > attribute instead of highmem_ecam. Move the enabl
On Mon, 04 Oct 2021 13:23:41 +0100,
Eric Auger wrote:
>
> Hi Marc,
>
> On 10/3/21 6:46 PM, Marc Zyngier wrote:
> > Even when the VM is configured with highmem=off, the highest_gpa
> > field includes devices that are above the 4GiB limit.
> > Similarily, nothing seem to check that the memory is w
David Gibson writes:
> On Mon, Dec 20, 2021 at 03:18:56PM -0300, Fabiano Rosas wrote:
>> In preparation to moving the interrupt code into separate functions,
>> create a PPCIntrArgs structure to serve as a consistent API.
>
> The patch doesn't seem to match this description - I see no new
> struc
From: "Cédric Le Goater" c...@kaod.org
To: "BALATON Zoltan" bala...@eik.bme.hu,"ma...@locati.it" ma...@locati.it
Cc: faro...@linux.ibm.com, qemu-devel@nongnu.org, qemu-...@nongnu.org,
danielhb...@gmail.com
Date: Sun, 26 Dec 2021 18:57:54 +0100
Subject: Re: [PATCH] target/ppc: Fix e6500 boot
O
if QEMU is started with used provided SLIC table blob,
-acpitable sig=SLIC,oem_id='CRASH
',oem_table_id="ME",oem_rev=2210,asl_compiler_id="",asl_compiler_rev=,data=/dev/null
it will assert with:
hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <=
maxlen)
a
Signed-off-by: Igor Mammedov
---
tests/qtest/bios-tables-test-allowed-diff.h | 2 ++
tests/data/acpi/q35/FACP.slic | Bin 0 -> 244 bytes
tests/data/acpi/q35/SLIC.slic | 0
3 files changed, 2 insertions(+)
create mode 100644 tests/data/acpi/q35/FACP.slic
create mo
Since 6.2 QEMU will assert when SLIC table is passed with
help of -acpitable. This series fixes the issue and adds a test
case for it.
When user uses '-acpitable' to add SLIC table, some ACPI
tables (FADT) will change its 'Oem ID'/'Oem Table ID' fields to
match that of SLIC. Test makes sure thati QEMU handles
those fields correctly when SLIC table is added with
'-acpitable' option.
Signed-off-by: Igor Mammedov
---
tests/qtest/b
Signed-off-by: Igor Mammedov
---
tests/qtest/bios-tables-test-allowed-diff.h | 2 --
tests/data/acpi/q35/FACP.slic | Bin 244 -> 244 bytes
tests/data/acpi/q35/SLIC.slic | Bin 0 -> 36 bytes
3 files changed, 2 deletions(-)
diff --git a/tests/qtest/bios-tables-test-al
"ma...@locati.it" writes:
> I have updated the guest VM but I get exactly the same result except that
> now I have libc-2.33.so installed.
>
> [...]
> VFS: Mounted root (ext4 filesystem) on device 254:0.
> devtmpfs: mounted
> Freeing unused kernel image (initmem) memory: 468K
> This architectur
On Mon, 04 Oct 2021 11:11:10 +0100,
Andrew Jones wrote:
>
> On Sun, Oct 03, 2021 at 05:46:04PM +0100, Marc Zyngier wrote:
> > The highmem attribute is nothing but another way to express the
> > PA range of a VM. To support HW that has a smaller PA range then
> > what QEMU assumes, pass this PA ra
Hello,
On Mon, 27 Dec 2021, ma...@locati.it wrote:
I have updated the guest VM but I get exactly the same result except that now
I have libc-2.33.so installed.
[...]
VFS: Mounted root (ext4 filesystem) on device 254:0.
devtmpfs: mounted
Freeing unused kernel image (initmem) memory: 468K
This
On Mon, 27 Dec 2021, Fabiano Rosas wrote:
"ma...@locati.it" writes:
I have updated the guest VM but I get exactly the same result except that now
I have libc-2.33.so installed.
[...]
VFS: Mounted root (ext4 filesystem) on device 254:0.
devtmpfs: mounted
Freeing unused kernel image (initmem)
Le 27/12/2021 à 13:50, Andrey Kazmin a écrit :
The possible variants for region type in /proc/self/maps are either
private "p" or shared "s". In the current implementation,
we mark shared regions as "-". It could break memory mapping parsers
such as included into ASan/HWASan sanitizers.
Signed-o
Make sure both the highmem PCIe and GICv3 regions are disabled when
they don't fully fit in the PA range.
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zyngier
---
hw/arm/virt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 212079e7a6..18e615070f 100
Just like we can control the enablement of the highmem PCIe region
using highmem_ecam, let's add a control for the highmem GICv3
redistributor region.
Similarily to highmem_ecam, these redistributors are disabled when
highmem is off.
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zyngier
---
hw
Even when the VM is configured with highmem=off, the highest_gpa
field includes devices that are above the 4GiB limit.
Similarily, nothing seem to check that the memory is within
the limit set by the highmem=off option.
This leads to failures in virt_kvm_type() on systems that have
a crippled IPA
Currently, the highmem PCIe region is oddly keyed on the highmem
attribute instead of highmem_ecam. Move the enablement of this PCIe
region over to highmem_ecam.
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zyngier
---
hw/arm/virt-acpi-build.c | 10 --
hw/arm/virt.c| 4 ++-
Here's another stab at enabling QEMU on systems with pathologically
reduced IPA ranges such as the Apple M1 (previous version at [1]).
Eventually, we're able to run a KVM guest with more than just 3GB of
RAM on a system with a 36bit IPA space, and at most 123 vCPUs.
This series does a few things:
The highmem attribute is nothing but another way to express the
PA range of a VM. To support HW that has a smaller PA range then
what QEMU assumes, pass this PA range to the virt_set_memmap()
function, allowing it to correctly exclude highmem devices
if they are outside of the PA range.
Signed-off
On 12/27/21 20:31, Igor Mammedov wrote:
> if QEMU is started with used provided SLIC table blob,
>
> -acpitable sig=SLIC,oem_id='CRASH
> ',oem_table_id="ME",oem_rev=2210,asl_compiler_id="",asl_compiler_rev=,data=/dev/null
> it will assert with:
>
> hw/acpi/aml-build.c:61:build_ap
On Fri, Dec 24, 2021 at 11:54:18AM +0800, Chao Peng wrote:
> On Thu, Dec 23, 2021 at 06:02:33PM +, Sean Christopherson wrote:
> > On Thu, Dec 23, 2021, Chao Peng wrote:
> > > Similar to hva_tree for hva range, maintain interval tree ofs_tree for
> > > offset range of a fd-based memslot so the l
HiFive Unmatched PDMA supports high/low 32-bit access of 64-bit
register, but QEMU emulation support low part access now. Enhance QEMU
emulation to support high 32-bit access.
Also, permit 4/8-byte valid access in PDMA as we have verified 32/64-bit
accesses of PDMA registers are supported.
Jim S
It's obvious that PDMA support 64-bit access of 64-bit registers, and
in previous commit, we confirm that PDMA support 32-bit access of both
32/64-bit registers. Thus, we configure 32/64-bit memory access of
PDMA registers as valid in general.
Signed-off-by: Jim Shu
Reviewed-by: Frank Chang
---
Real PDMA support high 32-bit read/write memory access of 64-bit
register.
The following result is PDMA tested in U-Boot on Unmatched board:
1. Real PDMA is allowed high 32-bit read/write to 64-bit register.
=> mw.l 0x300 0x0 <= Disclaim channel 0
=> mw.l 0x300 0x1
From: Frank Chang
In SPI-mode, SD card's OCR register: Card Capacity Status (CCS) bit
is not set to 1 correclty when the assigned SD image size is larger
than 2GB (SDHC). This will cause the SD card to be indentified as SDSC
incorrectly. CCS bit should be set to 1 if we are using SDHC.
Also, as
Hi Klaus,
On Thu, Dec 23, 2021 at 11:57 PM Klaus Heinrich Kiwi
wrote:
>
> Em qui., 23 de dez. de 2021 às 09:54, Cédric Le Goater
> escreveu:
> >
> > [ Adding Klaus ]
>
> Thanks Cedric. It's been a while since I've looked at this but I'll do my
> best..
>
> >
> > On 12/22/21 03:22, Troy Lee wro
When doing failover and checkpoint, some returns are missed in error
handling. Let's add it.
Signed-off-by: Lei Rao
---
migration/colo.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/migration/colo.c b/migration/colo.c
index 5f7071b3cd..014d3cba01 100644
--- a/migrat
49 matches
Mail list logo
