From owner-freebsd-hackers@freebsd.org Tue Jan 5 02:36:49 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3E464D5912 for ; Tue, 5 Jan 2021 02:36:49 +0000 (UTC) (envelope-from nc@freebsd.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8xTY36hkz4rPd; Tue, 5 Jan 2021 02:36:49 +0000 (UTC) (envelope-from nc@freebsd.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 9CD9BEB2A5; Mon, 4 Jan 2021 18:36:44 -0800 (PST) MIME-Version: 1.0 Date: Mon, 04 Jan 2021 18:36:44 -0800 From: Neel Chauhan To: Doug Ambrisko Cc: Mark Johnston , freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: <20210102190644.GB87535@ambrisko.com> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> <20201231200744.GA95383@ambrisko.com> <4f3f6a02a452f766063ae2acb060dc64@neelc.org> <7cda3be6594d5ad5bdc69019f72b03d3@neelc.org> <20210102190644.GB87535@ambrisko.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <1aa63edbf7abb4f6b3f0d8c18bd948e0@freebsd.org> X-Sender: nc@freebsd.org Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_4445c4a291a95b8c663417445d53c4d7"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4D8xTY36hkz4rPd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 02:36:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_4445c4a291a95b8c663417445d53c4d7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Unrelated to VMD, but I have recently gotten a Ports commit bit and now have a @FreeBSD.org email, in case you wanted to know who to give credit to. It's still me, and it forwards to ${FIRSTNAME}@neelc.org. My handle is nc@. -Neel On 2021-01-02 11:06, Doug Ambrisko wrote: > With VMD, the PCI "root" is hidden behind it. To access devices behind > the VMD device, a new domain is created and when PCI config. space > is accessed, it is indexed via the VMD device via the offset. Intel > seems to have reduced the available bus space on some HW. So for a bus > access less then what they implemented in HW we have to return error > that nothing is there. Then when we get to the starting bus device, > we need to offset that to 0 based in the HW. The PCI probe will run > look for busses from 0 to 255. From the Linux driver your HW only > works > from 224 to 255. So we need to fail anything under 224 and for bus > requests 224 and higher then subtract 224. Thus the b - > sc->vmd_bus_start > part. I'm not sure if we could do it the other way in which we allow > 0-12 bus requests to pass and fail if it is over. I'm not sure if > there is any specific reason why that wouldn't work. Linux didn't > do that but that doesn't mean it wouldn't work. It would be good to > start with the Linux method and then test 0-n, where n is the max. > busses that HW allows. Anything n or more would have to return a fail. > > Doug A. > > On Sat, Jan 02, 2021 at 09:20:20AM -0800, Neel Chauhan wrote: > | Just to ping you in case you may have missed my reply (I understand, > New > | Years Day). > | > | Is there a reason why "b = pci_get_bus(dev);" return 0 even when the > bus > | number is shifted (as it is on Linux)? > | > | -Neel > | > | On 2020-12-31 21:49, Neel Chauhan wrote: > | > Hi Doug, > | > > | > Thank you so much for this information. > | > > | > On 2020-12-31 12:07, Doug Ambrisko wrote: > | >> FYI, looks like this needs to be ported over from Linux: > | >> static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct > pci_bus > | >> *bus, > | >> unsigned int devfn, int reg, int > | >> len) > | >> { > | >> char __iomem *addr = vmd->cfgbar + > | >> ((bus->number - vmd->busn_start) << > 20) + > | >> (devfn << 12) + reg; > | >> > | >> to > | >> vmd_read_config > | >> offset = (b << 20) + (s << 15) + (f << 12) + reg; > | >> > | >> vmd_write_config(device_t dev, u_int b, u_int s, u_int f, u_int > reg, > | >> offset = (b << 20) + (s << 15) + (f << 12) + reg; > | >> > | >> ie. > | >> offset = ((b - sc->vmd_bus_start) << 20) + (s << 15) + (f << 12) > + > | >> reg; > | >> > | >> vmd_bus_start should be added to the softc as a uint8_t type and > needs > | >> to > | >> be set via attach. We need range checks to make sure > | >> vmd_write_config/vmd_read_config doesn't read something out of > range > | >> since it has been reduced. > | > > | > One thing I noticed is that the "b" variable (which corresponds to > the > | > Linux bus->number) is 0 (thanks to printf). This should be the bus > | > number if we want to attach. > | > > | > If I use: "b = pci_get_bus(dev);" in the attach, b is still 0. > | > > | > And that leads to a kernel panic. > | > > | >> Not sure what the shadow registers do. These both seem to be new > | >> Intel > | >> features and Intel doc's have been minimal. Looks like Intel is > doing > | >> a sparse map now on newer devices. > | > > | > I guess Linux is our best hope. Unless the new Intel docs is the > Linux > | > kernel source. > | > > | >> I'm concerned about the Linux comment of: > | >> * Certain VMD devices may have a root port configuration > | >> option which > | >> * limits the bus range to between 0-127, 128-255, or > 224-255 > | >> > | >> since I don't see anything to limit it between 0-127 only starting > | >> at 0, 128 or 224, Maybe there is max of 128 busses overall? > | > > | > I could be wrong, but I guess that's a typo. > | > > | >> I don't have this type of HW to test things. > | > > | > I can use my hardware for testing. In the worse case scenario, I > can > | > donate an entry-level 11th Gen/TigerLake system if I have the funds > | > and/or can get a tax credit. > | > > | >> Doug A. > | > > | > -Neel > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" --=_4445c4a291a95b8c663417445d53c4d7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=488 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFpeUj+sDItoNIly9vzSRBRPfYX0FAl/z0LwACgkQvzSRBRPf YX0PPwf8D8yQGlQG8SwVvT+H+joEPHN2T2EGsxn71R18eRzEZ36jmrMxKRGRvVLa G0FMwvBvXYxp1l4nGXSIpod4IWW9aibsXZby7acbOgfNoH0JLLsK5t3w369lzb/2 xc6oYy01+C6dqsWHMSGtaRA4HV4OdrDzwq4oyuML95e1qP9ifwtGGsu9ClTzAiyA u75PB5l1wvja0gy/HVXF6A8ln+Ctnb/a0NIBJiCXLb8uic9ilB8cbOND5JN2sHUZ mlozemDauWUQoU1BDCLdRmXOlTPQjXxYC5DWMFuQcoHmAa3fwWpLw8KLp8dtOS+H xUv5thKRbfOqx3hj0NZUCsipN09spQ== =90/K -----END PGP SIGNATURE----- --=_4445c4a291a95b8c663417445d53c4d7--