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

Re: Proposal for physical address based hypercalls


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 28 Sep 2022 14:06:43 +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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OBLInMlojnTFV21wrEZ2CRy1C0KdrYkbE46O3y3IEVA=; b=esjT8gpPrUUWeExVnSAtYP2wJptpjcYBbqE2eO5zqLG5H257R3l5zX7hz3IiKZ0zIxu2AMFaEdsN08fMxFonufgsCG2HEFzICA6WmTSuZerX/ITWE9DhFSkydUKOiASEqnqcxokn9bV8TgnUS4QIhsEzJcn4SmKT64NiLBcB18vq1uRB72u98rYczkco5jLTGgNYTngECNRpEPNpN8x5uJE5CxiL5sgPKNpvE4mXHJv6lXC/Ke+8VFKnkv8Qs9d4IL5rf+zNyn0ESb/nPKTdCTYxZdHHryeo45NvTKXxpM3d68uj6lQYThcrmX37EARegZcPjkMzuE9DFI9EtesjAQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FitsUuUCGw1Lih/g/XeVfr/+CbYixitWzXAFzUTiHRosDcI6/sOKGFBrao03ibCCCOQPpj8zl97SNA+NaUi5+FohqAk/IKBavwiwZDdapOgHZvdLgf3hWelzELsZlZQxd331eD2KqM3sui9LEDpQ61OjdwfCYWUZQ2fg9F/lltTL0VX3+D8BKyB3m8ZLM1YaILA4ggvkje+uZucs55zDw6V0Zh03ZwxuJ5BGcH2rpNhwRw/zWQY6uhTMuRq56QHtTMWue7Bf3qJQGjkrOfvv9QYVL0MNzXj28QL5ljnPSN4Jh/c3d5bQjtet+aDPNcetutjpG0HJvzsbyIOa8IIimw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 28 Sep 2022 12:07:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.09.2022 12:58, Andrew Cooper wrote:
> 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.

I don't think there's a dependency, and I think there never really has been.
We've been advocating for its use, but we've not enforced that anywhere, I
don't think.

> 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.

All of these look like orthogonal problems to me. That's likely all
relevant for, as I think you've been calling it, ABI v2, but shouldn't
hinder our switching to a physical address based hypercall model.
Otherwise I'm afraid we'll never make any progress in that direction.

Jan



 


Rackspace

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