Re: [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-10-18 15:48, Christoffer Dall wrote:
> On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
>>>
>>> With the XICS, there are two types of irqchip: a source controller and
>>> a presentation controller.  There is one presentation controller per
>>> vcpu and typically one source controller per PCI host bridge (a source
>>> controller can manage multiple sources).  The "buid" above is
>>> basically an identifier for a source controller.
>>>
>>> So with the above, it would be quite easy to add new types and
>>> arguments for them.
>>
>> The only possible issue is that afiak, the ioctl number depends on the
>> structure size, no ? If it does, then we should add some padding to the
>> union to leave room for new types.
>>
> It sounds overall ok to me, however, Peter Maydell pointed out that
> QEMU is architected in such a way that creating the IRQ chip happens
> before QEMU knows how the chip fits with the model it is emulating and
> therefore lacks bits of information that we require for initializing
> the irq chip.
> 
> Specifically on ARM the information needed is the base address of a
> hardware peripheral, which is virtualization aware, and is mapped
> directly into the guest's physical address space.
> 
> One could argue that's not a concern for designing a good kernel api,
> but on the other hand, qemu is already quite a large system on its
> own, and we have to be practical.
> 
> Another alternative is to just let qemu init the device, later give
> the base address and check before each execution of the vcpu whether
> the base address has been set and simply return an error if not. This
> latter approach just seems horrible and unintuitive to me.
> 
> Thoughts?

The current irqchip API is like this:

KVM_CREATE_IRQCHIP (without any parameters)
...
KVM_CREATE_VCPU
KVM_SET_IRQCHIP (or the other way around)
...
KVM_RUN

The arguments you cannot pass via KVM_CREATE_IRQCHIP - which is more
like a "Hey, there will be an IRQ chip!" - could be passed via
KVM_SET_IRQCHIP (it has 512 bytes space). Provided there are sane
configuration defaults, at least after KVM_CREATE_VCPU, KVM_SET_IRQCHIP
becomes optional. Then you don't need the a check on KVM_RUN.

What do we need in addition to this in any of the non-x86 archs?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux