Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu-request in that case is that I don't want
the async behaviour of vcpu-requests in that case, I want the
memory slot updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access the vcpu control block
Christian Ehrhardt wrote:
The bad thing on vcpu-request in that case is that I don't want
the async behaviour of vcpu-requests in that case, I want the
memory slot updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access the vcpu control block even when
the vcpu
Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu-request in that case is that I don't want the
async behaviour of vcpu-requests in that case, I want the memory
slot updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access the vcpu control block
Christian Ehrhardt wrote:
Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu-request in that case is that I don't want the
async behaviour of vcpu-requests in that case, I want the memory
slot updated in all vcpu's when the ioctl is returning.
You mean, the hardware can
Avi Kivity wrote:
Christian Ehrhardt wrote:
Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu-request in that case is that I don't want
the async behaviour of vcpu-requests in that case, I want the
memory slot updated in all vcpu's when the ioctl is returning.
You mean,
From: Carsten Otte co...@de.ibm.com
This patch fixes an incorrectness in the kvm backend for s390.
In case virtual cpus are being created before the corresponding
memory slot is being registered, we need to update the sie
control blocks for the virtual cpus.
*updates in v3*
In consideration of
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Carsten Otte co...@de.ibm.com
This patch fixes an incorrectness in the kvm backend for s390.
In case virtual cpus are being created before the corresponding
memory slot is being registered, we need to update the sie
control blocks for
Christian Ehrhardt wrote:
On x86, we use slots_lock to protect memory slots. When we change
the global memory configuration, we set a bit in vcpu-requests, and
send an IPI to all cpus that are currently in guest mode for our
guest. This forces the cpu back to host mode. On the next entry,
Avi Kivity wrote:
Christian Ehrhardt wrote:
On x86, we use slots_lock to protect memory slots. When we change
the global memory configuration, we set a bit in vcpu-requests, and
send an IPI to all cpus that are currently in guest mode for our
guest. This forces the cpu back to host mode.
Christian Ehrhardt wrote:
I thought about implementing it with slots_lock, vcpu-request, etc
but it really looks like overkill for s390.
We could make (some of) it common code, so it won't look so bad.
There's value in having all kvm ports do things similarly; though of
course we shouldn't
Avi Kivity wrote:
Christian Ehrhardt wrote:
I thought about implementing it with slots_lock, vcpu-request, etc
but it really looks like overkill for s390.
We could make (some of) it common code, so it won't look so bad.
There's value in having all kvm ports do things similarly; though of
Christian Ehrhardt wrote:
The bad thing on vcpu-request in that case is that I don't want the
async behaviour of vcpu-requests in that case, I want the memory slot
updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access the vcpu control block even when the
vcpu
ehrha...@linux.vnet.ibm.com wrote:
From: Carsten Otte co...@de.ibm.com
This patch fixes an incorrectness in the kvm backend for s390.
In case virtual cpus are being created before the corresponding
memory slot is being registered, we need to update the sie
control blocks for the virtual cpus.
From: Carsten Otte co...@de.ibm.com
This patch fixes an incorrectness in the kvm backend for s390.
In case virtual cpus are being created before the corresponding
memory slot is being registered, we need to update the sie
control blocks for the virtual cpus. In order to do that, we
use the
14 matches
Mail list logo
