[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
Date: Fri, 01 Jun 2012 17:59:04 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2012-06-01 17:30, Michael S. Tsirkin wrote:
> On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote:
>> On 2012-06-01 16:34, Michael S. Tsirkin wrote:
>>> On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote:
>>>> On 2012-06-01 15:27, Michael S. Tsirkin wrote:
>>>>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote:
>>>>>> On 2012-05-30 22:31, Michael S. Tsirkin wrote:
>>>>>>>>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use
>>>>>>>>> irq_count instead of the pic_levels bitmap.
>>>>>>>> Just that this affects generic PCI code, not only PIIX-specific things.
>>>>>>> Yes but it's not a problem - pci_bus_irqs sets the map function and 
>>>>>>> nirqs.
>>>>>>>> And that we need to save/restore some irq_count field according to the
>>>>>>>> old semantics.
>>>>>>> Well, it's a bug: this is redundant info we should not have exposed it.
>>>>>>> Anyway, let's make the rest work properly and cleanly first, add a FIXME
>>>>>>> for now, then we'll find a hack making it work for migration.
>>>>>> It remains non-trivial: I got your patch working (a minor init issue),
>>>>>> but yet without changing the number of IRQs for PIIX3, so keeping the
>>>>>> irq_count semantics for this host bridge.
>>>>>> Now I'm facing three possibilities of how to proceed:
>>>>> They all look OK I think :) Some comments below.
>>>>>> 1. Give up on the (currently broken) feature to write a vmstate for
>>>>>>    older QEMU versions.
>>>>>>    This will allow to declare the irq_count field in vmstate_pcibus
>>>>>>    unused, and we would have to restore it on vmload step-wise via the
>>>>>>    PCI devices. It would also allow to change its semantics for PIIX3,
>>>>>>    mapping directly to PIC IRQs.
>>>>> I think that's okay too simply because these things are usually
>>>>> easy to fix after the fact when the rest of the issues are addressed.
>>>> Don't get what you mean with "fixed". If we fix the vmstate generation
>>>> in making it backward-compatible again, we enter option 2. Option 1 is
>>>> explicitly about giving this up.
>>> What I really mean is I think I see how 2 can be added without much
>>> pain. So let's focus on 1 for now and worst case we break migration.
>> I'd like to avoid planing for this worst case as long as there are also
>> statements [1] that this is not acceptable for QEMU in general. It
>> doesn't to create a beautiful architecture initially about which we
>> already know that it will become more complex than alternatives in the end.
> 1 and 2 are same really except 2 adds a hack for compatibility, no?

Yes, 2 would allow us to maintain irq_count in different ways as well,
specifically using it calculate shared output IRQ lines before reporting
them to the PIC generically. This approach has both a charming and an
ugly face.


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

reply via email to

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