Re: RFC/patch portability: split kvm_vm_ioctl

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Carsten Otte wrote:
>
>
> Avi Kivity wrote:
>> We need to distinguish between x86 specific (only x86 has this) and s390
>> special (everyone has it except s390). In the latter case it should
>> still be in common code to avoid duplication, with a guard to disable
>> compilation on s390.
>>
>> KVM_SET_MEMORY_REGION is in theory applicable to non-s390 but I'd like
>> to deprecate it, so there's no point in implementing it on non-x86. The
>> rest are s390 special rather than x86 specific.
>>
>> As related previously, KVM_SET_USER_MEMORY_REGION should work for s390
>> (with an extra check for the guest phsyical start address).
> I thought about that all through the weekend. To me, it looks like I 
> want to eliminate "s390 special" as far as possible. In given case, 
> I'll follow Anthonys suggestion and support 
> KVM_SET_USER_MEMORY_REGION. KVM_SET_MEMORY_REGION will also go common, 
> and in case 

While KVM_SET_MEMORY_REGION can be supported on other archs, there's no 
reason to do so.  It will be supported on x86 for backward compatibility 
but newer ports need only support the newer APIs.

>
> As for the pic/apic part, I think it is x86 specific. Christian 
> Ehrhardt stated he believes ppc won't have that too.
>

Yes, it's x86 specific.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/