On 25.02.22 11:30, Jan Beulich wrote:
On 25.02.2022 11:24, Julien Grall wrote:
On 25/02/2022 08:12, Jan Beulich wrote:
On 24.02.2022 23:55, Julien Grall wrote:
On 16/02/2022 09:29, Jan Beulich wrote:
On 16.02.2022 08:20, Juergen Gross wrote:
On 15.02.22 22:13, Julien Grall wrote:
As a side note, should we also update SUPPORT.md?

Good question.

I'm not sure here either - talking about individual hypercall sub-ops
seems overly small granularity to me for this kind of doc. Plus I
don't view deprecation and de-supporting as the same thing. The latter
would mean to render unsupported any old XenoLinux which may still be
in use, all of the sudden.

I understand this would result to unsupport some old OSes (not clear how
old). However, from what Juergen said this feature is untested.

To me it sound like we are not confident that we could security support
this feature.

So I am not sure to understand why we only want to deprecate it.

Not sure what to say: Rendering unsupported however old guests is not
a nice step. Hence my concern (which isn't an outright objection).

In the past we have removed support for feature we deemed unsafe to use
and it would require effort to secure it. This is despite the fact that
it may be used in production (e.g. PV devices, qemu trad...).

So I think the question here is really, do you think we can sensibly
security support GNTTABOP_transfer?

I don't think it's a question of "can", but of "are we willing to". It
would be "can" only if we learned of some seemingly very hard to solve
issue. From a workload perspective it would certainly be nice if we
didn't have to think about this anymore. Yet like in certain other
cases, besides the particular item here I'm also worried of setting
a precedent which may then be used to argue for the removal of support
for other operations, just to make our lives easier.

Just one comment: desupporting GNTTABOP_transfer would hit only systems
with a XenoLinux dom0. I think those running on a still supported Xen
version are really rare these days.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to