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

[David Hildenbrand]

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
> 


-- 

Thanks,

David / dhildenb