From: Michael S. Tsirkin m...@redhat.com
Use irqfd when supported by kernel.
This uses msix mask notifiers: when vector is masked, we poll it from
userspace. When it is unmasked, we poll it from kernel.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti
From: Marcelo Tosatti mtosa...@redhat.com
* upstream-merge: (266 commits)
OHCI qdev conversion
Fix arm-linux-user
ARMv7-M reset fixes
tcg/mips: use seb/seh instructions on MIPS32R2
tcg/mips: fix 64-bit linux-user on big endian MIPS
tcg/ppc: Implement eqv, nand and nor
Split TLB
From: Marcelo Tosatti mtosa...@redhat.com
Otherwise qemu-kvm iothread never sleeps on select().
Reported-by: David S. Ahern daah...@cisco.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 714a592..cc5b352 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
From: Michael S. Tsirkin m...@redhat.com
Support per-vector callbacks for msix mask/unmask.
Will be used for vhost net.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/msix.c b/hw/msix.c
index faee0b2..3ec8805 100644
---
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
kvm_mmu_page.oos_link is not used, so remove it
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
After is_rsvd_bits_set() checks, EFER.NXE must be enabled if NX bit is seted
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/paging_tmpl.h
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
This patch does:
- 'sp' parameter in inspect_spte_fn() is not used, so remove it
- fix 'kvm' and 'slots' is not defined in count_rmaps()
- fix a bug in inspect_spte_has_rmap()
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
From: Alexander Graf ag...@suse.de
Commit a0abee86af2d1f048dbe99d2bcc4a2cefe685617 introduced unsetting of the
IRQ line from userspace. This added a new core specific callback that I
apparently forgot to add for BookE.
So let's add the callback for BookE as well, making it build again.
From: Avi Kivity a...@redhat.com
MAXPHYADDR is derived from cpuid 0x8008, but when that isn't present, we
get some random value.
Fix by checking first that cpuid 0x8008 is supported.
Acked-by: Pekka Enberg penb...@cs.helsinki.fi
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by:
From: Andre Przywara andre.przyw...@amd.com
On SVM we set the instruction length of skipped instructions
to hard-coded, well known values, which could be wrong when (bogus,
but valid) prefixes (REX, segment override) are used.
Newer AMD processors (Fam10h 45nm and better, aka. PhenomII or
From: Jan Kiszka jan.kis...@siemens.com
Stop the switch immediately if task_switch_16/32 returned an error. Only
if that step succeeded, the switch should actually take place and update
any register states.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
This patch limits the number of pages per memory slot to make
us free from extra care about type issues.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Int is not long enough to store the size of a dirty bitmap.
This patch fixes this problem with the introduction of a wrapper
function to calculate the sizes of dirty bitmaps.
Note: in mark_page_dirty(), we have to consider the fact that
From: Avi Kivity a...@redhat.com
Log emulated instructions in ftrace, especially if they failed.
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 32c912c..a6544b8 100644
---
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
This patch fix:
- calculate zapped page number properly in mmu_zap_unsync_children()
- calculate freeed page number properly kvm_mmu_change_mmu_pages()
- if zapped children page it shoud restart hlist walking
KVM-Stable-Tag.
Signed-off-by: Xiao
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
define 'multimapped' as 'bool'
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 707d272..3c31c5a
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Quote from Avi:
|Just change the assignment to a 'goto restart;' please,
|I don't like playing with list_for_each internals.
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
'vcpu' is unused, remove it
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index b63e796..d217f9c 100644
--- a/arch/x86/kvm/mmu.c
From: Gleb Natapov g...@redhat.com
emulator_task_switch() should return -1 for failure and 0 for success to
the caller, just like x86_emulate_insn() does.
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/emulate.c
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Gleb Natapov g...@redhat.com
If kvm_task_switch() fails code exits to userspace without specifying
exit reason, so the previous exit reason is reused by userspace. Fix
this by specifying exit reason correctly.
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Remove 'struct kvm_unsync_walk' since it's not used
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index edfef80..b63e796 100644
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jan Kiszka jan.kis...@siemens.com
When a fault triggers a task switch, the error code, if existent, has to
be pushed on the new task's stack. Implement the missing bits.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git
From: Avi Kivity a...@redhat.com
There is no real distinction between glevels=3 and glevels=4; both have
exactly the same format and the code is treated exactly the same way. Drop
role.glevels and replace is with role.cr4_pae (which is meaningful). This
simplifies the code a bit.
As a side
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
Here is the new patch of V5 against tip/master of April 17th if anyone wants
to try it.
Ok, this looks pretty good from the perf angle - so once Avi likes patches #1
and #2 and creates a pullable branch we can apply #3 as well to
On 04/17/2010 09:12 PM, Avi Kivity wrote:
I think you were right the first time around.
Re-reading again (esp. the part about treatment of indirect NMI
vmexits), I think this was wrong, and that the code is correct. I am
now thoroughly confused.
--
error compiling committee.c: too many
On 04/19/2010 08:32 AM, Zhang, Yanmin wrote:
Below patch introduces perf_guest_info_callbacks and related register/unregister
functions. Add more PERF_RECORD_MISC_XXX bits meaning guest kernel and guest
user
space.
This doesn't apply against upstream. What branch was this generated
On 04/19/2010 04:26 AM, Alexander Graf wrote:
Very true. In fact, I certainly remember me putting a return and a
WARN_ON(true) because WARN() gave me a warning here. I wonder where that code
went ... hrm ...
Either way, thanks for looking over this patch!
Ugh - I messed up my patch
Lucas Meneghel Rodrigues wrote:
From: sshang ssh...@redhat.com
The test use kvm test harness kvmctl load binary test case file
to test various functions of the kvm kernel module.
I thought that tool is deprecated (or even broken), and I was about to
suggest dropping it from the tree in favor
On Mon, 2010-04-19 at 11:37 +0300, Avi Kivity wrote:
On 04/19/2010 08:32 AM, Zhang, Yanmin wrote:
Below patch introduces perf_guest_info_callbacks and related
register/unregister
functions. Add more PERF_RECORD_MISC_XXX bits meaning guest kernel and
guest user
space.
This
On 04/19/2010 11:55 AM, Zhang, Yanmin wrote:
On Mon, 2010-04-19 at 11:37 +0300, Avi Kivity wrote:
On 04/19/2010 08:32 AM, Zhang, Yanmin wrote:
Below patch introduces perf_guest_info_callbacks and related register/unregister
functions. Add more PERF_RECORD_MISC_XXX bits meaning guest
On 04/19/2010 11:59 AM, Avi Kivity wrote:
What branch was this generated
against?
It's against the latest tip/master. I checked out to 19b26586090 as
the latest
tip/master has some updates on perf.
I don't want to merge tip/master... does tip/perf/core contain the
needed updates?
On 04/18/2010 09:33 AM, Manish Regmi wrote:
Hi,
The following patch makes sure all code path of failed emulation
runs trace_kvm_emulate_insn_failed().
Please let me know if there is anything missing or wrong.
Thank you.
Signed-off-by: Manish Regmiregmi.man...@gmail.com
diff --git
Den 18.04.2010 11:56, skrev Gleb Natapov:
That's two different things here:
The issue that Espen is reporting is that the hosts have different
frequency and guests that relay on the tsc as a source clock will
notice that post migration. The is indeed a problem that -tdf does
not solve. -tdf
On Mon, 2010-04-19 at 11:59 +0300, Avi Kivity wrote:
On 04/19/2010 11:55 AM, Zhang, Yanmin wrote:
On Mon, 2010-04-19 at 11:37 +0300, Avi Kivity wrote:
On 04/19/2010 08:32 AM, Zhang, Yanmin wrote:
Below patch introduces perf_guest_info_callbacks and related
On 04/18/2010 09:35 AM, Manish Regmi wrote:
Hi,
When the vm exit reason is VM Entry failures it has leftmost bit set.
This patch
- clears the leftmost bit when copying to vmx-exit_reason. This will
make the checks like if ((vmx-exit_reason ==
EXIT_REASON_MCE_DURING_VMENTRY) valid in
On Mon, Apr 19, 2010 at 11:21:47AM +0200, Espen Berg wrote:
Den 18.04.2010 11:56, skrev Gleb Natapov:
That's two different things here:
The issue that Espen is reporting is that the hosts have different
frequency and guests that relay on the tsc as a source clock will
notice that post
The RCU/SRCU API have already changed for proving RCU usage.
I got the following dmesg when PROVE_RCU=y because we used incorrect API.
This patch coverts rcu_deference() to srcu_dereference() or family API.
===
[ INFO: suspicious
On 04/19/2010 12:41 PM, Lai Jiangshan wrote:
The RCU/SRCU API have already changed for proving RCU usage.
I got the following dmesg when PROVE_RCU=y because we used incorrect API.
This patch coverts rcu_deference() to srcu_dereference() or family API.
Applied the patch I just sent and let CONFIG_PROVE_RCU=y,
we can got the following dmesg. And we found that it is
because some codes in KVM dereferences srcu-protected pointer without
srcu_read_lock() held or update-side lock held.
It is not hard to fix, the problem is that:
Where is the most
On 04/19/2010 12:22 PM, Zhang, Yanmin wrote:
I don't want to merge tip/master... does tip/perf/core contain the
needed updates?
I think so. A moment ago, I checked out to b5a80b7e9 of tip/perf/core. All 3
patches could be applied cleanly and compilation is ok. A quick testing shows
Michael,
The idea is simple, just to pin the guest VM user space and then
let host NIC driver has the chance to directly DMA to it.
The patches are based on vhost-net backend driver. We add a device
which provides proto_ops as sendmsg/recvmsg to vhost-net to
send/recv directly to/from
On 04/19/2010 12:58 PM, Lai Jiangshan wrote:
Applied the patch I just sent and let CONFIG_PROVE_RCU=y,
we can got the following dmesg. And we found that it is
because some codes in KVM dereferences srcu-protected pointer without
srcu_read_lock() held or update-side lock held.
It is not hard to
On Mon, 2010-04-19 at 10:50 +0200, Jan Kiszka wrote:
Lucas Meneghel Rodrigues wrote:
From: sshang ssh...@redhat.com
The test use kvm test harness kvmctl load binary test case file
to test various functions of the kvm kernel module.
I thought that tool is deprecated (or even broken),
Lucas Meneghel Rodrigues wrote:
On Mon, 2010-04-19 at 10:50 +0200, Jan Kiszka wrote:
Lucas Meneghel Rodrigues wrote:
From: sshang ssh...@redhat.com
The test use kvm test harness kvmctl load binary test case file
to test various functions of the kvm kernel module.
I thought that tool is
On Mon, Apr 19, 2010 at 06:05:17PM +0800, Xin, Xiaohui wrote:
Michael,
The idea is simple, just to pin the guest VM user space and then
let host NIC driver has the chance to directly DMA to it.
The patches are based on vhost-net backend driver. We add a device
which provides
On 04/17/2010 01:22 AM, Alexander Graf wrote:
When we get a performance counter interrupt we need to route it on to the
Linux handler after we got out of the guest context. We also need to tell
our handling code that this particular interrupt doesn't need treatment.
So let's add those two bits
On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote:
+ do {
+ last = last_value;
Does this need a barrier() to prevent the compiler from re-reading
last_value for the subsequent lines? Otherwise (ret last) and
return last could execute with different values
On Sat, 2010-04-17 at 21:49 +0300, Avi Kivity wrote:
On 04/17/2010 09:48 PM, Avi Kivity wrote:
+static u64 last_value = 0;
Needs to be atomic64_t.
+
cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
{
struct pvclock_shadow_time shadow;
On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Please define a cpuid bit that makes this optional. When we eventually
enable it in the
On 04/19/2010 01:43 PM, Peter Zijlstra wrote:
+
cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
{
struct pvclock_shadow_time shadow;
unsigned version;
cycle_t ret, offset;
+u64 last;
+do {
+last = last_value;
On 04/19/2010 01:46 PM, Peter Zijlstra wrote:
On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Please define a cpuid bit that makes this
On Mon, 2010-04-19 at 12:46 +0200, Peter Zijlstra wrote:
On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
After this patch is applied, I don't see a single warp in time during 5
days
of execution, in any of the machines I saw them before.
Please define a cpuid bit
On 04/19/2010 01:39 PM, Peter Zijlstra wrote:
On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote:
+ do {
+ last = last_value;
Does this need a barrier() to prevent the compiler from re-reading
last_value for the subsequent lines? Otherwise (ret last)
On Mon, 2010-04-19 at 13:49 +0300, Avi Kivity wrote:
On 04/19/2010 01:46 PM, Peter Zijlstra wrote:
On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
After this patch is applied, I don't see a single warp in time during 5
days
of execution, in any of the machines I saw them
On 04/19/2010 01:49 PM, Peter Zijlstra wrote:
Right, so on x86 we have:
X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
independent, not that it doesn't stop in C states and similar fun stuff.
X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
and
On 04/19/2010 01:51 PM, Peter Zijlstra wrote:
Right, so on x86 we have:
X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
independent, not that it doesn't stop in C states and similar fun stuff.
X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
and
On 19.04.2010, at 12:34, Avi Kivity wrote:
On 04/17/2010 01:22 AM, Alexander Graf wrote:
When we get a performance counter interrupt we need to route it on to the
Linux handler after we got out of the guest context. We also need to tell
our handling code that this particular interrupt
On Mon, 2010-04-19 at 13:47 +0300, Avi Kivity wrote:
On 04/19/2010 01:43 PM, Peter Zijlstra wrote:
+
cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
{
struct pvclock_shadow_time shadow;
unsigned version;
cycle_t ret, offset;
+
On Mon, 2010-04-19 at 13:53 +0300, Avi Kivity wrote:
On 04/19/2010 01:49 PM, Peter Zijlstra wrote:
Right, so on x86 we have:
X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
independent, not that it doesn't stop in C states and similar fun stuff.
On Mon, 2010-04-19 at 13:50 +0300, Avi Kivity wrote:
On 04/19/2010 01:39 PM, Peter Zijlstra wrote:
On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote:
+ do {
+ last = last_value;
Does this need a barrier() to prevent the compiler from re-reading
From: sshang ssh...@redhat.com
The test use kvm test harness kvmctl load binary test case file
to test various functions of the kvm kernel module.
This test is for unit testing on older KVM branches, after some
consideration we decided to keep the modules for upstream and
branches that use
On 04/19/2010 02:05 PM, Peter Zijlstra wrote:
ACCESS_ONCE() is your friend.
I think it's implied with atomic64_read().
Yes it would be. I was merely trying to point out that
last = ACCESS_ONCE(last_value);
Is a narrower way of writing:
last = last_value;
barrier();
On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
Right, do bear in mind that the x86 implementation of atomic64_read() is
terrifyingly expensive, it is better to not do that read and simply use
the result of the cmpxchg.
atomic64_read() _is_ cmpxchg64b. Are you thinking of some
On Mon, 2010-04-19 at 14:13 +0300, Avi Kivity wrote:
On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
Right, do bear in mind that the x86 implementation of atomic64_read() is
terrifyingly expensive, it is better to not do that read and simply use
the result of the cmpxchg.
On 04/19/2010 01:59 PM, Peter Zijlstra wrote:
So what do we need? test for both TSC_RELIABLE and NONSTOP_TSC? IMO
TSC_RELIABLE should imply NONSTOP_TSC.
Yeah, I think RELIABLE does imply NONSTOP and CONSTANT, but NONSTOP
CONSTANT does not make RELIABLE.
The manual says:
On 04/19/2010 02:19 PM, Peter Zijlstra wrote:
Still have two cmpxchgs in the common case. The first iteration will
fail, fetching last_value, the second will work.
It will be better when we have contention, though, so it's worthwhile.
Right, another option is to put the initial read
On 04/19/2010 12:29 PM, Gleb Natapov wrote:
On Mon, Apr 19, 2010 at 11:21:47AM +0200, Espen Berg wrote:
Den 18.04.2010 11:56, skrev Gleb Natapov:
That's two different things here:
The issue that Espen is reporting is that the hosts have different
frequency and guests that relay on the tsc as
Thanks Dan.
However, as I checked this command device_add, I did not found QMP
support it.
I use the command:
{QMP: {query-command}}
In the return list, I did not found the device_add. The list is as below:
-
{return: [{name: quit},
On Mon, Apr 19, 2010 at 08:55:37PM +0800, chunhui zhao wrote:
Thanks Dan.
However, as I checked this command device_add, I did not found QMP
support it.
I use the command:
{QMP: {query-command}}
In the return list, I did not found the device_add. The list is as below:
Tests the ability of adding virtual cpus on the fly to qemu using
the monitor command cpu_set, then after everything is OK, run the
cpu_hotplug testsuite on the guest through autotest.
Updates: The cpu_set feature has been worked out and is in
better shape, however it is my understanding that
The virtio balloon driver can dig into the reservation pools
of the OS to satisfy a balloon request. This is not advisable
and other balloon drivers (drivers/xen/balloon.c) avoid this
as well. The patch also adds changes to avoid printing a warning
if allocation fails, since we retry after
Bugs item #2989366, was opened at 2010-04-19 15:47
Message generated for change (Tracker Item Submitted) made by tgr1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2989366group_id=180599
Please note that this message will contain a full copy of the
On Mon, Apr 19, 2010 at 02:10:54PM +0300, Avi Kivity wrote:
On 04/19/2010 02:05 PM, Peter Zijlstra wrote:
ACCESS_ONCE() is your friend.
I think it's implied with atomic64_read().
Yes it would be. I was merely trying to point out that
last = ACCESS_ONCE(last_value);
Is a narrower
On Fri, Apr 16, 2010 at 01:36:34PM -0700, Jeremy Fitzhardinge wrote:
On 04/15/2010 11:37 AM, Glauber Costa wrote:
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi
Since commit bf47a760f66ad, we no longer handle ptes with the global bit
set specially, so there is no reason to distinguish between shadow pages
created with cr4.gpe set and clear.
Such tracking is expensive when the guest toggles cr4.pge, so drop it.
Signed-off-by: Avi Kivity a...@redhat.com
On Mon, Apr 19, 2010 at 01:19:43PM +0200, Peter Zijlstra wrote:
On Mon, 2010-04-19 at 14:13 +0300, Avi Kivity wrote:
On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
Right, do bear in mind that the x86 implementation of atomic64_read() is
terrifyingly expensive, it is better to not
On 04/19/2010 05:21 PM, Glauber Costa wrote:
Oh yes, just trying to avoid a patch with both atomic64_read() and
ACCESS_ONCE().
you're mixing the private version of the patch you saw with this one.
there isn't any atomic reads in here. I'll use a barrier then
This patch writes
On 04/19/2010 05:32 PM, Glauber Costa wrote:
Right, another option is to put the initial read outside of the loop,
that way you'll have the best of all cases, a single LOCK'ed op in the
loop, and only a single LOCK'ed op for the fast path on sensible
architectures ;-)
last =
On Mon, 2010-04-19 at 17:33 +0300, Avi Kivity wrote:
On 04/19/2010 05:21 PM, Glauber Costa wrote:
Oh yes, just trying to avoid a patch with both atomic64_read() and
ACCESS_ONCE().
you're mixing the private version of the patch you saw with this one.
there isn't any atomic reads
The Buildbot has detected a new failure of default_i386_debian_5_0 on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/361
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
The Buildbot has detected a new failure of default_x86_64_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/300
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/299
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
On 04/19/2010 07:33 AM, Avi Kivity wrote:
On 04/19/2010 05:21 PM, Glauber Costa wrote:
Oh yes, just trying to avoid a patch with both atomic64_read() and
ACCESS_ONCE().
you're mixing the private version of the patch you saw with this one.
there isn't any atomic reads in here. I'll use
On 04/19/2010 07:46 AM, Peter Zijlstra wrote:
What avi says! :-)
On a 32bit machine a 64bit read are two 32bit reads, so
last = last_value;
becomes:
last.high = last_value.high;
last.low = last_vlue.low;
(or the reverse of course)
Now imagine a write getting interleaved with
On 04/19/2010 07:26 AM, Glauber Costa wrote:
Is the problem that the tscs are starting out of sync, or that they're
drifting relative to each other over time? Do the problems become worse
the longer the uptime? How large are the offsets we're talking about here?
The offsets usually
FYI, i found a few problems that need fixing:
+ unsigned long ip;
+ if (perf_guest_cbs perf_guest_cbs-is_in_guest())
missing newline.
+ int misc = 0;
+ if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
ditto.
+ PERF_RECORD_MISC_GUEST_KERNEL;
+
On Mon, Apr 19, 2010 at 09:19:38AM -0700, Jeremy Fitzhardinge wrote:
On 04/19/2010 07:26 AM, Glauber Costa wrote:
Is the problem that the tscs are starting out of sync, or that they're
drifting relative to each other over time? Do the problems become worse
the longer the uptime? How large
On 04/19/2010 12:54 AM, Avi Kivity wrote:
On 04/19/2010 01:51 PM, Peter Zijlstra wrote:
Right, so on x86 we have:
X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
independent, not that it doesn't stop in C states and similar fun
stuff.
X86_FEATURE_TSC_RELIABLE, which IIRC
=
CALL FOR PAPERS
KVM Forum 2010
=
DESCRIPTION
The KVM Forum is back! After a break last year we're proud to present
this year's gathering around KVM again. The
Fix a long standing bug where the unattended installs for
RHEL 3.9 32 bit were failing due to some limitations on the
boot install kernel for this specific version. Instead
of using dhclient, resort to static IP configuration and
bring joy to the land. This modification to the kickstart
file does
On Sun, 2010-04-18 at 21:32 -0600, David S. Ahern wrote:
On 04/18/2010 12:26 PM, Lucas Meneghel Rodrigues wrote:
On Sat, 2010-04-17 at 22:55 -0600, David S. Ahern wrote:
On 04/17/2010 10:09 PM, Amos Kong wrote:
%post --interpreter /usr/bin/python
import socket, os
Hello,
Finally I got QEMU-KVM to work but video performance under DOS is very
low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM is
slow)
I'm measuring 2 performance critical video performance parameters:
1.) INT 10h, function AX=4F05h (set same window/set window/get
Hi folks,
I've implemented a functional test for the cpu_set feature some time
ago. I was going through the patch queue and realized the patch needed
some respin, so I did it. I decided to try and see what is the state of
the feature, considering last time I tried it was not working
On Fri, Feb 19, 2010 at 12:22:20AM +0200, Michael S. Tsirkin wrote:
I took a stub at documenting CMD and FLUSH request types in virtio
block.
Any comments?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info
These are changes to uio_pci_generic.c to allow better use of the driver by
non-privileged processes.
1. Add back old code which allowed interrupt re-enablement through uio fd.
2. Translate PCI bards to uio mmap regions, to allow mmap through uio fd.
3. Allow devices which support MSI or MSI-X,
This patch adds the mergeable RX buffers feature to vhost.
Signed-off-by: David L Stevens dlstev...@us.ibm.com
diff -ruNp net-next-p0/drivers/vhost/net.c net-next-v4/drivers/vhost/net.c
--- net-next-p0/drivers/vhost/net.c 2010-03-22 12:04:38.0 -0700
+++
On Mon, Apr 19, 2010 at 4:20 AM, Avi Kivity a...@redhat.com wrote:
}
It's better not to trace #UD triggered emulations, since we except these to
fail, for example if the guest executes the UD2 instruction.
ya. that sounds more logical. Thanks for explaining.
Mohammed Gamal wrote:
On Tue, Apr 13, 2010 at 9:08 PM, jvrao jv...@linux.vnet.ibm.com wrote:
jvrao wrote:
Alexander Graf wrote:
On 12.04.2010, at 13:58, Jamie Lokier wrote:
Mohammed Gamal wrote:
On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier ja...@shareable.org
wrote:
Javier Guerra
1 - 100 of 127 matches
Mail list logo
