Re: [PATCH v6 01/10] KVM: arm64: Document PV-time interface

From: Mark Rutland <mark.rutland@arm.com>
To: Steven Price <steven.price@arm.com>
Cc: "Marc Zyngier" <maz@kernel.org>, "Will Deacon" <will@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"James Morse" <james.morse@arm.com>,
	"Julien Thierry" <julien.thierry.kdev@gmail.com>,
	"Suzuki K Pouloze" <suzuki.poulose@arm.com>,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 01/10] KVM: arm64: Document PV-time interface
Date: Mon, 21 Oct 2019 15:38:13 +0100	[thread overview]
Message-ID: <20191021143812.GB56589@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <d01edcb3-0d9a-d4ec-6a60-a82f3ffccba5@arm.com>

On Mon, Oct 21, 2019 at 02:40:31PM +0100, Steven Price wrote:
> On 18/10/2019 18:10, Mark Rutland wrote:
> > On Tue, Oct 15, 2019 at 06:56:51PM +0100, Mark Rutland wrote:
> [...]
> >>> +PV_TIME_ST
> >>> +    ============= ========    ==========
> >>> +    Function ID:  (uint32)    0xC5000021
> >>> +    Return value: (int64)     IPA of the stolen time data structure for this
> >>> +                              VCPU. On failure:
> >>> +                              NOT_SUPPORTED (-1)
> >>> +    ============= ========    ==========
> >>> +
> >>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> >>> +with inner and outer write back caching attributes, in the inner shareable
> >>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> >>> +meaningfully filled by the hypervisor (see structure below).
> >>
> >> At what granularity is this allowed to share IPA space with other
> >> mappings? The spec doesn't provide any guidance here, and I strongly
> >> suspect that it should.
> >>
> >> To support a 64K guest, we must ensure that this doesn't share a 64K IPA
> >> granule with any MMIO, and it probably only makes sense for an instance
> >> of this structure to share that granule with another vCPU's structure.
> >>
> >> We probably _also_ want to ensure that this doesn't share a 64K granule
> >> with memory the guest sees as regular system RAM. Otherwise we're liable
> >> to force it into having mismatched attributes for any of that RAM it
> >> happens to map as part of mapping the PV_TIME_ST structure.
> > 
> > I guess we can say that it's userspace's responsibiltiy to set this up
> > with sufficient alignment, but I do think we want to make a
> > recommendataion here.
> 
> I can add something like this to the kernel's documentation:
> 
>     It is advisable that one or more 64k pages are set aside for the
>     purpose of these structures and not used for other purposes, this
>     enables the guest to map the region using 64k pages and avoids
>     conflicting attributes with other memory.

Sounds good to me!

Thanks,
Mark.