qemu-trivial
[Top][All Lists]
Advanced

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

Re: [Qemu-trivial] [Qemu-devel] [PATCH] RFC kvm irqfd: add directly mapp


From: Michael S. Tsirkin
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] RFC kvm irqfd: add directly mapped MSI IRQ support
Date: Mon, 24 Jun 2013 16:41:11 +0300

On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
> Gleb Natapov <address@hidden> writes:
> 
> > On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote:
> >> Gleb Natapov <address@hidden> writes:
> >> 
> >> This should be a per-device mapping, yes.  But I'm not sure that VCPUs
> >> should even see anything.  I don't think a VCPU can generate an MSI
> >> interrupt by writing to this location.
> >> 
> > No, and lower 4k of this space is where APIC is mapped as seen from CPU.
> >> Is there anything that prevents us from using IRQFDs corresponding to
> >> the target of an MSI mapping and get rid of the MSI info in the kernel?
> >> 
> > Again, you assume that x86 has some pin that MSI triggers. This is not
> > the case; address/data is minimum that is needed to inject interrupt
> > there (or moving APIC into userspace, since this is where "translation"
> > is happening).
> 
> An APIC message contains:
> 
> 1) Destination Mode
> 2) Delivery mode
> 3) Level
> 4) Trigger mode
> 5) Vector
> 6) Destination
> 
> Which is more or less what the MSI addr/data pair encodes.
> 
> But we can certainly have a userspace interface to inject such a message
> into the LAPICs.  In fact, this is more or less what KVM_SIGNAL_MSI is
> doing except that it's called MSI and encodes things in an addr/pair.
> 
> Such an interface would also allow for a QEMU implementation of an IO
> APIC while still having the in-kernel LAPIC.
> 
> It would also allow QEMU to do per-device MSI decoding.
> 
> Isn't this more or less what Avi's previous proposal was around changing
> the APIC interfaces to userspace?
> 
> Regards,
> 
> Anthony Liguori

While that's not very elegant, I think we can use the existing
interface for this: just encode things in a fake
"msi message" in the format that kernel expects.

> >
> >> It seems like the only sane way to actually support (2) and (3).
> >> 
> >> Regards,
> >> 
> >> Anthony Liguori
> >
> > --
> >                     Gleb.



reply via email to

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