From: John Snow <jsnow@redhat.com>
To: tasleson@redhat.com, Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Qemu-block <qemu-block@nongnu.org>
Subject: Re: [RFC 4/4] ahci media error reporting
Date: Fri, 20 Sep 2019 15:29:16 -0400 [thread overview]
Message-ID: <ad9d3676-fd1c-b76c-db35-82a77a916705@redhat.com> (raw)
In-Reply-To: <549bb50e-7300-48e7-4de6-47976770b9ca@redhat.com>
On 9/20/19 3:25 PM, Tony Asleson wrote:
> On 9/20/19 11:18 AM, John Snow wrote:
>> For sure -- I handle the normative cases, but I don't test what happens
>> if you issue an unsupported NCQ command. (I don't know what real
>> hardware does right now, either. I'm sure I could read the spec and find
>> out, but don't have a testing setup that lets me analyze real hardware
>> anymore.)
>
> Regardless of what actual hardware does, it's always good to see what
> the spec says as hardware folks get it wrong too sometimes :-)
>
> -Tony
>
That depends. If we're emulating an "AHCI device", we should follow the
spec, but the one we instantiate in QEMU is the ICH9 version, so we try
to follow the hardware.
I do wind up looking at both, but because the relevant specs are split
across SATA, AHCI, ATA, ATAPI and into SCSI sometimes, (plus sub-specs)
it can be hard to piece together a holistic picture of what should
happen sometimes.
Looking at hardware is sometimes quicker and more definitive :)
Anyway, none of this helps you out much, but I will at least stay tuned
to review AHCI code and can try to help you make better incisions.
Enjoy your weekend!
--js
next prev parent reply other threads:[~2019-09-20 19:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 19:48 [RFC 0/4] POC: Generating realistic block errors Tony Asleson
2019-09-19 19:48 ` [RFC 1/4] Add qapi for block error injection Tony Asleson
2019-09-20 9:03 ` Philippe Mathieu-Daudé
2019-09-20 15:17 ` Tony Asleson
2019-09-19 19:48 ` [RFC 2/4] SCSI media error reporting Tony Asleson
2019-09-19 19:48 ` [RFC 3/4] NVMe " Tony Asleson
2019-09-19 19:48 ` [RFC 4/4] ahci " Tony Asleson
2019-09-19 20:43 ` John Snow
2019-09-19 21:49 ` Tony Asleson
2019-09-20 17:22 ` John Snow
2019-09-20 8:43 ` Kevin Wolf
2019-09-20 16:18 ` John Snow
2019-09-20 19:25 ` Tony Asleson
2019-09-20 19:29 ` John Snow [this message]
2019-09-20 8:36 ` [RFC 0/4] POC: Generating realistic block errors Kevin Wolf
2019-09-20 16:41 ` Tony Asleson
2019-09-20 17:08 ` Eric Blake
2019-09-20 19:15 ` Tony Asleson
2019-09-20 18:11 ` Kevin Wolf
2019-09-20 18:55 ` Tony Asleson
2019-09-30 14:54 ` Kevin Wolf
2019-09-20 9:22 ` Stefan Hajnoczi
2019-09-20 17:28 ` Tony Asleson
2019-11-14 15:47 ` Tony Asleson
2019-11-21 10:30 ` Stefan Hajnoczi
2019-11-21 11:12 ` Kevin Wolf
2019-11-26 18:19 ` Tony Asleson
2019-11-26 19:28 ` Kevin Wolf
2019-09-20 9:25 ` Stefan Hajnoczi
2019-09-20 14:41 ` no-reply
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=ad9d3676-fd1c-b76c-db35-82a77a916705@redhat.com \
--to=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=tasleson@redhat.com \
/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).