Re: RFC/patch portability: split kvm_vm_ioctl v3

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

Avi Kivity wrote:
> But that doesn't make the code portable.  The s390 userspace has to know 
> how to encode the number, and x86 will do it differently.
> 
> If it's really different, let's keep it different.  Unless you can push 
> the encoding so far back it's transparent to userspace (e.g. qemu).
I agree that we should keep it seperate unless it makes sense to have 
commonality.
A paravirt driver for example could make use of this abstraction: it 
could request an interrupt, and hand the __u64 that it got back to a 
function that actually sends the interrupt over.
But for now, I agree we should keep it seperate. I am just thinking 
loud here.

>> In addition, I would love to be able to specify which target CPUs may 
>> receive that interrupt because our IPI equivalent comes out just like 
>> a regular interrupt on just one target CPU.
>>
>> That boils down to something like this:
>> struct kvm_interrupt_data {
>>     __u64     interrupt_number;
>>     cpuset_t possible_target_cpus;
>> }
>> and an KVM_INJECT_INTERRUPT common ioctl for the vm to provide this.
> 
> Are cpusets exported to userspace?
> 
> x86 has something similar (IPI to a set of cpus) but it's handled 100% 
> in the kernel these days.
> 
No they are'nt. We'd need to come up with a different data structure 
for that. Does IPI have an interrupt number too?

-------------------------------------------------------------------------
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/