linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shanker R Donthineni <sdonthineni@nvidia.com>
To: Marc Zyngier <maz@kernel.org>, Vikram Sethi <vsethi@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" 
	<linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Jason Sequeira <jsequeira@nvidia.com>
Subject: Re: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR region in VMA
Date: Sat, 1 May 2021 06:36:11 -0500	[thread overview]
Message-ID: <49e26646-9f05-ccb8-f5c1-73a92ab79972@nvidia.com> (raw)
In-Reply-To: <87eeeqvm1d.wl-maz@kernel.org>

Hi Marc,

On 5/1/21 4:30 AM, Marc Zyngier wrote:
>> I think Device GRE has some practical problems.
>> 1. A lot of userspace code which is used to getting write combined
>> mappings to GPU memory from kernel drivers does memcpy/memset on it
>> which can insert ldp/stp which can crash on Device Memory Type. From
>> a quick search I didn't find a memcpy_io or memset_io in
>> glibc. Perhaps there are some other functions available, but a lot
>> of userspace applications that work on x86 and ARM baremetal won't
>> work on ARM VMs without such changes. Changes to all of userspace
>> may not always be practical, specially if linking to binaries
> This seems to go against what Alex was hinting at earlier, which is
> that unaligned accesses were not expected on prefetchable regions, and
> Shanker latter confirming that it was an actual bug. Where do we stand
> here?
>
We agreed to call it a driver bug if it's not following Linux write-combining
API ioremap_wc() semantics. So far I didn't find whether unaligned accesses
allowed or not for WC regions explicitly in Linux documentation. Page faults
due to driver unaligned accesses in kernel space will be under driver control,
we'll fix it.

Driver uses the architecture agnostic functions that are available in the Linux
kernel and expecting the same behavior in VM vs Baremetal. We would like
to keep the driver implementation is architecture-independent as much as
possible and support VM unaware. For ARM64, VM's ioremap_wc() definition
doesn't match baremetal.

We don't have any control over the userspace applications/drivers/libraries as
Vikram saying. Another example GCC memset() function uses 'DC ZVA' which
triggers an alignment fault if the actual memory type is device_xxx.




  reply	other threads:[~2021-05-01 11:43 UTC|newest]

Thread overview: 30+ 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
     [not found]           ` <87czucngdc.wl-maz@kernel.org>
2021-04-30 13:07             ` Shanker R Donthineni
2021-04-30 14:58             ` Shanker R Donthineni
     [not found]               ` <878s4zokll.wl-maz@kernel.org>
2021-04-30 16:57                 ` Vikram Sethi
2021-05-01  9:30                   ` Marc Zyngier
2021-05-01 11:36                     ` Shanker R Donthineni [this message]
     [not found]                       ` <87czu8uowe.wl-maz@kernel.org>
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=49e26646-9f05-ccb8-f5c1-73a92ab79972@nvidia.com \
    --to=sdonthineni@nvidia.com \
    --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=maz@kernel.org \
    --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).