On Sat, 2020-10-24 at 11:13 +0100, David Woodhouse wrote:
> OK, thanks. I'll rework Thomas's tree with that first and the other
> changes I'd mentioned in my parts, as well as fixing up that unholy
> chimæra of struct/union in which we set some bitfields from each side
> of the union, test and push
On 24 October 2020 10:13:36 BST, Paolo Bonzini wrote:
>On 24/10/20 10:26, David Woodhouse wrote:
>> I was also hoping Paolo was going to take the patch which just
>defines
>> the KVM_FEATURE_MSI_EXT_DEST_ID bit² ASAP, so that we end up with a
>> second patch³ that *just* wires it up to x86_init
On 24/10/20 10:26, David Woodhouse wrote:
> I was also hoping Paolo was going to take the patch which just defines
> the KVM_FEATURE_MSI_EXT_DEST_ID bit² ASAP, so that we end up with a
> second patch³ that *just* wires it up to x86_init.msi_ext_dest_id() for
> KVM.
>
> ¹ https://git.infradead.org/
On Sat, 2020-10-24 at 09:26 +0100, David Woodhouse wrote:
>
> And now I wish it was just a simple shift instead of an unholy maze of
> overlapping unions of bitfields. But I'll make more coffee and stare at
> it harder...
Hah, it really *was* unions of the bitfields. This boots...
diff --git a/a
On Fri, 2020-10-23 at 23:28 +0200, Thomas Gleixner wrote:
> On Fri, Oct 23 2020 at 11:10, David Woodhouse wrote:
> > On 22 October 2020 22:43:52 BST, Thomas Gleixner wrote:
> > It makes the callers slightly more readable, not having to cast to
> > uint32_t* from the struct.
> >
> > I did ponder
On Fri, Oct 23 2020 at 11:10, David Woodhouse wrote:
> On 22 October 2020 22:43:52 BST, Thomas Gleixner wrote:
> It makes the callers slightly more readable, not having to cast to uint32_t*
> from the struct.
>
> I did ponder defining a new struct with bitfields named along the
> lines of 'msi_ad
On Fri, 2020-10-23 at 00:10 +0200, Thomas Gleixner wrote:
> > -static void mp_setup_entry(struct irq_cfg *cfg, struct
> > mp_chip_data *data,
> > -struct IO_APIC_route_entry *entry)
> > +static void mp_setup_entry(struct irq_data *irq_data, struct
> > mp_chip_data *data)
> >
On 22 October 2020 22:43:52 BST, Thomas Gleixner wrote:
>On Fri, Oct 09 2020 at 11:46, David Woodhouse wrote:
>
>@@ -45,12 +45,11 @@ enum irq_alloc_type {
> };
>
>> +static void mp_swizzle_msi_dest_bits(struct irq_data *irq_data, void
>*_entry)
>> +{
>> +struct msi_msg msg;
>> +u32 *ent
On Thu, Oct 22 2020 at 23:43, Thomas Gleixner wrote:
> On Fri, Oct 09 2020 at 11:46, David Woodhouse wrote:
> Aside of that it works magically because polarity,trigger and mask bit
> have been set up before. But of course a comment about this is
> completely overrated.
Also this part:
> -static v
On Fri, Oct 09 2020 at 11:46, David Woodhouse wrote:
@@ -45,12 +45,11 @@ enum irq_alloc_type {
};
> +static void mp_swizzle_msi_dest_bits(struct irq_data *irq_data, void *_entry)
> +{
> + struct msi_msg msg;
> + u32 *entry = _entry;
Why is this a void * argument and then converting it t
From: David Woodhouse
The I/OAPIC generates an MSI cycle with address/data bits taken from its
Redirection Table Entry in some combination which used to make sense,
but now is just a bunch of bits which get passed through in some
seemingly arbitrary order.
Instead of making IRQ remapping drivers
11 matches
Mail list logo
