All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>, Michal Orzel <michal.orzel@arm.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	bertrand.marquis@arm.com, wei.chen@arm.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
Date: Mon, 17 May 2021 09:01:46 +0200	[thread overview]
Message-ID: <54e845e1-f283-d70c-a0c2-73e768e5a56e@suse.com> (raw)
In-Reply-To: <42a998be-2f99-a1b6-ace6-4c5d42af7046@xen.org>

On 12.05.2021 19:59, Julien Grall wrote:
> Hi,
> 
> On 11/05/2021 07:37, Michal Orzel wrote:
>> On 05.05.2021 10:00, Jan Beulich wrote:
>>> On 05.05.2021 09:43, Michal Orzel wrote:
>>>> --- a/xen/include/public/arch-arm.h
>>>> +++ b/xen/include/public/arch-arm.h
>>>> @@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
>>>>   
>>>>       /* Return address and mode */
>>>>       __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
>>>> -    uint32_t cpsr;                              /* SPSR_EL2 */
>>>> +    uint64_t cpsr;                              /* SPSR_EL2 */
>>>>   
>>>>       union {
>>>> -        uint32_t spsr_el1;       /* AArch64 */
>>>> +        uint64_t spsr_el1;       /* AArch64 */
>>>>           uint32_t spsr_svc;       /* AArch32 */
>>>>       };
>>>
>>> This change affects, besides domctl, also default_initialise_vcpu(),
>>> which Arm's arch_initialise_vcpu() calls. I realize do_arm_vcpu_op()
>>> only allows two unrelated VCPUOP_* to pass, but then I don't
>>> understand why arch_initialise_vcpu() doesn't simply return e.g.
>>> -EOPNOTSUPP. Hence I suspect I'm missing something.
> 
> I think it is just an overlooked when reviewing the following commit:
> 
> commit 192df6f9122ddebc21d0a632c10da3453aeee1c2
> Author: Roger Pau Monné <roger.pau@citrix.com>
> Date:   Tue Dec 15 14:12:32 2015 +0100
> 
>      x86: allow HVM guests to use hypercalls to bring up vCPUs
> 
>      Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
>      VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
>      guests.
> 
>      This patch introduces a new structure (vcpu_hvm_context) that 
> should be used
>      in conjuction with the VCPUOP_initialise hypercall in order to 
> initialize
>      vCPUs for HVM guests.
> 
>      Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>      Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>      Reviewed-by: Jan Beulich <jbeulich@suse.com>
>      Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> On Arm, the structure vcpu_guest_context is not exposed outside of Xen 
> and the tools. Interestingly vcpu_guest_core_regs is but it should only 
> be used within vcpu_guest_context.
> 
> So as this is not used by stable ABI, it is fine to break it.
> 
>>>
>> I agree that do_arm_vcpu_op only allows two VCPUOP* to pass and
>> arch_initialise_vcpu being called in case of VCPUOP_initialise
>> has no sense as VCPUOP_initialise is not supported on arm.
>> It makes sense that it should return -EOPNOTSUPP.
>> However do_arm_vcpu_op will not accept VCPUOP_initialise and will return
>> -EINVAL. So arch_initialise_vcpu for arm will not be called.
>> Do you think that changing this behaviour so that arch_initialise_vcpu returns
>> -EOPNOTSUPP should be part of this patch?
> 
> I think this change is unrelated. So it should be handled in a follow-up 
> patch.

My only difference in viewing this is that I'd say the adjustment
would better be a prereq patch to this one, such that the one here
ends up being more obviously correct. Also, if the function is
indeed not meant to be reachable, besides making it return
-EOPNOTSUPP (or alike) it should probably also have
ASSERT_UNREACHABLE() added.

Jan

> If you are taking care of this, would you mind to also look to move 
> struct vcpu_guest_core_regs within the #if defined(__XEN__) || 
> defined(__XEN_TOOLS__)?
> 
> I will attempt to do a proper review of this patch by the end of the week.
> 
> Cheers,
> 



  parent reply	other threads:[~2021-05-17  7:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05  7:42 [PATCH v3 00/10] arm64: Get rid of READ/WRITE_SYSREG32 Michal Orzel
2021-05-05  7:42 ` [PATCH v3 01/10] arm64/vfp: " Michal Orzel
2021-05-05  7:43 ` [PATCH v3 02/10] arm/domain: " Michal Orzel
2021-05-05 18:03   ` Julien Grall
2021-05-06  6:13     ` Michal Orzel
2021-05-10 17:02       ` Julien Grall
2021-05-05  7:43 ` [PATCH v3 03/10] arm: Modify type of actlr to register_t Michal Orzel
2021-05-05 18:04   ` Julien Grall
2021-05-05  7:43 ` [PATCH v3 04/10] arm/gic: Remove member hcr of structure gic_v3 Michal Orzel
2021-05-05  7:43 ` [PATCH v3 05/10] arm/gic: Get rid of READ/WRITE_SYSREG32 Michal Orzel
2021-05-05 18:06   ` Julien Grall
2021-05-05  7:43 ` [PATCH v3 06/10] arm/p2m: " Michal Orzel
2021-05-05  7:43 ` [PATCH v3 07/10] xen/arm: Always access SCTLR_EL2 using READ/WRITE_SYSREG() Michal Orzel
2021-05-05 18:07   ` Julien Grall
2021-05-05  7:43 ` [PATCH v3 08/10] arm/page: Get rid of READ/WRITE_SYSREG32 Michal Orzel
2021-05-05  7:43 ` [PATCH v3 09/10] arm/time,vtimer: " Michal Orzel
2021-05-05  7:43 ` [PATCH v3 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t Michal Orzel
2021-05-05  8:00   ` Jan Beulich
2021-05-05 11:49     ` Tamas K Lengyel
2021-05-11  6:37     ` Michal Orzel
2021-05-12 17:59       ` Julien Grall
2021-05-12 18:14         ` Andrew Cooper
2021-05-17  7:01         ` Jan Beulich [this message]
2021-05-17 16:03           ` Julien Grall
2021-05-21  6:33             ` Michal Orzel
2021-05-21  7:07               ` Jan Beulich
2021-06-07 13:16                 ` Michal Orzel
2021-06-07 13:31   ` Julien Grall
2021-07-01  8:19     ` Michal Orzel
2021-07-03 14:42       ` Julien Grall
2021-05-10 17:19 ` [PATCH v3 00/10] arm64: Get rid of READ/WRITE_SYSREG32 Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54e845e1-f283-d70c-a0c2-73e768e5a56e@suse.com \
    --to=jbeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=aisaila@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=michal.orzel@arm.com \
    --cc=ppircalabu@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas@tklengyel.com \
    --cc=wei.chen@arm.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.