From: Marc Zyngier <maz@kernel.org>
To: Shanker R Donthineni <sdonthineni@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"Christoffer\ Dall" <christoffer.dall@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<kvmarm@lists.cs.columbia.edu>, <linux-kernel@vger.kernel.org>,
<kvm@vger.kernel.org>, Vikram Sethi <vsethi@nvidia.com>,
Jason Sequeira <jsequeira@nvidia.com>
Subject: Re: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR region in VMA
Date: Fri, 30 Apr 2021 16:07:22 +0100 [thread overview]
Message-ID: <87a6pfolp1.wl-maz@kernel.org> (raw)
In-Reply-To: <7c685ae6-938b-9d99-20e6-f51398543441@nvidia.com>
On Fri, 30 Apr 2021 14:07:46 +0100,
Shanker R Donthineni <sdonthineni@nvidia.com> wrote:
>
>
> Hi Marc,
>
> On 4/30/21 6:47 AM, Marc Zyngi
> >>>> We've two concerns here:
> >>>> - Performance impacts for pass-through devices.
> >>>> - The definition of ioremap_wc() function doesn't match the host
> >>>> kernel on ARM64
> >>> Performance I can understand, but I think you're also using it to mask
> >>> a driver bug which should be resolved first. Thank
> >> We’ve already instrumented the driver code and found the code path
> >> for the unaligned accesses. We’ll fix this issue if it’s not
> >> following WC semantics.
> >>
> >> Fixing the performance concern will be under KVM stage-2 page-table
> >> control. We're looking for a guidance/solution for updating stage-2
> >> PTE based on PCI-BAR attribute.
> > Before we start discussing the *how*, I'd like to clearly understand
> > what *arm64* memory attributes you are relying on. We already have
> > established that the unaligned access was a bug, which was the biggest
> > argument in favour of NORMAL_NC. What are the other requirements?
> >
> We are relying on NORMAL_NC mapping for PCI prefetchable BARs
> instead of DEVICE_nGnRE in baremetal and VM. No other requirement
> other than this.
That wasn't really my question. What properties do you require for
this assigned MMIO window outside of unaligned accesses? Or to put it
another way, what goes wrong with any of the other device types?
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-30 15:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 16:29 [RFC 0/2] [RFC] Honor PCI prefetchable attributes for a virtual machine on ARM64 Shanker Donthineni
2021-04-29 16:29 ` [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR region in VMA Shanker Donthineni
2021-04-29 18:28 ` Alex Williamson
2021-04-29 19:14 ` Shanker R Donthineni
2021-04-29 19:46 ` Alex Williamson
2021-04-29 22:08 ` Vikram Sethi
2021-04-30 11:25 ` Shanker R Donthineni
2021-04-30 11:47 ` Marc Zyngier
2021-04-30 13:07 ` Shanker R Donthineni
2021-04-30 15:07 ` Marc Zyngier [this message]
2021-04-30 14:58 ` Shanker R Donthineni
2021-04-30 15:31 ` Marc Zyngier
2021-04-30 16:57 ` Vikram Sethi
2021-05-01 9:30 ` Marc Zyngier
2021-05-01 11:36 ` Shanker R Donthineni
2021-05-03 9:50 ` Marc Zyngier
2021-05-03 12:08 ` Shanker R Donthineni
2021-05-02 17:56 ` Vikram Sethi
2021-05-03 10:17 ` Marc Zyngier
2021-05-03 13:35 ` Mark Kettenis
2021-05-03 13:59 ` Vikram Sethi
2021-05-03 14:44 ` Alex Williamson
2021-05-03 22:03 ` Vikram Sethi
2021-05-04 8:30 ` Will Deacon
2021-05-05 18:02 ` Catalin Marinas
2021-05-06 7:22 ` Christoph Hellwig
2021-05-08 16:33 ` Shanker R Donthineni
2021-06-02 9:37 ` Marc Zyngier
2021-05-04 18:03 ` Alex Williamson
2021-06-02 9:11 ` Marc Zyngier
2021-04-30 9:54 ` Lorenzo Pieralisi
2021-04-30 12:38 ` Jason Gunthorpe
2021-04-29 16:29 ` [RFC 2/2] KVM: arm64: Add write-combine support for stage-2 entries Shanker Donthineni
2021-05-03 7:01 ` [RFC 0/2] [RFC] Honor PCI prefetchable attributes for a virtual machine on ARM64 Christoph Hellwig
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=87a6pfolp1.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=jsequeira@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sdonthineni@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=will@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 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).