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.

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.

I changed the other patch to condition things on USE_KVM, so this is now unnecessary.