[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 03/10] domain: GADDR based shared guest area registration alternative - teardown
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Tue, 17 Jan 2023 21:17:48 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=NJKwbt51lAIQ5yBjh6WMmX6f7pvIIpA15gy8NIXAXMQ=; b=Ddrp3gmuRLnTlrqO5qeijHikWcQTaCXGhVvkPlcJEB7UhsSQnaHVzIkNu3n1UmTd2VrQruZbSSDNGwerSfS4PrAGCZGY7yMlBgeGnyYwhztBIl1LQvsWKHSoGnifqP4u4n+5/PNTyDL14WL4Jjb8oHKKoeLQkLYfxkwpu/W9nMSsK/XIMLI4o6BshxrBIfOeshDu0ooDd3trHfEuG0lh5K8ecvY9fZm3um7HxM0vMW7xdfyH/w3VHiJNbeSCNw9tZwbeYcOAESN2BJhJOhwTfmaDT6RIdDPEjdBdbp2zePplhR73gKdAoC4t9B0sWxl5KrrOwg5o5lL0rCZSZ0JiKA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wz62AltO+8ziIU9ONWiHHk99476slIL96X5He1iufQnV/90y4eRgS/zY6xBqBRFSLoyJJNnQ0iUeUanQmEERxgev66hwfr0LkDbcmtR4HrkM/O+Iwk/j5wJmRaT3nteWxvQ/THOlEqe59UytCrGbmY3IsCSAwveFm7ICK3s2/YPYQAh+jMuy9Erz9VZ+lUNJF4Q3c/3oix+N5x+VmuhYTRFyB/ysu1lyGc+rIica6HorkIXzYVhIF9W5mSd5c5V2ORfWbSis8mD5SINPQLOVjGriZpNrvWVISeOA+oWUdtS0L3wqPlReYn0bYVw2tLgPjRXsXHwjHtnKiNnEOVxQtQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 17 Jan 2023 21:18:07 +0000
- Ironport-data: A9a23:u4t+GKhev10Nkq4nsaBAACBrX161qhEKZh0ujC45NGQN5FlHY01je htvUDqCaPmMZ2TzeNgiOd6z9k4BsZTTx9Q1HFZo/n82Qiob9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmUpH1QMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWt0N8klgZmP6sT5QaBzyN94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQ7Iw5VXDCStdvr//Wxe+Y9hu0kIefCadZ3VnFIlVk1DN4AaLWaG+Dv2oUd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEsluG1bbI5efTTLSlRtm+eq njL4CLSBRYCOcbE4TGE7mitlqnEmiaTtIc6RebhrqY63Qb7Kmo7Ki1KbFWnvMWFq0uDRolHC lFM3nQIsv1nnKCsZpynN/Gim1aGtBMBX9tbE8Uh9RqAjKHT5m6xFmUCCzJMdtEinMs3XiAxk E+EmcvzAj5iu6HTTmiSnp+WsDezNC49PWIEIygeQmMt+ML/qYs+ihbOSNdLE6OviNDxXzbqz FiisywWl7gVy8kR2M2GEUvvhjutot3MUVQz7wCOBma9tFohOciiepCi7kXd4bBYNoGFQ1Kdv X8C3c+D8OQJCpLLnyuIKAkQIIyUCz++GGW0qTZS81MJrlxBJ1bLkVhs3QxD
- Ironport-hdrordr: A9a23:PX/DcavC8yYv55/FLR6GL87u7skDZ9V00zEX/kB9WHVpm62j+v xG+c5xvyMc5wxhO03I5urwWpVoLUmzyXcX2+Us1NWZPDUO0VHARL2KhrGM/9SPIUzDH+dmpM JdT5Q=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHY444WbZhuHDQ41k2+L84eJy1YfK6jqy6A
- Thread-topic: [PATCH RFC 03/10] domain: GADDR based shared guest area registration alternative - teardown
On 19/10/2022 8:40 am, Jan Beulich wrote:
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, add the necessary domain cleanup hooks.
What are the two areas you're discussing here?
I assume you mean VCPUOP_register_vcpu_time_memory_area to be the
x86-specific op, but ARM permits both VCPUOP_register_vcpu_info and
VCPUOP_register_runstate_memory_area.
So isn't it more 2+1 rather than 1+1?
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> RFC: Zapping the areas in pv_shim_shutdown() may not be strictly
> necessary: Aiui unmap_vcpu_info() is called only because the vCPU
> info area cannot be re-registered. Beyond that I guess the
> assumption is that the areas would only be re-registered as they
> were before. If that's not the case I wonder whether the guest
> handles for both areas shouldn't also be zapped.
At this point in pv_shim_shutdown(), have already come out of suspend
(successfully) and are preparing to poke the PV guest out of suspend too.
The PV guest needs to not have its subsequent VCPUOP_register_vcpu_info
call fail, but beyond that I can entirely believe that it was coded to
"Linux doesn't crash" rather than "what's everything we ought to reset
here" - recall that we weren't exactly flush with time when trying to
push Shim out of the door.
Whatever does get reregstered will be reregistered at the same
position. No guest at all is going to have details like that dynamic
across migrate.
As a tangential observation, i see the periodic timer gets rearmed.
This is still one of the more insane default properties of a PV guest;
Linux intentionally clobbers it on boot, but I can equivalent logic to
re-clobber after resume.
~Andrew
|
