Re: [Xen-devel] [PATCH v3 09/23] xsplice: Add support for bug frames. (v4)

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 24/02/16 16:22, Konrad Rzeszutek Wilk wrote:
> . snip..
>> There is a neater way of doing this, which doesn't involve having "if (
>> regular ) else if ( xsplice )" logic chains through the code.
> s/chains/chain/
>
> There is only one that uses the 'xsplice' name in it:-)
>
> The other two are wrapped with the 'is_patch'.
>> Given a
>>
>> struct virtual_region
>> {
>>     struct list_head list;
>>     unsigned long start, size;
>>
>>     struct bug_frame *foo;
>>     struct exception_table_entry *bar;
>> };
>>
>> The init code can construct one for the base hypervisor, and xsplice can
>> add or remove entries from the list.  Then, the trap routines search the
>> virtual region list for [start, size) and follow the appropriate pointers.
> You are suggesting that on bootup we parse the the __stop_bug_frames_[0-3]
> (different on ARM), and create an linked list to contain those.

Can probably manage this at compile time for the builtin ones.

>
> Then xSplice can call in this API to add their own - and on unload it can
> unlink them and free them.
>
> If m understanding is correct - while it is certainly much nicer, it has 
> drawbacks:
>  - Increases the code to now handle the linked list and all the code around it
>    (And correspondingly we may have now some extra bugs to track).
>  - Bigger memory consumption - we now to have to consume memory for this list 
> - even
>    for the built-in ones.

I mean having one struct virtual_region for Xen itself (perhaps two; one
for .text and one for .init which gets removed later), and one extra for
each xpatch.

The extra memory consumption is a 6 pointers, traded against far cleaner
logic for bugfames and extable redirections.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel