[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 0/2] coroutine: add x86 specific co

From: David Hildenbrand
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 0/2] coroutine: add x86 specific coroutine backend
Date: Wed, 13 Mar 2019 15:01:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 13.03.19 14:24, Paolo Bonzini wrote:
> On 13/03/19 12:49, Peter Maydell wrote:
>> On Mon, 11 Mar 2019 at 12:49, Paolo Bonzini <address@hidden> wrote:
>>> This is in preparation for CET support for x86.
>> What's CET ?
> It's basically shadow stacks and tracking of indirect branch
> targets---hardware support for what others calls control-flow integrity.
>  I've now sent the full series, which consists of these patches (with a
> few cleanups) followed by CET support.
>>> I know this is very late, but if possible I'd like to have this in 4.0
>>> as an experimental backend.
>>> Paolo Bonzini (3):
>>>   qemugdb: fix licensing
>>>   qemugdb: allow adding support for other coroutine backends
>>>   coroutine: add x86 specific coroutine backend
>> I can't say I'm terribly enthusiastic about having
>> native-asm specific versions of the coroutine code.
>> It seems like the kind of thing that's going to be
>> fragile against changes in libc implementation, calling
>> convention, etc.
> I thought the same before I started writing it, but surprisingly it does
> not require any of that.  Since the asm clobbers all registers except
> the frame and stack pointer, the compiler will just push/pop all
> caller-save registers automatically in qemu_coroutine_switch and
> qemu_coroutine_new's prolog and epilog.  This also means that porting it
> to other architectures should require only a rewrite of the CO_SWITCH macro.

So the clobber list in the inline asm actually only hinders the compiler
to play cheap tricks when trying to optimize - so it is forced to
save/restore all caller-save register, right?

Sounds sane to me, porting it shouldn't be too hard (however I can't
tell when I will have time to look into the details).

> I can try porting it to ARM and/or aarch64 to prove that point, or
> perhaps David will enjoy beating me and doing an s390 port. :)
> Paolo



David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]