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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
