From: Jan Kiszka jan.kis...@siemens.com
It is not used, it is not needed, so let's remove it.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c |6 ++
kvm-stub.c |4 ++--
kvm.h |2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/kvm-all.c
From: Jan Kiszka jan.kis...@siemens.com
No functional changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c | 139 ++--
1 files changed, 79 insertions(+), 60 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index
From: Jan Kiszka jan.kis...@siemens.com
Simplify kvm_has_msr_star/hsave_pa to booleans and push their one-time
initialization into kvm_arch_init. Also handle potential errors of that
setup procedure.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/kvm.c | 47
From: Jan Kiszka jan.kis...@siemens.com
Instead of splattering the code with #ifdefs and runtime checks for
capabilities we cannot work without anyway, provide central test
infrastructure for verifying their availability both at build and
runtime.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
From: Jan Kiszka jan.kis...@siemens.com
All CPUX86State variables before CPU_COMMON are automatically cleared on
reset. Reorder nmi_injected and nmi_pending to avoid having to touch
them explicitly.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/cpu.h |6 --
Next round, addressing review comments and new findings:
- new: Flush coalesced mmio buffer on IO window exits
- new: Do not use qemu_fair_mutex in kvm mode
- new: Implicitly clear nmi_injected/pending on reset
- new: Fix !CONFIG_KVM_PARA build
- reworked: Read kvmclock only once per stopped
From: Jan Kiszka jan.kis...@siemens.com
For unknown reasons, xcr0 reset ended up in kvm_arch_update_guest_debug
on upstream merge. Fix this and also remove the misleading comment (1 is
THE reset value).
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/kvm.c |3 +--
1 files
From: Jan Kiszka jan.kis...@siemens.com
kvm_arch_reset_vcpu initializes mp_state, and that function is invoked
right after kvm_arch_init_vcpu.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/kvm.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
From: Jan Kiszka jan.kis...@siemens.com
Introduce the cpu_dump_state flag CPU_DUMP_CODE and implement it for
x86. This writes out the code bytes around the current instruction
pointer. Make use of this feature in KVM to help debugging fatal vm
exits.
Signed-off-by: Jan Kiszka
From: Jan Kiszka jan.kis...@siemens.com
This code path will not yet be taken as we still lack in-kernel irqchip
support. But qemu-kvm can already make use of it and drop its own
mp_state access services.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/kvm.c |3 +++
1 files
From: Jan Kiszka jan.kis...@siemens.com
The ordering doesn't matter in this case, but better keep it consistent.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/kvm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-i386/kvm.c
From: Jan Kiszka jan.kis...@siemens.com
Report KVM_EXIT_UNKNOWN, KVM_EXIT_FAIL_ENTRY, and KVM_EXIT_EXCEPTION
with more details to stderr. The latter two are so far x86-only, so move
them into the arch-specific handler. Integrate the Intel real mode
warning on KVM_EXIT_FAIL_ENTRY that qemu-kvm
Am 03.01.2011 17:09, Avi Kivity wrote:
On 01/03/2011 10:32 AM, Jan Kiszka wrote:
All previously sent patches against current uq combined, some smaller
tweaks applied, and 4 new patches added. Major news is support for
using up to 16M BIOSes and optional code dump for cpu_dump_state. Those
On 01/04/2011 10:42 AM, Jan Kiszka wrote:
Sounds really frightening... this glue code is a real breeding ground
for subtle bugs and merge problems.
...and that's why we are more than late with unifying it into a single
code base.
After that upcoming cleanup round we will have three major
On 01/04/2011 08:42 AM, Mike Galbraith wrote:
A couple questions.
On Mon, 2011-01-03 at 16:26 -0500, Rik van Riel wrote:
When running SMP virtual machines, it is possible for one VCPU to be
spinning on a spinlock, while the VCPU that holds the spinlock is not
currently running, because
On 01/03/2011 11:26 PM, Rik van Riel wrote:
When running SMP virtual machines, it is possible for one VCPU to be
spinning on a spinlock, while the VCPU that holds the spinlock is not
currently running, because the host scheduler preempted it to run
something else.
Both Intel and AMD CPUs have a
On Tue, 2011-01-04 at 11:14 +0200, Avi Kivity wrote:
Assuming there are no objections, Mike, can you get 2/3 into a
fast-forward-only branch of tip.git? I'll then merge it into kvm.git
and apply 1/3 and 2/3.
Wrong guy. Fast-forward is Peter's department.
-Mike
--
To unsubscribe
On Tue, 2011-01-04 at 11:09 +0200, Avi Kivity wrote:
On 01/04/2011 08:42 AM, Mike Galbraith wrote:
If I were to, say, run a 256 CPU VM on my quad, would this help me get
more hackbench or whatever oomph from my (256X80386/20:) box?
First of all, you can't run 256 guests on x86 kvm.
I
On 01/04/2011 12:32 PM, Mike Galbraith wrote:
On Tue, 2011-01-04 at 11:09 +0200, Avi Kivity wrote:
On 01/04/2011 08:42 AM, Mike Galbraith wrote:
If I were to, say, run a 256 CPU VM on my quad, would this help me get
more hackbench or whatever oomph from my (256X80386/20:) box?
Am 10.12.2010 19:44, Chris Wright wrote:
* Jan Kiszka (jan.kis...@siemens.com) wrote:
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -3627,9 +3627,9 @@ static int intel_iommu_attach_device(struct
iommu_domain *domain,
pte = dmar_domain-pgd;
if
On Thu, Dec 30, 2010 at 11:25 PM, Erich Weiler bitscrub...@gmail.com wrote:
I've got this issue that I've been banging my head against a wall for a
while over and I think another pair of eyes may help, if anyone have a
moment. We have this new-ish KVM VM server (with the latest CentOS 5.5
2010/11/29 Stefan Hajnoczi stefa...@gmail.com:
On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
tamura.yoshi...@lab.ntt.co.jp wrote:
event-tap controls when to start FT transaction, and provides proxy
functions to called from net/block devices. While FT transaction, it
queues up net/block
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Make sure to write the cleared MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
and MSR_KVM_ASYNC_PF_EN to the kernel state so that a freshly booted
guest cannot be disturbed by old values.
Signed-off-by:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow
On Tue, Jan 4, 2011 at 11:02 AM, Yoshiaki Tamura
tamura.yoshi...@lab.ntt.co.jp wrote:
After doing some heavy load tests, I realized that we have to
take a hybrid approach to replay for now. This is because when a
device moves to the next state (e.g. virtio decreases inuse) is
different
On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
2010/11/29 Stefan Hajnoczi stefa...@gmail.com:
On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
tamura.yoshi...@lab.ntt.co.jp wrote:
event-tap controls when to start FT transaction, and provides proxy
functions to called
Am 04.01.2011 12:08, Glauber Costa wrote:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:08, Glauber Costa wrote:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the
Am 04.01.2011 12:43, Glauber Costa wrote:
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:08, Glauber Costa wrote:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If kvmclock is used, which implies the kernel supports it,
On Tue, 2011-01-04 at 12:45 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:43, Glauber Costa wrote:
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
Am 04.01.2011 12:08, Glauber Costa wrote:
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock unfairness
problem. (probaby creating pthread_condattr_setautoyield_np or similar
knob is good one)
Often, the thread calling
2011/1/4 Michael S. Tsirkin m...@redhat.com:
On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
2010/11/29 Stefan Hajnoczi stefa...@gmail.com:
On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
tamura.yoshi...@lab.ntt.co.jp wrote:
event-tap controls when to start FT
On Tue, Jan 04, 2011 at 09:20:53PM +0900, Yoshiaki Tamura wrote:
2011/1/4 Michael S. Tsirkin m...@redhat.com:
On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
2010/11/29 Stefan Hajnoczi stefa...@gmail.com:
On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
Currently we have some ad-hoc code in x86.c to restrict #UD emulation to
expected instructions (that is, vendor specific instructions). This patchset
replaces the ad-hoc code with proper emulator support using decode tables.
Avi Kivity (4):
KVM: Fix x86_decode_insn() return code check
KVM:
'goto done' leads to a maze of checks and actions, all pointless. Bail
out immediately if we can't decode.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
x86_decode_insn() doesn't return X86EMUL_* values, it returns
EMULATION_* codes. Adjust the check.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
Mark some instructions as vendor specific, and allow the caller to request
emulation only of vendor specific instructions. This is useful in some
circumstances (responding to a #UD fault).
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h |1 +
Use the new support in the emulator, and drop the ad-hoc code in x86.c.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c | 31 +++
1 files changed, 3 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
2011/1/4 Michael S. Tsirkin m...@redhat.com:
On Tue, Jan 04, 2011 at 09:20:53PM +0900, Yoshiaki Tamura wrote:
2011/1/4 Michael S. Tsirkin m...@redhat.com:
On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
2010/11/29 Stefan Hajnoczi stefa...@gmail.com:
On Thu, Nov 25, 2010
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread and
vcpus. It's now only taken by the latter, isn't it?
This and the
On 01/03/2011 10:21 PM, Zhai, Edwin wrote:
Riel,
Thanks for your patch. I have changed the ple_gap to 128 on xen side,
but forget the patch for KVM:(
A little bit big is no harm, but more perf data is better.
So should I resend the patch with the ple_gap default
changed to 128, or are you
On 01/04/2011 04:17 PM, Anthony Liguori wrote:
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread
and
vcpus. It's now
On Tue, Jan 4, 2011 at 5:29 AM, Rik van Riel r...@redhat.com wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may
On 01/04/2011 04:18 PM, Rik van Riel wrote:
On 01/03/2011 10:21 PM, Zhai, Edwin wrote:
Riel,
Thanks for your patch. I have changed the ple_gap to 128 on xen side,
but forget the patch for KVM:(
A little bit big is no harm, but more perf data is better.
So should I resend the patch with the
On 01/03/11 11:57, Juan Quintela wrote:
Please send any agenda items you are interested in covering.
thanks, Juan.
Do we have anything for the agenda yet?
Jes
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On 01/04/2011 08:31 AM, Jes Sorensen wrote:
On 01/03/11 11:57, Juan Quintela wrote:
Please send any agenda items you are interested in covering.
thanks, Juan.
Do we have anything for the agenda yet?
I could use the extra hour to catch up from the Holiday (as I assume a
lot
Juan Quintela quint...@redhat.com wrote:
Please send any agenda items you are interested in covering.
By popular request, this call got cancelled O:-)
Later, Juan.
thanks, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
Avi Kivity wrote:
On 01/04/2011 04:18 PM, Rik van Riel wrote:
So should I resend the patch with the ple_gap default
changed to 128, or are you willing to ack the current
patch?
I think 128 is safer given than 41 was too low. We have to take into
account newer cpus and slower
On Tue, Jan 04, 2011 at 10:45:13PM +0900, Yoshiaki Tamura wrote:
2011/1/4 Michael S. Tsirkin m...@redhat.com:
On Tue, Jan 04, 2011 at 09:20:53PM +0900, Yoshiaki Tamura wrote:
2011/1/4 Michael S. Tsirkin m...@redhat.com:
On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
On 01/04/11 15:33, Anthony Liguori wrote:
On 01/04/2011 08:31 AM, Jes Sorensen wrote:
On 01/03/11 11:57, Juan Quintela wrote:
Please send any agenda items you are interested in covering.
thanks, Juan.
Do we have anything for the agenda yet?
I could use the extra hour to
On 01/04/2011 08:27 AM, Avi Kivity wrote:
On 01/04/2011 04:17 PM, Anthony Liguori wrote:
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access
On Tue, Jan 04, 2011 at 12:56:16AM +0200, Michael Goldish wrote:
On 01/04/2011 12:06 AM, Eduardo Habkost wrote:
On Mon, Jan 03, 2011 at 07:22:17PM -0200, Eduardo Habkost wrote:
[...]
If you want to be extra careful, you can keep an index of contexts for
each exception ever seen, and clear
On 01/04/2011 04:55 PM, Anthony Liguori wrote:
When the TCG thread, it needs to let the IO thread run for at least
one iteration. Coordinating the execution of the IO thread such
that it's guaranteed to run at least once and then having it drop
the qemu mutex long enough for the TCG
On Tue, Jan 04, 2011 at 12:56:16AM +0200, Michael Goldish wrote:
I think that's risky:
try:
vm.create() # context aware, raises an exception
except:
try:
vm.destroy() # context aware, raises an exception
except:
pass
raise
Heh, did you try the code
On 01/04/2011 09:12 AM, Avi Kivity wrote:
On 01/04/2011 04:55 PM, Anthony Liguori wrote:
When the TCG thread, it needs to let the IO thread run for at least
one iteration. Coordinating the execution of the IO thread such
that it's guaranteed to run at least once and then having it drop
Hi Stefan,
Thanks for replying! I was able to figure it out - it was not the fault of
KVM. One of the guests was running ganglia gmetad which was updating 30,000+
rrd files every 15 seconds (thus generating load via disk I/O), I didn't spot
that until shutting down the VMs one by one until I
On Tue, Jan 4, 2011 at 5:29 AM, Rik van Riel r...@redhat.com wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may
On 01/04/2011 11:41 AM, Hillf Danton wrote:
/* !curr-sched_class-yield_to_task ||*/
+ curr-sched_class != p-sched_class) {
+ goto out;
+ }
+
/*
* ask scheduler to compute the next for successfully
On Wed, Jan 5, 2011 at 12:44 AM, Rik van Riel r...@redhat.com wrote:
On 01/04/2011 11:41 AM, Hillf Danton wrote:
/* !curr-sched_class-yield_to_task || */
+ curr-sched_class != p-sched_class) {
+ goto out;
+ }
+
On 01/04/2011 11:51 AM, Hillf Danton wrote:
Wouldn't that break for FIFO and RR tasks?
There's a reason all the scheduler folks wanted a
per-class yield_to_task function :)
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
If the user
On Wed, Jan 5, 2011 at 12:54 AM, Rik van Riel r...@redhat.com wrote:
On 01/04/2011 11:51 AM, Hillf Danton wrote:
Wouldn't that break for FIFO and RR tasks?
There's a reason all the scheduler folks wanted a
per-class yield_to_task function :)
Where is the yield_to callback in the patch for
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the hypervisor (kvm in
this case) to be RT, which it isn't. Then you either need to very
On Wed, Jan 5, 2011 at 1:08 AM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the
On Tue, 2011-01-04 at 15:14 +0900, KOSAKI Motohiro wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may
On Tue, 2011-01-04 at 11:26 +0100, Mike Galbraith wrote:
On Tue, 2011-01-04 at 11:14 +0200, Avi Kivity wrote:
Assuming there are no objections, Mike, can you get 2/3 into a
fast-forward-only branch of tip.git? I'll then merge it into kvm.git
and apply 1/3 and 2/3.
Wrong guy.
On Wed, 2011-01-05 at 01:12 +0800, Hillf Danton wrote:
On Wed, Jan 5, 2011 at 1:08 AM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
On 01/04/2011 12:08 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the hypervisor (kvm in
this case) to be RT,
On Mon, 2011-01-03 at 16:29 -0500, Rik van Riel wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may want to use
The PCI sysfs rom file is exposed read-only by default, but we need
to write to it to enable and disable the ROM around the read. When
running as root, the code works fine as is, but when running
de-privileged via libvirt, the fopen(r+) will fail if the file
doesn't have owner write permissions.
On Mon, Dec 27, 2010 at 12:08:45PM +0200, Avi Kivity wrote:
Instead, drop large mappings, which were the reason we dropped shadow.
Signed-off-by: Avi Kivity a...@redhat.com
---
v2: maintain largepage stats
arch/x86/kvm/mmu.c | 12
virt/kvm/kvm_main.c |7 +--
2
On Tue, Dec 28, 2010 at 07:38:20PM -1000, Zachary Amsden wrote:
On systems with synchronized TSCs, we still have VCPU individual
KVM clocks, each with their own computed offset. As this all happens
at different times, the computed KVM clock offset can vary, causing a
globally visible
On Tue, Dec 28, 2010 at 07:38:18PM -1000, Zachary Amsden wrote:
During a host suspend, TSC may go backwards, which KVM interprets
as an unstable TSC. Technically, KVM should not be marking the
TSC unstable, which causes the TSC clocksource to go bad, but
should be adjusting the TSC offsets in
* Alex Williamson (alex.william...@redhat.com) wrote:
The PCI sysfs rom file is exposed read-only by default, but we need
to write to it to enable and disable the ROM around the read. When
running as root, the code works fine as is, but when running
de-privileged via libvirt, the fopen(r+)
On Tue, 2011-01-04 at 10:30 -0800, Chris Wright wrote:
* Alex Williamson (alex.william...@redhat.com) wrote:
The PCI sysfs rom file is exposed read-only by default, but we need
to write to it to enable and disable the ROM around the read. When
running as root, the code works fine as is,
The PCI sysfs rom file is exposed read-only by default, but we need
to write to it to enable and disable the ROM around the read. When
running as root, the code works fine as is, but when running
de-privileged via libvirt, the fopen(r+) will fail if the file
doesn't have owner write permissions.
On Tue, 2011-01-04 at 19:04 +0100, Peter Zijlstra wrote:
+ p_cfs_rq = cfs_rq_of(pse);
+ yield = 1;
+ }
+#endif
+
+ if (yield)
+ clear_buddies(cfs_rq, se);
+ else if (preempt)
+ clear_buddies(p_cfs_rq, curr);
+
+ /* Tell the
On Wed, Dec 29, 2010 at 07:53:39PM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
kvm_arch_reset_vcpu includes the same logic (minus the obsolete feature
check), and every caller of kvm_reset_mpstate also calls that function.
Signed-off-by: Jan Kiszka
On Fri, Dec 31, 2010 at 01:22:34PM +0800, Huang Ying wrote:
qemu_ram_remap() unmaps the specified RAM pages, then re-maps these
pages again. This is used by KVM HWPoison support to clear HWPoisoned
page tables across guest rebooting, so that a new page may be
allocated later to recover the
From: Jan Kiszka jan.kis...@siemens.com
Make sure to re-register the IRQ of an assigned device as INTx when the
guest disables MSI[X] mode again.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.12.2010, at 20:51, Peter Tyser wrote:
Previously SPRGs 4-7 were improperly read and written in
kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
Signed-off-by: Peter Tyser pty...@xes-inc.com
Thanks a lot for the catch.
On 01/04/2011 08:20 AM, Marcelo Tosatti wrote:
On Tue, Dec 28, 2010 at 07:38:20PM -1000, Zachary Amsden wrote:
On systems with synchronized TSCs, we still have VCPU individual
KVM clocks, each with their own computed offset. As this all happens
at different times, the computed KVM clock
On Sun, Jan 02, 2011 at 08:33:13PM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Obviously a merge artifact.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/kvm.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
Applied, thanks.
--
To
On Tue, Jan 04, 2011 at 08:17:26AM -0600, Anthony Liguori wrote:
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread and
Il 04/01/2011 19:15, Dario Faggioli ha scritto:
Forwarded Message
From: Peter Zijlstraa.p.zijls...@chello.nl
To: Rik van Rielr...@redhat.com
Cc: Hillf Dantondhi...@gmail.com,kvm@vger.kernel.org,
linux-ker...@vger.kernel.org, Avi Kivitia...@redhat.com, Srivatsa
Il 05/01/2011 00:38, Tommaso Cucinotta ha scritto:
Of course, don't misunderstand me: this is a necessary condition for a
stable performance of KVM VMs, I'm not saying it is sufficient for
... it.
Please, comment on this (reply to all, please, I'm not following LKML).
Thanks,
Tommaso
--
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock unfairness
problem. (probaby creating pthread_condattr_setautoyield_np or similar
knob is good one)
Often, the thread
NAK NAK NAK, yield_to is utter crap, and the only reason kvm 'needs' it
is because its wants to be utter crap (run unmodified guests).
There is plenty of sane serialization primitives for userspace, fix your
locking mess instead of pushing crap.
The only reason I'm maybe half-way
On 01/04/2011 05:36 AM, Marcelo Tosatti wrote:
On Tue, Dec 28, 2010 at 07:38:18PM -1000, Zachary Amsden wrote:
During a host suspend, TSC may go backwards, which KVM interprets
as an unstable TSC. Technically, KVM should not be marking the
TSC unstable, which causes the TSC clocksource to
On Tue, 2011-01-04 at 16:32 +0800, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
There is no need to restrict writing back MCE MSRs to reset or full
state updates as setting their values has no side effects.
Sorry for late.
The MCE MSRs contents is sticky for warm reset except
On Fri, 2010-12-31 at 17:10 +0800, Jan Kiszka wrote:
Am 31.12.2010 06:22, Huang Ying wrote:
In Linux kernel HWPoison processing implementation, the virtual
address in processes mapping the error physical memory page is marked
as HWPoison. So that, the further accessing to the virtual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.12.2010, at 20:51, Peter Tyser wrote:
Previously SPRGs 4-7 were improperly read and written in
kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
Signed-off-by: Peter Tyser pty...@xes-inc.com
Thanks a lot for the catch.
91 matches
Mail list logo
