On 23/06/16 04:17, Itaru Kitayama wrote: > On 6/22/16 9:20 PM, Marc Zyngier wrote: >> I'm only using DT, which works just fine on Overdrive, even with 64kB >> pages. >> >> I think I understand the issue you're having, which is not what I >> was thinking of. The issue is that because ACPI doesn't tell us >> anything about the size of the GICV region, we have to assume that >> it is 8kB, and cannot distinguish a safe platform from an unsafe >> one, failing the size test on 64kB. > > Is it likely in the future specification of ACPI the size information > stored in the GIC subtable? In 6.1 or earlier, it seems optional to me. I don't see any provision for that, and it is already too late (systems exist in the wild). > I also had to allow the not page-aligned physical address of GICV, below > is an excerpt of apic.dsl > > [054h 0084 8] Virtual GIC Base Address : 00000000E116F000 Right, this is what I was referring to in my initial reply. The problem is that we cannot know what is actually safe to map into a guest's address space without any sizing information. Also, we have the issue of mapping GICV at an offset in a page, which userspace needs to be made aware of. So even with your hack, it is unlikely that you'll be able to boot a guest because userspace has only 1/16th probability to map GICV at offset 0xf000. Doing so requires reporting the page offset to userspace. I had this patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/264852.html but that requires buy-in from QEMU (though I can do the corresponding kvmtool change). Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
