From: Robin Murphy <robin.murphy@arm.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org, ray.huang@amd.com,
"Cong Liu" <liucong2@kylinos.cn>,
daniel@ffwll.ch, spice-devel@lists.freedesktop.org,
airlied@redhat.com, "Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64
Date: Wed, 23 Mar 2022 10:26:52 +0000 [thread overview]
Message-ID: <cfd7b57e-0573-db04-3692-acedd20fb51e@arm.com> (raw)
In-Reply-To: <20220323101138.7oiwefh7ofcxojgq@sirius.home.kraxel.org>
On 2022-03-23 10:11, Gerd Hoffmann wrote:
> On Wed, Mar 23, 2022 at 09:45:13AM +0000, Robin Murphy wrote:
>> On 2022-03-23 07:15, Christian K�nig wrote:
>>> Am 22.03.22 um 10:34 schrieb Cong Liu:
>>>> qxl use ioremap to map ram_header and rom, in the arm64 implementation,
>>>> the device is mapped as DEVICE_nGnRE, it can not support unaligned
>>>> access.
>>>
>>> Well that some ARM boards doesn't allow unaligned access to MMIO space
>>> is a well known bug of those ARM boards.
>>>
>>> So as far as I know this is a hardware bug you are trying to workaround
>>> here and I'm not 100% sure that this is correct.
>>
>> No, this one's not a bug. The Device memory type used for iomem mappings is
>> *architecturally* defined to enforce properties like aligned accesses, no
>> speculation, no reordering, etc. If something wants to be treated more like
>> RAM than actual MMIO registers, then ioremap_wc() or ioremap_cache() is the
>> appropriate thing to do in general (with the former being a bit more
>> portable according to Documentation/driver-api/device-io.rst).
>
> Well, qxl is a virtual device, so it *is* ram.
>
> I'm wondering whenever qxl actually works on arm? As far I know all
> virtual display devices with (virtual) pci memory bars for vram do not
> work on arm due to the guest mapping vram as io memory and the host
> mapping vram as normal ram and the mapping attribute mismatch causes
> caching troubles (only noticeable on real arm hardware, not in
> emulation). Did something change here recently?
Indeed, Armv8.4 introduced the S2FWB feature to cope with situations
like this - essentially it allows the hypervisor to share RAM-backed
pages with the guest without losing coherency regardless of how the
guest maps them.
Robin.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org, ray.huang@amd.com,
"Cong Liu" <liucong2@kylinos.cn>,
spice-devel@lists.freedesktop.org, airlied@redhat.com,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64
Date: Wed, 23 Mar 2022 10:26:52 +0000 [thread overview]
Message-ID: <cfd7b57e-0573-db04-3692-acedd20fb51e@arm.com> (raw)
In-Reply-To: <20220323101138.7oiwefh7ofcxojgq@sirius.home.kraxel.org>
On 2022-03-23 10:11, Gerd Hoffmann wrote:
> On Wed, Mar 23, 2022 at 09:45:13AM +0000, Robin Murphy wrote:
>> On 2022-03-23 07:15, Christian K�nig wrote:
>>> Am 22.03.22 um 10:34 schrieb Cong Liu:
>>>> qxl use ioremap to map ram_header and rom, in the arm64 implementation,
>>>> the device is mapped as DEVICE_nGnRE, it can not support unaligned
>>>> access.
>>>
>>> Well that some ARM boards doesn't allow unaligned access to MMIO space
>>> is a well known bug of those ARM boards.
>>>
>>> So as far as I know this is a hardware bug you are trying to workaround
>>> here and I'm not 100% sure that this is correct.
>>
>> No, this one's not a bug. The Device memory type used for iomem mappings is
>> *architecturally* defined to enforce properties like aligned accesses, no
>> speculation, no reordering, etc. If something wants to be treated more like
>> RAM than actual MMIO registers, then ioremap_wc() or ioremap_cache() is the
>> appropriate thing to do in general (with the former being a bit more
>> portable according to Documentation/driver-api/device-io.rst).
>
> Well, qxl is a virtual device, so it *is* ram.
>
> I'm wondering whenever qxl actually works on arm? As far I know all
> virtual display devices with (virtual) pci memory bars for vram do not
> work on arm due to the guest mapping vram as io memory and the host
> mapping vram as normal ram and the mapping attribute mismatch causes
> caching troubles (only noticeable on real arm hardware, not in
> emulation). Did something change here recently?
Indeed, Armv8.4 introduced the S2FWB feature to cope with situations
like this - essentially it allows the hypervisor to share RAM-backed
pages with the guest without losing coherency regardless of how the
guest maps them.
Robin.
next prev parent reply other threads:[~2022-03-23 10:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 9:34 [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64 Cong Liu
2022-03-22 9:34 ` [PATCH v1 2/2] drm/ttm: enable ioremap buffer according to TTM mem caching setting for arm64 Cong Liu
2022-03-23 7:15 ` [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64 Christian König via Virtualization
2022-03-23 7:15 ` Christian König
2022-03-23 9:45 ` Robin Murphy
2022-03-23 9:45 ` Robin Murphy
2022-03-23 9:46 ` Christian König via Virtualization
2022-03-23 9:46 ` Christian König
2022-03-23 10:11 ` Gerd Hoffmann
2022-03-23 10:11 ` Gerd Hoffmann
2022-03-23 10:26 ` Robin Murphy [this message]
2022-03-23 10:26 ` Robin Murphy
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=cfd7b57e-0573-db04-3692-acedd20fb51e@arm.com \
--to=robin.murphy@arm.com \
--cc=airlied@linux.ie \
--cc=airlied@redhat.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=liucong2@kylinos.cn \
--cc=ray.huang@amd.com \
--cc=spice-devel@lists.freedesktop.org \
--cc=virtualization@lists.linux-foundation.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.