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 pat
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 us
Am 26.11.2009 um 16:24 schrieb Alexander Graf :
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.
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 us
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 BUI
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 use
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, ex
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 wor
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 pat
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 us
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
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
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.
in
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 us
14 matches
Mail list logo
