[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 1/2] arm/kvm: add support for MTE
From: |
Cornelia Huck |
Subject: |
Re: [PATCH v6 1/2] arm/kvm: add support for MTE |
Date: |
Tue, 07 Mar 2023 18:05:36 +0100 |
User-agent: |
Notmuch/0.37 (https://notmuchmail.org) |
On Thu, Mar 02 2023, Peter Maydell <peter.maydell@linaro.org> wrote:
> On Thu, 2 Mar 2023 at 14:29, Cornelia Huck <cohuck@redhat.com> wrote:
>>
>> On Thu, Mar 02 2023, Peter Maydell <peter.maydell@linaro.org> wrote:
>> > I think having MTE in the specific case of KVM behave differently
>> > to how we've done all these existing properties and how we've
>> > done MTE for TCG would be confusing. The simplest thing is to just
>> > follow the existing UI for TCG MTE.
>> >
>> > The underlying reason for this is that MTE in general is not a feature
>> > only of the CPU, but also of the whole system design. It happens
>> > that KVM gives us tagged RAM "for free" but that's an oddity
>> > of the KVM implementation -- in real hardware there needs to
>> > be system level support for tagging.
>>
>> Hm... the Linux kernel actually seems to consider MTE to be a cpu
>> feature (at least, it lists it in the cpu features).
>>
>> So, is your suggestion to use the 'mte' prop of the virt machine to mean
>> "enable all prereqs for MTE, i.e. allocate tag memory for TCG and enable
>> MTE in the kernel for KVM"? For TCG, we'll get MTE for the max cpu
>> model; for KVM, we'd get MTE for host (== max), but I'm wondering what
>> should happen if we get named cpu models and the user specifies one
>> where we won't have MTE (i.e. some pre-8.5 one)?
>
> I think we can probably cross that bridge when we get to it,
> but I imagine the semantics would be "cortex-foo plus MTE"
> (in the same way that -cpu cortex-foo,+x,-y can add and
> subtract features from a baseline).
While implementing this, I realized another thing that I had managed to
miss before: With tcg, we'll start out with mte=3 and downgrade to mte=0
if we don't have tag memory. With kvm, enabling mte can at most give us
the mte version that the host exposes, so setting mte=on for the machine
might give as well mte=2 in the end [which I still need to implement by
querying the host support, I guess.] This means we have slightly
different semantics for tcg and kvm; but more importantly, we need to
implement something for compat handling.
The Linux kernel distinguishes between 'mte' and 'mte3', and KVM exposes
the MTE cap if mte >=2. Do we need two props as well? If yes, what about
tcg?
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE, Cornelia Huck, 2023/03/01
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE, Andrea Bolognani, 2023/03/01
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE, Peter Maydell, 2023/03/02
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE, Cornelia Huck, 2023/03/02
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE, Peter Maydell, 2023/03/02
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE, Cornelia Huck, 2023/03/03
- Re: [PATCH v6 1/2] arm/kvm: add support for MTE,
Cornelia Huck <=