Re: [PATCH v2 2/6] gnttab: allow setting max version per-domain

From: Juergen Gross <jgross@suse.com>
To: "Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Cc: Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Christian Lindig <christian.lindig@citrix.com>,
	David Scott <dave@recoil.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/6] gnttab: allow setting max version per-domain
Date: Wed, 20 Oct 2021 13:45:26 +0200	[thread overview]
Message-ID: <19c25cbf-8697-b970-91e5-195f07a5222a@suse.com> (raw)
In-Reply-To: <a3d9388a-e2f5-76aa-d51a-2d74afb92bbd@suse.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 2931 bytes --]

On 20.10.21 12:57, Jan Beulich wrote:
> On 20.10.2021 10:04, Roger Pau Monné wrote:
>> On Fri, Oct 15, 2021 at 11:48:33AM +0200, Jan Beulich wrote:
>>> On 15.10.2021 11:39, Jan Beulich wrote:
>>>> On 22.09.2021 10:21, Roger Pau Monne wrote:
>>>>> --- a/xen/include/public/domctl.h
>>>>> +++ b/xen/include/public/domctl.h
>>>>> @@ -87,14 +87,22 @@ struct xen_domctl_createdomain {
>>>>>       /*
>>>>>        * Various domain limits, which impact the quantity of resources
>>>>>        * (global mapping space, xenheap, etc) a guest may consume.  For
>>>>> -     * max_grant_frames and max_maptrack_frames, < 0 means "use the
>>>>> -     * default maximum value in the hypervisor".
>>>>> +     * max_grant_frames, max_maptrack_frames and max_gnttab_version < 0
>>>>> +     * means "use the default maximum value in the hypervisor".
>>>>>        */
>>>>>       uint32_t max_vcpus;
>>>>>       uint32_t max_evtchn_port;
>>>>>       int32_t max_grant_frames;
>>>>>       int32_t max_maptrack_frames;
>>>>>   
>>>>> +/* Grant version, use low 4 bits. */
>>>>> +#define XEN_DOMCTL_GRANT_version_mask    0xf
>>>>> +#define XEN_DOMCTL_GRANT_version_default 0xf
>>>>> +
>>>>> +#define XEN_DOMCTLGRANT_MAX XEN_DOMCTL_GRANT_version_mask
>>>>> +
>>>>> +    uint32_t grant_opts;
>>>>
>>>> As it now seems unlikely that this will make 4.16, please don't forget
>>>> to bump the interface version for 4.17. With that and preferably with
>>>> the nit above addressed, hypervisor parts:
>>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> Actually no, I'm afraid there is an issue with migration: If the tool
>>> stack remembers the "use default" setting and hands this to the new
>>> host, that host's default may be different from the source host's. It
>>> is the effective max-version that needs passing on in this case, which
>>> in turn requires a means to obtain the value.
>>
>> Hm, my thinking was that the admin (or a higer level orchestration
>> tool) would already have performed the necessary adjustments to assert
>> the environments are compatible.
> 
> I don't think we can rely on this in the hypervisor. We may take this
> as a prereq for proper working, but I think we ought to detect
> violations and report errors in such a case.
> 
>> This problem already exist today where you can migrate a VM from a
>> host having the max default grant version to one having
>> gnttab=max-ver:1 without complains.
> 
> Are you sure about "without complaints"? What would a guest do if it
> expects to be able to use v2, since it was able to on the prior host?

A Linux guest should "just work". On resume it is setting up the grant
interface again like on boot (in fact there is one difference: the
number of grant frames is kept from before suspending).

Guest transparent migration wouldn't work in such a case, and I have no
idea how other OS's will react.

Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]