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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f14cfd5b-c103-5d56-82fb-59d0371c6f21@arm.com>
Date:   Wed, 19 Aug 2020 09:54:40 +0100
From:   Steven Price <steven.price@....com>
To:     Marc Zyngier <maz@...nel.org>, Keqian Zhu <zhukeqian1@...wei.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        kvmarm@...ts.cs.columbia.edu, kvm@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        James Morse <james.morse@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        wanghaibin.wang@...wei.com
Subject: Re: [RFC PATCH 0/5] KVM: arm64: Add pvtime LPT support

On 18/08/2020 15:41, Marc Zyngier wrote:
> On 2020-08-17 09:41, Keqian Zhu wrote:
>> Hi all,
>>
>> This patch series picks up the LPT pvtime feature originally developed
>> by Steven Price: https://patchwork.kernel.org/cover/10726499/
>>
>> Backgroud:
>>
>> There is demand for cross-platform migration, which means we have to
>> solve different CPU features and arch counter frequency between hosts.
>> This patch series can solve the latter problem.
>>
>> About LPT:
>>
>> This implements support for Live Physical Time (LPT) which provides the
>> guest with a method to derive a stable counter of time during which the
>> guest is executing even when the guest is being migrated between hosts
>> with different physical counter frequencies.
>>
>> Changes on Steven Price's work:
>> 1. LPT structure: use symmatical semantics of scale multiplier, and use
>>    fraction bits instead of "shift" to make everything clear.
>> 2. Structure allocation: host kernel does not allocates the LPT 
>> structure,
>>    instead it is allocated by userspace through VM attributes. The 
>> save/restore
>>    functionality can be removed.
>> 3. Since LPT structure just need update once for each guest run, add a 
>> flag to
>>    indicate the update status. This has two benifits: 1) avoid 
>> multiple update
>>    by each vCPUs. 2) If the update flag is not set, then return NOT 
>> SUPPORT for
>>    coressponding guest HVC call.
>> 4. Add VM device attributes interface for userspace configuration.
>> 5. Add a base LPT read/write layer to reduce code.
>> 6. Support ptimer scaling.
>> 7. Support timer event stream translation.
>>
>> Things need concern:
>> 1. https://developer.arm.com/docs/den0057/a needs update.
> 
> LPT was explicitly removed from the spec because it doesn't really
> solve the problem, specially for the firmware: EFI knows
> nothing about this, for example. How is it going to work?
> Also, nobody was ever able to explain how this would work for
> nested virt.
> 
> ARMv8.4 and ARMv8.6 have the feature set that is required to solve
> this problem without adding more PV to the kernel.

Hi Marc,

These are good points, however we do still have the situation that CPUs 
that don't have ARMv8.4/8.6 clearly cannot implement this. I presume the 
use-case Keqian is looking at predates the necessary support in the CPU 
- Keqian if you can provide more details on the architecture(s) involved 
that would be helpful.

Nested virt is indeed more of an issue - we did have some ideas around 
using SDEI that never made it to the spec. However I would argue that 
the most pragmatic approach would be to not support the combination of 
nested virt and LPT. Hopefully that can wait until the counter scaling 
support is available and not require PV.

We are discussing (re-)releasing the spec with the LPT parts added. If 
you have fundamental objections then please me know.

Thanks,

Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ