On 2011-04-27 14:12, Avi Kivity wrote:
> On 04/27/2011 02:21 PM, Jan Kiszka wrote:
>> On 2011-04-27 11:14, Avi Kivity wrote:
>>> On 04/27/2011 12:06 PM, Jan Kiszka wrote:
>>>>>
>>>>> We can simply drop all route entries that are used exclusively in qemu
>>>>> (i.e. not bound to an irqfd) and let the cache rebuild itself.
>>>>
>>>> When should they be dropped?
>>>
>>> Whenever we need to allocate a new routing entry, but cannot because it
>>> is full.
>>>
>>> def kvm_send_msi_message(addr, val):
>>> gsi = route_cache.get((addr, val), None)
>>> if gsi is None:
>>> expire_volatile_route_cache_entries_if_full()
>>> gsi = alloc_gsi_cache_entry()
>>> route_cache[(addr, val)] = gsi
>>> update_route_cache()
>>> kvm_irq_line(gsi, 1)
>>> kvm_irq_line(gsi, 0)
>>>
>>> The code would have to be in kvm.c, where it can track whether an entry
>>> is volatile or persistent.
>>
>> Yeah, what I forgot is the other side of this caching: Looking up the
>> GSI from the MSI addr/data tuple. That's more complex than the current
>> O(1) way via device.msitable[vector]. Well, we could use some hash
>> table. But is it worth it? IMHO only if we could radically simplify the
>> PCI device hooking as well (HPET is negligible compared to that). But
>> I'm not yet sure if we can given what vhost needs.
>
> A hash table is indeed overcomplicated for this.
>
> How about a replacement for stl_phys() for the MSI case:
>
> - stl_phys(timer->fsb >> 32, timer->fsb & 0xffffffff);
> + msi_stl_phys(timer->fsb >> 32, timer->fsb & 0xffffffff,
> &timer->msi_cache);
>
> msi_stl_phys(target_phys_addr_t addr, uint32_t data, MSICache *cache)
> {
> if (kvm_msi_enabled() && addr & MSI_ADDR_MASK == msi_base_addr) {
> if (cache->addr != addr || cache->data != data) {
> kvm_update_msi_cache(cache, addr, data);
> }
> kvm_irq_line(cache->gsi, 1);
> kvm_irq_line(cache->gsi, 0);
> return;
> }
> stl_phys(addr, data);
> }
I was planning for a MSI short-path anyway. Also for TCG, it's pointless
to go through lengthy stl_phys if we know it's supposed to be an MSI
message.
>
> This bit of code would need to be updated for IOMMU and interrupt
> remapping,
Quite a bit updates required for that anyway.
> but at least it means that devices don't need significant
> change for kvm support. We could also allocate a single gsi for use in
> hw/apic.c so hacks like using DMA to generate an MSI will work (will be
> slow, though).
Needs some thoughts, maybe it will work. Though, it's not yet clear to
me if we can drop the kvm hooks from msi/msix.c and still support
vhost/dev-assignment this way. Just to keep hpet.c cleaner, I don't
think it's worth the effort.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
