[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for physical address based hypercalls
- To: Juergen Gross <jgross@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Wei Chen <Wei.Chen@xxxxxxx>
- Date: Thu, 29 Sep 2022 18:16:20 +0800
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; 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=nkOnfQJNOiimrsmcpCV6O+uwz8ue26vjLsIXsPctdZ8=; b=RQnAIrk7xBHyauJgLLz0Olul2lVVaJ/BJ40dBTCLKVh+/BBBVlG9iv3tWF72uhuCSC0jYBvz4uHPBcwsxjqMFVwPNNelQ++lpOroiaSmte4XE48m9O3XoO0tLsmF3BP9rkRUws1GLtH01IPsvlEyEqoXwOU8R5xZVPOYYc8LK9SEiflczny2uaAllgy9xhlRyp49EXXPajz5r3yZS7HopNruDelv96zpZaH43UPdGqhEWQjeuHMIIM2qeyXKrgh0K2cw2tblJ6GkvG/jwMor8yhTFbkvjdrSMvf8knBZnNKhF2t6svUxHz8NI9nio1xBOWLh0SOhg0REKmbm2H8mZA==
- 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=nkOnfQJNOiimrsmcpCV6O+uwz8ue26vjLsIXsPctdZ8=; b=MIE8vnV8I52664Mic2wXrGO8KgPRlZu9fOvuH1xFqlEUVdFgGbxw1TV2+tmzIThDfBjZgNIUw+sLYKfcx324w/gNwffK4WyFvFvLwiz45N8Z3X8b39+mufr8Hrig/d+nClVuITkSQuDh0PoXc91AsQysU7FAo2/rW9pgrw0e8dtSLmtfSlkW59heX6zNpD3hYdzatBA2iu0d7iKDJGJdI7xrLVoc7Vl1EXe9ap52jUH19rodBChutQm7ezgPwtxxd2CBb6KmRZEAjvxBlxyHmiGrCVz7tNLh7uuVURdTrcB9lnLJvHgHtXIpqTXymtGzB2YTQNBtW8D+j3+pVczK9Q==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=gp2ha6BUKsQ9C0+K/WnSKTlliDYy82YqnDLbRbEakxBwucsS0JmoiF/0WIEWnGV0hghm2AJ/7fU11QOV4BcWo6+skUlzSSIwTScMPTKNFDnVBWCyvzd/NKVyrZNrKPwPK1cWHkvwjImyZNipUBIK0atvdwzufacMWcfitVEcQDPiPfLpnRUGq0OxP4WAtsuVuSQRsLmvvIiMhVel8614RsvhMFNfGBzdBGsDtxCLyqfmOC7ROUFH2xsxMmehUrq4VZv/pUQHIYTHCfFSrCg1pB3Hk+KmEFjjgYC3ICxeIKWdtqbNE+iAMpcFNSAO83uV6DF8sV6sUy0sW8/DBwNRfQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZFWcw2ucuDzCSJz7Gg78emEh0Aq6mVFB36W65pGBNK9ZIzicdGZyybKScWnB80VwxKomRlOIUWMIvBx0IHjXiOq7ozqWIuxz+2EO6wvphY5RbrGp01IoLoCBN5I7WnX9DrbQ5PhAZTg+IgUez5q7WC4NsuAHgHC0BI1zMmBqC0STHr8d3J0yJfB2m8qOiYMXwxRWvSCAca4eS3YSPI7a1lpGpN3tkbqKucyOl6j+1HpUesmdNcyU0pgIw0oWiCyEFUzYa6cGfhLudrfTjZaDzmC/faQhF4drxnPWo2lTIk8U2OkyD+vdD7vt6ZwPHtA2zq1sQDmv0OPWFu8zfglw/w==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 29 Sep 2022 10:16:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
Hi Juergen，
On 2022/9/28 21:03, Juergen Gross wrote:
On 28.09.22 14:06, Jan Beulich wrote:
On 28.09.2022 12:58, Andrew Cooper wrote:
On 28/09/2022 11:38, Jan Beulich wrote:
What about an alternative model allowing to use most of the current
hypercalls unmodified?
We could add a new hypercall for registering hypercall buffers via
virtual address, physical address, and size of the buffers (kind of a
software TLB). The buffer table would want to be physically addressed
by the hypercall, of course.
It might be interesting to have this table per vcpu (it should be
allowed to use the same table for multiple vcpus) in order to speed
up finding translation entries of percpu buffers.
Any hypercall buffer being addressed virtually could first tried to
be found via the SW-TLB. This wouldn't require any changes for most
of the hypercall interfaces. Only special cases with very large buffers
might need indirect variants (like Jan said: via GFN lists, which could
be passed in registered buffers).
Encrypted guests would probably want to use static percpu buffers in
order to avoid switching the encryption state of the buffers all the
time.
I agree with this one. When we were working on Arm Realm, we were also
concerned about how buffers in hypercalls were shared between Xen and
realm VM. Dynamically switching between protected and unprotected (can
be accessed by VM and Xen, could not execute code) states of memory can
be very expensive. And these uncertainties are also very easy to cause
security problems. We have thought about explicitly reserving a section
of unprotected memory for the realm VM for hypercall buffers, but that
means Xen drivers of Linux need to be modified. It's great to see the
community starts to do design about this.
Cheers,
Wei Chen
An unencrypted PVH/HVM domain (e.g. PVH dom0) could just define one
giant buffer with the domain's memory size via the physical memory
mapping of the kernel. All kmalloc() addresses would be in that region.
A buffer address not found would need to be translated like today (and
fail for an encrypted guest).
Thoughts?
Juergen
|
