qemu modifies host audio sample rate with coreaudio backend to 44.1khz on startup

[Frank Carmickle]

Greetings all,

Every time a qemu instance is run, the host systems audio hardware sample rate 
is set to 44.1khz. Is it possible to change this behavior, and if so, how?

Thank you,
--FC

Cross compilation of QEMU source code for ARM64

[Pedro Miguel Veiga de Almeida e Silva]

Hello,

I am trying to cross compile the source code to deploy it in a xilinx
ZCU106. But every time I execute the ./configure
--target-list=aarch64-softmmu --enable-kvm and then make.

But the file that compiles is a X86.

Can you help me?

vhost-user's disk can support physical_block_size=4096, logical_block_size=512?

[顾泽兵 via]

Hello community,

I have a disk with both logical and physical sector size being 4096. I have
a qcow2 image which is built from a virtual machine has legacy 512 bytes
sector size.
I use spdk-vhost as the backend storage.

The commandline of qemu is like this:
/usr/bin/qemu-system-x86_64  \
-nographic \
-name debug-threads=on -nic none  -m 8G,slots=3,maxmem=16G -mem-prealloc
-cpu host  -enable-kvm  -M q35 \
-smp 8,sockets=4,cores=2,threads=1 \
-object
memory-backend-file,id=ram-node0,mem-path=/dev/hugepages,share=yes,size=8G,host-nodes=0,policy=bind
\
-numa node,nodeid=0,cpus='0-7',memdev=ram-node0 \
-device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
\
-object iothread,id=iothread1 \
-object iothread,id=iothread2 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1
\
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2
\
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3
\
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4
\
*-chardev
socket,id=charvirtio-disk1,path=/var/run/spdk/qemu/disk0.sock,reconnect=1 \*
*-device
vhost-user-blk-pci-non-transitional,chardev=charvirtio-disk1,bus=pci.4,addr=0x0,id=virtio-disk1,num-queues=2,bootindex=0
\*


The result is that the system can’t start normally.
As I know, there are 2 questions:
1、Seabios can't support sector size of 4096.
2、The qcow2 image which is built with sector size of 512 can’t interpreted
with sector size of 4096. The key point is MBR partion table.


I know that QEMU is supposed to emulate 512 byte sectors on top of a 4k
sector disk on the host. The command line is like this:
'physical_block_size=4096,logical_block_size=512’.

Unfortunately, When I add 'physical_block_size=4096,logical_block_size=512’
to vhost-user-blk-pci-non-transitional, qemu print error:
Property 'vhost-user-blk-pci-non-transitional.physical_block_size' not
found.

Can we have a plan to support params of
'physical_block_size=4096,logical_block_size=512’ to
vhost-user-blk-pci-non-transitional? Or any other advice on how to possibly
work around this?
Thank you very much!

Re: Anyone can help me? I run KVM + QEMU failed

[Peter Maydell]

On Thu, 23 Mar 2023 at 06:59, Zheng Jian  wrote:
>
> Dear Qemu technical experts:
>
> My question is whether QEMU also needs to support specific CPU models
> when KVM is turned on? Here is the description of the problem I encountered.

No, there's nothing particularly you need to enable in QEMU.

> I want to run KVM+QEMU on my mobile phone, which is piexl7. Compiled
> the corresponding qemu-system-aarch64 bin.
>
> Then put it into the mobile phone to run, and found that qemu would
> hang, and then stopped running. The command line is as follows
>
> ./qemu-system-aarch64 -enable-kvm -m 1024 -M virt -cpu host  \
>-nographic -kernel Image -drive if=none,file=disk_oe64.img,id=fs -device 
> virtio-blk-device,drive=fs \
>   -append "earlyprintk console=ttyAMA0 mem=512M rootwait root=/dev/vda rw"

There's nothing obviously wrong with this command line (well, the
difference between the -m option and the mem= command line is
weird but shouldn't hurt).

Suggestions for debugging:
 * look for anything interesting in the host kernel logs
 * check whether 'earlycon' is any better for early kernel
   output than 'earlyprintk'
 * make sure you're using a recent QEMU
 * make sure you're using a recent host kernel
 * make sure you're using a recent guest kernel
 * enable QEMU's gdbstub and connect a gdb to it to see what's
   happening (if you're comfortable with trying to debug low-level
   boot issues)

thanks
-- PMM