add gemma accelerator classification results

1 files changed, 25 insertions, 0 deletions

diff --git a/results/classifier/accel-gemma3:12b/kvm/1904490 b/results/classifier/accel-gemma3:12b/kvm/1904490
new file mode 100644
index 00000000..1cdf921d
--- /dev/null
+++ b/results/classifier/accel-gemma3:12b/kvm/1904490
@@ -0,0 +1,25 @@
+
+intel-hda: valid registers are unknown
+
+According to HDA specification, "3.1.2 General Register Behaviors and Access Requirements":
+
+"All controller registers must be addressable as byte, Word, and Dword quantities."
+
+But e.g. if you try the following to reset and enable the CORB, assuming es:esi contains the base MMIO address of the controller,
+
+ es or [esi+4bh], byte 80h   ; reset CORB
+corbresetloop:
+ es test [esi+4bh], byte 80h ; is HW done resetting yet?
+ jnz corbreset1ok            ; yes, bit is now 1
+ hlt                         ; wait a little bit
+ jmp corbresetloop           ; and check again
+corbreset1ok:
+ es and [esi+4bh], byte 7fh  ; clear the bit
+
+It will hang indefinitely because the bit never gets set, and if you enable debug output of the controller with "-device intel-hda,debug=1", you will see infinitely the line "unknown register, addr 0x4b" output. The same code on a real hardware (I tried with ICH7M) works fine, as it should according to the spec.
+
+Host/guest/version does not matter (I am writing own drivers) --- as of right now, latest version still has this code:
+
+https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c
+
+which seems to emit "unknown register" message in intel_hda_reg_find(), and this function does not take into account range of addresses that each register occupies.
\ No newline at end of file