qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH v11 06/10] hvf: arm: Implement -cpu host


From: Alexander Graf
Subject: Re: [PATCH v11 06/10] hvf: arm: Implement -cpu host
Date: Thu, 16 Sep 2021 19:47:03 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

On 16.09.21 17:55, Peter Maydell wrote:
> On Thu, 16 Sept 2021 at 16:30, Alexander Graf <agraf@csgraf.de> wrote:
>>
>> On 16.09.21 14:24, Peter Maydell wrote:
>>> On Wed, 15 Sept 2021 at 19:10, Alexander Graf <agraf@csgraf.de> wrote:
>>>> Now that we have working system register sync, we push more target CPU
>>>> properties into the virtual machine. That might be useful in some
>>>> situations, but is not the typical case that users want.
>>>>
>>>> So let's add a -cpu host option that allows them to explicitly pass all
>>>> CPU capabilities of their host CPU into the guest.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@csgraf.de>
>>>> Acked-by: Roman Bolshakov <r.bolshakov@yadro.com>
>>>> Reviewed-by: Sergio Lopez <slp@redhat.com>
>>>>
>>>> +    /*
>>>> +     * A scratch vCPU returns SCTLR 0, so let's fill our default with the 
>>>> M1
>>>> +     * boot SCTLR from https://github.com/AsahiLinux/m1n1/issues/97
> Side note: SCTLR_EL1 is a 64-bit register, do you have anything that
> prints the full 64-bits to confirm that [63:32] are indeed all 0?


Yes, m1n1 prints the full 64bit value:
https://github.com/AsahiLinux/m1n1/blob/main/src/memory.c#L459

That said, I'm not sure we really have to model the guest's reset SCTLR
in EL1 to be identical to the host's reset SCTLR in EL2. I think it's a
great start, but as long as there is no spec that indicates what SCTLR
should be in EL1, we can make our own rules IMHO.


Alex




reply via email to

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