On Fri, 2013-06-21 at 17:10 -0600, Alex Williamson wrote:
> MSI-X is rather ugly. As you suggest, we trap accesses to the MSI-X
> table. We don't know how many vectors the guest is going to use, so we
> incrementally add them by disabling and re-enabling with a new vector
> count. The host deci
On Sat, 2013-06-22 at 08:21 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2013-06-22 at 00:12 +0200, Alexander Graf wrote:
> > On 21.06.2013, at 23:54, Benjamin Herrenschmidt wrote:
> >
> > > On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote:
> > >> Not sure. We could just declare a "direct
On 21.06.2013, at 23:54, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote:
>> Not sure. We could just declare a "direct virq==irq" mode in which
>> msi.data == virq == irq. No need for any translation then.
>
> Maybe. Beware that MSI data is only 16-bit on
On Sat, 2013-06-22 at 00:12 +0200, Alexander Graf wrote:
> On 21.06.2013, at 23:54, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote:
> >> Not sure. We could just declare a "direct virq==irq" mode in which
> >> msi.data == virq == irq. No need for any tra
On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote:
> Not sure. We could just declare a "direct virq==irq" mode in which
> msi.data == virq == irq. No need for any translation then.
Maybe. Beware that MSI data is only 16-bit on the wire but we may not
care here.
One thing I'm not 100% certai
On 21.06.2013, at 14:10, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-21 at 14:05 +0200, Alexander Graf wrote:
>> Oh, I thought that was obvious. BookE also has in-kernel emulation and
>> also does set kvm_msi_via_irqfd_allowed. The code above is spapr
>> specific and would simply rewrite vali
On Fri, 2013-06-21 at 14:05 +0200, Alexander Graf wrote:
> Oh, I thought that was obvious. BookE also has in-kernel emulation and
> also does set kvm_msi_via_irqfd_allowed. The code above is spapr
> specific and would simply rewrite valid BookE MPIC addresses into
> something broken.
>
> In fact,
On 21.06.2013, at 14:03, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-21 at 12:33 +0200, Alexander Graf wrote:
>>> +int kvm_arch_irqchip_add_msi_route(KVMState *s, MSIMessage msg)
>>> +{
>>> +if (!kvm_msi_via_irqfd_allowed)
>>> +return -1;
>>> +
>>> +msg.address -= spapr->msi_w
On Fri, 2013-06-21 at 12:33 +0200, Alexander Graf wrote:
> > +int kvm_arch_irqchip_add_msi_route(KVMState *s, MSIMessage msg)
> > +{
> > +if (!kvm_msi_via_irqfd_allowed)
> > +return -1;
> > +
> > +msg.address -= spapr->msi_win_addr;
> > +return (msg.address >> 2) + msg.data;
>
On 21.06.2013, at 11:22, Alexey Kardashevskiy wrote:
> At the moment kvm_irqchip_add_msi_route() adds routing entries for every
> MSI IRQ we want to use with IRQFD.
>
> However on PPC64-pSeries no routing is required as QEMU is already doing
> MSIMessage to IRQ converson. When the guest needs to
At the moment kvm_irqchip_add_msi_route() adds routing entries for every
MSI IRQ we want to use with IRQFD.
However on PPC64-pSeries no routing is required as QEMU is already doing
MSIMessage to IRQ converson. When the guest needs to allocate some
MSI vectors, it asks a hypervisor (QEMU) which ret
11 matches
Mail list logo
