public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>, Jon Masters <jcm@redhat.com>
Cc: Mario Smarduch <m.smarduch@samsung.com>,
	kvm-devel <kvm@vger.kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH 3/3] arm, arm64: KVM: handle potential incoherency of readonly memslots
Date: Thu, 20 Nov 2014 22:13:10 +0100	[thread overview]
Message-ID: <546E5966.4090608@redhat.com> (raw)
In-Reply-To: <CAFEAcA9M69W7uWkixoTuQ6hT8-h2fb3bYuAnH+B=idwb7eFUAQ@mail.gmail.com>

On 11/20/14 21:10, Peter Maydell wrote:
> On 20 November 2014 19:49, Jon Masters <jcm@redhat.com> wrote:
>> On 11/20/2014 01:40 PM, Peter Maydell wrote:
>>> The situation is not so bleak as this. See section B2.9 "Mismatched
>>> memory attributes" in the ARMv8 ARM ARM (DDI0487A.d), which lays
>>> out in some detail what the results of mismatched attributes are
>>> (generally, you lose ordering or coherency guarantees you might
>>> have hoped to have). They're not pretty, but it's not as bad
>>> as completely UNPREDICTABLE behaviour.
>>
>> Quick side note that I did raise exactly this issue with the ARM
>> Architecture team several years ago (that of missmatched memory
>> attributes between a guest and hypervisor) and it is a known concern.
> 
> I think in practice for a well-behaved guest we can arrange
> that everything is fine (roughly, the guest has to treat
> DMA-capable devices as doing coherent-dma, which we can tell
> them to do via DT bindings or ACPI[*], plus the special
> case handling we already have for bootup), and naughty guests
> will only confuse themselves. But I need to think a bit more
> about it (and we should probably write down how it works
> somewhere :-)).
> 
> [*] We should be able to emulate non-coherent-DMA devices but
> would need an extra API from KVM so userspace can do "clean
> dcache to point of coherency". And in practice I'm not sure
> we need to emulate those devices...

This basically means that virtio transfers should just use normal memory
in the guest (treating virtio transfers as "coherent DMA"), right?

We're actually doing that in the ArmVirtualizationQemu.dsc build of
edk2, and Things Work Great (TM) in guests on the Mustang.

Thanks
Laszlo

  reply	other threads:[~2014-11-20 21:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 14:58 [PATCH 1/3] kvm: add a memslot flag for incoherent memory regions Ard Biesheuvel
2014-11-17 14:58 ` [PATCH 2/3] arm, arm64: KVM: allow forced dcache flush on page faults Ard Biesheuvel
2014-11-17 14:58 ` [PATCH 3/3] arm, arm64: KVM: handle potential incoherency of readonly memslots Ard Biesheuvel
2014-11-17 15:29   ` Paolo Bonzini
2014-11-17 15:39     ` Marc Zyngier
2014-11-17 16:03       ` Paolo Bonzini
2014-11-17 15:49     ` Laszlo Ersek
2014-11-19 23:32       ` Mario Smarduch
2014-11-20  8:08         ` Laszlo Ersek
2014-11-20 18:35           ` Mario Smarduch
2014-11-20 18:40             ` Peter Maydell
2014-11-20 19:15               ` Mario Smarduch
2014-11-20 19:49               ` Jon Masters
2014-11-20 20:10                 ` Peter Maydell
2014-11-20 21:13                   ` Laszlo Ersek [this message]
2014-11-20 21:59                     ` Peter Maydell
2014-11-21 11:19         ` Christoffer Dall
2014-11-22  1:50           ` Mario Smarduch
2014-11-22 10:18             ` Christoffer Dall
2014-11-22 10:26               ` Laszlo Ersek
2014-11-22 12:27             ` Peter Maydell
2014-11-19  8:51   ` Ard Biesheuvel
2014-11-19 11:02     ` Paolo Bonzini
2014-11-19 11:03     ` Paolo Bonzini

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=546E5966.4090608@redhat.com \
    --to=lersek@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=jcm@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=m.smarduch@samsung.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.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