On 2 October 2012 18:55, Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx> wrote: > On Oct 2, 2012, at 6:25 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon <will.deacon@xxxxxxx> >>> We really don't want the physical memory map for the guest hardwired in >> the >>> kernel. Please find a way to parameterise this from userspace. >> >> Yes, this is a known problem. KVM doesn't offer a standard way of passing >> the address of an interrupt controller (none of the other architectures >> have it memory mapped). >> >> We probably need a separate ioctl > > Thoughts on how to make this API flexible enough? > > Can we somehow provide a device tree to the host kernel, which would > be the same device tree the guest uses, which may also describe virtio > features, or is this completely sci fi? I'm not really in favour of trying to shoehorn device trees in here (among other things, the virtual machine we create should be the actual machine matching the hardware, not something randomly generated from the device tree. Also requiring userspace to manufacture a device tree from scratch is kind of awkward: there's no reason the guest has to be using one, and it's a lot of effort to go to to pass a single address into the kernel...) We probably want to be passing in the "base of the cpu-internal peripherals", rather than "base of the GIC" specifically. For the A15 these are the same thing, but that's not inherent [compare the A9 which has more devices at fixed offsets from a configurable base address]. On hardware this is done by having an input signal that's sampled at reset that tells the CPU where the peripherals are; is there an equivalent of that for any other CPU properties that we have already in the KVM API? -- PMM -- 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
