> 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? > > Gabe Black wrote: > 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.
I changed the other patch to condition things on USE_KVM, so this is now unnecessary. - 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
