From: Jacob <1904490@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1904490] [NEW] intel-hda: valid registers are unknown
Date: Tue, 17 Nov 2020 03:05:43 -0000 [thread overview]
Message-ID: <160558234310.29971.12864468607339587807.malonedeb@gac.canonical.com> (raw)
Public bug reported:
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.
** Affects: qemu
Importance: Undecided
Status: New
** Tags: intel-hda
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1904490
Title:
intel-hda: valid registers are unknown
Status in QEMU:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1904490/+subscriptions
next reply other threads:[~2020-11-17 3:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 3:05 Jacob [this message]
2021-05-10 4:29 ` [Bug 1904490] Re: intel-hda: valid registers are unknown Thomas Huth
2021-07-10 4:17 ` Launchpad Bug Tracker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=160558234310.29971.12864468607339587807.malonedeb@gac.canonical.com \
--to=1904490@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.