Current Milestones: || || Planned || Estimate || Actual || ||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 || ||a15-lpae-support || 2012-07-13 || 2012-07-13 || || ||clean-up-kvm-patches || || || || ||track-kvm-abi-changes || || || || ||fake-trustzone || || || || Overall KVM plan for 'do by end August': QEMU parts of this are a mix of clean-up-kvm-patches and track-kvm-abi-changes blueprints, mostly. http://cards.linaro.org/browse/CARD-167
== a15-lpae-support == * did the basic benchmarking of the LPAE series; using 64 bits for guest physical addresses has between 0 and 0.5% hit to performance, which IMHO is sufficiently minimal that it is not a problem. * wrote a set of follow-up patches which allow the vexpress-a15 model to accept large RAM sizes (mostly turning off the "too big" user-error message, fixing some over-small types in the QEMU boot loader and adding support for handling device tree blobs with 64 bit address/size fields). * discovered that Linux will happily throw away the top 32 bits of a device tree memory node's size field. Wrote a patch for this, which works but needs redoing to fix in a cleaner way. == other == * qemu-linaro 2012.07 release prep: bug triage, investigation, rolling tarball, testing * arm-devs pullreq
KVM blueprint progress tracker: http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=sta...
-- PMM
On Fri, Jul 06, 2012 at 05:19:10PM +0100, Peter Maydell wrote:
Current Milestones: || || Planned || Estimate || Actual || ||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
Wow. That's a lot of months off-plan! I like it that you have the planned dates so I don't want to complain about it, but in your mind why did this take so long?
||a15-lpae-support || 2012-07-13 || 2012-07-13 || || ||clean-up-kvm-patches || || || || ||track-kvm-abi-changes || || || || ||fake-trustzone || || || ||
Also, are you planning on having planned/estimate entries here, given your "by-August" entry?
- discovered that Linux will happily throw away the top 32 bits of a device tree memory node's size field. Wrote a patch for this, which works but needs redoing to fix in a cleaner way.
That's weird. Why would it do that?
On 6 July 2012 19:00, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Jul 06, 2012 at 05:19:10PM +0100, Peter Maydell wrote:
Current Milestones: || || Planned || Estimate || Actual || ||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
Wow. That's a lot of months off-plan! I like it that you have the planned dates so I don't want to complain about it, but in your mind why did this take so long?
A combination of: * I'm not very good at estimation, and going through all the cp15 registers and converting them took much longer than I expected * we ran into the combination of QEMU-upstream-freeze, Connect and my holiday, which accounts for 7-8 weeks all on its own where the status was basically "complete but not landed upstream" * we rearranged the schedule in early Feb when it became clear that this cp15-rework wasn't an absolute dependency for us to hit the initial milestone for Connect in SF, so we did various other tasks instead and cp15-rework went on the back burner for a month or two * some underestimation of how much time I would spend doing this dev work rather than other things (like qemu-linaro releases, upstream maintainer work, etc).
||a15-lpae-support || 2012-07-13 || 2012-07-13 || || ||clean-up-kvm-patches || || || || ||track-kvm-abi-changes || || || || ||fake-trustzone || || || ||
Also, are you planning on having planned/estimate entries here, given your "by-August" entry?
It's a bit tricky because the set of work we ended up with in the 'by August' card doesn't neatly line up with the blueprint boundaries, and also because there's a bunch of stuff on the card which is "wait for kernel side implementation then do a small amount of QEMU side work", and which I therefore can't provide estimate dates for because I have no idea when the kernel will be done. There's also a chunk of work I wasn't expecting to see on the card (though I don't disagree that it's there) and which thus doesn't yet have an underlying blueprint. I'll try to clean this up a bit for next week so that bit at least has some plan/estimate dates.
- discovered that Linux will happily throw away the top 32 bits of a device tree memory node's size field. Wrote a patch for this, which works but needs redoing to fix in a cleaner way.
That's weird. Why would it do that?
Because historically the assumption in arch/arm has been that you can't possibly have a memory size that won't fit in 32 bits because physical addresses are 32 bits; this is just a dangling assumption that never got fixed. See thread on linaro-dev for technical detail.
-- PMM
linaro-toolchain@lists.linaro.org
-
Christian Robottom Reis -
Peter Maydell