On Mon, Jun 24, 2013 at 10:17:41AM -0500, Anthony Liguori wrote:
> Alexander Graf writes:
>
> > On 24.06.2013, at 16:31, Anthony Liguori wrote:
> >
> >> "Michael S. Tsirkin" writes:
> >>
> >>> On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
> Gleb Natapov writes:
>
On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
> Gleb Natapov writes:
>
> > On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote:
> >> Gleb Natapov writes:
> >>
> >> This should be a per-device mapping, yes. But I'm not sure that VCPUs
> >> should even see anything
Alexander Graf writes:
> On 24.06.2013, at 16:31, Anthony Liguori wrote:
>
>> "Michael S. Tsirkin" writes:
>>
>>> On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
Gleb Natapov writes:
Isn't this more or less what Avi's previous proposal was around changing
"Michael S. Tsirkin" writes:
> On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
>> Gleb Natapov writes:
>>
>> 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
On 24.06.2013, at 16:31, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
>> On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
>>> Gleb Natapov writes:
>>>
>>> Isn't this more or less what Avi's previous proposal was around changing
>>> the APIC interfaces to userspace?
On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
> Gleb Natapov writes:
>
> > On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote:
> >> Gleb Natapov writes:
> >>
> >> This should be a per-device mapping, yes. But I'm not sure that VCPUs
> >> should even see anything
Gleb Natapov writes:
> On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote:
>> Gleb Natapov 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 loc
On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote:
> Gleb Natapov writes:
>
> > On Sun, Jun 23, 2013 at 10:06:05AM -0500, Anthony Liguori wrote:
> >> On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
> >> wrote:
> >> > On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
On 24.06.2013, at 14:32, Anthony Liguori wrote:
> Gleb Natapov writes:
>
>> On Sun, Jun 23, 2013 at 10:06:05AM -0500, Anthony Liguori wrote:
>>> On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
>>> wrote:
On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
> On 06/21/2013
Gleb Natapov writes:
> On Sun, Jun 23, 2013 at 10:06:05AM -0500, Anthony Liguori wrote:
>> On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
>> wrote:
>> > On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
>> >> On 06/21/2013 12:34 PM, Alex Williamson wrote:
>> >>
>> >>
>> >> Do not
Alex Williamson writes:
> On Sun, 2013-06-23 at 10:06 -0500, Anthony Liguori wrote:
>> On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
>> wrote:
>> > On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
>> >> On 06/21/2013 12:34 PM, Alex Williamson wrote:
>> >>
>> >>
>> >> Do not fol
On Mon, Jun 24, 2013 at 07:36:25AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-06-23 at 17:07 +0300, Michael S. Tsirkin wrote:
> > Yes I think that's fine really.
> >
> > Basically devices all speak MSIMessage as they should -
> > this is what the PCI spec says.
> > On all normal s
On Sun, Jun 23, 2013 at 10:06:05AM -0500, Anthony Liguori wrote:
> On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
> wrote:
> > On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
> >> On 06/21/2013 12:34 PM, Alex Williamson wrote:
> >>
> >>
> >> Do not follow you, sorry. For x86, is
On Sun, 2013-06-23 at 10:06 -0500, Anthony Liguori wrote:
> On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
> wrote:
> > On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
> >> On 06/21/2013 12:34 PM, Alex Williamson wrote:
> >>
> >>
> >> Do not follow you, sorry. For x86, is it that
On Sun, 2013-06-23 at 17:07 +0300, Michael S. Tsirkin wrote:
> Yes I think that's fine really.
>
> Basically devices all speak MSIMessage as they should -
> this is what the PCI spec says.
> On all normal systems guests also speak MSIMessage so
> the API which uses these makes sense for kv
On Thu, Jun 20, 2013 at 11:46 PM, Alex Williamson
wrote:
> On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
>> On 06/21/2013 12:34 PM, Alex Williamson wrote:
>>
>>
>> Do not follow you, sorry. For x86, is it that MSI routing table which is
>> updated via KVM_SET_GSI_ROUTING in KVM? W
On Sun, Jun 23, 2013 at 9:07 AM, Michael S. Tsirkin wrote:
> On Fri, Jun 21, 2013 at 09:51:20AM +1000, Alexey Kardashevskiy wrote:
>> And kvm_irqchip_add_msi_route does not have any link to a device or a bus
>> so I'll have to walk through all PHBs in system and see if PHB's MSI window
>> is the o
On Fri, Jun 21, 2013 at 09:51:20AM +1000, Alexey Kardashevskiy wrote:
> And kvm_irqchip_add_msi_route does not have any link to a device or a bus
> so I'll have to walk through all PHBs in system and see if PHB's MSI window
> is the one from MSIMessage and convert MSIMessage to virq. Pretty easy an
On 06/21/2013 04:12 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-21 at 00:03 -0600, Alex Williamson wrote:
>> On Fri, 2013-06-21 at 15:12 +1000, Benjamin Herrenschmidt wrote:
>>> On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote:
Maybe you could add a device parameter to kvm_irqc
On Fri, 2013-06-21 at 00:03 -0600, Alex Williamson wrote:
> On Fri, 2013-06-21 at 15:12 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote:
> > > Maybe you could add a device parameter to kvm_irqchip_add_msi_route so
> > > that it can be implemented on
On Fri, 2013-06-21 at 15:12 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote:
> > Maybe you could add a device parameter to kvm_irqchip_add_msi_route so
> > that it can be implemented on POWER without this pci_bus_map_msi
> > interface that seems very
On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote:
> Maybe you could add a device parameter to kvm_irqchip_add_msi_route so
> that it can be implemented on POWER without this pci_bus_map_msi
> interface that seems very unique to POWER. Thanks,
You mean unique to all non-x86 ? :-)
I believ
On Fri, 2013-06-21 at 12:49 +1000, Alexey Kardashevskiy wrote:
> On 06/21/2013 12:34 PM, Alex Williamson wrote:
> > On Fri, 2013-06-21 at 11:56 +1000, Alexey Kardashevskiy wrote:
> >> On 06/21/2013 02:51 AM, Alex Williamson wrote:
> >>> On Fri, 2013-06-21 at 00:08 +1000, Alexey Kardashevskiy wrote:
On 06/21/2013 12:34 PM, Alex Williamson wrote:
> On Fri, 2013-06-21 at 11:56 +1000, Alexey Kardashevskiy wrote:
>> On 06/21/2013 02:51 AM, Alex Williamson wrote:
>>> On Fri, 2013-06-21 at 00:08 +1000, Alexey Kardashevskiy wrote:
At the moment QEMU creates a route for every MSI IRQ.
N
On Fri, 2013-06-21 at 11:56 +1000, Alexey Kardashevskiy wrote:
> On 06/21/2013 02:51 AM, Alex Williamson wrote:
> > On Fri, 2013-06-21 at 00:08 +1000, Alexey Kardashevskiy wrote:
> >> At the moment QEMU creates a route for every MSI IRQ.
> >>
> >> Now we are about to add IRQFD support on PPC64-pser
On 06/21/2013 02:51 AM, Alex Williamson wrote:
> On Fri, 2013-06-21 at 00:08 +1000, Alexey Kardashevskiy wrote:
>> At the moment QEMU creates a route for every MSI IRQ.
>>
>> Now we are about to add IRQFD support on PPC64-pseries platform.
>> pSeries already has in-kernel emulated interrupt control
On 06/21/2013 02:37 AM, Anthony Liguori wrote:
> Alexey Kardashevskiy writes:
>
>> At the moment QEMU creates a route for every MSI IRQ.
>>
>> Now we are about to add IRQFD support on PPC64-pseries platform.
>> pSeries already has in-kernel emulated interrupt controller with
>> 8192 IRQs. Also, p
On Fri, 2013-06-21 at 00:08 +1000, Alexey Kardashevskiy wrote:
> At the moment QEMU creates a route for every MSI IRQ.
>
> Now we are about to add IRQFD support on PPC64-pseries platform.
> pSeries already has in-kernel emulated interrupt controller with
> 8192 IRQs. Also, pSeries PHB already supp
Alexey Kardashevskiy writes:
> At the moment QEMU creates a route for every MSI IRQ.
>
> Now we are about to add IRQFD support on PPC64-pseries platform.
> pSeries already has in-kernel emulated interrupt controller with
> 8192 IRQs. Also, pSeries PHB already supports MSIMessage to IRQ
> mapping
On Fri, Jun 21, 2013 at 12:08:58AM +1000, Alexey Kardashevskiy wrote:
> At the moment QEMU creates a route for every MSI IRQ.
>
> Now we are about to add IRQFD support on PPC64-pseries platform.
> pSeries already has in-kernel emulated interrupt controller with
> 8192 IRQs. Also, pSeries PHB alrea
At the moment QEMU creates a route for every MSI IRQ.
Now we are about to add IRQFD support on PPC64-pseries platform.
pSeries already has in-kernel emulated interrupt controller with
8192 IRQs. Also, pSeries PHB already supports MSIMessage to IRQ
mapping as a part of PAPR requirements for MSI/MSI
31 matches
Mail list logo
