Re: accessing a PCIe register from userspace through kmem or other ways ?
On Tue, Apr 5, 2016 at 2:10 AM, Konstantin Belousovwrote: > The mmap(2) interface to /dev/mem did not have the issue ever. The problem > was only with the read(2)/write(2) accesses. > I mis-remembered my situation. I was performing a read on /dev/mem rather than reading through a mmap. Thanks for clearing this up. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Tue, Apr 05, 2016 at 08:27:32PM +0300, Konstantin Belousov wrote: > On Tue, Apr 05, 2016 at 10:02:07AM -0700, John Baldwin wrote: > > For the ioctl I planned to either 1) call vm_mmap_object() or the like > > directly > > and return the virtual address to the user, or 2) return the mmap offset to > > use > > from the ioctl that the user would then supply to mmap() and d_mmap_single > > would > > use to find the object created by the ioctl. 1) is probably simpler and is > > more > > what I was leaning towards. Still, I want to be able to handle > > invalidations > > either by pinning the BAR while the object is mapped, or being able to > > invalidate > > the object. Given that you can eject a hotplug PCI device, I think explicit > > invalidation is the better route in this case. I would create a VM object > > for > > each BAR on the first mmap request and save a reference to it in the PCI bus > > ivars. If the BAR is ever cleared I would be able to find the object and > > invalidate it ensuring any programs that then tried to access it would get a > > page fault instead of accessing some other random thing. > > Option 2) is what I discussed, and what has been used for GEM and TTM. > It allows to create an object per buffer (per BAR for /dev/pci case), > and you indeed can easily iterate over managed pages belonging to the > given buffer/BAR because they belong to the object' queue. > > This scheme utilizes d_mmap_single() on the 'global' object (/dev/pci, > /dev/card/dri etc), which takes offset and decodes it into the > buffer/BAR. > > In my opinion, it is prettier than explicit call to vm_mmap_object() > since it leaves all high-level stuff to the VM subsystem proper. Driver > only needs to create the suitable object (and manage offsets). > > On the other hand, GEM has to emulate another Linux interface, where > ioctl() really performs mapping. But again, there it is simpler > to ensure that vm_object for buffer/BAR is created, and then call > vm_map_find((), not even touching middle-level of vm_mmap_object(). See > i915_gem_mmap_ioctl(). > Important thing I forgot about, is that managed fictitious pages, which are created by MGTDEVICE pagers, must be supported by the pmap. It is not hard, the issue is that typical pmap does not make a distinction between unmanaged and fictitious pages. For x86, this was implemented by r224746 + r233168. For other pmaps, r224746 alone might be enough, but it was never tested for clear reasons. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Tue, Apr 05, 2016 at 10:02:07AM -0700, John Baldwin wrote: > For the ioctl I planned to either 1) call vm_mmap_object() or the like > directly > and return the virtual address to the user, or 2) return the mmap offset to > use > from the ioctl that the user would then supply to mmap() and d_mmap_single > would > use to find the object created by the ioctl. 1) is probably simpler and is > more > what I was leaning towards. Still, I want to be able to handle invalidations > either by pinning the BAR while the object is mapped, or being able to > invalidate > the object. Given that you can eject a hotplug PCI device, I think explicit > invalidation is the better route in this case. I would create a VM object for > each BAR on the first mmap request and save a reference to it in the PCI bus > ivars. If the BAR is ever cleared I would be able to find the object and > invalidate it ensuring any programs that then tried to access it would get a > page fault instead of accessing some other random thing. Option 2) is what I discussed, and what has been used for GEM and TTM. It allows to create an object per buffer (per BAR for /dev/pci case), and you indeed can easily iterate over managed pages belonging to the given buffer/BAR because they belong to the object' queue. This scheme utilizes d_mmap_single() on the 'global' object (/dev/pci, /dev/card/dri etc), which takes offset and decodes it into the buffer/BAR. In my opinion, it is prettier than explicit call to vm_mmap_object() since it leaves all high-level stuff to the VM subsystem proper. Driver only needs to create the suitable object (and manage offsets). On the other hand, GEM has to emulate another Linux interface, where ioctl() really performs mapping. But again, there it is simpler to ensure that vm_object for buffer/BAR is created, and then call vm_map_find((), not even touching middle-level of vm_mmap_object(). See i915_gem_mmap_ioctl(). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Tuesday, April 05, 2016 07:21:29 PM Konstantin Belousov wrote: > On Tue, Apr 05, 2016 at 08:55:54AM -0700, John Baldwin wrote: > > Mostly I do not have experience with MGTDEVICE, though I was planning to > > look at it as a way to implement this. Two things though: 1) there may > > not be a cdev to associate with, and 2) I know of at least one device driver > > that would use this in addition to using this for a general "map this BAR" > > ioctl on /dev/pci. > So /dev/pci is the natural cdev to place the functionality. > An ioctl on /dev/pci may mmap BAR and return the base address. > > > There are other cases in the past where I used OBJT_SG > > but would have preferred to use a variant that used managed pages so that > > I could invidate any existing mappings. In particular what I want to do > > is invalidate an object so that any future uses fail. > > > > Alternatively, it might be nice to hook a destructor call into a VM object > > so that I could know when the object is no longer in use (knowing that all > > its mappings have been destroyed). When using OBJT_SG objects as aliases > > for other things (memory allocated via contigmalloc or bus_dma or for > > resources like PCI BARs), I could keep a reference count on the original > > "thing" that I increment when creating an OBJT_SG object to return from > > something like d_mmap_single() or the /dev/pci ioctl and drop the reference > > count in the destructor hook for that object. > This is in essence how GEM objects + MGTDEVICE mappings work for i915. > > The only bottleneck in the API arrangement is that d_mmap_single() only > gets the offset as the identifying data to construct the mapping. > For /dev/pci, the offset parameter would need to encode d:b:s:f and BAR > index. For the ioctl I planned to either 1) call vm_mmap_object() or the like directly and return the virtual address to the user, or 2) return the mmap offset to use from the ioctl that the user would then supply to mmap() and d_mmap_single would use to find the object created by the ioctl. 1) is probably simpler and is more what I was leaning towards. Still, I want to be able to handle invalidations either by pinning the BAR while the object is mapped, or being able to invalidate the object. Given that you can eject a hotplug PCI device, I think explicit invalidation is the better route in this case. I would create a VM object for each BAR on the first mmap request and save a reference to it in the PCI bus ivars. If the BAR is ever cleared I would be able to find the object and invalidate it ensuring any programs that then tried to access it would get a page fault instead of accessing some other random thing. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Tue, Apr 05, 2016 at 08:55:54AM -0700, John Baldwin wrote: > Mostly I do not have experience with MGTDEVICE, though I was planning to > look at it as a way to implement this. Two things though: 1) there may > not be a cdev to associate with, and 2) I know of at least one device driver > that would use this in addition to using this for a general "map this BAR" > ioctl on /dev/pci. So /dev/pci is the natural cdev to place the functionality. An ioctl on /dev/pci may mmap BAR and return the base address. > There are other cases in the past where I used OBJT_SG > but would have preferred to use a variant that used managed pages so that > I could invidate any existing mappings. In particular what I want to do > is invalidate an object so that any future uses fail. > > Alternatively, it might be nice to hook a destructor call into a VM object > so that I could know when the object is no longer in use (knowing that all > its mappings have been destroyed). When using OBJT_SG objects as aliases > for other things (memory allocated via contigmalloc or bus_dma or for > resources like PCI BARs), I could keep a reference count on the original > "thing" that I increment when creating an OBJT_SG object to return from > something like d_mmap_single() or the /dev/pci ioctl and drop the reference > count in the destructor hook for that object. This is in essence how GEM objects + MGTDEVICE mappings work for i915. The only bottleneck in the API arrangement is that d_mmap_single() only gets the offset as the identifying data to construct the mapping. For /dev/pci, the offset parameter would need to encode d:b:s:f and BAR index. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Tuesday, April 05, 2016 09:14:31 AM Konstantin Belousov wrote: > On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > > However, another question is how to deal with systems that do bus address > > translation (like the arm64 ThunderX boxes) where the values in the PCI > > BAR are not CPU physical addresses. To do this properly we may need some > > sort of bus method akin to my bus_map_resource() WIP but one that instead > > returns a suitable 'struct sglist' for a given 'struct resource *' that > > can be used with OBJT_SG to build a VM object to use for the mapping. > Is there any documentation on the ThunderX PCI access mechanisms ? The Host-PCI (or really some other bus -> PCI) bridges apply a fixed offset to PCI addresses, so if your BAR has address X written to it, the CPU has to use an address of X + Y (where Y is the PCI window base address) to access it. The bridge device decodes the access to address X + Y and generates a PCI transaction to address X. It's not clear to me how DMA works for these devices (e.g. if all DMA requests from PCI devices have to use an IOMMU built into the bridge). > > (At some point I do think I would like a variant of OBJT_SG that used > > managed pages so that mappings could be revoked when whatever is backing > > the sglist is disabled (e.g. the device is ejected or the BAR is > > relocated, etc.).) > Why cannot you use MGTDEVICE pager already ? Driver would need to > maintain its private list of pages, and from this PoV, a convenience > wrapper around MGTDEVICE which unifies operations on sg lists could be > useful. Still, it could be that the wrapper appear to be single-purpose. Mostly I do not have experience with MGTDEVICE, though I was planning to look at it as a way to implement this. Two things though: 1) there may not be a cdev to associate with, and 2) I know of at least one device driver that would use this in addition to using this for a general "map this BAR" ioctl on /dev/pci. There are other cases in the past where I used OBJT_SG but would have preferred to use a variant that used managed pages so that I could invidate any existing mappings. In particular what I want to do is invalidate an object so that any future uses fail. Alternatively, it might be nice to hook a destructor call into a VM object so that I could know when the object is no longer in use (knowing that all its mappings have been destroyed). When using OBJT_SG objects as aliases for other things (memory allocated via contigmalloc or bus_dma or for resources like PCI BARs), I could keep a reference count on the original "thing" that I increment when creating an OBJT_SG object to return from something like d_mmap_single() or the /dev/pci ioctl and drop the reference count in the destructor hook for that object. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > However, another question is how to deal with systems that do bus address > translation (like the arm64 ThunderX boxes) where the values in the PCI > BAR are not CPU physical addresses. To do this properly we may need some > sort of bus method akin to my bus_map_resource() WIP but one that instead > returns a suitable 'struct sglist' for a given 'struct resource *' that > can be used with OBJT_SG to build a VM object to use for the mapping. Is there any documentation on the ThunderX PCI access mechanisms ? > > (At some point I do think I would like a variant of OBJT_SG that used > managed pages so that mappings could be revoked when whatever is backing > the sglist is disabled (e.g. the device is ejected or the BAR is > relocated, etc.).) Why cannot you use MGTDEVICE pager already ? Driver would need to maintain its private list of pages, and from this PoV, a convenience wrapper around MGTDEVICE which unifies operations on sg lists could be useful. Still, it could be that the wrapper appear to be single-purpose. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Mon, Apr 04, 2016 at 09:02:49PM -0700, John Baldwin wrote: > kib@ fixed /dev/mem to handle addresses beyond the direct map limit to use > temporary mappings instead of failing with EFAULT in 277051 which was only > committed to HEAD last January, so well after 8.2. The mmap(2) interface to /dev/mem did not have the issue ever. The problem was only with the read(2)/write(2) accesses. >From what I understand, since the goal of the OP was to measure BAR access latencies, read(2) (or write) is unsuitable for him for obvious reasons. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Monday, April 04, 2016 08:58:47 PM Ryan Stone wrote: > On Mon, Apr 4, 2016 at 6:45 PM, John Baldwinwrote: > > > I suspect Ryan might be referring to BARs outside of the DMAP which we > > only populate to Maxmem IIRC. /dev/mem should work for those. > > > > Unfortunately I no longer have access to the systems so I can't really > confirm. I had a debug tool that attempted to read PCI device registers > through /dev/mem, and on these systems (which were running a 8.2 > derivative) the reads from /dev/mem failed with some kind of error. > > The one detail that I do remember is that the errors started happening > after we enabled the use of 64-bit BARs in the BIOS and the addresses > assigned to the BARs were quite large -- I believe well beyond the bounds > of real memory. kib@ fixed /dev/mem to handle addresses beyond the direct map limit to use temporary mappings instead of failing with EFAULT in 277051 which was only committed to HEAD last January, so well after 8.2. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Mon, Apr 4, 2016 at 6:45 PM, John Baldwinwrote: > I suspect Ryan might be referring to BARs outside of the DMAP which we > only populate to Maxmem IIRC. /dev/mem should work for those. > Unfortunately I no longer have access to the systems so I can't really confirm. I had a debug tool that attempted to read PCI device registers through /dev/mem, and on these systems (which were running a 8.2 derivative) the reads from /dev/mem failed with some kind of error. The one detail that I do remember is that the errors started happening after we enabled the use of 64-bit BARs in the BIOS and the addresses assigned to the BARs were quite large -- I believe well beyond the bounds of real memory. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Friday, April 01, 2016 08:04:58 PM Konstantin Belousov wrote: > On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote: > > That is actually a really good question. I know that with some recent > > BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would > > actually be mapped outside of the range of /dev/mem. From a quick glance > > at libpciaccess, I don't think that it handles this case. A specific > > mechanism for allowing mmaping of BARs would be useful, I think. > > I am not sure what do you mean by 'outside of the range of /dev/mem'. > IMO /dev/mem (not kmem) handles every possible physical address both > for mmap(2) and for read(2)/write(2). For io interface there were > some bugs, but they are believed to be fixed. I mean amd64. I suspect Ryan might be referring to BARs outside of the DMAP which we only populate to Maxmem IIRC. /dev/mem should work for those. However, another question is how to deal with systems that do bus address translation (like the arm64 ThunderX boxes) where the values in the PCI BAR are not CPU physical addresses. To do this properly we may need some sort of bus method akin to my bus_map_resource() WIP but one that instead returns a suitable 'struct sglist' for a given 'struct resource *' that can be used with OBJT_SG to build a VM object to use for the mapping. (At some point I do think I would like a variant of OBJT_SG that used managed pages so that mappings could be revoked when whatever is backing the sglist is disabled (e.g. the device is ejected or the BAR is relocated, etc.).) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote: > That is actually a really good question. I know that with some recent > BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would > actually be mapped outside of the range of /dev/mem. From a quick glance > at libpciaccess, I don't think that it handles this case. A specific > mechanism for allowing mmaping of BARs would be useful, I think. I am not sure what do you mean by 'outside of the range of /dev/mem'. IMO /dev/mem (not kmem) handles every possible physical address both for mmap(2) and for read(2)/write(2). For io interface there were some bugs, but they are believed to be fixed. I mean amd64. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Fri, Apr 1, 2016 at 12:31 PM, John Baldwinwrote: > Sorry, I mapped PCIe registers to the PCI-e config space register set. I > am > not sure exactly how libpciaccess handles register access (perhaps it reads > raw bars and maps them via /dev/mem)? However, it would not be hard to a > new ioctl to /dev/pci to allow one to mmap a specific BAR of a given > device. > That is actually a really good question. I know that with some recent BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would actually be mapped outside of the range of /dev/mem. From a quick glance at libpciaccess, I don't think that it handles this case. A specific mechanism for allowing mmaping of BARs would be useful, I think. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Friday, April 01, 2016 01:07:55 PM Luigi Rizzo wrote: > On Thu, Mar 31, 2016 at 11:55 PM, Ryan Stonewrote: > > > On Thu, Mar 31, 2016 at 4:39 PM, John Baldwin wrote: > > > >> On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote: > >> > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo > >> wrote: > >> > > >> > > Hi, > >> > > I'd like to test the rate at which I can access device registers > >> > > on a PCIe card, and was wondering whether I need to patch a device > >> > > driver, or perhaps I can use /dev/kmem once I figure out where > >> > > the registers are mapped ? > >> > > > >> > > >> > You do not need to patch a device driver. Have you looked at > >> > libpciaccess? This should give you everything you need. > >> > >> You can also look at what pciconf uses. (It has a read_config() method > >> that uses an ioctl on an fd of /dev/pci). > >> > > > > pciconf can only access the configuration space, right? I believe that > > Luigi is more interested in measuring the latency to a register mapped from > > a BAR. > > > > Thank you all for you answers, I will look at libpciaccess. > > Yes my goal is to look at the rate and latency for accessing > BAR-mapped registers Sorry, I mapped PCIe registers to the PCI-e config space register set. I am not sure exactly how libpciaccess handles register access (perhaps it reads raw bars and maps them via /dev/mem)? However, it would not be hard to a new ioctl to /dev/pci to allow one to mmap a specific BAR of a given device. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Thu, Mar 31, 2016 at 11:55 PM, Ryan Stonewrote: > On Thu, Mar 31, 2016 at 4:39 PM, John Baldwin wrote: > >> On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote: >> > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo >> wrote: >> > >> > > Hi, >> > > I'd like to test the rate at which I can access device registers >> > > on a PCIe card, and was wondering whether I need to patch a device >> > > driver, or perhaps I can use /dev/kmem once I figure out where >> > > the registers are mapped ? >> > > >> > >> > You do not need to patch a device driver. Have you looked at >> > libpciaccess? This should give you everything you need. >> >> You can also look at what pciconf uses. (It has a read_config() method >> that uses an ioctl on an fd of /dev/pci). >> > > pciconf can only access the configuration space, right? I believe that > Luigi is more interested in measuring the latency to a register mapped from > a BAR. > Thank you all for you answers, I will look at libpciaccess. Yes my goal is to look at the rate and latency for accessing BAR-mapped registers cheers luigi -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Thu, Mar 31, 2016 at 4:39 PM, John Baldwinwrote: > On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote: > > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo > wrote: > > > > > Hi, > > > I'd like to test the rate at which I can access device registers > > > on a PCIe card, and was wondering whether I need to patch a device > > > driver, or perhaps I can use /dev/kmem once I figure out where > > > the registers are mapped ? > > > > > > > You do not need to patch a device driver. Have you looked at > > libpciaccess? This should give you everything you need. > > You can also look at what pciconf uses. (It has a read_config() method > that uses an ioctl on an fd of /dev/pci). > pciconf can only access the configuration space, right? I believe that Luigi is more interested in measuring the latency to a register mapped from a BAR. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote: > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzowrote: > > > Hi, > > I'd like to test the rate at which I can access device registers > > on a PCIe card, and was wondering whether I need to patch a device > > driver, or perhaps I can use /dev/kmem once I figure out where > > the registers are mapped ? > > > > You do not need to patch a device driver. Have you looked at > libpciaccess? This should give you everything you need. You can also look at what pciconf uses. (It has a read_config() method that uses an ioctl on an fd of /dev/pci). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: accessing a PCIe register from userspace through kmem or other ways ?
On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzowrote: > Hi, > I'd like to test the rate at which I can access device registers > on a PCIe card, and was wondering whether I need to patch a device > driver, or perhaps I can use /dev/kmem once I figure out where > the registers are mapped ? > You do not need to patch a device driver. Have you looked at libpciaccess? This should give you everything you need. -Jim > thanks > luigi > > -- > -+--- > Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/. Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -+--- > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"