[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
vcpu_show_execution_state() difference between Arm and x86
- To: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 1 Sep 2021 15:39:31 +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; bh=6gOIlwfeDw151rTxi3HU+tBg3DOPTUR73ZuMPiIZHoc=; b=CRp3Ye82S0aOXdlC4tp4jCzjyS9ZmS92mF73ZVYdbNG6BqTgbMRzU2ylYQFyCcflU1qpQTUky9sQNpJBdzjesEtAjWjOQTIIxVqUKKEv2rd/8EOgm/9C2uKF7USILMQN69fso0fz7qKWyVtbP4DytqfdEkWV03gKBgtafki0piCDK7KyS8bDlpW3D7QVnYBAM5Mj/K7KfCmdOVtnaZnAmt16D8wdQtCcFdh0R3bii38FmlImXRzUDsT6UDO249NL+8uoVjZ3kh/5kBOZdWDJT3ONSJ9Ehfke8o57BHUuFwcQe1dRAg/1KdpS/aD8kQDHnT0DxlTMTK4bz4Gd9L5E0g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JBhcJGpW5huymKKurh1Y480OXWQYKrpZ0ZPCfYX/2LQcj/OTZxGIWy0BhYkNF26PqQQxLraxurcPWSFrsyE3MOHV/x4Hrbd7K5L1qa7Bl7Xf1b/I7F8+aUuxoe9FmvNly07BKavMIdm9QzuLzcu8WY4ly+KLzvI5NawY4lBjdP2htQC8XCd9fA+bOMbu9yRUbvSYziTHM8zQxQsP0dn42k0PBsgGzjUieeSdvNWaWV1U7iWfCyhIF/iVau1EgDwKL2oG23hcmfRCXaJ47TSfhhhs91QL7srqbRPrfvPre/q5uTU65SPLl1feU9tN/+uxXvwKolew9rgfkaV8gq61RA==
- Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 01 Sep 2021 13:39:58 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
All,
back in 2016 Andrew added code to x86'es variant to avoid interleaving
of output. The same issue ought to exist on Arm. The lock acquired,
or more importantly the turning off of IRQs while doing so, is now
getting in the way of having PVH Dom0's state dumped the 2nd time. For
register state I did find a sufficiently simple (yet not pretty)
workaround. For the stack, where I can't reasonably avoid using p2m
functions, this is going to be more difficult.
Since I expect Arm to want to also have interleave protection at some
point, and since Arm also acquires the p2m lock while accessing Dom0's
stacks, I wonder whether anyone has any clever idea on how to avoid
the (valid) triggering of check_lock()'s assertion without intrusive
changes. (As to intrusive changes - acquiring the p2m lock up front in
recursive mode, plus silencing check_lock() for nested acquires of a
lock that's already being held by a CPU was my initial idea.)
Thanks, Jan
|
