[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook |
Date: |
Mon, 17 Oct 2011 13:29:08 +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 2011-10-17 13:22, Avi Kivity wrote:
> On 10/17/2011 01:15 PM, Jan Kiszka wrote:
>> On 2011-10-17 12:56, Avi Kivity wrote:
>>> On 10/17/2011 11:27 AM, Jan Kiszka wrote:
>>>> So far we deliver MSI messages by writing them into the target MMIO
>>>> area. This reflects what happens on hardware, but imposes some
>>>> limitations on the emulation when introducing KVM in-kernel irqchip
>>>> models. For those we will need to track the message origin.
>>>
>>> Why do we need to track the message origin? Emulated interrupt remapping?
>>
>> The origin holds the routing cache which we need to track if the message
>> already has a route (and that without searching long lists) and to
>> update that route instead of add another one.
>
> Okay, having read more of the code I understand this better. The
> approach of providing an explicit cache entry, while more intrusive, is
> simpler (at least, without std::unordered_map). However you do need
> destructors for the cache to let the core know that it can't reference
> it anymore.
See my other mail.
>
>
>>
>>>
>>>
>>> Not sure what the gain is from intercepting the msi just before the
>>> stl_phys() vs. in the apic handler.
>>
>> APIC is x86-specific, MSI is not. I think Xen will also want to make use
>> of this hook. I originally though of using it for the KVM in-kernel
>> models as well, but I will now establish a callback at APIC-level
>> (upstream will look differently from qemu-kvm in this regard).
>>
>
> But you still have to handle it the the platform interrupt controller
> (or whatever processes msi messages) since you can still DMA there. So
> you don't get away from doing it there anyway.
Right, but that's the slow path (which is still handled - on x86 via the
MMIO region the APIC still maintains).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- [Qemu-devel] [RFC][PATCH 00/45] qemu-kvm: MSI layer rework for in-kernel irqchip support, Jan Kiszka, 2011/10/17
- [Qemu-devel] [RFC][PATCH 07/45] msi: Generalize msix_supported to msi_supported, Jan Kiszka, 2011/10/17
- [Qemu-devel] [RFC][PATCH 01/45] msi: Guard msi/msix_write_config with msi_present, Jan Kiszka, 2011/10/17
- [Qemu-devel] [RFC][PATCH 15/45] qemu-kvm: Drop unused kvm_del_irq_route, Jan Kiszka, 2011/10/17
- [Qemu-devel] [RFC][PATCH 10/45] msix: Factor out msix_message_from_vector, Jan Kiszka, 2011/10/17
- [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook, Jan Kiszka, 2011/10/17
- Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook, Michael S. Tsirkin, 2011/10/17
- Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook, Avi Kivity, 2011/10/17
- Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook, Michael S. Tsirkin, 2011/10/17
- Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook, Jan Kiszka, 2011/10/18
Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook, Michael S. Tsirkin, 2011/10/17