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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
