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

[Julien Grall <julien@xxxxxxx>]

Hi Andrew,

On 05/10/2023 19:58, Andrew Cooper wrote:
> I see this series has been committed.  But it's broken in a really
> fundamental way.
Thanks for pointing out. But I'd like to understand how I come to only 
hear about those concerns on the series after committing. Did I miss any 
thread? Even if this series has been pending for over 6 months, should 
have I waited longer before committing?
Furthermore, Jan pointed out that this series was discussed recently 
during the x86 meeting. Did you raise any concern during the call and 
they were not carried on the ML?
> This is a new extension with persistent side effects to an existing part
> of the guest ABI.
>
> 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, and
> has exploded on us more times than I care to count in security fixes
> alone, and that doesn't even cover the issues Amazon have reported over
> the years.
Indeed. But, AFAIR, all those patches got stuck because of diverging 
opinions between you and you. Can we finally come to an agreement on how 
to disable/expose a new hypercall/feature so we can move on?
> Henry: Blocker for 4.18.   The absolutely bare minimum necessary to
> avoid reversion is some kind of positive enumeration that the two new
> hypercalls are available.
So to clarify, you would like both an interface for the guest and the 
toolstack for 4.18. Is this correct?
> Otherwise I will be #if 0'ing out the new hypercalls before this ABI
> mistake gets set in stone.
>
>
> If this were x86-only it would need to be a CPUID flag, but it will need
> to be something arch-agnostic in this case. 
I think we can add two new flags in XENVER_get_features to indicate to 
the guest that the feature is supported. What do you think?
> The series should not have
> come without a proper per-domain control and toolstack integration,
I think this requirement should be written down in a document we can use 
for future reference and not expect people to remember what may have 
been said on the ML for previous hypercall addition.
Cheers,

--
Julien Grall