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 virtual >> addresses. >> >> This patch exports enough of the MMU segment state to userspace to make >> debugging work and thus also includes the groundwork for migration. >> >> >> struct kvm_sregs { >> - __u32 pvr; >> - char pad[1020]; >> + union { >> + struct { >> + __u32 pvr; >> + __u64 sdr1; >> + struct { >> + struct { >> + __u64 slbe; >> + __u64 slbv; >> + } slb[64]; >> + } ppc64; >> + struct { >> + __u32 sr[16]; >> + __u64 ibat[8]; >> + __u64 dbat[8]; >> + } ppc32; >> + }; >> + __u8 pad[1024]; >> + }; >> }; >> > > 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, existing qemu code will break. If I align the pad array manually I'll definitely mess up something. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html