Can you give an example of kernel work arounds which are "not*ISA related in context of Cortex-A8 or Cortex-A9 ? --Anup On Wed, May 16, 2012 at 3:42 PM, Marc Zyngier <marc.zyngier at arm.com> wrote: > On 16/05/12 10:49, Anup Patel wrote: > > Guest OSes are only concerned with the underlying ISA. > > I think you're living in an idealized world where you never have any > erratum. Look at the list of things the kernel works around. See how > many of them are *not* ISA related. > > > If we are providing ARMv7a Cortext-A8 with additional features as Guest > VCPU then there is no harm because the Guest OS will simply ignore the > additional features. > > > > Regarding the Cache operations the Guest OS is supossed to read the > CacheType register to determine parameters required in doing Cache > operations. > > Regarding the TLB Set/Way operations the SWIO bit of HCR helps Guest OS > do Set/Way maintenance correctly. > > > > I dont see any *technical* issue here. If you still believe it will be > problem for KVM ARM then do whatever feels right. > > Amen. > > M. > > > --Anup > > > > On Wed, May 16, 2012 at 3:09 PM, Marc Zyngier <marc.zyngier at arm.com > <mailto:marc.zyngier at arm.com>> wrote: > > [List added back, please don't drop it] > > > > On 16/05/12 10:30, Anup Patel wrote: > >> There are difference between Cortex-A9 and Cortex-A15 too. I dont > understand then when have you got VExpress-A9 guest working a Cortex-A15 ? > > > > Well, KVM/ARM started emulating an A9 indeed, but it doesn't mean this > > is the right thing, and it should be removed. Just think of how you > > manage processor errata. Are you going to apply A9 workarounds on an > > A15? How are you going to handle the A15 errata when your kernel > > believes this is an A9? > > > >> Its your choice to accept it or reject it. I really dont care about KVM > ARM. Just had some finding which I thought might interest KVM ARM folks. > > > > Your collaboration is very much appreciated. Really. But I believe there > > are *technical* issues with this approach. > > > >> We are able to emulate Realview-PB-A8 and VExpress-A9 guest (UP & SMP) > on Xvisor ARM running on Cortex-A15. We will be soon have VExpress-A15 > guest too. > > > > I do not doubt that for a second. You still may want to consider the > > above point if you're aiming for reliable operation of the guest. > > > > Cheers, > > > > M. > > > >> --Anup > >> > >> On Wed, May 16, 2012 at 2:39 PM, Marc Zyngier <marc.zyngier at arm.com > <mailto:marc.zyngier at arm.com><mailto:marc.zyngier at arm.com<mailto: > marc.zyngier at arm.com>>> wrote: > >> On 16/05/12 08:54, Peter Maydell wrote: > >>> On 16 May 2012 05:05, Anup Patel <anup at brainfault.org<mailto: > anup at brainfault.org><mailto:anup at brainfault.org<mailto:anup at brainfault.org>>> > wrote: > >>>> Realview-PB-A8 kernel boots fine on QEMU Emulator. The kernel gets > alignment > >>>> faults only when we try to use KVM ARM. > >>> > >>> TCG QEMU doesn't emulate alignment faults, so you'll never see them. > >>> (This is really a bug in TCG QEMU.) > >>> > >>>> Although, I did not see this issue with VExpress-A9 kernel, so have > >>>> mentioned it explicitly in my patch. Making this change CPUID > specific would > >>>> be even more correct way of doing it. > >>> > >>> What I mean is that we should be checking CPUID and saying "no, > >>> you cannot emulate an A8 or A9 with KVM". > >> > >> I strongly agree with that. We should certainly push back on anything > >> that pretends to expose a different CPU than the one we actually run on. > >> > >> This is fundamentally broken because we're actually running on the > >> physical CPU. Think errata workaround, cache behavior, all the subtle > >> things that make A8/A9 vastly different from A15. > >> > >> It you want to emulate an A8, use TCG QEMU. > >> > >> M. > >> -- > >> Jazz is not dead. It just smells funny... > >> > >> > >> > > > > > > -- > > Jazz is not dead. It just smells funny... > > > > > > > > > -- > Jazz is not dead. It just smells funny... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20120516/81cba0d2/attachment-0001.html
