Zhang, Xiantao wrote:
> Avi Kivity wrote:
>   
>> Carsten Otte wrote:
>>     
>>> Zhang, Xiantao wrote:
>>>       
>>>> User-allocation should be what we are heading. But considering
>>>> compatibility with old user-space support, I think kernel-allocation
>>>> approach should exist for a long time.
>>>>         
>>> That's right. This is why I would prefer to have the corresponding
>>> code out of kvm_main.c: it may exist for a long time for x86.
>>>
>>>       
>>>> I think we don't need to consider
>>>> this case now. Once the kernel-allocation approach is abandoned in
>>>> future, as you say, we can move them all into x86.
>>>>         
>>> I'd rather prefer to move it upfront. Otherwise, I'd have to consider
>>> that case for s390 as long as it remains in common. At least I'd have
>>> to make sure it does'nt get used on s390 using an if() or #ifdef.
>>>       
>> I agree, other archs shouldn't have to suffer.
>>     
>
> So,  now we move the whole thing(__kvm_set_memory_region) into arch ? :)
> Xiantao
>   

It's fairly generic.  Only the if (!user_alloc) parts need to move.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to