Re: [CRITICAL for 4.18] Re: [PATCH v5 00/10] runstate/time area registration by (guest) physical address

["Roger Pau Monné" <roger.pau@citrix.com>]

On Fri, Oct 06, 2023 at 10:00:35AM +0200, Roger Pau Monné wrote:
> On Thu, Oct 05, 2023 at 07:58:50PM +0100, Andrew Cooper wrote:
> > I see this series has been committed.  But it's broken in a really
> > fundamental way.
> > 
> > 
> > This is a new extension with persistent side effects to an existing part
> > of the guest ABI.
> 
> The only change in the ABI is the different return code for multiple
> attempts to map the vcpu_info page, it used to be -EINVAL and it's
> -EBUSY now, which seems more descriptive.
> 
> The added hypercalls are an extension of the ABI, not not a
> modification of an existing part.  Or maybe I'm not understanding the
> complaint.
> 
> > Yet there doesn't appear to be any enumeration that the interface is
> > available to begin with.  Requiring the guest to probe subops, and
> > having no way to disable it on a per-domain basis is unacceptable,
> 
> We have never mandated such disables to be part of the series adding
> the new hypercalls, those have always been retro fitted in case of
> need.  Not saying we shouldn't do it, but it's not something we have
> asked submitters to do.

I've been thinking about this, and I assume that we would like some
kind of tools interface to list supported features by the hypervisor,
and then a way to disable them.  We could then use such information to
level the hypercall interface across a pool of hosts, and make sure
it's always the same.

In principle guest should cope with some features/hypercalls not being
able on resume, but we all know this is not always the case.

I'm going to punt this, as adding such interface would be too
disruptive at this point in the release, and in any case it's
unlikely we could reach an agreement on how the interface should look
like in a very short time frame.

Roger.