lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 22 Jun 2023 14:17:05 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Per Bilse <Per.Bilse@...rix.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        "open list:X86 ENTRY CODE" <linux-kernel@...r.kernel.org>,
        "moderated list:XEN HYPERVISOR INTERFACE" 
        <xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH] Updates to Xen hypercall preemption

On 22.06.23 13:15, Peter Zijlstra wrote:
> On Thu, Jun 22, 2023 at 12:33:31PM +0200, Juergen Gross wrote:
>> On 22.06.23 10:26, Peter Zijlstra wrote:
> 
>>>> The downside would be that some workloads might see worse performance
>>>> due to backend I/O handling might get preempted.
>>>
>>> Is that an actual concern? Mark this a legaxy inteface and anybody who
>>> wants to get away from it updates.
>>
>> It isn't that easy. See above.
> 
> Well, the old stuff gets to use full preemption on Dom0, then the new
> stuff gets more shiny options.

Yeah, but what about the hypercalls from non-dom0 systems needing the same
handling? This would require to run all guests which are using hypercalls
fully preemptive.

> 
>>>> Just thinking - can full preemption be enabled per process?
>>>
>>> Nope, that's a system wide thing. Preemption is something that's driven
>>> by the requirements of the tasks that preempt, not something by the
>>> tasks that get preempted.
>>
>> Depends. If a task in a non-preempt system could switch itself to be
>> preemptable, we could do so around hypercalls without compromising the
>> general preemption setting. Disabling preemption in a preemptable system
>> should continue to be possible for short code paths only, of course.
> 
> So something along those lines was suggested elsewhere, and I'm still
> not entirely sure how I feel about it, but look here:
> 
>    https://lkml.kernel.org/r/20230403052233.1880567-1-ankur.a.arora@oracle.com
> 
> Specifically patches 7 and 8. It is very close so that you currently
> do/want. Those patches are many moons old and i've not seen an update on
> them, so I've no idea where they are.
> 
> It solves a similar problem except it is 'rep string' instructions
> that's being interrupted.

Right. I'll ping Ankur.


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ