> On Nov. 18, 2014, 2:54 a.m., Ali Saidi wrote: > > This will break compilation on non-linux platforms, so if we need something > > like this, it will need to have two checks, one that kvm is possible, and > > the other that it's enabled. > > > > However, that alone doesn't solve the problem because the issue is that now > > devices will exist that need KVM, but if KVM isn't compiled... > > One solution is a skeleton header that can be used in case !USE_KVM, but as > > you allude to this is very ugly. > > Off the top of my head the way I'd prefer to see it done is let objects > > register ranges with the System object and then the KVM code could iterate > > that list if it was compiled in. Sound reasonable? > > Gabe Black wrote: > Well it's not just header files, it's also the python Param stuff. > Param.KvmVM doesn't work if KvmVM isn't a parameter type, even if it won't be > set to anything. > > It won't really help for there to be a static list of ranges because we > need to move the framebuffer around in response to changes in the devices > BARs. We need to control the placement dynamically, at least from the > perspective of the simulation. > > Andreas Hansson wrote: > As Ali points out, we need to make sure this still builds on non-Linux > platforms, and another case to watch out for is the NULL isa. > > Is the reason for this patch the registration and enumeration of the > memory ranges? If so, may I propose we introduce a DeviceMemory class or > similar, and then use multiple inheritance. The DeviceMemory could be > responsible for the APi needed to setup and manage the memory ranges, and > still be independent of the KVM code. Do you think that would work?
The original issue is that the device we're trying to use with x86 has its own framebuffer and doesn't DMA in a region of memory. That means that every byte the kernel writes into the frame buffer causes the VM to exit which wrecks performance. That's not a problem on ARM (as implemented) because it periodically grabs memory which will naturally batch together changes. The way we worked around the problem was to mark the framebuffer in the graphics device as memory so that writes to it don't cause the VM to exit. The device then periodically tells VNC its buffer is dirty whether it is or not. That was done by injecting new regions into PhysMem which would then use a hacked in back door to add the region to the VM after the fact. This version attempts to clean that up a bit by making the device talk to KVM directly instead of going through PhysMem. To do that, the graphics device needs to have a pointer to tell it where the KVM object is, and that requires a Param.KvmVM. If the KvmVM Simobject hasn't been enabled, that doesn't work. The graphics device can't record where it wants the framebuffer to map to ahead of time for the KvmVM object to discover since its location is set by a BAR configured by the kernel as it runs. The intention is that if KVM isn't available, the parameter/pointer passed to the graphics device will be NULL and the graphics device won't do anything KVM related. I'm not sure how a DeviceMemory class will help, particularly because it would need to reconfigure the memory range's mapping in the guest on the fly and hence need to operate on the KVM instance. If I'm just not seeing something please let me know. Is the USE_KVM setting visible as a preprocessor directive in the C++? If so, I could use that to set the kvm pointer to NULL if KVM is turned off instead of getting it from the parameters. Then the question is how to condition adding the KVM parameter to the python version of the device. - Gabe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2513/#review5461 ----------------------------------------------------------- On Nov. 18, 2014, 2:27 a.m., Gabe Black wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2513/ > ----------------------------------------------------------- > > (Updated Nov. 18, 2014, 2:27 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10548:47efc3192cf5 > --------------------------- > KVM: Build in most of the KVM stuff even if we're not going to use it. > > Otherwise it's impossible (or at least highly impractical) to use the KVM VM > as an optional parameter on objects which aren't conditionally built. If > there's no KVM instance that gets set up, those pointers should just be NULL. > > > Diffs > ----- > > src/cpu/kvm/SConscript f66948658a36b6874e84ee5da37e70d351287cb4 > > Diff: http://reviews.gem5.org/r/2513/diff/ > > > Testing > ------- > > > Thanks, > > Gabe Black > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
