On Tue, Oct 13 2020 at 12:51, David Woodhouse wrote:
> With that realisation, I've fixed the comment in my ext_dest_id branch
> to remove all mention of IRQ remapping. It now looks like this:
>
> static int x86_vector_select(struct irq_domain *d, struct irq_fwspec *fwspec,
>
On Tue, 2020-10-13 at 11:53 +0100, David Woodhouse wrote:
> On Tue, 2020-10-13 at 12:46 +0200, Thomas Gleixner wrote:
> > And after becoming more awake, that wont work anyway because there is
> > more than one IR domain, so there is no way to return an error "You
> > forgot to register" obviously.
On Tue, 2020-10-13 at 12:46 +0200, Thomas Gleixner wrote:
> And after becoming more awake, that wont work anyway because there is
> more than one IR domain, so there is no way to return an error "You
> forgot to register" obviously.
>
> But the APIC id (32768) valid check is also broken because
On Tue, Oct 13 2020 at 11:28, Thomas Gleixner wrote:
> On Tue, Oct 13 2020 at 08:52, David Woodhouse wrote:
>> On Tue, 2020-10-13 at 00:13 +0200, Thomas Gleixner wrote:
>> + dom = irq_find_matching_fwspec(fwspec, DOMAIN_BUS_IR);
>> + if (dom)
>> + return IS_ERR(dom) ?
On Tue, 2020-10-13 at 11:28 +0200, Thomas Gleixner wrote:
> On Tue, Oct 13 2020 at 08:52, David Woodhouse wrote:
> > On Tue, 2020-10-13 at 00:13 +0200, Thomas Gleixner wrote:
> > + dom = irq_find_matching_fwspec(fwspec, DOMAIN_BUS_IR);
> > + if (dom)
> > + return
On Tue, Oct 13 2020 at 08:52, David Woodhouse wrote:
> On Tue, 2020-10-13 at 00:13 +0200, Thomas Gleixner wrote:
> + dom = irq_find_matching_fwspec(fwspec, DOMAIN_BUS_IR);
> + if (dom)
> + return IS_ERR(dom) ? NULL : dom;
> +
> + return x86_vector_domain;
> +}
>
>
On Tue, 2020-10-13 at 00:13 +0200, Thomas Gleixner wrote:
> On Mon, Oct 12 2020 at 21:20, David Woodhouse wrote:
> > On Mon, 2020-10-12 at 20:38 +0200, Thomas Gleixner wrote:
> > > Nasty, but way better than what we have now.
> >
> > Want me to send that out in email or is the git tree enough
On Mon, Oct 12 2020 at 21:20, David Woodhouse wrote:
> On Mon, 2020-10-12 at 20:38 +0200, Thomas Gleixner wrote:
>> Nasty, but way better than what we have now.
>
> Want me to send that out in email or is the git tree enough for now?
>
> I've cleaned it up a little and fixed a bug in the I/OAPIC
On Mon, 2020-10-12 at 20:38 +0200, Thomas Gleixner wrote:
> On Mon, Oct 12 2020 at 17:06, David Woodhouse wrote:
> > On Mon, 2020-10-12 at 11:33 +0200, Thomas Gleixner wrote:
> > > You might want to look into using irq_find_matching_fwspec()
> > > instead for
> > > both HPET and IOAPIC. That needs
On Mon, Oct 12 2020 at 17:06, David Woodhouse wrote:
> On Mon, 2020-10-12 at 11:33 +0200, Thomas Gleixner wrote:
>> You might want to look into using irq_find_matching_fwspec() instead for
>> both HPET and IOAPIC. That needs a select() callback implemented in the
>> remapping domains.
>
> That
On Mon, 2020-10-12 at 11:33 +0200, Thomas Gleixner wrote:
> On Sun, Oct 11 2020 at 22:15, David Woodhouse wrote:
> > On 11 October 2020 18:12:08 BST, Thomas Gleixner wrote:
> > > On Sat, Oct 10 2020 at 12:58, David Woodhouse wrote:
> > > > On 10 October 2020 12:44:10 BST, Thomas Gleixner
> > >
On Sun, Oct 11 2020 at 22:15, David Woodhouse wrote:
> On 11 October 2020 18:12:08 BST, Thomas Gleixner wrote:
>> On Sat, Oct 10 2020 at 12:58, David Woodhouse wrote:
>>> On 10 October 2020 12:44:10 BST, Thomas Gleixner
>> wrote:
>>> Yeah. There's some muttering to be done for HPET about whether
On 11 October 2020 18:12:08 BST, Thomas Gleixner wrote:
>On Sat, Oct 10 2020 at 12:58, David Woodhouse wrote:
>> On 10 October 2020 12:44:10 BST, Thomas Gleixner
>wrote:
>>>On Sat, Oct 10 2020 at 11:06, David Woodhouse wrote:
>
The IRQ remapping drivers already plug into the device-add
On Sat, Oct 10 2020 at 12:58, David Woodhouse wrote:
> On 10 October 2020 12:44:10 BST, Thomas Gleixner wrote:
>>On Sat, Oct 10 2020 at 11:06, David Woodhouse wrote:
>>> The IRQ remapping drivers already plug into the device-add notifier
>>> and can fill in the appropriate MSI domain just like
On Sat, Oct 10 2020 at 11:06, David Woodhouse wrote:
> On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote:
>> On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
>> For the next submission, can you please
>>
>> - pick up the -ENODEV changes for HPET/IOAPIC which I posted earlier
>
> I
On 10 October 2020 12:44:10 BST, Thomas Gleixner wrote:
>On Sat, Oct 10 2020 at 11:06, David Woodhouse wrote:
>> On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote:
>>> On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
>>> For the next submission, can you please
>>>
>>> - pick up
On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote:
> On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
> > On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
> > > >
> > > > (We'd want the x86_vector_domain to actually have an MSI compose
> > > > function in the !CONFIG_PCI_MSI
On 9 October 2020 00:27:06 BST, Thomas Gleixner wrote:
>On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
>> On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
>>> >
>>> > (We'd want the x86_vector_domain to actually have an MSI compose
>>> > function in the !CONFIG_PCI_MSI case if
On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote:
> On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
>> >
>> > (We'd want the x86_vector_domain to actually have an MSI compose
>> > function in the !CONFIG_PCI_MSI case if we did this, of course.)
>>
>> The compose function and the
On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote:
> On Thu, Oct 08 2020 at 17:08, David Woodhouse wrote:
> > On Thu, 2020-10-08 at 13:55 +0100, David Woodhouse wrote:
> >
> > (We'd want the x86_vector_domain to actually have an MSI compose
> > function in the !CONFIG_PCI_MSI case if we
On Thu, Oct 08 2020 at 17:08, David Woodhouse wrote:
> On Thu, 2020-10-08 at 13:55 +0100, David Woodhouse wrote:
>
> (We'd want the x86_vector_domain to actually have an MSI compose
> function in the !CONFIG_PCI_MSI case if we did this, of course.)
The compose function and the vector domain
On Thu, 2020-10-08 at 13:55 +0100, David Woodhouse wrote:
>
> In fact I'm really tempted to make Linux's io_apic.c just use
> irq_chip_compose_msi_msg() and swizzle the bits out of the message
> identically for IR and non-IR alike (modulo the pin hack), and delete
> the IR_IO_APIC_route_entry
On Thu, 2020-10-08 at 14:05 +0200, Thomas Gleixner wrote:
> Why MSI_EXT_DEST_ID? It's enabling that for MSI and IO/APIC. The
> underlying mechanism might be the same, but APIC_EXT_DEST_ID is more
> general and then you might also make the explanation of that bit
> match the changelog.
It's
On Wed, Oct 07 2020 at 13:20, David Woodhouse wrote:
> From: David Woodhouse
>
> This allows the host to indicate that IOAPIC and MSI emulation supports
> 15-bit destination IDs, allowing up to 32768 CPUs without interrupt
> remapping.
>
> cf. https://patchwork.kernel.org/patch/11816693/ for qemu
From: David Woodhouse
This allows the host to indicate that IOAPIC and MSI emulation supports
15-bit destination IDs, allowing up to 32768 CPUs without interrupt
remapping.
cf. https://patchwork.kernel.org/patch/11816693/ for qemu
Signed-off-by: David Woodhouse
Acked-by: Paolo Bonzini
---
25 matches
Mail list logo
