From: Corey Minyard <minyard@acm.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, "Corey Minyard" <cminyard@mvista.com>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [Qemu-devel] [PATCH] Revert "smbus: do not immediately complete commands"
Date: Fri, 19 Jan 2018 08:07:01 -0600 [thread overview]
Message-ID: <19605015-5d30-f91e-3344-32ae4555a7dd@acm.org> (raw)
In-Reply-To: <20180119051309-mutt-send-email-mst@kernel.org>
On 01/18/2018 09:17 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 18, 2018 at 07:55:41PM -0600, minyard@acm.org wrote:
>> From: Corey Minyard <cminyard@mvista.com>
>>
>> This reverts commit 880b1ffe6ec2f0ae25cc4175716227ad275e8b8a.
>>
>> The commit being reverted says:
>>
>> PIIX4 errata says that "immediate polling of the Host Status Register BUSY
>> bit may indicate that the SMBus is NOT busy."
>> Due to this, some code does the following steps:
>> (a) set parameters
>> (b) start command
>> (c) check for smbus busy bit set (to know that command started)
>> (d) check for smbus busy bit not set (to know that command finished)
>>
>> Let (c) happen, by immediately setting the busy bit, and really executing
>> the command when status register has been read once.
>>
>> This fixes a problem with AMIBIOS, which can now properly initialize the
>> PIIX4.
>>
>> Emulating bad hardware so badly written software will work doesn't sound
>> like a good idea to me. I have patches that add interrupt capability
>> to pm_smbus, but this change breaks that because the Linux driver
>> starts the transaction then waits for interrupts before reading the
>> status register. That obviously won't work with these changes.
>>
>> The right way to fix this in AMIBIOS is to ignore the host busy bit
>> and use the other bits in the host status register to tell if the
>> transaction has completed. Using host busy is racy, anyway, if you
>> get interrupted or something while processing, you may miss step (c)
>> in your algorithm and fail.
>>
>> Cc: Hervé Poussineau <hpoussin@reactos.org>
>> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> Signed-off-by: Corey Minyard <cminyard@mvista.com>
> Would it be possible to limit the change to when guest uses
> interrupts?
I did think about that, but it seems rather frail. What if another
piece of software
does this but has the interrupt enable bit set? And AMIBIOS is still
broken doing
that algorithm on real hardware. If you get a bus collision, for
instance, that will
be almost instantaneous and the firmware is likely to miss it.
The 82801 documentation is pretty clear that you should use the INTR and
error
bits in the status register to know if a transaction is complete.
If you really want to emulate real hardware, I guess the right way to do
this
would be to add a delay between the start bit being set and the transaction
being done. I'm not sure how timers work with vmstate, I'd have to look at
that.
IMHO it's best to revert this change and fix AMIBIOS. If that is
impossible, then adding the delay or doing the interrupt enable
thing you suggest (assuming AMIBIOS doesn't have interrupts
enabled), and fixing that assert would be best. I can submit
a patch either way, depending on what you want.
-corey
>> ---
>> hw/i2c/pm_smbus.c | 16 +---------------
>> 1 file changed, 1 insertion(+), 15 deletions(-)
>>
>> diff --git a/hw/i2c/pm_smbus.c b/hw/i2c/pm_smbus.c
>> index 0d26e0f..a044dd1 100644
>> --- a/hw/i2c/pm_smbus.c
>> +++ b/hw/i2c/pm_smbus.c
>> @@ -62,9 +62,6 @@ static void smb_transaction(PMSMBus *s)
>> I2CBus *bus = s->smbus;
>> int ret;
>>
>> - assert(s->smb_stat & STS_HOST_BUSY);
>> - s->smb_stat &= ~STS_HOST_BUSY;
>> -
>> SMBUS_DPRINTF("SMBus trans addr=0x%02x prot=0x%02x\n", addr, prot);
>> /* Transaction isn't exec if STS_DEV_ERR bit set */
>> if ((s->smb_stat & STS_DEV_ERR) != 0) {
>> @@ -137,13 +134,6 @@ error:
>>
>> }
>>
>> -static void smb_transaction_start(PMSMBus *s)
>> -{
>> - /* Do not execute immediately the command ; it will be
>> - * executed when guest will read SMB_STAT register */
>> - s->smb_stat |= STS_HOST_BUSY;
>> -}
>> -
>> static void smb_ioport_writeb(void *opaque, hwaddr addr, uint64_t val,
>> unsigned width)
>> {
>> @@ -159,7 +149,7 @@ static void smb_ioport_writeb(void *opaque, hwaddr addr, uint64_t val,
>> case SMBHSTCNT:
>> s->smb_ctl = val;
>> if (val & 0x40)
>> - smb_transaction_start(s);
>> + smb_transaction(s);
>> break;
>> case SMBHSTCMD:
>> s->smb_cmd = val;
>> @@ -191,10 +181,6 @@ static uint64_t smb_ioport_readb(void *opaque, hwaddr addr, unsigned width)
>> switch(addr) {
>> case SMBHSTSTS:
>> val = s->smb_stat;
>> - if (s->smb_stat & STS_HOST_BUSY) {
>> - /* execute command now */
>> - smb_transaction(s);
>> - }
>> break;
>> case SMBHSTCNT:
>> s->smb_index = 0;
>> --
>> 2.7.4
next prev parent reply other threads:[~2018-01-19 14:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 1:55 [Qemu-devel] [PATCH] Revert "smbus: do not immediately complete commands" minyard
2018-01-19 3:17 ` Michael S. Tsirkin
2018-01-19 14:07 ` Corey Minyard [this message]
2018-01-19 21:15 ` Corey Minyard
2018-01-21 17:36 ` Hervé Poussineau
2018-01-22 14:36 ` Corey Minyard
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=19605015-5d30-f91e-3344-32ae4555a7dd@acm.org \
--to=minyard@acm.org \
--cc=cminyard@mvista.com \
--cc=f4bug@amsat.org \
--cc=hpoussin@reactos.org \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).