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

Re: [PATCH v5 2/4] xen/riscv: introduce setup_initial_pages


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Bob Eshleman <bobbyeshleman@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 2 May 2023 08:15:49 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tYW6Ju3/WGY+WAhCKayIV6c3SHWrtO97t72yOJ0NzeY=; b=J6bX0SUIIzm2dmPEFEJImyqW/FB+pFbbkGOuTseFfKqt7uw964HbLJMAGcY4yPUYvOFbdu7jt0BVncsBm6FLuv+HHQqI4VuwYuQO6EAPCkSkKJceBu+tcg+NeeLTsYRq195OxLTyiSY9DWxPP2uNiSz0+lIzP6f0dw8NIqnakCloRGuBFO5pCrtii4ugune34RnjaG+vhW40MQtXDAqYn/CjWniZkOBXp6Y0vGPHpqToEqZIQ43NEfGPb2t+2qGkaiThFJrNmBtdTbL8yR5tN4ozOz32SqcyD++EoIOQG2RWDNkwmGWeCg7RjjTK3UeDTjvK68U65RCb2/Mtscqkfg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S73vx3jv+I3zZIewPLdwXxwL5Aq+E0BKkejpZnLnCQUCIebL3U9nqGJlBFlL3uZ0wyV2g9O4tiOG3PA+J7yR+gudvO8412CtM9smOizWAHsrMW22QsPisn5NudrHgDKB2r82DHg14DhMTRjm+E0aDYndDPf0mb5DwQ0som4TtGl7Ryjo3t5MoLCQucULrTKhygXezoakFMkhxOx1bvo5m0AbAISl0nq2BK4ZeQ06dYJK/fm25fHZBbQO0M6pSYCER6QMvoKg6cuv7txi1M32Ldhf2INfMO0qB8NI6ObpVq0/9jOfaVl4DSkJaLgQqcqwBXvWYpV+nuh7Wo394LEkrw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Julien Grall <julien@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 02 May 2023 06:16:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.04.2023 22:05, Oleksii wrote:
> Hi Jan,
> 
> On Mon, 2023-04-24 at 17:35 +0200, Jan Beulich wrote:
>> On 24.04.2023 17:16, Oleksii wrote:
>>> On Mon, 2023-04-24 at 12:18 +0200, Jan Beulich wrote:
>>>> On 21.04.2023 18:01, Oleksii wrote:
>>>>> On Thu, 2023-04-20 at 16:36 +0200, Jan Beulich wrote:
>>>>>> On 19.04.2023 17:42, Oleksii Kurochko wrote:
>>>>>>> +    csr_write(CSR_SATP,
>>>>>>> +              ((unsigned long)stage1_pgtbl_root >>
>>>>>>> PAGE_SHIFT)
>>>>>>>>
>>>>>>> +              satp_mode << SATP_MODE_SHIFT);
>>>>>>> +
>>>>>>> +    if ( (csr_read(CSR_SATP) >> SATP_MODE_SHIFT) ==
>>>>>>> satp_mode
>>>>>>> )
>>>>>>> +        is_mode_supported = true;
>>>>>>> +
>>>>>>> +    /* Clean MMU root page table and disable MMU */
>>>>>>> +    stage1_pgtbl_root[index] = paddr_to_pte(0x0, 0x0);
>>>>>>> +
>>>>>>> +    csr_write(CSR_SATP, 0);
>>>>>>> +    asm volatile("sfence.vma");
>>>>>>
>>>>>> I guess what you do in this function could do with some more
>>>>>> comments.
>>>>>> Looks like you're briefly enabling the MMU to check that what
>>>>>> you
>>>>>> wrote
>>>>>> to SATP you can also read back. (Isn't there a register
>>>>>> reporting
>>>>>> whether the feature is available?)
>>>>> I supposed that it has to be but I couldn't find a register in
>>>>> docs.
>>>>
>>>> Well, yes, interestingly the register is marked WARL, so
>>>> apparently
>>>> intended to by used for probing like you do. (I find the
>>>> definition
>>>> of
>>>> WARL a little odd though, as such writes supposedly aren't
>>>> necessarily
>>>> value preserving. For SATP this might mean that translation is
>>>> enabled
>>>> by a write of an unsupported mode, with a different number of
>>>> levels.
>>>> This isn't going to work very well, I'm afraid.)
>>> Agree. It will be an issue in case of a different number of levels.
>>>
>>> Then it looks there is no way to check if SATP mode is supported.
>>>
>>> So we have to rely on the fact that the developer specified
>>> RV_STAGE1_MODE correctly in the config file.
>>
>> Well, maybe the spec could be clarified in this regard. That WARL
>> behavior may be okay for some registers, but as said I think it isn't
>> enough of a guarantee for SATP probing. Alistair, Bob - any thoughts?
> I've re-read the manual regarding CSR_SATP and the code of detecting
> SATP mode will work fine.
> From the manual ( 4.1.11
> Supervisor Address Translation and Protection (satp) Register ):
> “Implementations are not required to support all MODE settings, and if
> satp is written with an unsupported MODE, the entire write has no
> effect; no fields in satp are modified.”

Ah, I see. That's the sentence I had overlooked (and that's unhelpfully
not only not implied to be that way, but actively implied to be different
by figures 4.11 and 4.12 naming [all] the individual fields as WARL).

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.