qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 4/4] kvm: i386: Add classic PCI device assign


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v3 4/4] kvm: i386: Add classic PCI device assignment
Date: Thu, 06 Sep 2012 18:16:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-09-06 18:06, Andreas Färber wrote:
> Am 06.09.2012 10:44, schrieb Jan Kiszka:
>> On 2012-08-30 20:30, Jan Kiszka wrote:
>>> This adds PCI device assignment for i386 targets using the classic KVM
>>> interfaces. This version is 100% identical to what is being maintained
>>> in qemu-kvm for several years and is supported by libvirt as well. It is
>>> expected to remain relevant for another couple of years until kernels
>>> without full-features and performance-wise equivalent VFIO support are
>>> obsolete.
>>>
>>> A refactoring to-do that should be done in-tree is to model MSI and
>>> MSI-X support via the generic PCI layer, similar to what VFIO is already
>>> doing for MSI-X. This should improve the correctness and clean up the
>>> code from duplicate logic.
>>>
>>> Signed-off-by: Jan Kiszka <address@hidden>
>>> ---
>>>
>>> Changes in v3:
>>>  - addressed comment by Peter (changed device name to kvm-pci-assign +
>>>    alias)
>>>  - addressed (most) comments by Michael
>>>  - fixed INT pin regression
>>
>> Does someone _disagree_ that there are no open (and reasonably solvable)
>> issues and that this can now be merged through uq/master?
> 
> My implicit suggestion was to add a notice that new patch contributions
> to the file from date yyyy-mm-dd on would be declared GPLv2+, as Paolo
> has done elsewhere. That would limit the amount of people to ask for a
> potential relicensing attempt.

Sorry, someone else will have to add this.

Personally I think it is pointless to worry about it here anyway as
hunting down all contributors and getting them to agree on a GPLv2+ will
take longer than the expected lifetime of this component.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]