audio performance running Linux arm64 on Macos arm64

[Frank Carmickle]

Greetings Qemu users,

I've been fighting with audio support for a Linux guest on Macos. I am 
currently using the UTM wrapper, which I see has forked Qemu, so apologies if I 
need to run mainline Qemu to provide the right feedback to the mailing list.

I'd like to run the Debian kernel, if possible. The only audio drivers that UTM 
has that are also in the Debian kernel are ich6 and ich9, hda_intel. After some 
time the audio stops playing and usually the following is found in kmsg.

snd_hda_intel :00:02.0: IRQ timing workaround is activated for card #0. 
Suggest a bigger bdl_pos_adj.

I've played with setting different module parameters. Currently I have

options snd-hda-intel enable_msi=1 bdl_pos_adj=8,8 \
position_fix=2 \
align_buffer_size=0 \
 beep_mode=1 power_save=0

With those settings, I seem to not loose the audio, but the latency is so high 
that it's difficult to use the system.

I need the latency to be low, as I am using a screen reader in the virtual 
machine.

Can anyone make some recommendations on module parameters or qemu options to 
use to get stable low latency audio from a arm64 Linux virt on an arm64 Macos 
system?

Thanks so very much for any help.
--FC

Re: Emulating graviton G3

[Peter Maydell]

On Fri, 3 Mar 2023 at 07:27, Robert Henry  wrote:
>
> I cannot figure out how to make QEMU TCG emulate aarch64 Graviton G3.  I'm 
> working against master/head of the QEMU source.
>
> I come up with feature names by consulting 
> https://marcin.juszkiewicz.com.pl/download/tables/arm-socs.html which is 
> compendium of the /proc/cpuinfo info crowd sourced from linux running on real 
> systems
>
> I'm trying to either (a) add features to QEMU's '-cpu neoverse-n1,...' or (b) 
> take features away from '-cpu max,...'
>
> Unfortunately, many names of implemented or unimplemented features are not 
> known by the -cpu mechanism.  For example, from max I want to kill 
> "smeb16f32", or from neoverse-n1 I want to add in "svei8mm", but neither name 
> is known.  Indeed, the only names known by -cpu are those exposed via the qmp 
> mechanism are of the form  "sveNNN" for vector bit width NNN.
>
> Is there some trick I'm missing?

Broadly speaking, we do not expose most architectural-level
features via the '-cpu,+foo' option syntax. We only do that
for features where it seems "important" to give users that
level of control, or where we need to model multiple machine
types that have differently-configured CPUs of the same type in
real hardware.

So your options are:
 * use one of the pre-defined CPU types
 * use 'max' to get everything
 * write a patch to define a new CPU model type that gets
   the ID registers and feature settings right. If there are
   features that we don't emulate yet then they need to be
   implemented first

In this specific case, the Graviton G3 is a Neoverse-V1.
That CPU is on Linaro's todo-list to implement:
 https://linaro.atlassian.net/browse/QEMU-422
The only missing pieces at the moment are:
 * FEAT_LSE2 support (there are patches on list for this,
   which might or might not make it into 8.0)
 * writing the function to define the CPU type (which is
   easy)

thanks
-- PMM

Re: Emulating graviton G3

[Philippe Mathieu-Daudé]

Cc'ing qemu-arm@ list

On 3/3/23 08:20, Robert Henry wrote:
I cannot figure out how to make QEMU TCG emulate aarch64 Graviton G3.  
I'm working against master/head of the QEMU source.


I come up with feature names by consulting 
https://marcin.juszkiewicz.com.pl/download/tables/arm-socs.html 
 which 
is compendium of the /proc/cpuinfo info crowd sourced from linux running 
on real systems


I'm trying to either (a) add features to QEMU's '-cpu neoverse-n1,...' 
or (b) take features away from '-cpu max,...'


Unfortunately, many names of implemented or unimplemented features are 
not known by the -cpu mechanism.  For example, from max I want to kill 
"smeb16f32", or from neoverse-n1 I want to add in "svei8mm", but neither 
name is known.  Indeed, the only names known by -cpu are those exposed 
via the qmp mechanism are of the form  "sveNNN" for vector bit width NNN.


Is there some trick I'm missing?