Re: in-kernel interrupt controller steering

[Gleb Natapov <gleb@redhat.com>]

On Wed, Mar 06, 2013 at 11:04:21AM +0100, Alexander Graf wrote:
> 
> 
> Am 06.03.2013 um 10:58 schrieb Gleb Natapov <gleb@redhat.com>:
> 
> > On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
> >> Il 05/03/2013 16:25, Gleb Natapov ha scritto:
> >>>> 1) We need to set the generic interrupt type of the system before we create vcpus.
> >>>> 
> >>>> This is a new ioctl that sets the overall system interrupt controller type to a specific model. This used so that when we create vcpus, we can create the appended "local interrupt controller" state without the actual interrupt controller device available yet. It is also used later to switch between interrupt controller implementations.
> >>>> 
> >>>> This interrupt type is write once and frozen after the first vcpu got created.
> >>> 
> >>> Why explicit ioctl is needed? Why not require specific irqchip to be
> >>> created before first vcpu. The device created determines system interrupt
> >>> controller type.
> >> 
> >> QEMU creates CPUs before devices, and CPUs need to know what kind of
> >> local interrupt controller to create.  Similar to how in-kernel LAPIC
> >> state is created long before the userspace device that proxies the LAPIC.
> > So what is the difference between calling this special ioctl before
> > creating vcpus and calling create device ioctl instead and create QEMU
> > proxy device at whatever point in time QEMU wants to create it?
> 
> I don't understand the question really. What proxy device?
> 
That's how Paolo called the QEMU part of the kernel irqchip device.

So the question is this. You propose special ioctl to set "irqchip
architecture". Lets call it SET_IRQCHIP_ARCH. QEMU suppose to do that:

ioctl(SET_IRQCHIP_ARCH, MPIC)
create_vcpus()
create_devices()
  create_irqchips()
    ioctl(CREATE_DEVICE, MPIC)
    ioctl(SET_ATTR, attr1)
    ioctl(SET_ATTR, attr2)
 

Why can't it do:
ioctl(CREATE_DEVICE, MPIC)
create_vcpus()
  create_irqchips()
   ioctl(SET_ATTR, attr1)
   ioctl(SET_ATTR, attr2)

The question is rhetorical though because I know it can, it does that
for x86. So the real question is what is the disadvantages that warrant
separate ioctl?

--
			Gleb.