From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexander Graf <agraf@suse.de>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] RFC: hcd-ohci: add dma error handling
Date: Wed, 17 Jul 2013 22:47:04 +1000 [thread overview]
Message-ID: <1374065224.19894.464.camel@pasglop> (raw)
In-Reply-To: <837907FD-06ED-4E0C-AD23-436ACA49789A@suse.de>
On Wed, 2013-07-17 at 14:31 +0200, Alexander Graf wrote:
> On 17.07.2013, at 13:15, Benjamin Herrenschmidt wrote:
>
> > On Wed, 2013-07-17 at 19:46 +1000, Alexey Kardashevskiy wrote:
> >> Current hcd-ohci does not handle DMA errors which can actually
> >> happen.
> >>
> >> However it is not clear what approach should be used here -
> >> for example, get_dwords returns positive number saying that there
> >> is no error as all the callers consider the return value as fail
> >> if it is less than zero. Normally you would expect bool=true/int=0
> >> as success and bool=false/int=-1 as fail.
> >>
> >> Any suggestion?
> >
> > The right thing to do is not only to bring the error up the stack, but
> > essentially to set the error bits in the PCI command status and put the
> > whole HCI in error state (and stop operating)
> >
> > That how real HW reacts.
>
> Who does that? I always assumed it's the IOMMU that kills the device
> when it accesses regions it's not allowed to access.
Hah, no, iommu's only "kill devices" on fancy HW like powerpc :-)
On these, when any kind of error occur, we isolate the entire thing.
> On real hardware, memory transfers don't have error return codes, do they?
No they sort-of do :-)
For example, on PCI, there are 3 common causes of errors: Parity, Target
Aborts and Master Aborts. The former is somewhat obvious, the second
means the target aborted the cycle before completion, the latter usually
means no target responded (timeout). There are two physical lines used
to convey error informations (and potentially abort cycles), PERR and
SERR.
Depending on the details of the bus protocol, the error causes can be a
bit different. On PCIe you can actually shoot error messages up the
link, transactions are packets and can result in an error response,
etc...
Since qemu mostly emulates PCI, let's stick to that. An iommu error will
typically be a target abort. So the device should react as such.
A typical O/EHCI will stop operating, set itself into error state (which
can be queried by MMIO) and will set something like PERR in its config
space to signal that it got an error.
Cheers,
Ben.
prev parent reply other threads:[~2013-07-17 12:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 9:46 [Qemu-devel] [PATCH] RFC: hcd-ohci: add dma error handling Alexey Kardashevskiy
2013-07-17 11:15 ` Benjamin Herrenschmidt
2013-07-17 12:31 ` Alexander Graf
2013-07-17 12:47 ` Benjamin Herrenschmidt [this message]
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=1374065224.19894.464.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=aliguori@us.ibm.com \
--cc=kraxel@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).