Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.112.34 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.112.34; helo=mail.nvidia.com;
Subject: Re: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
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>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
 <87czucngdc.wl-maz@kernel.org>
 <1edb2c4e-23f0-5730-245b-fc6d289951e1@nvidia.com>
 <878s4zokll.wl-maz@kernel.org>
 <BL0PR12MB2532CC436EBF626966B15994BD5E9@BL0PR12MB2532.namprd12.prod.outlook.com>
 <87eeeqvm1d.wl-maz@kernel.org>
From:   Shanker R Donthineni <sdonthineni@nvidia.com>
Message-ID: <49e26646-9f05-ccb8-f5c1-73a92ab79972@nvidia.com>
Date:   Sat, 1 May 2021 06:36:11 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87eeeqvm1d.wl-maz@kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2021 11:36:14.5647
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 712ee9e5-5449-4892-24a4-08d90c9553e4
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.112.34];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT054.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5081
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.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.