Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to
On 11/30/2009 03:02 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This
On 11/26/2009 01:16 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This
Avi Kivity wrote:
On 11/26/2009 01:16 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address
space we're
in and resolve addresses. While that is a big problem for migration,
it's also
unpleasent when debugging, as gdb and the monitor don't work on
On 11/26/2009 02:46 PM, Alexander Graf wrote:
Please avoid unnamed unions in user-visible headers - they're a gcc
extension.
Yes, we have them elsewhere, but let's not add to the pile.
I'm open to scalable suggestions that don't break existing userspace code.
If I name the union now,
Avi Kivity wrote:
On 11/26/2009 02:46 PM, Alexander Graf wrote:
Please avoid unnamed unions in user-visible headers - they're a gcc
extension.
Yes, we have them elsewhere, but let's not add to the pile.
I'm open to scalable suggestions that don't break existing userspace
code.
If I
On 11/26/2009 03:16 PM, Alexander Graf wrote:
You can keep pvr out of the (named) union.
So we'd have
sregs.padded.ppc64.slb?
or sregs.u.ppc64.slb.
I don't see how that is an improvement.
Buildability takes precedence.
(an alternative is to drop the union, and add a
Am 26.11.2009 um 16:24 schrieb Alexander Graf ag...@suse.de:
Currently userspace has no chance to find out which virtual address
space we're
in and resolve addresses. While that is a big problem for migration,
it's also
unpleasent when debugging, as gdb and the monitor don't work on
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
On 24.11.2009, at 16:02, Avi Kivity wrote:
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space
we're
in and resolve addresses. While that is a big problem for migration, it's
also
unpleasent when debugging, as gdb and
On 11/24/2009 05:04 PM, Alexander Graf wrote:
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to
12 matches
Mail list logo
