On Thu, Sep 11, 2014 at 01:03:19PM -0700, Mario Smarduch wrote: > On 09/10/2014 08:13 PM, Christoffer Dall wrote: > > On Thu, Sep 04, 2014 at 10:25:43AM -0700, Mario Smarduch wrote: > >> On 09/03/2014 08:29 PM, wanghaibin wrote: > >>> On 2014/9/4 7:01, Mario Smarduch wrote: > >>> > >>>> On 09/02/2014 07:42 PM, wanghaibin wrote: > >>>>> On 2014/8/27 8:04, Mario Smarduch wrote: > >>>>> > > > > [...] > > > >>>>> > >>>>> > >>>>> About CONFIG_ARM , I suggest cancle this limmit.. > >>>>> I just implement a few interfaces for ARM64 , and tested this patch using VNC, it's work. > >>>>> > >>>> Yes I was planing to do that once ARMv7 and generic/arch split for > >>>> dirty log and tlb flush functions are settled. I realize at this time > >>>> ARMv8 just needs it's own tlb flush and it's done. But I need a strong > >>>> test case before claiming ARMv8 support > >>>> > >>>> I have some ideas on testing it but migration is probably most > >>>> reliable and the only use case really. > >>>> > >>>> Can you elaborate on your test environment for ARMv8 (you could > >>>> email off-line if too long, also thanks for testing!). > > > > > > I don't mind merging this code for ARMv7 only. For sure, Mario you > > would need to test your setup with ARMv8 carefully before we could merge > > this for v8, and we should revisit the pud_huge considerations for > > ARMv8, although I suspect we're alright given we have similar code in > > clear_pud_entry(). > > Yes a definitive test is needed to validate ARMv8 logging. > Migration with a busy environment (lmbench, random dirty) > does that on ARMv7. I'll work with wanhaibin check his environment, > and start looking through QEMU ARMv8 migration status. > Alex Bennee is working on this, but we're having some issues with the GIC state. Don't hold your breath, it may be a number of weeks before we have it done. I'll let you know as soon as we have. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
