Avi Kivity wrote:
Marcelo Tosatti wrote:
(continued below)
Anyway, yeah, the set request / wait mechanism you implement here is
quite similar to the idea mentioned earlier that could be used for
x86.
Just get rid of this explicit KVM_REQ_MMU_RELOAD knowledge in
arch-independent code pl
Marcelo Tosatti wrote:
(continued below)
Anyway, yeah, the set request / wait mechanism you implement here is
quite similar to the idea mentioned earlier that could be used for x86.
Just get rid of this explicit KVM_REQ_MMU_RELOAD knowledge in
arch-independent code please (if you want t
On Mon, Jun 08, 2009 at 12:51:26PM +0200, Christian Ehrhardt wrote:
>>> Index: kvm/virt/kvm/kvm_main.c
>>> ===
>>> --- kvm.orig/virt/kvm/kvm_main.c
>>> +++ kvm/virt/kvm/kvm_main.c
>>> @@ -1682,6 +1682,10 @@ static int kvm_vcpu_release
Christian Ehrhardt wrote:
Hmm ... would that be worth a clarifying patch to atomic_ops.txt that
confused me in the first place ?
If it confused you, it probably confuses others.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "uns
Avi Kivity wrote:
Christian Ehrhardt wrote:
Really need that smp_mb__after_clear_bit ? AFAIK test_and_clear_bit
implies a barrier?
Well I agree that practically test_and_clear_bit has a barrier on
s390, but as far as I read Documentation/atomic_ops.txt at line
339-360 I think the interf
Christian Ehrhardt wrote:
Really need that smp_mb__after_clear_bit ? AFAIK test_and_clear_bit
implies a barrier?
Well I agree that practically test_and_clear_bit has a barrier on
s390, but as far as I read Documentation/atomic_ops.txt at line
339-360 I think the interface does not imply
Marcelo Tosatti wrote:
On Tue, Jun 02, 2009 at 04:26:11PM +0200, ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
[...]
@@ -706,13 +713,19 @@ int kvm_arch_set_memory_region(struct kv
/* request update of sie control block for all available vcpus */
for (i = 0;
On Tue, Jun 02, 2009 at 04:26:11PM +0200, ehrha...@linux.vnet.ibm.com wrote:
> From: Christian Ehrhardt
>
> As requested this is a rebased patch on top of the already applied v3
> of the patch series.
>
> *updates to applied version*
> - ensure the wait_on_bit waiter is notified
> - ensure dropp
Avi Kivity wrote:
Christian Bornträger wrote:
Am Dienstag 26 Mai 2009 09:57:58 schrieb Avi Kivity:
[...]
In our low-level interrupt handler we do check for signal_pending,
machine_check_pending and need_resched to leave the sie instruction.
For anything else a the host sees a cpu bound gue
Christian Bornträger wrote:
Am Dienstag 26 Mai 2009 09:57:58 schrieb Avi Kivity:
I could add that behaviour, but that could make our normal interrupt
handling much slower. Therefore I don't want to call that function,
but on the other hand I like the "skip if the request is already set"
funct
Am Dienstag 26 Mai 2009 09:57:58 schrieb Avi Kivity:
> > I could add that behaviour, but that could make our normal interrupt
> > handling much slower. Therefore I don't want to call that function,
> > but on the other hand I like the "skip if the request is already set"
> > functionality and think
Christian Ehrhardt wrote:
There already exists a loop which does this, see
make_all_cpus_request(). It uses an IPI (Marcelo, can't it use the
reschedule interrupt?). It has a couple of optimizations -- if the
request is already set, it skips the IPI, and it avoids the IPI for
vcpus out of
Christian Ehrhardt wrote:
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
[...]
-/* update sie control blocks, and unlock all vcpus */
+/* request update of sie control block for all available vcpus */
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
This patch relocates the variables kvm-s390 uses to track guest mem
addr/size.
As discussed dropping the variables at struct kvm_arch level allows
to use the
common vcpu->request based mechanism to reload guest mem
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
This patch relocates the variables kvm-s390 uses to track guest mem addr/size.
As discussed dropping the variables at struct kvm_arch level allows to use the
common vcpu->request based mechanism to reload guest memory if e.g. changes
v
15 matches
Mail list logo
