Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Itaru Kitayama <itaru.kitayama@riken.jp>
Cc: "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: Increase GICV size to 64KB so !4KB page-size kernels are able to initialize KVM
Date: Thu, 23 Jun 2016 08:33:50 +0100	[thread overview]
Message-ID: <576B90DE.5090004@arm.com> (raw)
In-Reply-To: <a168054f-b71c-944e-c91a-9a6a00404aa6@riken.jp>

On 23/06/16 04:17, Itaru Kitayama wrote:
> On 6/22/16 9:20 PM, Marc Zyngier wrote:
>> I'm only using DT, which works just fine on Overdrive, even with 64kB
>> pages.
>>
>> I think I understand the issue you're having, which is not what I
>> was thinking of. The issue is that because ACPI doesn't tell us
>> anything about the size of the GICV region, we have to assume that
>> it is 8kB, and cannot distinguish a safe platform from an unsafe
>> one, failing the size test on 64kB.
> 
> Is it likely in the future specification of ACPI the size information
> stored in the GIC subtable? In 6.1 or earlier, it seems optional to me.

I don't see any provision for that, and it is already too late (systems
exist in the wild).

> I also had to allow the not page-aligned physical address of GICV, below
> is an excerpt of apic.dsl
> 
> [054h 0084   8]     Virtual GIC Base Address : 00000000E116F000

Right, this is what I was referring to in my initial reply. The problem
is that we cannot know what is actually safe to map into a guest's
address space without any sizing information.

Also, we have the issue of mapping GICV at an offset in a page, which
userspace needs to be made aware of. So even with your hack, it is
unlikely that you'll be able to boot a guest because userspace has only
1/16th probability to map GICV at offset 0xf000.

Doing so requires reporting the page offset to userspace. I had this patch:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/264852.html

but that requires buy-in from QEMU (though I can do the corresponding
kvmtool change).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

      reply	other threads:[~2016-06-23  7:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22  6:48 Increase GICV size to 64KB so !4KB page-size kernels are able to initialize KVM Itaru Kitayama
2016-06-22 10:06 ` Marc Zyngier
2016-06-22 11:02   ` Itaru Kitayama
2016-06-22 12:20     ` Marc Zyngier
2016-06-23  3:17       ` Itaru Kitayama
2016-06-23  7:33         ` Marc Zyngier [this message]

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=576B90DE.5090004@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=itaru.kitayama@riken.jp \
    --cc=kvmarm@lists.cs.columbia.edu \
    /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