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

Re: [Xen-devel] [PATCH RFC for-4.13 10/10] xen/arm64: entry: Ensure the guest state is synced when receiving a vSError


  • To: Julien Grall <julien.grall@xxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Fri, 27 Sep 2019 15:30:05 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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-SenderADCheck; bh=bG2xXp9Dg0nsTHmECDsXay2H2BuZ4YGFXDGn+rWb9YM=; b=giokO2e9Ko/sg5KQYidkVTDv9Bbv26yIZu//SL6/Jd7DyzoIJfy3iTTHqYZLsFZkNCXZdYFFFi8Zrpd95oUvJOB6i2UHbBhfGt6X6Fhs0ip1K3dDL1NMUBnQki68+xREtlaFXxxVRaAhOyQ5VM9d9zBaNDf+z7+Lp6T7zhcCGsFjLpKUqIDQo0b8P9IG6UmQueDBEJgRvjAeWKMt62WFymVD1Tc/PoclaVFbReR8vZYJmFGPq2p+KXCkTo6Uez8G7+27gN98yzLJXkKs7HviO8nSi9KhaXjkV8Yuf8DdBCAjSCu3edMxvm8RFDD9dSv5TYZYwCIPvi7LbJ40gXHh1Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FA+fMhfr6gaLLH+PR2s7qz1Eqsi6Qv2fSCatDHke36W4Fp2g2NJoDG0gz+BLycz4eBxEU3ETm34OkpCYvzqNcSlB442ewROQ+OJeGLw3Q/uhiyiJf7I2krqFDvqO/bAKOrUpgJqBO3LsYY7PlAfEwSsTidl6AFMgV/pgJoQhYjGCoi1Yav7ejSKSC5nc0BxgpZPgkkmz2Ezo8RmOD+XEEZqAz6iTnMnAMG5Okq86OYayAFzHPQPtrHjeKXdBa7LtW5KNN+BbGJ5l/pkIeZcGJGVpzDeu+11UpgDB+tv6MhPfw4L91eUunKCfOT0ErFwME9epdT6yRBibXuIHv+8tBQ==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@xxxxxxxx;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, "andrii.anisov@xxxxxxxxx" <andrii.anisov@xxxxxxxxx>
  • Delivery-date: Fri, 27 Sep 2019 15:30:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVdJmXIorHdthDnUCQMEMpZACXoqc/p6sA
  • Thread-topic: [PATCH RFC for-4.13 10/10] xen/arm64: entry: Ensure the guest state is synced when receiving a vSError

Hi Julien,

Julien Grall writes:

> At the moment, when a SError is received while checking for a pending
> one, we will skip the handling the initial exception.
>
> This includes call to exit_from_guest{, _noirq} that is used to
Did you mean enter_hypervisor_from_guest{, _noirq} there? Otherwise, I'm
confused a lot.

> synchronize part of the guest state with the internal representation.
> However, we still call leave_hypervisor_tail() which is used for preempting
> the guest and synchronizing back part of the guest state.
>
> exit_from_guest{, _noirq} works in pair with leave_hypervisor_tail(), so
> skipping if former may result to a loss of some part of  guest state.
> An example is the new vGIC which will save the state of the LRS on exit
> from the guest and rewrite all of them on entry to the guest.
>
> For now, calling leave_hypervisor_tail() is not necessary when injecting
> a vSError to the guest. But as the path is spread accross multiple file,
> it is hard to enforce that for the future (someone we may want to crash the
> domain). Therefore it is best to call exit_from_guest{, _noirq} in the
> vSError path as well.
>
> Note that the return value of check_pending_vserror is now set in x19
> instead of x0. This is because we want to keep the value across call to
> C-function and x0, unlike x19, will not be saved by the callee.
>
> Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
>
> ---
>
> I am not aware of any issues other than with the new vGIC. But I
> haven't looked hard enough so I think it would be worth to try to fix it
> for Xen 4.13.
> ---
>  xen/arch/arm/arm64/entry.S | 21 ++++++++++++++-------
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 91cf6ee6f4..f5350247e1 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -168,11 +168,13 @@
>          /*
>           * The vSError will be checked while 
> SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
>           * is not set. If a vSError took place, the initial exception will be
> -         * skipped. Exit ASAP
> +         * skipped.
> +         *
> +         * However, we still need to call exit_from_guest{,_noirq} as the
> +         * return path to the guest may rely on state saved by them.
>           */
>          alternative_if SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
>          bl      check_pending_vserror
> -        cbnz    x0, 1f
>          alternative_else_nop_endif
>  
>          mov     x0, sp
> @@ -180,6 +182,11 @@
>          msr     daifclr, \iflags
>          mov     x0, sp
>          bl      enter_hypervisor_from_guest
> +
> +        alternative_if SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
> +        cbnz    x19, 1f
> +        alternative_else_nop_endif
> +
>          mov     x0, sp
>          bl      do_trap_\trap
>  1:
> @@ -383,9 +390,9 @@ return_from_trap:
>  /*
>   * This function is used to check pending virtual SError in the gap of
>   * EL1 -> EL2 world switch.
> - * The x0 register will be used to indicate the results of detection.
> - * x0 -- Non-zero indicates a pending virtual SError took place.
> - * x0 -- Zero indicates no pending virtual SError took place.
> + * The register x19 will be used to indicate the results of detection.
> + * x19 -- Non-zero indicates a pending virtual SError took place.
> + * x19 -- Zero indicates no pending virtual SError took place.
>   */
>  check_pending_vserror:
>          /*
> @@ -432,9 +439,9 @@ abort_guest_exit_end:
>  
>          /*
>           * Not equal, the pending SError exception took place, set
> -         * x0 to non-zero.
> +         * x19 to non-zero.
>           */
> -        cset    x0, ne
> +        cset    x19, ne
>  
>          ret


-- 
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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