Re: PCI extended configuration support

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

 Hi, Jonathan.

On 2015/09/09 23:02, Jonathan A. Kollasch wrote:
> On Tue, Sep 08, 2015 at 12:58:31PM +0900, MAEKAWA Masahide wrote:
> > On 2015/09/08 0:59, Jonathan A. Kollasch wrote:
> > >    - abuse of the pcitag_t  (I have patches that fix this.)
> >
> > Your patches? Where? your local?
>
> Attached.  This has been successfully tested on a machine that uses
> Mode 2 configuration access.  Mode 2 is very rare nowadays, and is being
> misdetected more often now that firmware is placing IO ports up in the
> 0xC000ish range.  The Mode 2 tag is incapable of representing a complete
> PCI Bus,Device,Function tuple, and thus has no place being a generic
> representation of a BDF for use by any configuration access method.
> This patch makes the x86 pcitag_t a simple BDF.

 Thanks. Why you haven't committed that change? I think it's OK to commit.

> > >    - pci_conf_size() is unnecessary
> >
> > Why?
>
> Because there's no need to care.  We already support extended
> configuration space on some evbmips/arm, and haven't needed it yet.
> Just read back 0xffffffff and ignore writes if extended configuration is
> inaccessible.  No need to bloat the API and kernel.

　You mean the range check should be modified in all MD part?
And also, MI driver should check the ability of accessing extended
configuration area with:

	a) the return value of pci_get_ext_capability()
or
	b) write code in each driver

Only small number of driver will be required to use b), so it might
be OK to provide MI function to do it now.

And,

>  - too much ACPI dependence, there's nothing that says you have to use
>    ACPI MCFG to get this information

 I think updated patch solved the prolbem (see below)

>  - possibility of too much KVA usage on 32-bit kernels
>
>  - on-demand bus mapping may happen in inappropriate (interrupt) context

 In old patch, all bus area which was accessed were mapped and never unmapped.
In updated patch, configuration areas are mapped when a pci bus are attached (pci<n>).
And then, if there is no any devices in the bus, it's unmapped. Is it OK?

>  - x86 bus_space_read/write functions do not use the %eax/ax/al register,
>  as required by the AMD documentation for Family 10h's (and others) extended
>  configuration space access.

 We have not known it. Thanks. It's fixed in the new patch.

	http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/tmp/20150911-nbsd-pci-extconf-support.diff

Could you check again?

 And, I suspect that you have other diffs locally, could we share your diff?

> 	Jonathan Kollasch


--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)