Hi!
I've been getting some locking-related warning when I fire up a KVM
machine. This has been popping up since a 2.6.30 kernel:
[snip]
[119206.978058] BUG: MAX_LOCK_DEPTH too low!
[119206.978062] turning off the locking correctness validator.
[119206.978067] Pid: 9510, comm: kvm Not tainted
On 09/29/2009 06:04 AM, Zachary Amsden wrote:
They are globals, not clearly protected by any ordering or locking, and
vulnerable to various startup races.
Instead, for variable TSC machines, register the cpufreq notifier and get
the TSC frequency directly from the cpufreq machinery. Not only
On 09/29/2009 06:04 AM, Zachary Amsden wrote:
Both VMX and SVM require per-cpu memory allocation, which is done at module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online could not be hardware enabled.
diff --git
On 09/28/2009 01:22 PM, Marcelo Tosatti wrote:
To determine whether to wait for IPI to finish on remote cpu.
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Index: qemu-kvm/kvm/user/test/lib/x86/smp.c
===
---
On 09/28/2009 01:22 PM, Marcelo Tosatti wrote:
So one can measure SMP overhead.
+
+ for (n = cpu_count(); n 0; n--)
+ on_cpu(n-1, do_tests, 0, 0);
Should be done inside do_test(), so we can start the measurement on all
cpus at the same time (right now, if some cpus
On 09/29/2009 12:18 PM, Con Kolivas wrote:
Resending with a couple of extra CCs.
Only extra details I guess were debian stable with kvm that reports itself as:
QEMU PC emulator version 0.9.1 (kvm-72), Copyright (c) 2003-2008 Fabrice
Bellard
Note that I get this stack corruption *every time*,
Bugs item #2868883, was opened at 2009-09-28 16:27
Message generated for change (Comment added) made by yanv
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2868883group_id=180599
Please note that this message will contain a full copy of the comment
Hi
Actually I am using 2.6.21 kernel and inserting kvm-76 module.
It is fine when I am using cpu affinity( like taskset 1
./qemu-system-x86-64 -hda imgage name ).
I am having quad core intel xeon processor.
But without cpu affinity It is hanging randomly.(./qemu-system-x86-64
Resending with a couple of extra CCs.
Only extra details I guess were debian stable with kvm that reports itself as:
QEMU PC emulator version 0.9.1 (kvm-72), Copyright (c) 2003-2008 Fabrice
Bellard
Note that I get this stack corruption *every time*, and it must be with
the -no-kvm option.
Con
Avi,
Any comments for this new patch?
Thanks,
Zhai, Edwin wrote:
Avi Kivity wrote:
+#define KVM_VMX_DEFAULT_PLE_GAP41
+#define KVM_VMX_DEFAULT_PLE_WINDOW 4096
+static int __read_mostly ple_gap = KVM_VMX_DEFAULT_PLE_GAP;
+module_param(ple_gap, int, S_IRUGO);
+
+static int __read_mostly
Bugs item #2869748, was opened at 2009-09-29 14:47
Message generated for change (Tracker Item Submitted) made by dietmarmaurer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2869748group_id=180599
Please note that this message will contain a full copy of
Bugs item #2868883, was opened at 2009-09-28 16:27
Message generated for change (Comment added) made by yanv
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2868883group_id=180599
Please note that this message will contain a full copy of the comment
using 0.11.0, live migration works as expected, but max downtime does not seem
to work, for example:
# migrate_set_downtime 1
After that tcp migration has much longer downtimes (up to 20 seconds).
Also, it seems that the 'monitor' is locked (take up to 10 seconds until I get
a monitor
Hello.
I'm having quite an.. unusable system here.
It's not really a regresssion with 0.11.0,
it was something similar before, but with
0.11.0 and/or 2.6.31 it become much worse.
The thing is that after some uptime, kvm
guest prints something like this:
hrtimer: interrupt too slow, forcing
On 09/28/2009 11:33 AM, Zhai, Edwin wrote:
Avi Kivity wrote:
+#define KVM_VMX_DEFAULT_PLE_GAP41
+#define KVM_VMX_DEFAULT_PLE_WINDOW 4096
+static int __read_mostly ple_gap = KVM_VMX_DEFAULT_PLE_GAP;
+module_param(ple_gap, int, S_IRUGO);
+
+static int __read_mostly ple_window =
Avi Kivity wrote:
On 09/29/2009 03:12 PM, Michael Tokarev wrote:
[]
The thing is that after some uptime, kvm
guest prints something like this:
hrtimer: interrupt too slow, forcing clock min delta to 461487495 ns
[]
What happens if you use hpet or pmtimer as guest clocksource?
For all the
Bugs item #2868883, was opened at 2009-09-28 15:27
Message generated for change (Comment added) made by mdw21
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2868883group_id=180599
Please note that this message will contain a full copy of the comment
Instead of using the unmaintained original CTCS suite,
use the CTCS2 project. Since it's not necessary to keep
the old version around, just bump the source version and
add patches to fix the build under 64 bit architectures
New features of the test:
* Using a newer version compared to the
Seems the bwidth calculation is the problem. The code simply does:
bwidth = (bytes_transferred - bytes_transferred_last) / timediff
but I assume network traffic is buffered, so calculated bwidth is sometimes
much too high.
- Dietmar
-Original Message-
From:
this patch solves the problem by calculation an average bandwidth.
- Dietmar
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Dietmar Maurer
Sent: Dienstag, 29. September 2009 16:37
To: kvm
Subject: RE: migrate_set_downtime bug
Dietmar Maurer wrote:
this patch solves the problem by calculation an average bandwidth.
Can you take a look Glauber?
Regards,
Anthony Liguori
- Dietmar
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Dietmar Maurer
Sent:
On Fri, 2009-09-25 at 05:22 -0400, Jiri Zupka wrote:
- Dor Laor dl...@redhat.com wrote:
On 09/16/2009 04:09 PM, Jiri Zupka wrote:
- Dor Laordl...@redhat.com wrote:
On 09/15/2009 09:58 PM, Jiri Zupka wrote:
After a quick review I have the following questions:
1. Why
On 09/28/2009 10:30 PM, Avi Kivity wrote:
On 09/29/2009 06:04 AM, Zachary Amsden wrote:
Both VMX and SVM require per-cpu memory allocation, which is done at
module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online
On Tue, Sep 29, 2009 at 10:39:57AM -0500, Anthony Liguori wrote:
Dietmar Maurer wrote:
this patch solves the problem by calculation an average bandwidth.
Can you take a look Glauber?
Regards,
Anthony Liguori
- Dietmar
-Original Message-
From: kvm-ow...@vger.kernel.org
Also, if this is really the case (buffered), then the bandwidth capping
part
of migration is also wrong.
Have you compared the reported bandwidth to your actual bandwith ? I
suspect
the source of the problem can be that we're currently ignoring the time
we take
to transfer the state of
On 09/27/2009 04:53 PM, Joerg Roedel wrote:
Depends. If it's a global yield(), yes. If it's a local yield() that
doesn't rebalance the runqueues we might be left with the spinning task
re-running.
Only one runable task on each cpu is unlikely in a situation of high
vcpu overcommit
On Tue, Sep 29, 2009 at 08:56:24AM +0300, Priit Laes wrote:
Hi!
I've been getting some locking-related warning when I fire up a KVM
machine. This has been popping up since a 2.6.30 kernel:
[snip]
[119206.978058] BUG: MAX_LOCK_DEPTH too low!
[119206.978062] turning off the locking
Avi Kivity escreveu:
but a newbie is born every minute.
Reporting in!
As a newbie in KVM, I really appreciate those efforts.
Promise to help on docs when I realize that I know what I am doing. :)
Thank you.
--
Leandro Quibem Magnabosco.
--
To unsubscribe from this list: send the line
Matthew Tippett wrote:
Hi,
I would like to call attention to the SQLite performance under KVM in
the current Ubuntu Alpha.
http://www.phoronix.com/scan.php?page=articleitem=linux_2631_kvmnum=3
SQLite's benchmark as part of the Phoronix Test Suite is typically IO
limited and is affected by
Avi Kivity wrote:
On 09/24/2009 10:49 PM, Matthew Tippett wrote:
The test itself is a simple usage of SQLite. It is stock KVM as
available in 2.6.31 on Ubuntu Karmic. So it would be the environment,
not the test.
So assuming that KVM upstream works as expected that would leave
either 2.6.31
Matthew Tippett wrote:
First up, Phoronix hasn't tuned. It's observing the delivered state
by an OS vendor. I started with what I believe to be the starting
point - KVM.
So the position of the KVM now is that it is either QEMU's
configuration or Ubuntu's configuration. No further guidance or
Matthew Tippett wrote:
I have created a launchpad bug against qemu-kvm in Ubuntu.
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/437473
Just re-iterating, my concern isn't so much performance, but integrity
of stock KVM configurations with server or other workloads that expect
sync
Okay, bringing the leafs of the discussions onto this thread.
As per
http://www.phoronix.com/scan.php?page=articleitem=linux_2631_kvmnum=1single=1
The host OS (as well as the guest OS when testing under KVM) was
running an Ubuntu 9.10 daily snapshot with the Linux 2.6.31 (final) kernel
I am
In get_command_status_output() and is_responsive() use read_nonblocking(0) to
read the unread output before sending input (e.g. a command).
The timeout is currently 0.1 because theoretically it should help if the guest
still produces output when the function is called, but in practice there's no
get_command_output() is safer because it waits for the prompt to return.
sendline() returns immediately, and the output generated in response to the
command can appear later and interfere with the test.
For example, the prompt can appear while the Autotest wrapper waits for an
Autotest test to
This parameter multiplies the timeout values of all the barriers in a step file
test.
It is useful for slower hosts, under load (e.g. when executing multiple tests
in parallel) and for testing QEMU without KVM. In any of these cases, the
multiplier should be greater than 1 in order to give the
The timeout of qemu-img commands is currently 30 seconds.
This may not suffice under heavy load (e.g. when multiple tests run in parallel
and use the same physical disk).
Signed-off-by: Michael Goldish mgold...@redhat.com
---
client/tests/kvm/kvm_vm.py |2 +-
1 files changed, 1
Add a few comments, group similar lines and replace some blocks with one-liners.
Note: the weird form
timeout_multiplier = float(params.get(timeout_multiplier) or 1)
allows the user to fall back to the default value by setting timeout_multiplier
to .
The more common form
timeout_multiplier =
Currently read_nonblocking() is called repeatedly until a match is found.
This is fine as long as internal_timeout, the timeout parameter passed to
read_nonblocking(), is greater than zero. If it equals zero the loop will keep
the CPU busy and stress the host.
To avoid this, use select() to wait
On Tue, Sep 29, 2009 at 2:32 PM, Matthew Tippett tippe...@gmail.com wrote:
I would prefer rather than riling against Phoronix or the results as
presented, ask questions to seek further information about what was tested
rather than writing off all of it as completely invalid.
Matthew-
If you
On Tue, 2009-05-05 at 09:56 +0100, Mark McLoughlin wrote:
This commit:
commit 559a8f45f34cc50d1a60b4f67a06614d506b2e01
Subject: Remove stray GSO code from virtio_net (Mark McLoughlin)
Removed some GSO code from upstream qemu.git, but it needs to
be re-instated in qemu-kvm.git.
On Tue, 2009-09-29 at 21:45 +0100, Mark McLoughlin wrote:
On Tue, 2009-05-05 at 09:56 +0100, Mark McLoughlin wrote:
This commit:
commit 559a8f45f34cc50d1a60b4f67a06614d506b2e01
Subject: Remove stray GSO code from virtio_net (Mark McLoughlin)
Removed some GSO code from upstream
Matthew Tippett wrote:
Okay, bringing the leafs of the discussions onto this thread.
As per
http://www.phoronix.com/scan.php?page=articleitem=linux_2631_kvmnum=1single=1
The host OS (as well as the guest OS when testing under KVM) was
running an Ubuntu 9.10 daily snapshot with the Linux
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/x86.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fedac9d..15d2ace 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@
They are globals, not clearly protected by any ordering or locking, and
vulnerable to various startup races.
Instead, for variable TSC machines, register the cpufreq notifier and get
the TSC frequency directly from the cpufreq machinery. Not only is it
always right, it is also perfectly
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/svm.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9a4daca..d1036ce 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -330,13 +330,14 @@ static
Both VMX and SVM require per-cpu memory allocation, which is done at module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online could not be hardware enabled.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
On Sun, Sep 27, 2009 at 2:42 AM, Avi Kivity a...@redhat.com wrote:
qemu-kvm-0.11.0 is now available. This release is is based on the upstream
qemu 0.11.0, plus kvm-specific enhancements.
Thanks, Avi.
We in Ubuntu have tracked each of the two previous RC's, and we will
have this GA version in
Dustin Kirkland wrote:
On Sun, Sep 27, 2009 at 2:42 AM, Avi Kivity a...@redhat.com wrote:
qemu-kvm-0.11.0 is now available. This release is is based on the upstream
qemu 0.11.0, plus kvm-specific enhancements.
Thanks, Avi.
We in Ubuntu have tracked each of the two previous RC's, and we will
Rest of cases are already fixed qemu-upstream
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/device-assignment.c |2 +-
qemu-kvm.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index
On Wed, 2009-09-30 at 01:48 +0400, Michael Tokarev wrote:
Dustin Kirkland wrote:
On Sun, Sep 27, 2009 at 2:42 AM, Avi Kivity a...@redhat.com wrote:
qemu-kvm-0.11.0 is now available. This release is is based on the upstream
qemu 0.11.0, plus kvm-specific enhancements.
Thanks, Avi.
Hi,
Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
I'd like to do a few things different this time around. I don't think
the -rc process went very well as I don't think we got more testing out
of it. I'd like to shorten the timeline for 0.12.0 a good bit. The
0.10
On Tue, Sep 29, 2009 at 6:54 PM, Anthony Liguori aligu...@us.ibm.com wrote:
Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
I'd like to do a few things different this time around. I don't think the
-rc process went very well as I don't think we got more testing out of
Avi,
I modify it according your comments. The only thing I want to keep is
the module param ple_gap/window. Although they are not per-guest, they
can be used to find the right value, and disable PLE for debug purpose.
Thanks,
Avi Kivity wrote:
On 09/28/2009 11:33 AM, Zhai, Edwin wrote:
Dustin Kirkland wrote:
On Tue, Sep 29, 2009 at 6:54 PM, Anthony Liguori aligu...@us.ibm.com wrote:
Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
I'd like to do a few things different this time around. I don't think the
-rc process went very well as I don't think
http://www.linux-kvm.org/page/HOWTO1 says to build kvm I should get the
latest kvm-release.tar.gz.
http://www.linux-kvm.org/page/Downloads says If you want to use the
latest version of KVM kernel modules and supporting userspace, you can
download the latest version from
On Tue, Sep 29, 2009 at 06:54:53PM -0500, Anthony Liguori wrote:
Hi,
Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
I'd like to do a few things different this time around. I don't think
the -rc process went very well as I don't think we got more testing out
of
On Tue, Sep 29, 2009 at 06:36:57PM +0200, Dietmar Maurer wrote:
Also, if this is really the case (buffered), then the bandwidth capping
part
of migration is also wrong.
Have you compared the reported bandwidth to your actual bandwith ? I
suspect
the source of the problem can be that
The default, IDE, is highly supported by guests but may be slow, especially
with disk arrays. If your guest supports it, use the virtio interface:
Avi,
what is the status of data integrity issues Chris Hellwig summarized some time
ago?
Is it safe to recommend virtio to newbies already? Shouldn't
On (Tue) Sep 29 2009 [18:54:53], Anthony Liguori wrote:
Hi,
Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
I'd like to do a few things different this time around. I don't think
the -rc process went very well as I don't think we got more testing out
of it. I'd
Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.
KVM on BookE always virtualizes the host CPU. On Book3s we go a step further
and take the PVR from userspace that tells us what kind of CPU we are supposed
to virtualize, because we support Book3s_32 and Book3s_64
We need to store more information than we currently have for vcpus
when running on Book3s.
So let's extend the internal struct definitions.
Signed-off-by: Alexander Graf ag...@suse.de
---
v3 - v4:
- use context_id instead of mm_context
---
arch/powerpc/include/asm/kvm_host.h | 75
PowerPC code handles dirty logging in the generic parts atm. While this
is great for return -ENOTSUPP, we need to be rather target specific
when actually implementing it.
So let's split it to implementation specific code, so we can implement
it for book3s.
Signed-off-by: Alexander Graf
KVM for PowerPC only supports embedded cores at the moment.
While it makes sense to virtualize on small machines, it's even more fun
to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
This patchset implements KVM support for Book3s_64 hosts and guest support
for Book3s_64 and
We need to intercept interrupt vectors. To do that, let's add a file
we can always include which only activates the intercepts when we have
then configured.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm_book3s_64_asm.h | 58 ++
1 files
This adds the book3s specific header file that contains structs that
are only valid on book3s specific code.
Signed-off-by: Alexander Graf ag...@suse.de
---
v3 - v4:
- use context_id instead of mm_alloc
---
arch/powerpc/include/asm/kvm_book3s.h | 136 +
1
Little opcodes behave differently on desktop and embedded PowerPC cores.
In order to reflect those differences, let's add some #ifdef code to emulate.c.
We could probably also handle them in the core specific emulation files, but I
would prefer to reuse as much code as possible.
Signed-off-by:
This is the really low level of guest entry/exit code.
Book3s_64 has an SLB, which stores all ESID - VSID mappings we're
currently aware of.
The segments in the guest differ from the ones on the host, so we need
to switch the SLB to tell the MMU that we're in a new context.
So we store a shadow
This is the of entry / exit code. In order to switch between host and guest
context, we need to switch register state and call the exit code handler on
exit.
This assembly file does exactly that. To finally enter the guest it calls
into book3s_64_slb.S. On exit it gets jumped at from
We need to access some VCPU fields from assembly code. In order to get
the proper offsets, we have to define them in asm-offsets.c.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kernel/asm-offsets.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff
To be able to keep KVM as module, we need to export the SLB trampoline
addresses to the module, so it knows where to jump to.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_64_exports.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
For KVM we need to allocate a new context id, but don't really care about
all the mm context around it.
So let's split the alloc and destroy functions for the context id, so we can
grab one without allocating an mm context.
Signed-off-by: Alexander Graf ag...@suse.de
---
Getting from host state to the guest is only half the story. We also need
to return to our host context and handle whatever happened to get us out of
the guest.
On PowerPC every guest exit is an interrupt. So all we need to do is trap
the host's interrupt handlers and get into our #VMEXIT code to
For KVM we need to store some information in the PACA, so we
need to extend it.
This patch adds KVM SLB shadow related entries to the PACA and
a field that indicates if we're inside a guest.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/paca.h |9 +
1
We designed the Book3S port of KVM as modular as possible. Most
of the code could be easily used on a Book3S_32 host as well.
The main difference between 32 and 64 bit cores is the MMU. To keep
things well separated, we treat the book3s_64 MMU as one possible compile
option.
This patch adds all
Now we have everything in place to be able to build KVM, so let's add it
as config option and in the Makefile.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/Kconfig | 17 +
arch/powerpc/kvm/Makefile | 27 +++
2 files changed, 40
It looks like the variable pc is defined. At least the current code always
failed on me stating that pc is already defined somewhere else.
Let's use _pc instead, because that doesn't collide.
Is this the right approach? Does it break on 440 too? If not, why not?
Signed-off-by: Alexander Graf
We currently use host endian long types to store information
in the dirty bitmap.
This works reasonably well on Little Endian targets, because the
u32 after the first contains the next 32 bits. On Big Endian this
breaks completely though, forcing us to be inventive here.
So Ben suggested to
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get the pointer interpreted
correctly, I just make it bounce twice, but admittedly that is not ideal.
I'm open for
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get the pointer
Hollis Blanchard 09/29/09 2:00 AM
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
-BUILD_BUG_ON(__builtin_constant_p(type));
+BUILD_BUG_ON(!__builtin_constant_p(type));
On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich jbeul...@novell.com wrote:
Hollis Blanchard 09/29/09 2:00 AM
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
-
On 09/29/2009 11:17 AM, Alexander Graf wrote:
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read a 64 bit pointer.
This is what happens with
Am 29.09.2009 um 06:25 schrieb Avi Kivity a...@redhat.com:
On 09/29/2009 11:17 AM, Alexander Graf wrote:
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64
On 29.09.2009, at 15:25, Avi Kivity wrote:
On 09/29/2009 11:17 AM, Alexander Graf wrote:
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read
On 09/29/2009 06:29 PM, Alexander Graf wrote:
How about this one? (broken whitespace!)
From c3864a2c5e1fccff7839e47f12c09d9739ca441e Mon Sep 17 00:00:00 2001
From: Alexander Graf ag...@suse.de
Date: Thu, 23 Jul 2009 21:05:57 +0200
Subject: [PATCH] Enable 32bit dirty log pointers on 64bit host
On 29.09.2009, at 18:42, Avi Kivity wrote:
On 09/29/2009 06:29 PM, Alexander Graf wrote:
How about this one? (broken whitespace!)
From c3864a2c5e1fccff7839e47f12c09d9739ca441e Mon Sep 17 00:00:00
2001
From: Alexander Graf ag...@suse.de
Date: Thu, 23 Jul 2009 21:05:57 +0200
Subject:
87 matches
Mail list logo
