> On Feb. 10, 2014, 12:28 a.m., Steve Reinhardt wrote:
> > You comment that "we are currently limited to configurations where there is 
> > only one KVM CPU per event queue"... can you expand on this?  I.e., why 
> > can't I have multiple KVM CPUs per event queue and timeslice among them?  
> > Or is that not what you meant?

The limitation at the moment is because we can't multiplex between KVM CPUs in 
the same event queue. This is caused by the way we simulated until the next 
event (we look into the future and request an exit when the next event is due), 
if there is another KVM CPU executing, we'll see that one on the same or a 
nearby tick. It might be possible to get multiplexing to work by ignoring KVM 
events when we look into the local event queue to calculate when to exit from 
KVM.


> On Feb. 10, 2014, 12:28 a.m., Steve Reinhardt wrote:
> > src/cpu/kvm/base.hh, line 625
> > <http://reviews.gem5.org/r/2159/diff/1/?file=39258#file39258line625>
> >
> >     seems to be a typo in this comment... should this be "is called as"?

Oopps. Thanks for spotting it.


> On Feb. 10, 2014, 12:28 a.m., Steve Reinhardt wrote:
> > src/cpu/kvm/base.cc, line 1111
> > <http://reviews.gem5.org/r/2159/diff/1/?file=39259#file39259line1111>
> >
> >     I wasn't sure why you changed from sigprocmask to pthread_sigmask, but 
> > on googling for the answer I found this:
> >     http://stackoverflow.com/questions/2170672/sigprocmask-causing-segfault
> >     
> >     So it makes sense to me now, but might be worth a mention in the commit 
> > message.

That wasn't the problem I encountered. The problem I had was that I need to 
ensure that only the thread executing the KVM CPU's event queue should be 
affected by the new signal mask. sigprocmask might actually work -- I don't 
know -- but the man page is pretty clear on the subject:

"The use of sigprocmask() is unspecified in a multithreaded process; see 
pthread_sigmask(3)."


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2159/#review4896
-----------------------------------------------------------


On Feb. 9, 2014, 9:01 p.m., Andreas Sandberg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2159/
> -----------------------------------------------------------
> 
> (Updated Feb. 9, 2014, 9:01 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10062:ec5050f0c501
> ---------------------------
> kvm: Add support for multi-system simulation
> 
> The introduction of parallel event queues added most of the support
> needed to run multiple VMs (systems) within the same gem5
> instance. This changeset fixes up signal delivery so that KVM's
> control signals are delivered to the thread that executes the CPU's
> event queue.
> 
> Since CPUs must execute in their own threads, we are currently limited
> to configurations where there is only one KVM CPU per event queue. In
> practice, this means that multi-system configurations can be
> simulated, but not multiple CPUs in a shared-memory configuration.
> 
> 
> Diffs
> -----
> 
>   src/cpu/kvm/base.hh 3b0d0c988ed6 
>   src/cpu/kvm/base.cc 3b0d0c988ed6 
>   src/cpu/kvm/timer.cc 3b0d0c988ed6 
> 
> Diff: http://reviews.gem5.org/r/2159/diff/
> 
> 
> Testing
> -------
> 
> Tested boot and interactive use of single CPU system -- works.
> Tested boot of dual-system configuration and interactive use -- works.
> 
> Did not run regressions as the current tests do not test KVM functionality.
> 
> Also available from the multisys branch in git://github.com/andysan/gem5.git.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to