* Re: ARM64 kvm cache coherency problem
2019-05-20 7:14 ` ARM64 kvm cache coherency problem Marc Zyngier
@ 2019-05-20 7:31 ` kevin zhao
0 siblings, 0 replies; 2+ messages in thread
From: kevin zhao @ 2019-05-20 7:31 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kvmarm
[-- Attachment #1.1: Type: text/plain, Size: 2147 bytes --]
It's much more clear to me now.
Thanks Marc !
在 2019/5/20 下午3:14, Marc Zyngier 写道:
> Hi Kevin,
>
> On Mon, 20 May 2019 04:19:50 +0100,
> kevin zhao <xiaoqiang.zhao@cloudminds.com> wrote:
>> [1 <multipart/alternative (7bit)>]
>> [1.1 <text/plain; UTF-8 (8bit)>]
>> Hi, there:
>>
>> I have seen some RFC about solving ARM64 kvm cache incoherency
>> issue ([1], [2]) in May 2015. I followed a few threads and did not
>> know how this arguments ends.
> First, let me put things straight: there is no KVM/arm64 cache
> coherency problem. The issue is that people expect behaviours that are
> specific to x86 (such as coherency between cacheable and non-cacheable
> aliases) to work on non-x86 architectures. This isn't a reasonable
> expectation, unfortunately.
>
> The patches you refer to try to workaround the issue by changing
> either QEMU's or the kernel's behaviour. I contend that none of these
> need to be changed, but instead the guest has to be fixed to properly
> behave on the arm64 architecture, which includes things such as not
> lying about what is a real device and what is an emulated one.
>
> I've ranted publicly on this very subject a long while ago[1], with
> all the gory details of what fails, why, and what the solutions
> are. In the end, KVM/arm64 works remarkably well for what actually
> matters, such as PV devices (virtio) and directly assigned devices,
> without any cache coherency issue.
>
>> Does anybody know how this problem is solved finally ?
> The architecture has gained the ARMv8.4 FWB extension, which solves
> some of these problems by allowing Stage-2 to override the guest's
> attributes (and a couple of other things that make I$/D$ coherency
> much easier). Yes, it would have been nice to have this since day one
> (circa 2008), but it involves getting hold of a crystal ball and a
> time machine, both of which are out of stock at my local dealer.
>
> I don't know of any publicly available CPU implementing FWB at this
> stage, so this is a moot point...
>
> Thanks,
>
> M.
>
> [1] https://events.static.linuxfound.org/sites/events/files/slides/slides_10.pdf
>
--
[-- Attachment #1.2.1: Type: text/html, Size: 3070 bytes --]
[-- Attachment #1.2.2: CloudMinds Logo_English_Color_Landscape_forEmail116.png --]
[-- Type: image/png, Size: 4219 bytes --]
[-- Attachment #2: xiaoqiang_zhao.vcf --]
[-- Type: text/x-vcard, Size: 149 bytes --]
begin:vcard
fn;quoted-printable:=E8=B5=B5 =E5=B0=8F=E5=BC=BA
n;quoted-printable;quoted-printable:=E5=B0=8F=E5=BC=BA;=E8=B5=B5
version:2.1
end:vcard
[-- Attachment #3: Type: text/plain, Size: 151 bytes --]
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 2+ messages in thread