From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Schopp Subject: Re: [PATCH v2 9/9] arm64: KVM: vgic: deal with GIC sub-page alignment Date: Wed, 25 Jun 2014 09:56:28 -0500 Message-ID: <53AAE31C.2060506@amd.com> References: <1403169693-13982-1-git-send-email-marc.zyngier@arm.com> <1403169693-13982-10-git-send-email-marc.zyngier@arm.com> <53A9D14D.2020802@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: Marc Zyngier , "kvmarm@lists.cs.columbia.edu" , arm-mail-list , kvm-devel To: Peter Maydell Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: kvm.vger.kernel.org On 06/24/2014 05:28 PM, Peter Maydell wrote: > On 24 June 2014 20:28, Joel Schopp wrote: >> On 06/19/2014 04:21 AM, Marc Zyngier wrote: >>> The GIC CPU interface is always 4k aligned. If the host is using >>> 64k pages, it is critical to place the guest's GICC interface at the >>> same relative alignment as the host's GICV. Failure to do so results >>> in an impossibility for the guest to deal with interrupts. >>> >>> Add a KVM_DEV_ARM_VGIC_GRP_ADDR_OFFSET attribute for the VGIC, allowing >>> userspace to retrieve the GICV offset in a page. It becomes then trivial >>> to adjust the GICC base address for the guest. >> >> Does this mean there is a corresponding patch for qemu? > Not as far as I know. It's a bit awkward on the QEMU end because > we really want to provide the guest a consistent memory map > regardless of the host CPU. So at best we'd probably use it to > say "sorry, can't run on this CPU/host kernel". I think most arm64 servers are going to run with 64k pages. It seems like a major problem to have qemu not work on these systems. > > (That said, if you think you can make QEMU usefully use the > information and want to write a QEMU patch I'm not averse > to the idea.) I'll have to think about this approach some more, but I'm not opposed to doing the work if I thought it was the right thing to do. > > kvmtool is probably better placed to take advantage of it since > it takes more of a "deal with what the host provides you" > philosophy. kvmtool is fun as a play toy, but in the real world nobody is building clouds using kvmtool, they use kvm with qemu. > > thanks > -- PMM