Re: RFC/patch portability: split kvm_vm_ioctl v3

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

Carsten Otte wrote:
> Dong, Eddie wrote:
>> BTW, how S390 user/kernel interrupt signal is communicated?
> Our s90host prototype does inject it from userspace, so there is no 
> need to have a call for that.
>
> Nevertheless, I really love the lightweight exits that kvm has 
> invented and I want to use it on s390 with kvm too.

It originated as a Xen hvm thing which Eddie & co. ported over.

> In that case, we'll have an interrupt facility in the kernel that is 
> in terms of functionality close to the pic/lapic work for x86.
>
> For that, I think we could encode an interrupt number in an __u64 that 
> has a platform specific helper function in userspace to generate that 
> interrupt number: for x86 that would just equal the irq line, for s390 
> that would be more complex. The common kvm code can then take that 
> __u64 number and call an architecture specific callback that injects 
> the interrupt.
>

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).

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

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


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