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

Re: Design session PVH dom0


  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 26 Sep 2022 11:30:38 +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=36aA06mf3eqFMteeQaZDhocyqplfnDuQ1lntQKtwgmk=; b=eDh8UPnE2Wp6ByYDXB5V1AsgMWbJg4RJcIC1sAVnnyhaGObxefflbRtqtjM0T1zyCHDTW62GSTgizT1PhYw+wHx9F4uYYSFFmTp72GuS8YtolaENT7FlbCOVK+VvvfWp6hxq/NGf8oc2AT9p6B67QDovVJ0ZwQ6IoYolos9ZJS/ZuziBufUAL3JV1BUtErzxJWpL674+puOlzhZjzN84vZuYG8Ylm9DPEblYS9PseRYpEP3MhnZd6xMcfJYrAwJli/yUkRS0p+9nOZlrBm9bMGFll0/bR3Aoen3fTyn7D95oU4H92zizQI/2iplCDuLENgUYra8J/s5AE+qScBz1lQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EyqlxPK5QqNxzYovsaI7oHssxUTcfj5OvTRXltZXDewLNDwIoFLRH+Hp4NqVBH9HlYZAckCsAHMsb78WMwm3VfP1bbcip+6/p+MWMirPjECEInrse9yWwPubmkqgxyMMoKzCZcFRbnXH0ia7tENgA/83UujHvHqn/XT3xjoaZYjsXdCmANiaNnpYR4KLR9kEit7L1Uk8DLbmUmK4MBqUXznT7GcTZPLiJvEtkg+NEnetKUmu7KVssfHuVZc0YBNtib2iNEbKell3QQ+lUZyv8+BYm50OgL8bmvR/qWEEoJqaQxFYTq0Gek6AUvXw1d4W5ATfLzToGui6SMj32rsbOA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 26 Sep 2022 09:30:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.09.2022 10:33, Juergen Gross wrote:
> On 26.09.22 09:53, Jan Beulich wrote:
>> On 23.09.2022 10:20, Juergen Gross wrote:
>>> On 21.09.22 17:53, Marek Marczykowski-Górecki wrote:
>>>> Session description (by Jan):
>>>> In the course of working on an XSA I had to finally get PVH Dom0 work on 
>>>> at least one of my systems, in a minimal fashion. This had turned up a 
>>>> number of issues, some of which have since remained pending. Therefore I’d 
>>>> like to gain understanding on whether there is any future to this mode of 
>>>> Dom0 operation, and if so when it can be expected to be better than tech 
>>>> preview or even just experimental.
>>>
>>> ...
>>>
>>>> Jürgen: PVH dom0 performance?
>>>>
>>>> Roger: it's bad; mostly relevant is qemu interfaces
>>>>
>>>> George: only for safety certifications? performance penalty may be okay
>>>>
>>>> Jürgen: hypercalls can be improved (virtual buffers?)
>>>
>>> Some more thoughts on this topic: Having hypercall variants with physically
>>> addressed buffers will help, but there is an additional complexity: what
>>> about hypercalls with really large buffers (e.g. the bitmap for modified
>>> pages for guest migration). In order to avoid having to allocate huge
>>> physically contiguous buffers for those purposes we'd probably need
>>> something like scatter/gather lists for hypercall buffers.
>>
>> Not sure. I'd rather see us add new (sub)hypercalls for such non-standard
>> cases. E.g. the bitmap example you give would be amended by a new flavor
>> having the caller pass in an array of GFNs (perhaps, as you say, with
>> further indirection to deal with that array also growing large). I'd
>> really like to keep the common case simple.
> 
> The question is how many hypercalls would be hit by the not common case.
> 
> Taking a quick glance I spotted:
> 
> - grant_table_op (subops setup_table and get_status_frames)
> - memory_op (several sub-ops)
> - multicall (main list of calls)
> - console_io (console data)
> - mmuext_op (some ops allow lists)
> - xsm_op (not sure a buffer can span pages, but interface would allow it)
> - physdev_op (subop set_iobitmap)
> - hvm_op (altp2m handling)
> - sysctl (multiple sub-ops)
> - domctl (multiple sub-ops)
> - hypfs (node data can exceed page size)
> 
> Do we really want to special case all of those?

Looking at the Linux uses of several of the ones covered by the top three
entries in your list I find they all use contiguous buffers already, to a
fair part because of limiting maximum number of entries. Therefore I don't
really think all of these would need special casing, until a reasonable
use case is demonstrated where such large lists are actually needed.

Jan



 


Rackspace

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