> 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.

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?


- Andreas


-----------------------------------------------------------
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

Reply via email to