Re: accessing a PCIe register from userspace through kmem or other ways ?

[Ryan Stone]

On Tue, Apr 5, 2016 at 2:10 AM, Konstantin Belousov 
wrote:

> 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 ?

[Konstantin Belousov]

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 ?

[Konstantin Belousov]

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 ?

[John Baldwin]

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 ?

[Konstantin Belousov]

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 ?

[John Baldwin]

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 ?

[Konstantin Belousov]

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 ?

[Konstantin Belousov]

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 ?

[John Baldwin]

On Monday, April 04, 2016 08:58:47 PM Ryan Stone wrote:
> On Mon, Apr 4, 2016 at 6:45 PM, John Baldwin  wrote:
> 
> > 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 ?

[Ryan Stone]

On Mon, Apr 4, 2016 at 6:45 PM, John Baldwin  wrote:

> 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 ?

[John Baldwin]

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 ?

[Konstantin Belousov]

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 ?

[Ryan Stone]

On Fri, Apr 1, 2016 at 12:31 PM, John Baldwin  wrote:

> 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 ?

[John Baldwin]

On Friday, April 01, 2016 01:07:55 PM Luigi Rizzo wrote:
> On Thu, Mar 31, 2016 at 11:55 PM, Ryan Stone  wrote:
> 
> > 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 ?

[Luigi Rizzo]

On Thu, Mar 31, 2016 at 11:55 PM, Ryan Stone  wrote:

> 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 ?

[Ryan Stone]

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.
___
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 ?

[John Baldwin]

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

-- 
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 ?

[Jim Harris]

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.


-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"