From: Andrzej Jakowski <andrzej.jakowski@linux.intel.com>
To: Klaus Jensen <its@irrelevant.dk>
Cc: kbusch@kernel.org, kwolf@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [PATCH v4 2/2] nvme: allow cmb and pmr to be enabled on same device
Date: Tue, 21 Jul 2020 14:54:19 -0700 [thread overview]
Message-ID: <9143a543-d32d-f3e7-c37b-b3df7f853952@linux.intel.com> (raw)
In-Reply-To: <20200715080658.GA506302@apples.localdomain>
On 7/15/20 1:06 AM, Klaus Jensen wrote:
> Hi Andrzej,
>
> I've not been ignoring this, but sorry for not following up earlier.
>
> I'm hesitent to merge anything that very obviously breaks an OS that we
> know is used a lot to this using this device. Also because the issue has
> not been analyzed well enough to actually know if this is a QEMU or
> kernel issue.
Hi Klaus,
Thx for your response! I understand your hesitance on merging stuff that
obviously breaks guest OS.
>
> Now, as far as I can test, having the MSI-X vector table and PBA in BAR
> 0, PMR in BAR 2 and CMB in BAR 4 seems to make everyone happy
> (irregardless of IOMMU on/off).
>
> Later, when the issue is better understood, we can add options to set
> offsets, BIRs etc.
>
> The patch below replaces your "[PATCH v4 2/2] nvme: allow cmb and pmr to
> be enabled" (but still requires "[PATCH v4 1/2] ...") and applies to
> git://git.infradead.org/qemu-nvme.git nvme-next branch.
>
> Can you reproduce the issues with that patch? I can't on a stock Arch
> Linux 5.7.5-arch1-1 kernel.
While I'm happy that approach with MSIX and PBA in BAR0 works fine, I
feel that investigation part why it works while mine doesn't is
missing. It looks to me that both patches are basically following same
approach: create memory subregion and overlay on top of other memory
region. Why one works and the other doesn't then?
Having in mind that, I have recently focused on understanding problem.
I observed that when guest assigns address to BAR4, addr field in
nvme-bar4 memory region gets populated, but it doesn't get automatically
populated in ctrl_mem (cmb) memory subregion, so later when nvme_addr_is_cmb()
is called address check works incorrectly and as a consequence vmm does dma
read instead of memcpy.
I created a patch that sets correct address on ctrl_mem subregion and guest
OS boots up correctly.
When I looked into pci and memory region code I noticed that indeed address
is only assigned to top level memory region but not to contained subregions.
I think that because in your approach cmb grabs whole bar exclusively it works
fine.
Here is my question (perhaps pci folks can help answer :)): if we consider
memory region overlapping for pci devices as valid use case should pci
code on configuration cycles walk through all contained subregion and
update addr field accordingly?
Thx!
next prev parent reply other threads:[~2020-07-21 21:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 21:48 [PATCH v4] nvme: allow cmb and pmr emulation on same device Andrzej Jakowski
2020-07-01 21:48 ` [PATCH v4 1/2] nvme: indicate CMB support through controller capabilities register Andrzej Jakowski
2020-07-07 16:27 ` Maxim Levitsky
2020-07-07 19:15 ` Klaus Jensen
2020-07-30 11:26 ` Maxim Levitsky
2020-07-01 21:48 ` [PATCH v4 2/2] nvme: allow cmb and pmr to be enabled on same device Andrzej Jakowski
2020-07-02 10:13 ` Klaus Jensen
2020-07-02 10:31 ` Klaus Jensen
2020-07-02 15:07 ` Andrzej Jakowski
2020-07-02 17:51 ` Klaus Jensen
2020-07-02 23:33 ` Andrzej Jakowski
2020-07-06 7:15 ` Klaus Jensen
2020-07-08 4:44 ` Andrzej Jakowski
2020-07-15 8:06 ` Klaus Jensen
2020-07-15 8:21 ` Klaus Jensen
2020-07-21 21:54 ` Andrzej Jakowski [this message]
2020-07-22 7:43 ` Klaus Jensen
2020-07-22 17:00 ` Andrzej Jakowski
2020-07-22 17:21 ` Klaus Jensen
2020-07-22 18:14 ` Andrzej Jakowski
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=9143a543-d32d-f3e7-c37b-b3df7f853952@linux.intel.com \
--to=andrzej.jakowski@linux.intel.com \
--cc=its@irrelevant.dk \
--cc=kbusch@kernel.org \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).