Re: [kvm-ia64-devel] [PATCH 0/5] RFC: ia64/pv_ops: ia64 intrinsicsparavirtualization

[Dong, E. <edd...@in...>]

Remove rest mailinglist since it is an implementation detail
argument that may confuse more people.


Isaku Yamahata wrote:
>> 
>> It depends on where do we start to patch. I.e. if the patch code will
>> replace the prologue code or not? I think we can solve this by
>> replace the prologue, but  I may miss something.
> 
> Yes, we can scan instruction backward looking for alloc instruction
> and rewrite it and know its frame size (sol and sof).
> Thus we can guarantee that output registers are accessible.

If we know where out0 is, we can simply generate patched code
dynamically.
Adding additional information into patch_site should be enough to
provide us
the information like:
	"mov out0=out0".

> In fact specifying "out0", "out1", ... as clobbered registers
> in inline assembler code, gcc allocates them. and we can
> clobber those registers.
> 
> However we can't clobber stacked registers out of specified ones
> so that its conversion differs from C function calling one.
> For example
>         func()
>                 // out0 and out1 are allocated.
>                 paravirt_get_cpuid(index);
>                         // asm volatile ("..."

We can add "mov out0=out0" here,
I saw it works using a simple code for reference.


Or we can use following code more effectively:

 .pushsection .parasections;\t .long ...; mov out0=out0;; .long
...;\t.popsection

It seems there is a bug in AS binutil. 

>                         //               "br.call xen_get_cpuid"
>                         //               "...":
>                         //               input: output:
>                         //               "out0");
>                 other_func(arg0, arg1);
> 
> In xen_get_cpuid() we can't clobber out1 so that xen_get_cpuid()
> isn't allowed to allocate any extra stacked registers.
> It means that xen_get_cpuid() can't be written in C.
> 
> 

I just say your original statement is bias, it doesn't mean I have a
preference there :(  Still think generating code in place with single
source + dual compile is simplest.

Thanks, eddie