diff for duplicates of <53D78937.3010307@de.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 8eb6bf3..18461b9 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -62,7 +62,7 @@ We have I think we have to differentiate between KVM/TCG. On KVM we always do in kernel halt and qemu sees a halted only for STOPPED or disabled wait. TCG has to take care of the normal wait as well. -From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense. +>From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense. The question is now only how to model it correctly without breaking TCG/KVM and reuse as much common code as possible. Correct? diff --git a/a/content_digest b/N1/content_digest index c79e334..12d95b5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -80,7 +80,7 @@ "\n" "I think we have to differentiate between KVM/TCG. On KVM we always do in kernel halt and qemu sees a halted only for STOPPED or disabled wait. TCG has to take care of the normal wait as well.\n" "\n" - "From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense.\n" + ">From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense.\n" "\n" "The question is now only how to model it correctly without breaking TCG/KVM and reuse as much common code as possible. Correct?\n" "\n" @@ -89,4 +89,4 @@ "\n" Christian -7a294643f6db6766859e6383674e4682f80222d201d495e8f39e04117cad7508 +59b304df45617cf8c8b9bf944f539ec75a321962701f3eef3c8bba03880d3e0f
diff --git a/a/1.txt b/N2/1.txt index 8eb6bf3..18461b9 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -62,7 +62,7 @@ We have I think we have to differentiate between KVM/TCG. On KVM we always do in kernel halt and qemu sees a halted only for STOPPED or disabled wait. TCG has to take care of the normal wait as well. -From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense. +>From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense. The question is now only how to model it correctly without breaking TCG/KVM and reuse as much common code as possible. Correct? diff --git a/a/content_digest b/N2/content_digest index c79e334..8228379 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -8,12 +8,12 @@ "Date\0Tue, 29 Jul 2014 13:44:55 +0200\0" "To\0Alexander Graf <agraf@suse.de>" " David Hildenbrand <dahi@linux.vnet.ibm.com>\0" - "Cc\0KVM <kvm@vger.kernel.org>" + "Cc\0linux-s390 <linux-s390@vger.kernel.org>" + KVM <kvm@vger.kernel.org> qemu-devel <qemu-devel@nongnu.org> - Cornelia Huck <cornelia.huck@de.ibm.com> - Paolo Bonzini <pbonzini@redhat.com> Jens Freimann <jfrei@linux.vnet.ibm.com> - " linux-s390 <linux-s390@vger.kernel.org>\0" + Cornelia Huck <cornelia.huck@de.ibm.com> + " Paolo Bonzini <pbonzini@redhat.com>\0" "\00:1\0" "b\0" "On 28/07/14 16:22, Alexander Graf wrote:\n" @@ -80,7 +80,7 @@ "\n" "I think we have to differentiate between KVM/TCG. On KVM we always do in kernel halt and qemu sees a halted only for STOPPED or disabled wait. TCG has to take care of the normal wait as well.\n" "\n" - "From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense.\n" + ">From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense.\n" "\n" "The question is now only how to model it correctly without breaking TCG/KVM and reuse as much common code as possible. Correct?\n" "\n" @@ -89,4 +89,4 @@ "\n" Christian -7a294643f6db6766859e6383674e4682f80222d201d495e8f39e04117cad7508 +868d55f971c779f0e49c2596f9ab6133eeefd283211c7408e446bff916c1e265
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.