Anthony Liguori wrote:
> Avi Kivity wrote:
>>
>> Please separate the code movement and changes into separate patches.
>
> I'm not sure there's a great way to do this that preserves
> bisectability and results in meaningful history. I could leave the
> #ifdef's in i8254-kvm.c and then have a seco
Avi Kivity wrote:
>
> Please separate the code movement and changes into separate patches.
I'm not sure there's a great way to do this that preserves bisectability
and results in meaningful history. I could leave the #ifdef's in
i8254-kvm.c and then have a second patch that removes them. That
Anthony Liguori wrote:
> Part of the feedback we received from Fabrice about the KVM patches for QEMU
> is that we should create a separate device for the in-kernel APIC to avoid
> having lots of if (kvm_enabled()) within the APIC code that were difficult to
> understand why there were needed.
>
>
Fixes issues with pit for PPC.
Acked-by: Jerone Young <[EMAIL PROTECTED]>
On Mon, 2008-03-24 at 13:54 -0500, Anthony Liguori wrote:
> Part of the feedback we received from Fabrice about the KVM patches for QEMU
> is that we should create a separate device for the in-kernel APIC to avoid
> having
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> Hollis Blanchard wrote:
>>
>>> This patch solves annoying qemu build breakage hitting PowerPC around
>>> struct kvm_pit_state, so that's another vote in favor...
>>>
>>>
>> I have an updated version of the patch but it's breaking the
Anthony Liguori wrote:
> Hollis Blanchard wrote:
>> This patch solves annoying qemu build breakage hitting PowerPC around
>> struct kvm_pit_state, so that's another vote in favor...
>>
>
> I have an updated version of the patch but it's breaking the build b/c
> something fouled up right now wit
Hollis Blanchard wrote:
This patch solves annoying qemu build breakage hitting PowerPC around
struct kvm_pit_state, so that's another vote in favor...
I have an updated version of the patch but it's breaking the build b/c
something fouled up right now with configure. libkvm pulls in
linux
On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
> Part of the feedback we received from Fabrice about the KVM patches
> for QEMU
> is that we should create a separate device for the in-kernel APIC to
> avoid
> having lots of if (kvm_enabled()) within the APIC code that were
> difficult to
Yang, Sheng wrote:
> And we got two choices in userspace: one ioctl to reset all kvm devices, or
> one ioctl for each device. For we are separating in kernel device into
> separate devices, seems the later is more proper. But would it bring other
> troubles like inconsistent state for smp?
>
>
Anthony Liguori wrote:
> Part of the feedback we received from Fabrice about the KVM patches for QEMU
> is that we should create a separate device for the in-kernel APIC to avoid
> having lots of if (kvm_enabled()) within the APIC code that were difficult to
> understand why there were needed.
>
>
On Thursday 13 March 2008 06:13:48 Anthony Liguori wrote:
> Dor Laor wrote:
> > On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
> >> Part of the feedback we received from Fabrice about the KVM patches
> >> for QEMU
> >> is that we should create a separate device for the in-kernel APIC to
Dor Laor wrote:
> On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
>
>> Part of the feedback we received from Fabrice about the KVM patches
>> for QEMU
>> is that we should create a separate device for the in-kernel APIC to
>> avoid
>> having lots of if (kvm_enabled()) within the APIC c
On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
> Part of the feedback we received from Fabrice about the KVM patches
> for QEMU
> is that we should create a separate device for the in-kernel APIC to
> avoid
> having lots of if (kvm_enabled()) within the APIC code that were
> difficult t
13 matches
Mail list logo
