All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Christoffer Dall <c.dall@virtualopensystems.com>,
	Alexander Graf <agraf@suse.de>,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [kvmarm] [PATCH v10 07/14] KVM: ARM: Memory virtualization setup
Date: Sun, 19 Aug 2012 16:00:09 +0300	[thread overview]
Message-ID: <5030E359.5040201@redhat.com> (raw)
In-Reply-To: <CAFEAcA9DcWL1vXNPQWte1Q9P7HyamuekC=7RemxnaBjoUT6i5g@mail.gmail.com>

On 08/19/2012 12:38 PM, Peter Maydell wrote:
> On 19 August 2012 05:34, Christoffer Dall <c.dall@virtualopensystems.com> wrote:
>> On Thu, Aug 16, 2012 at 2:25 PM, Alexander Graf <agraf@suse.de> wrote:
>>> A single hva can have multiple gpas mapped, no? At least that's what I gathered
>>> from the discussion about my attempt to a function similar to this :).
> 
>> I don't think this is the case for ARM, can you provide an example? We
>> use gfn_to_pfn_prot and only allow user memory regions. What you
>> suggest would be multiple physical addresses pointing to the same
>> memory bank, I don't think that makes any sense on ARM hardware, for
>> x86 and PPC I don't know.
> 
> I don't know what an hva is,

host virtual address

(see Documentation/virtual/kvm/mmu.txt for more TLAs in this area).

 but yes, ARM boards can have the same
> block of RAM aliased into multiple places in the physical address space.
> (we don't currently bother to implement the aliases in qemu's vexpress-a15
> though because it's a bunch of mappings of the low 2GB into high
> addresses mostly intended to let you test LPAE code without having to
> put lots of RAM on the hardware).

Even if it weren't common, the API allows it, so we must behave sensibly.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-08-19 13:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 15:27 [PATCH v10 00/14] KVM/ARM Implementation Christoffer Dall
2012-08-16 15:28 ` [PATCH v10 01/14] ARM: add mem_type prot_pte accessor Christoffer Dall
2012-08-16 15:28 ` [PATCH v10 02/14] ARM: Add config option ARM_VIRT_EXT Christoffer Dall
2012-08-16 15:28 ` [PATCH v10 03/14] ARM: Section based HYP idmap Christoffer Dall
2012-08-16 15:28 ` [PATCH v10 04/14] ARM: Expose PMNC bitfields for KVM use Christoffer Dall
2012-08-16 15:28 ` [PATCH v10 05/14] KVM: ARM: Initial skeleton to compile KVM support Christoffer Dall
2012-08-16 15:29 ` [PATCH v10 06/14] KVM: ARM: Hypervisor inititalization Christoffer Dall
2012-08-23 15:08   ` [kvmarm] " Lei Wen
2012-08-23 15:27     ` Christoffer Dall
2012-08-24  8:04       ` Lei Wen
2012-08-24 13:38         ` Marc Zyngier
2012-08-24 14:34           ` Lei Wen
2012-08-16 15:29 ` [PATCH v10 07/14] KVM: ARM: Memory virtualization setup Christoffer Dall
2012-08-16 18:25   ` [kvmarm] " Alexander Graf
2012-08-19  4:34     ` Christoffer Dall
2012-08-19  9:38       ` Peter Maydell
2012-08-19 13:00         ` Avi Kivity [this message]
2012-08-19 20:00           ` Christoffer Dall
2012-08-23  8:12   ` Min-gyu Kim
2012-08-23 14:46     ` Christoffer Dall
2012-08-16 15:29 ` [PATCH v10 08/14] KVM: ARM: Inject IRQs and FIQs from userspace Christoffer Dall
2012-08-21  8:20   ` Jan Kiszka
2012-08-21 14:13     ` Christoffer Dall
2012-08-16 15:29 ` [PATCH v10 09/14] KVM: ARM: World-switch implementation Christoffer Dall
2012-08-16 15:29 ` [PATCH v10 10/14] KVM: ARM: Emulation framework and CP15 emulation Christoffer Dall
2012-08-16 15:30 ` [PATCH v10 11/14] KVM: ARM: User space API for getting/setting co-proc registers Christoffer Dall
2012-08-16 15:30 ` [PATCH v10 12/14] KVM: ARM: Handle guest faults in KVM Christoffer Dall
2012-08-16 15:30 ` [PATCH v10 13/14] KVM: ARM: Handle I/O aborts Christoffer Dall
2012-08-16 15:30 ` [PATCH v10 14/14] KVM: ARM: Guest wait-for-interrupts (WFI) support Christoffer Dall

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=5030E359.5040201@redhat.com \
    --to=avi@redhat.com \
    --cc=agraf@suse.de \
    --cc=c.dall@virtualopensystems.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --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 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.