On 10.02.2012, at 00:43, Scott Wood wrote:
> On 02/09/2012 05:23 PM, Alexander Graf wrote:
>> How about we return 1 for kvm_arch_vcpu_in_guest_mode() on !x86
>> always, just like it's done today basically? Then we can worry about
>> needless IPIs later and don't regress from the respective curren
On 02/09/2012 05:23 PM, Alexander Graf wrote:
> How about we return 1 for kvm_arch_vcpu_in_guest_mode() on !x86
> always, just like it's done today basically? Then we can worry about
> needless IPIs later and don't regress from the respective current
> kick implementations.
And perhaps call the fu
On 10.02.2012, at 00:18, Christoffer Dall wrote:
> On Thu, Feb 9, 2012 at 3:02 PM, Alexander Graf wrote:
>>
>> On 09.02.2012, at 23:33, Christoffer Dall wrote:
>>
>>> From: Christoffer Dall
>>>
>>> The kvm_vcpu_kick function performs roughly the same funcitonality on
>>> most all architectur
On Thu, Feb 9, 2012 at 3:02 PM, Alexander Graf wrote:
>
> On 09.02.2012, at 23:33, Christoffer Dall wrote:
>
>> From: Christoffer Dall
>>
>> The kvm_vcpu_kick function performs roughly the same funcitonality on
>> most all architectures, so we shouldn't have separate copies.
>>
>> PowerPC keeps a
On 09.02.2012, at 23:33, Christoffer Dall wrote:
> From: Christoffer Dall
>
> The kvm_vcpu_kick function performs roughly the same funcitonality on
> most all architectures, so we shouldn't have separate copies.
>
> PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch
> structu
From: Christoffer Dall
The kvm_vcpu_kick function performs roughly the same funcitonality on
most all architectures, so we shouldn't have separate copies.
PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch
structure and to accomodate this special need a
__KVM_HAVE_ARCH_VCPU_GET
