Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL

[Neel Chauhan]

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 at .

-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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscribe at freebsd.org"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20210104/e6d9da94/attachment.sig>