On 05/21/2012 02:31 PM, Jan Kiszka wrote:
> On 2012-05-20 11:45, Avi Kivity wrote:
> > On 05/20/2012 05:42 PM, Michael S. Tsirkin wrote:
> >> On Thu, May 17, 2012 at 10:32:28AM -0300, Jan Kiszka wrote:
> >>> After this series, to only reasons to still use qemu-kvm for production
> >>> purposes will
On 2012-05-20 11:45, Avi Kivity wrote:
> On 05/20/2012 05:42 PM, Michael S. Tsirkin wrote:
>> On Thu, May 17, 2012 at 10:32:28AM -0300, Jan Kiszka wrote:
>>> After this series, to only reasons to still use qemu-kvm for production
>>> purposes will be PCI device assignment
>>
>> Yay!
>>
>> By the wa
On Thu, May 17, 2012 at 10:32:28AM -0300, Jan Kiszka wrote:
> After this series, to only reasons to still use qemu-kvm for production
> purposes will be PCI device assignment
Yay!
By the way, there are probably not many reasons to keep the
assignment code out of qemu.git. It duplicates a ton of
c
On 05/20/2012 05:42 PM, Michael S. Tsirkin wrote:
> On Thu, May 17, 2012 at 10:32:28AM -0300, Jan Kiszka wrote:
> > After this series, to only reasons to still use qemu-kvm for production
> > purposes will be PCI device assignment
>
> Yay!
>
> By the way, there are probably not many reasons to keep
On 05/17/2012 04:32 PM, Jan Kiszka wrote:
> [ changes in v2: rebase over uq/master ]
>
> This series is another major milestone of merging qemu-kvm into
> upstream. It implements the required interfaces and logic to directly
> inject MSI-X interrupts generated by the vhost-net kernel module into
>
[ changes in v2: rebase over uq/master ]
This series is another major milestone of merging qemu-kvm into
upstream. It implements the required interfaces and logic to directly
inject MSI-X interrupts generated by the vhost-net kernel module into
the KVM in-kernel irqchip. This involves
- establish
