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

Mark Rutland
2019-10-21T14:38:45Z

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.