On 18/11/14 13:22, Steve Reinhardt via gem5-dev wrote:
I haven't looked at the code in question, so I'm just going by what I've
seen in this email thread. However, it seems like there ought to be some
alternative solutions here. I like the general direction Andreas is going,
though it would be nice to avoid more multiple inheritance :). The way I
see it, the basic idea there is to create an API (either on an existing
object like System or on a new object) that the device can call
irrespective of whether KVM is configured or not, but which gives enough
information to get the job done; then the other object can be responsible
for either coordinating with KVM or (presumably) ignoring all those calls
if KVM is not configured.
As a simpler alternative, maybe we don't need to give the kvm pointer to
the device via python; if the System object has an accessor that would
return the vm pointer, then the device could call that during
initialization, and it would of course just return NULL if kvm is not
configured
I would actually see it as a requirement of the new API that the
underlying kvm vm is not exposed to device models. Exposing the VM would
make the code base harder to maintain and extend (what if we want to add
support for another virtualization interface?).
The idea of adding a few more APIs to the System class seems good to me.
We already use it to coordinate physical memories. As far as I can tell
from the description a minimal API could look something like this:
void System::mapDeviceMemory(DeviceMemory &mem)
void System::unmapDeviceMemory(DeviceMemory &mem)
void System::registerMemoryCallbacks(const MemoryCallbackInterface
&callbacks)
This would make it possible to get rid of the dependency between devices
and kvm. The kvm VM, or any other device that needs the information,
would just register a set of callbacks with the system (probably just
map/unmap notifications) and the device would just talk to the system
and be virtualization agnostic.
//Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
