On Mar 10, 2012, at 6:30 AM, Peter Maydell <peter.maydell at linaro.org> wrote: > On 9 March 2012 18:44, Alexander Golec <thejfasi at gmail.com> wrote: >> I'm an undergrad at Columbia, and I'm working on a project for a >> class to implement virtio on kvm-arm for the Cortex A15. The goal >> is to get some form of virtio up and running and measure >> performance as best we can, given that we are looking at running >> on simulators right now. > > I'm afraid I think this is fundamentally misguided. You cannot > measure performance in any useful way running on the Fast Model. > The set of things which are slow in hardware are not necessarily > slow to the same extent under simulation, and some things which > are very slow in simulation do not have the same penalty when > run on real hardware. It is a long way from a simple "linear > slowdown" model. You can use the simulator to develop and test > the virtio code, but for performance evaluation you're going > to have to wait until hardware is available. While I understand what you are saying, I think this is not the complete story. Alex would be able to measure number of instructions spent on IO with virtio vs. without virtio for example that should give some indication of which direction it would take us. I know we would really need to know number of cycles to say anything really precise, but ballpark I think it's fine. There are also other aspects of his work, like considering accelerated graphics inside KVM but its further out and outside the scope of this discussion. Another item that makes this relevant is improving performance on the simulator itself. That will be extremely useful for testing both now and later even when there is hardware. > >> My current approach is as follows: vanilla virtio uses PCI >> as its transport mechanism, which poses a problem for >> PCI-less ARM devices. I've looked at Peter Maydell's >> changes for using mmio as a transport for virtio, and >> I've hit on a an obstacle, namely that the code uses the >> post-39bff object API, which dropped just days after the >> kvm-a15 branch started. > > I'm not sure what this "kvm-a15" branch you're referring > to is. If it's a QEMU branch and it predates the object > API landing then you don't want to be doing any serious > work on it anyway because you'll be making more work for > yourself when it comes to landing upstream. > >> Here's what I was thinking: read up on both the new and >> old API and modify the changes to use the old API. > > There are two reasons this doesn't make sense: > (a) we should be doing development as close to > head of QEMU master upstream as we can manage and (b) > if you really want the old pre-API-change versions you > can go and fish them out of the mailing list archives. > I did the rebase for you exactly because I thought you > wanted a version against a newer version of QEMU so > you could work on them... Alex, it sounds like you used a wrong version of qemu for these patches. Please try the linaro branches as Peter suggests. I think you should focus on getting something working sooner as opposed to later and we can always worry about upstreaming later on. > -Christoffer
