> On Feb. 9, 2014, 3:28 p.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?
> 
> Andreas Sandberg wrote:
>     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.

I see.  So this would be a limitation with the current single-threaded model as 
well, right?  I guess I was reading too much into it and thinking this was a 
new limitation due to the multiple queues.


> On Feb. 9, 2014, 3:28 p.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.
> 
> Andreas Sandberg wrote:
>     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)."
>

Right... I didn't necessarily mean the segfault, I just noticed at that link a 
similar comment about sigprocmask only being valid for single-threaded 
processes.  Anyway, adding a sentence like "Switched from sigprocmask() to 
pthread_sigmask() because the former is not compatible with multiple threads" 
to the commit message would be nice for those of us not familiar with these 
details.


- Steve


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


On Feb. 10, 2014, 1:45 a.m., Andreas Sandberg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2159/
> -----------------------------------------------------------
> 
> (Updated Feb. 10, 2014, 1:45 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10062:4fea5050f4f2
> ---------------------------
> 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.
> 
> There are currently no facilities to multiplex between multiple KVM
> CPUs in the same event queue, we are therefore 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