On 10/08/2012 04:01:11 PM, Alexander Graf wrote:
On 08.10.2012, at 22:45, Scott Wood wrote:
> On 10/07/2012 08:30:06 AM, Alexander Graf wrote:
>> On 07.10.2012, at 15:26, Avi Kivity wrote:
>> > The downside of this generic approach is that it prepares
suprises down
>> > the road. The alterna
On 08.10.2012, at 22:45, Scott Wood wrote:
> On 10/07/2012 08:30:06 AM, Alexander Graf wrote:
>> On 07.10.2012, at 15:26, Avi Kivity wrote:
>> > The downside of this generic approach is that it prepares suprises down
>> > the road. The alternative approach, of adding a new KVM_EXIT_RESET,
>> > a
On 10/07/2012 08:30:06 AM, Alexander Graf wrote:
On 07.10.2012, at 15:26, Avi Kivity wrote:
> The downside of this generic approach is that it prepares suprises
down
> the road. The alternative approach, of adding a new KVM_EXIT_RESET,
> avoids this minefield, but requires ABI changes every
On 07.10.2012, at 15:34, Avi Kivity wrote:
> On 10/07/2012 03:30 PM, Alexander Graf wrote:
Yup. The new APIC MSR registers would also have the same problem, right?
>>>
>>> Which new APIC MSR registers?
>>
>> I thought x2apic can be accessed through MSRs? If you want to emulate that
On 10/07/2012 03:30 PM, Alexander Graf wrote:
>>>
>>> Yup. The new APIC MSR registers would also have the same problem, right?
>>
>> Which new APIC MSR registers?
>
> I thought x2apic can be accessed through MSRs? If you want to emulate that in
> user space, you need something similar.
It's em
On 07.10.2012, at 15:30, Avi Kivity wrote:
> On 10/07/2012 03:26 PM, Alexander Graf wrote:
>>>
>>> Ah, yes. I forgot to add this exit to that section of the spec.
>>
>> Patch submitted :).
>
> Ugh, the whole point of finding problems in patches is that I don't have
> to think about them for a
On 10/07/2012 03:26 PM, Alexander Graf wrote:
>>
>> Ah, yes. I forgot to add this exit to that section of the spec.
>
> Patch submitted :).
Ugh, the whole point of finding problems in patches is that I don't have
to think about them for a while. Posting a new patch in a few minutes
negates this
On 07.10.2012, at 15:26, Avi Kivity wrote:
> On 10/07/2012 03:19 PM, Alexander Graf wrote:
>>
>> On 07.10.2012, at 15:13, Avi Kivity wrote:
>>
>>> On 10/07/2012 01:41 AM, Alexander Graf wrote:
SPRs on PowerPC are the equivalent to MSRs on x86. They usually
control behavior inside a co
On 07.10.2012, at 15:19, Alexander Graf wrote:
>
> On 07.10.2012, at 15:13, Avi Kivity wrote:
>
>> On 10/07/2012 01:41 AM, Alexander Graf wrote:
>>> SPRs on PowerPC are the equivalent to MSRs on x86. They usually
>>> control behavior inside a core, so the best place to emulate them
>>> traditio
On 10/07/2012 03:19 PM, Alexander Graf wrote:
>
> On 07.10.2012, at 15:13, Avi Kivity wrote:
>
>> On 10/07/2012 01:41 AM, Alexander Graf wrote:
>>> SPRs on PowerPC are the equivalent to MSRs on x86. They usually
>>> control behavior inside a core, so the best place to emulate them
>>> traditional
On 07.10.2012, at 15:13, Avi Kivity wrote:
> On 10/07/2012 01:41 AM, Alexander Graf wrote:
>> SPRs on PowerPC are the equivalent to MSRs on x86. They usually
>> control behavior inside a core, so the best place to emulate them
>> traditionally has been the kernel side of kvm.
>>
>> However, some
On 10/07/2012 01:41 AM, Alexander Graf wrote:
> SPRs on PowerPC are the equivalent to MSRs on x86. They usually
> control behavior inside a core, so the best place to emulate them
> traditionally has been the kernel side of kvm.
>
> However, some SPRs should be emulated by user space. For example
SPRs on PowerPC are the equivalent to MSRs on x86. They usually
control behavior inside a core, so the best place to emulate them
traditionally has been the kernel side of kvm.
However, some SPRs should be emulated by user space. For example
the DBCR0 register which is used for machine reset. Or t
13 matches
Mail list logo