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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191021143812.GB56589@lakrids.cambridge.arm.com>
Date:   Mon, 21 Oct 2019 15:38:13 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Steven Price <steven.price@....com>
Cc:     Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Russell King <linux@...linux.org.uk>,
        James Morse <james.morse@....com>,
        Julien Thierry <julien.thierry.kdev@...il.com>,
        Suzuki K Pouloze <suzuki.poulose@....com>,
        kvm@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 01/10] KVM: arm64: Document PV-time interface

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.