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

Re: Introduction of stable interface between Xenstore and hypervisor

  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 10 Sep 2021 15:22:46 +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; bh=oiFVKQIxRWxLlX3K6tsHaH0EGKjhQ4+KcCSrfELvS60=; b=RbKFTyxBHbBVqB3MImGuaoCYl0OIUC0gPy8yGOTIMST6ASG58lYi6vYCduWeOeCr0d/kLnodmC0oKJ1yBzy8huZ1c/BZiLl4IIP4vu+cu1DDx1kQ3mzsd2n3ihHMJDNlaZHUwoAYdOm7qO49wuR0wyWpQYyjaAhzFt4zXXp9EP0ky8Zv17wQQSBHnKpaobwAdilS75EyEw0UNxW3dhs1r5DJfeRp0XolEl6Bb7/Ha10nKVflUCYGPCfU0zRYEOAgbDJtrNdPRmjOo8J6evy0ogTdYUAoFgfCA49w0r1RVR/d4vVY3HN2c73wfnBGLfz01ZqLuxNlQaoAdL1lpoz28w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XTAoj5ne5WynUrGqiKgxtqoJoatjjYrbM080Fw4wwIqkSuK6ycNI5q4lZp6k0f4u7jfbqInMr/DlcbACEiMWSTyMKz1q2g7Uo+jk9l2BUz6gnDiEsbh6628kGsg89Pv+9hMOWiU8UQKBbdoz3yepv/MRGsmoJ8vSFFtKt4VQKmlGR24nHiB3i4WvdKZTRLJVbaqF8j0JOpl0iNlsNXA4bW/3rh6Xw9vEvxdXtU0VbEJwTSA9VBZzuz//nYLoAuVlYfPFyL/0o8GPcyvv2I+rNnAZCICfJ6xs507NZTI/mSwyeuaCuwJDddxIRwLexQggAYABvbIeODpAapBurIHfCw==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 10 Sep 2021 13:22:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09.09.2021 08:27, Juergen Gross wrote:
> Today Xenstore is using one unstable interface to retrieve the state
> of a domain (existing, dying).
> In order to decouple Xenstore further from the hypervisor, a stable
> interface should be established. This new interface should cover the
> following functionality:
> - get the needed state of a domain (existing, dying)
> - get a unique identifier per domain telling Xenstore that a domid
>    has been reused (today Xenstore could in theory miss this)
> - provide a way to avoid having to get the state of all domains when
>    a state change of a domain has been signaled (there is only an event
>    "some domain has changed state" today: VIRQ_DOM_EXC)
> I'm suggesting the following hypervisor modifications:
> - Addition of a global 64 bit domain sequence counter. This counter
>    will be incremented each time a new domain is created.
> - Addition of a sequence count to struct domain. It will be set to
>    the value of the new global domain sequence counter when the domain
>    is being created.

This looks like an "extended domain ID", which I think we want to
avoid unless exposure is extremely limited. Since we can't easily
predict what future usage this may have, I would suggest to seed the
global with a 15-bit (or wider) random value. I'd like to further
suggest considering to not have this be maintained by simply
incrementing, to make very clear to consumers that the actual value
has no other meaning. This could be done by multiplying by a random
odd number larger than 1 (determined at build or boot time). All we
want to guarantee is that numbers don't repeat (earlier than a 64-bit
value would wrap when linearly incremented).

> - Addition of a global bitmap with one bit for each possible domid
>    (resulting in a 4 kB page). Each time the state of a domain is changed
>    (domain creation, shutdown, deletion) the related bit is set.
>    When the VIRQ_DOM_EXC event is being registered the bitmap is reset to
>    have the bits set for all existing domains.

This page, as I understand from the subsequent item, is not intended
to be exposed to the domain running xenstored (or any other one)?

> - Addition of a new stable hypercall ("get domain state") returning the
>    following information:
>    + domid of a domain having the bit set in above bitmap
>    + state of that domain (existing, dying)
>    + sequence count of that domain
>    The related bit is reset in the bitmap as a side effect of the call.

What I'd like us to consider up front is whether xenstored is going
to remain only entity interested in this kind of information. The
entire design looks to leverage that there's only a single consumer
in the system.

I understand the caller would iterate over this hypercall. Is there
concern about this iteration never finishing, if e.g. a guest gets
rebooted quickly enough?




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