On 05.01.2012, at 18:16, Scott Wood wrote:
> On 01/04/2012 08:36 PM, Alexander Graf wrote:
>>
>> On 04.01.2012, at 21:12, Scott Wood wrote:
>>
>>> On 01/03/2012 07:10 PM, Alexander Graf wrote:
>>>> diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
>>>> index 25964ee..fb3fddc 100644
>>>> --- a/arch/powerpc/include/asm/kvm.h
>>>> +++ b/arch/powerpc/include/asm/kvm.h
>>>> @@ -327,4 +327,6 @@ struct kvm_book3e_206_tlb_params {
>>>> __u32 reserved[8];
>>>> };
>>>>
>>>> +#define KVM_ONE_REG_PPC_HIOR KVM_ONE_REG_PPC | 0x100
>>>
>>> Where does 0x100 come from?
>>
>> I quite frankly don't remember :). This could just as well be 0 or 1.
>>
>>> There should probaly be some structure to the register space, with a
>>> subarch field distinguishing between "common SPR", "book3s SPR", "book3e
>>> SPR", along with others for non-SPR registers, KVM inventions, etc.
>>
>> Not sure we really need this. I would very much prefer to just always
>> use the textual representation. What would we do if something book3s
>> specific suddenly becomes generic (like Altivec for example, or
>> FPU)?
>
> Good point... A plain enumeration should be fine. 0x100 was strange
> enough that it left me wondering what the value should be for the next
> register to be added -- I didn't want it to turn into something like the
> booke regs->trap mess, where some exceptions re-use the classic offsets,
> and other exceptions have numbers that seem to be pulled from out of
> nowhere.
Yup. I'll change it to something lower.
Also we're already using KVM_REG for MMIO register identifiers. But I guess we can just reuse the namespace as long as we're careful to not overlap them later.
#define KVM_REG_MASK 0x001f
#define KVM_REG_EXT_MASK 0xffe0
#define KVM_REG_GPR 0x0000
#define KVM_REG_FPR 0x0020
#define KVM_REG_QPR 0x0040
#define KVM_REG_FQPR 0x0060
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
