[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for physical address based hypercalls
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Wed, 28 Sep 2022 10:58:32 +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=Xwtq2mYsbEtoYgqO+YuFXU95aetesuxDjlrp/uhJasY=; b=YHA61kNxXIGQrwT3GaRajRI1h9LoY/sYVE/FJDjCCl6DZ+HRE4iftiGagtqT7h+W0NYu9VCeGQrAZxyuUOoN8tolYVrXPZhwtUqxMzHFLSHRZmPL3jlvZelGASZvyv2hpLJYPeW5+wo4zQxd4KBzopU98c1+xfkX12PDagNGCw+oG58Y4YawCEwbvMDVEFT8kS8D0D53jfw4TxHD4ZHGhvi/WozW8i0jOm30eRRzMDe1u/GGNQYqmOttmfEvqhaBJOb+9O3DZTltAqkYcgP3TlD3M3F3rcat4oXD47UEZXXIOHnlupRQQNEhntfTiv/ciNdS5pooLOpOhPgGmB951Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oSCYFi/SabRZCgvaGhbaAohRWX6DNAchW7axhk3Md/JbyLyh4rHexsfVLYWPuYmzEgZQI4IR+S1ExPle7A1VDv1T2O+Kv1wof0LA/JwVE/iRN2voosMEVL7/cPVGXQlSEhE1VF+E9KvqSenX4JXdmkAybhwd+7UNr2Be00ICZ7+QVs4dvexj5ZtmU4rSGBgqcITlY2DmAYbVuZXDTjTPqbyUxc/JwcdYgH1hLuzWXEeY3v1IAovTbgW5flzdg0asBU/5M1WXijVXuqne0Asp4Ew36GMpNwGlKQ/oqmr2grUkzH3IcJPmnXtpElE1CFZ8YMSLap4ZXTbpPwCYvHzamA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Delivery-date: Wed, 28 Sep 2022 10:58:40 +0000
- Ironport-data: A9a23:ZMzxbKJxcOhfiuTvFE+Rw5QlxSXFcZb7ZxGr2PjKsXjdYENS1zBSy jROWjjUOq3ba2v8eNt3a9nio04A75PWydAySwZlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAgk/vOHtIQMcacUghpXwhoVSw9vhxqnu89k+ZAjMOwRgiAo rsemeWGULOe82MyYzl8B56r8ks15qyj4mNA5zTSWNgQ1LPgvyhNZH4gDfnZw0vQGuF8AuO8T uDf+7C1lkuxE8AFU47Nfh7TKyXmc5aKVeS8oiM+t5uK23CukhcawKcjXMfwXG8M49m/c3Kd/ /0W3XC4YV9B0qQhA43xWTEAe811FfUuFLMqvRFTGCFcpqHLWyKE/hlgMK05FY0z8+ZFPmxfz tgVb2k1Qy+Bt/+YxJvuH4GAhux7RCXqFKU2nyg4iBTmV7MhS52FRLjW79hF2jt2ntpJAfvVe 8seb3xocQjEZBpMfFwQDfrSns/x3iW5L2Ie9Q/T/PJti4TQ5FUZPLzFGdzZYNGVA+5SmV6Vv Dnu9GXlGBAKcteYzFJp91r8376TwH6rAur+EpWIqadBrUaOzFYXJwRIV2K0+teXoE6xDoc3x 0s8v3BGQbIJ3E6hQ8T5Xha4iGWZpRNaUN1Ve8Uq5QfIxqfK7gKxAmkfUiUHeNEgrNUxRzEhy hmOhdyBONB0mLicSHbY86jOqzq3YHARNTVbPXVCShYZ6d7+po11lgjIUttoDK+yiJvyBC30x DeJ6iM5gt3/kPI26klyxnif6xrEm3QDZlRdCtn/No590j5EWQ==
- Ironport-hdrordr: A9a23:Z+5K/qz3t5U/a0PkDIrSKrPxgOskLtp133Aq2lEZdPULSKGlfp GV9sjziyWetN9IYgBZpTgZUJPwC080hqQFmrX5Wo3SETUO2VHYZ72KiLGP/9SOIVybygcw78 Zdmu1FeaTN5DtB/IrHCWuDYrEdKbC8mcjG69s2jU0dKz2CAJsQjDuRfzzrd3GeMzM2Z6bReq D92uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmfDHOind+i1bfyJEwL8k/2 SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dY2xY4kuW3XRYzSTFcZcso65zXUISSaUmRIXee z30lQd1gJImjTsly+O0F3QMkLboUwTAjfZuCKlaD3Y0IPErXsBerV8bcgySGqk12Mw+N57y6 5FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwtVrQc/tQ0qbWIlUs4nkaUPuEdOVJsQFiPz744qVO FoEcHH/f5TNVeXdWrQsGVjyMGlGi1bJGbPfmES/siOlzRGlnFwyEUVgMQZg3cb7Zo4D51J/f 7NPKhknKxHCsUWcaV+DuEcRtbfMB2FfTvcdGaJZVj3HqAOPHzA75bx/bUu/emvPIcFyZMj8a 6xJW+wdVRCCX4GJff+rKGjqCq9PllVdQ6du/129tx+pqD2QqbtPGmKVE0u+vHQ0MkiPg==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHY0yaT5LEru00uSkuEONBLdSy8OK30rDEA
- Thread-topic: Proposal for physical address based hypercalls
On 28/09/2022 11:38, Jan Beulich wrote:
> As an alternative I'd like to propose the introduction of a bit (or multiple
> ones, see below) augmenting the hypercall number, to control the flavor of the
> buffers used for every individual hypercall. This would likely involve the
> introduction of a new hypercall page (or multiple ones if more than one bit is
> to be used), to retain the present abstraction where it is the hypervisor
> which
> actually fills these pages.
There are other concerns which need to be accounted for.
Encrypted VMs cannot use a hypercall page; they don't trust the
hypervisor in the first place, and the hypercall page is (specifically)
code injection. So the sensible new ABI cannot depend on a hypercall table.
Also, rewriting the hypercall page on migrate turns out not to have been
the most clever idea, and only works right now because the instructions
are the same length in the variations for each mode.
Also continuations need to change to avoid userspace liveness problems,
and existing hypercalls that we do have need splitting between things
which are actually privileged operations (within the guest context) and
things which are logical control operations, so the kernel can expose
the latter to userspace without retaining the gaping root hole which is
/dev/xen/privcmd, and a blocker to doing UEFI Secureboot.
So yes, starting some new clean(er) interface from hypercall 64 is the
plan, but it very much does not want to be a simple mirror of the
existing 0-63 with a differing calling convention.
~Andrew
|
