On 03/14/2013 02:03:30 PM, Alexander Graf wrote:
On 14.03.2013, at 19:35, Scott Wood wrote:
> On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
>> On 14.03.2013, at 19:20, Scott Wood wrote:
>> > On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
>> >> Setting this capability on a vcpu connects that vcpu to an
interrupt
>> >> controller device. The args[0] field of the argument
kvm_enable_cap
>> >> struct specifies the overall architecture of the interrupt
>> >> controller. The args[1] field specifies the CPU number for the
vcpu
>> >> from the interrupt controller's point of view.
>> >> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx>
>> >> ---
>> >> arch/powerpc/include/asm/kvm_host.h | 3 +++
>> >> arch/powerpc/kvm/powerpc.c | 29
+++++++++++++++++++++++++++++
>> >> include/uapi/linux/kvm.h | 1 +
>> >> 3 files changed, 33 insertions(+)
>> >> diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
>> >> index f4ba881..dd167e4 100644
>> >> --- a/arch/powerpc/include/asm/kvm_host.h
>> >> +++ b/arch/powerpc/include/asm/kvm_host.h
>> >> @@ -373,6 +373,9 @@ struct kvmppc_booke_debug_reg {
>> >> struct kvm_vcpu_arch {
>> >> ulong host_stack;
>> >> u32 host_pid;
>> >> +
>> >> + u32 intr_ctrler;
>> >> +
>> >
>> > That abbreviation seems a bit awkward, and we should also have a
>> > private-data pointer.
>> >
>> > How about:
>> >
>> > u32 irq_arch;
>> We also want int pic_fd, no?
>
> Not sure we really need that on the vcpu. We'll need it on the vm
unless we add it as an arg to the vcpu cap enable.
I don't think we need anything vm global for the cpu <-> PIC
connections.
The two components have to link up somehow. If the vcpu cap enable
ioctl doesn't specify it, then the device creation will have to stick a
reference to itself somewhere in the vm.
Also, if you want to deregister a CPU (hotplug remove), you probably
want to tell the PIC that the CPU has gone.
Yes, I mentioned that in my previous e-mail.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html