linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: John Garry <john.garry@huawei.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Marc Zyngier" <maz@kernel.org>, "Will Deacon" <will@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	syzkaller <syzkaller@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: arm64 syzbot instances
Date: Mon, 22 Mar 2021 16:49:24 +0000	[thread overview]
Message-ID: <CAFEAcA9d5NLUcn_wdj=pUWEW9arRcZnOwUuqtoSep=FSjpB_Tw@mail.gmail.com> (raw)
In-Reply-To: <771d89a8-b7e0-6095-b101-e7ae91bcdc85@huawei.com>

On Mon, 22 Mar 2021 at 16:36, John Garry <john.garry@huawei.com> wrote:
>
> >>
> >> There's apparently a bit in the PCI spec that reads:
> >>          The host bus bridge, in PC compatible systems, must return all
> >>          1's on a read transaction and discard data on a write transaction
> >>          when terminated with Master-Abort.
> >>
> >> which obviously applies only to "PC compatible systems".
> >
> > Right. As far as I can tell, all ARMv8 and most ARMv7 based SoCs
> > do this to be more compatible with PC style operating systems like
> > Linux, but you are right that the specification here does not
> > mandate that, and the older ARMv5 SoCs seem to be compliant
> > as well based on this.

> >> TBH I'm having difficulty seeing why the kernel should be doing
> >> this at all, though. The device tree tells you you have a PCI
> >> controller; PCI supports enumeration of devices; you know exactly
> >> where everything is mapped because the BARs tell you that.
> >> I don't see anything that justifies the kernel in randomly
> >> dereferencing areas of the IO or memory windows where it hasn't
> >> mapped anything.
>
> BIOS has described a CPU-addressable PIO region in the PCI hostbridge,
> and the kernel has mapped it:
>
> [    3.974309][    T1] pci-host-generic 4010000000.pcie:       IO
> 0x003eff0000..0x003effffff -> 0x0000000000
>
> So I don't see why any accesses there should fault.

As requested above, do you have the PCI spec reference for
why the PIO region is supposed to do -1/discard for parts of
the PIO region where the kernel hasn't mapped any devices ?
For classic PCI, at least, the spec does not seem to mandate it.

thanks
-- PMM

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2021-03-22 16:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 11:38 arm64 syzbot instances Dmitry Vyukov
2021-03-11 12:33 ` Mark Rutland
2021-03-11 16:56   ` Dmitry Vyukov
2021-03-17 18:45     ` Mark Rutland
2021-03-18  8:32       ` Dmitry Vyukov
2021-03-11 17:11   ` Dmitry Vyukov
2021-03-11 13:30 ` Arnd Bergmann
2021-03-11 17:25   ` Dmitry Vyukov
2021-03-12  6:42     ` Dmitry Vyukov
2021-03-11 17:57   ` Dmitry Vyukov
2021-03-12  8:39     ` Arnd Bergmann
2021-03-12  8:46       ` Dmitry Vyukov
2021-03-12  9:16         ` Arnd Bergmann
2021-03-12  9:21           ` Dmitry Vyukov
2021-03-12 10:10             ` Arnd Bergmann
2021-03-12 10:38               ` Dmitry Vyukov
2021-03-12 10:52                 ` Arnd Bergmann
2021-03-15  9:43                   ` John Garry
2021-03-15 10:01                     ` Dmitry Vyukov
2021-03-15 10:29                       ` John Garry
2021-03-15 10:34                         ` Dmitry Vyukov
2021-03-15 11:11                         ` Arnd Bergmann
2021-03-20 20:43           ` Peter Maydell
2021-03-21 11:52             ` Arnd Bergmann
2021-03-21 11:55               ` Arnd Bergmann
2021-03-21 18:59             ` Arnd Bergmann
2021-03-22 13:51               ` Peter Maydell
2021-03-22 15:42                 ` Arnd Bergmann
2021-03-22 16:34                   ` John Garry
2021-03-22 16:49                     ` Peter Maydell [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='CAFEAcA9d5NLUcn_wdj=pUWEW9arRcZnOwUuqtoSep=FSjpB_Tw@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dvyukov@google.com \
    --cc=john.garry@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=will@kernel.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).