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 ?
thanks
luigi
--
-+
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 d
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
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 wonderin
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
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
> >>
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 ioc
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
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
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
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 acc
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
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 b
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
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 wo
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 cde
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_mm
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
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. Thank
19 matches
Mail list logo
