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.
