All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mateusz Nowicki <nowicki@posteo.net>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [Question] Custom MMIO handler - is it possible?
Date: Thu, 01 Feb 2024 15:38:42 +0000	[thread overview]
Message-ID: <ISO68S.RPAGJSCS217U3@posteo.net> (raw)
In-Reply-To: <20240131212009.GA601947@bhelgaas>

Thanks for a quick reply Bjorn!

Actually performance is not the biggest concern.
Mmiotrace has documented SMP race condition:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/trace/mmiotrace.rst#n135

Also playing correctly with page fault is quite a challenge. I'm trying 
to find a simpler/easier solution :)

Thanks for Qemu tip! I'll take a look


On Wed, Jan 31 2024 at 15:20:09 -06:00:00, Bjorn Helgaas 
<helgaas@kernel.org> wrote:
> On Wed, Jan 31, 2024 at 08:42:18PM +0000, nowicki@posteo.net wrote:
>>  Hello,
>> 
>>  I'm trying to implement a fake PCIe device and I'm looking for 
>> guidance (by
>>  fake I mean fully software device).
>> 
>>  So far I implemented:
>>  - fake PCIe bus with custom fake pci_ops.read & pci_ops.write 
>> functions
>>  - fake PCIe switch
>>  - fake PCIe endpoint
>> 
>>  Fake devices have implemented PCIe registers and are visible in 
>> user space
>>  via lspci tool.
>>  Registers can be edited via setpci tool.
>> 
>>  Now I'm looking for a way to implement BAR regions with custom 
>> memory
>>  handlers. Is it even possible?
>>  Basically I'd like to capture each MemoryWrite & MemoryRead 
>> targeted for
>>  PCIe endpoint's BAR region and emulate NVMe registers.
>> 
>>  I'm in dead-end right now and I'm seeing only two options:
>>  - generate page faults on every access to fake BAR region and 
>> execute fake
>>  PCIe endpoint's callbacks - similar/the same as mmiotrace
>>  - periodically scan fake BAR region for any changes
>> 
>>  Both solutions have drawbacks.
>>  Is there other way to implement fake BAR region?
> 
> Sounds kind of cool and potentially useful to build kernel test tools.
> 
> Is the page fault on access option a problem because you want better
> performance?  I assume you really *want* to know about every write and
> possibly even every read, so a page fault seems like the way to do
> that.
> 
> Maybe qemu would have some ideas?  I assume it implements some similar
> things.
> 
> Bjorn



  reply	other threads:[~2024-02-01 15:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 20:42 [Question] Custom MMIO handler - is it possible? nowicki
2024-01-31 21:20 ` Bjorn Helgaas
2024-02-01 15:38   ` Mateusz Nowicki [this message]
2024-02-01 18:06     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ISO68S.RPAGJSCS217U3@posteo.net \
    --to=nowicki@posteo.net \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.