On 9/26/13 5:50 PM, Roger Pau Monné wrote:
On 26/09/13 03:48, Julian Elischer wrote:
On 9/25/13 11:04 PM, Roger Pau Monné wrote:
On 25/09/13 16:56, Julian Elischer wrote:
If CPUs are mapped around, how are IPIs handled? I assume they must be
emulated?
I've noticed that under Xen (on both
On 27/09/13 09:44, Julian Elischer wrote:
On 9/26/13 5:50 PM, Roger Pau Monné wrote:
On 26/09/13 03:48, Julian Elischer wrote:
On 9/25/13 11:04 PM, Roger Pau Monné wrote:
On 25/09/13 16:56, Julian Elischer wrote:
If CPUs are mapped around, how are IPIs handled? I assume they must be
On 26/09/13 03:48, Julian Elischer wrote:
On 9/25/13 11:04 PM, Roger Pau Monné wrote:
On 25/09/13 16:56, Julian Elischer wrote:
If CPUs are mapped around, how are IPIs handled? I assume they must be
emulated?
I've noticed that under Xen (on both Amazon EC2 and a Redhat server)
whenever you
On 9/26/13 4:16 PM, Peter Grehan wrote:
Hi Julian,
If CPUs are mapped around, how are IPIs handled? I assume they must be
emulated?
For bhyve, if the target vCPU of an IPI is running, a null IPI is
sent on the host to force it to exit so the IPI can be injected
If CPUs are mapped around, how are IPIs handled? I assume they must be
emulated?
I've noticed that under Xen (on both Amazon EC2 and a Redhat server)
whenever you schedule a thread it always sits on the run queue for 20
uSecs before it starts running. It looks to me like it's the IPI
taking
On 25/09/13 16:56, Julian Elischer wrote:
If CPUs are mapped around, how are IPIs handled? I assume they must be
emulated?
I've noticed that under Xen (on both Amazon EC2 and a Redhat server)
whenever you schedule a thread it always sits on the run queue for 20
uSecs before it starts