Re: [PATCH] Updates to Xen hypercall preemption

[Per Bilse]

On 6/21/2023 9:04 PM, Peter Zijlstra wrote:
> On Wed, Jun 21, 2023 at 07:19:21PM +0000, Per Bilse wrote:
>> On 6/21/2023 5:40 PM, Peter Zijlstra wrote:
>>> I don't understand it -- fundamentally, how can linux schedule when the
>>> guest isn't even running? Hypercall transfers control to the
>>> host/hypervisor and leaves the guest suspended.
>>
>> Hi Peter, as noted in earlier note to Andy, this is essentially existing
>> code that other commits have rendered ineffective over time.  Hence,
>> the finer details of how or why it works haven't changed since it was
>> first introduced.
> 
> That doesn't mean you don't have to explain how stuff works
Hi Peter, first of all I want to say that the vigilance and dedication
you and so many other people show for the kernel project and the
integrity of the code is highly appreciated.  It isn't so that "we"
(whomever that may be) are ignorant of that, and I have personally
enjoyed the freedoms of BSD, and later Linux, systems for longer than
I care to remember.  There is, however, a scope to every patch.

In this case we change CONFIG_PREEMPTION to CONFIG_PREEMPT in two
places; the other (quite minor) changes follow on from that, partly
to avoid a repeat in the future.  The code that is en- or disabled
by this change has already been through all the dscussion, reviews,
considerations, and gnashing of teeth that time-honoured traditions
require.  Maybe things were different at the time it was committed,
but that's nothing new -- a few years ago I was fixing IPv6 code
from the end of the last century, and it's entirely unsustainable
to repeat and rehash libraries of old discussions and code simply
because an ifdef is changed.

In all its brutality, the current state of affairs is that the kernel
has bugs that will cause it to crash or otherwise malfunction in
certain circumstances.  There is code present in the kernel that will
prevent that, but this code has become ineffective due to oversights
in commits made since the code was introduced.  We thought it was
in everybody's best interests to ensure this code was re-enabled,
that's all.  I fully support you and everybody else in your desire to
maintain the highest possible standards, and as I said to Andy wrt
his suggestion, I'll see what I can do.  In the meantime, I highly
recommend not shooting the messenger.

Best,

   -- Per