qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 2/2] hw/arm/raspi: Restrict BCM2835 / BCM2836 SoC to TCG


From: Philippe Mathieu-Daudé
Subject: Re: [RFC PATCH 2/2] hw/arm/raspi: Restrict BCM2835 / BCM2836 SoC to TCG
Date: Tue, 2 Feb 2021 14:29:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

On 2/2/21 1:28 PM, Peter Maydell wrote:
> On Mon, 1 Feb 2021 at 08:18, Luc Michel <luc@lmichel.fr> wrote:
>> On 16:14 Sun 31 Jan     , Philippe Mathieu-Daudé wrote:
>>> KVM requires the target cpu to be at least ARMv8 architecture
>>> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
>>> "target/arm: Remove KVM support for 32-bit Arm hosts").
>> Wow, is there absolutely no way to do that then? What about using an
>> ARMv8 and starting in AArch32 mode? Is that possible with KVM? I guess
>> it might not be strictly identical as spawning the "real" CPU...
> 
> "Support hardware-accelerated emulation of older v7 CPUs" is
> not a design goal of the virtualization extensions; you can't
> do it. KVM does support having a guest CPU which is AArch32 for EL1,
> but that will never be a v7 CPU, because it will be the same as
> the host CPU, which will always be v8.
> 
> In general I would prefer that we don't try to do stuff to
> make KVM kinda-sorta-work on random 32-bit boards by stuffing
> in a not-the-right-type CPU, because this increases our
> security boundary massively.

Fine, as this simplifies many things.

> At the moment we can reasonably
> say "only the 'virt' board and one of the Xilinx boards are
> security-critical".

What about the SBSA-ref?

Thanks,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]