| Message ID | 20230326052039.33717-3-minhquangbui99@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/5] i386/tcg: implement x2APIC registers MSR access | expand |
On Sun, 2023-03-26 at 12:20 +0700, Bui Quang Minh wrote: > This commit extends the APIC ID to 32-bit long and remove the 255 max APIC > ID limit in userspace APIC. The array that manages local APICs is now > dynamically allocated based on the max APIC ID of created x86 machine. > Also, new x2APIC IPI destination determination scheme, self IPI and x2APIC > mode register access are supported. > > Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> > --- > hw/i386/x86.c | 8 +- > hw/intc/apic.c | 229 +++++++++++++++++++++++--------- > hw/intc/apic_common.c | 8 +- > include/hw/i386/apic.h | 3 +- > include/hw/i386/apic_internal.h | 2 +- > 5 files changed, 184 insertions(+), 66 deletions(-) > > diff --git a/hw/i386/x86.c b/hw/i386/x86.c > index a88a126123..fa9b15190d 100644 > --- a/hw/i386/x86.c > +++ b/hw/i386/x86.c > @@ -132,11 +132,11 @@ void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version) > * Can we support APIC ID 255 or higher? > * > * Under Xen: yes. > - * With userspace emulated lapic: no > + * With userspace emulated lapic: yes. Are you making this unconditional? It shall not be possible to emulate a CPU *without* X2APIC? > * With KVM's in-kernel lapic: only if X2APIC API is enabled. > */ > if (x86ms->apic_id_limit > 255 && !xen_enabled() && > - (!kvm_irqchip_in_kernel() || !kvm_enable_x2apic())) { > + kvm_irqchip_in_kernel() && !kvm_enable_x2apic()) { > error_report("current -smp configuration requires kernel " > "irqchip and X2APIC API support."); > exit(EXIT_FAILURE); ... > @@ -276,16 +288,17 @@ static void apic_bus_deliver(const uint32_t *deliver_bitmask, > apic_set_irq(apic_iter, vector_num, trigger_mode) ); > } > > -void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, uint8_t delivery_mode, > +void apic_deliver_irq(uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, > uint8_t vector_num, uint8_t trigger_mode) We can make this 'static' while we're here. It isn't actually called from anywhere else, is it? > { > - uint32_t deliver_bitmask[MAX_APIC_WORDS]; > + uint32_t *deliver_bitmask = g_malloc(max_apic_words * sizeof(uint32_t)); > > trace_apic_deliver_irq(dest, dest_mode, delivery_mode, vector_num, > trigger_mode); > > apic_get_delivery_bitmask(deliver_bitmask, dest, dest_mode); > apic_bus_deliver(deliver_bitmask, delivery_mode, vector_num, trigger_mode); > + g_free(deliver_bitmask); > } > > bool is_x2apic_mode(DeviceState *dev) ... > > static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > - uint8_t dest, uint8_t dest_mode) > + uint32_t dest, uint8_t dest_mode) > { > APICCommonState *apic_iter; > int i; > > + memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); > + > + /* x2APIC broadcast id for both physical and logical (cluster) mode */ > + if (dest == 0xffffffff) { > + apic_get_broadcast_bitmask(deliver_bitmask, true); > + return; > + } > + > if (dest_mode == 0) { Might be nice to have a constant for DEST_MODE_PHYS vs. DEST_MODE_LOGICAL to make this clearer? > + apic_find_dest(deliver_bitmask, dest); > + /* Broadcast to xAPIC mode apics */ > if (dest == 0xff) { > - memset(deliver_bitmask, 0xff, MAX_APIC_WORDS * sizeof(uint32_t)); > - } else { > - int idx = apic_find_dest(dest); > - memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); > - if (idx >= 0) > - apic_set_bit(deliver_bitmask, idx); > + apic_get_broadcast_bitmask(deliver_bitmask, false); Hrm... aren't you still interpreting destination 0x000000FF as broadcast even for X2APIC mode? Or am I misreading this? > } > } else { > /* XXX: cluster mode */ > ... > @@ -366,7 +370,7 @@ static const VMStateDescription vmstate_apic_common = { > VMSTATE_UINT8(arb_id, APICCommonState), > VMSTATE_UINT8(tpr, APICCommonState), > VMSTATE_UINT32(spurious_vec, APICCommonState), > - VMSTATE_UINT8(log_dest, APICCommonState), > + VMSTATE_UINT32(log_dest, APICCommonState), > VMSTATE_UINT8(dest_mode, APICCommonState), > VMSTATE_UINT32_ARRAY(isr, APICCommonState, 8), > VMSTATE_UINT32_ARRAY(tmr, APICCommonState, 8), Hm, doesn't this need to be added in a separate subsection, much as ide_drive/pio_state in the example in docs/devel/migration.rst? Or did I *not* need to do that in commit ecb0e98b4 (unrelated to x2apic, but similar addition of state)? Can you confirm that you've tested the behaviour when migrating back from this to an older QEMU, both for a guest *with* X2APIC enabled (which should fail gracefully), and a guest without X2APIC (which should work). > diff --git a/include/hw/i386/apic.h b/include/hw/i386/apic.h > index 2cebeb4faf..d938bfa8e0 100644 > --- a/include/hw/i386/apic.h > +++ b/include/hw/i386/apic.h > @@ -3,7 +3,8 @@ > > > /* apic.c */ > -void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, uint8_t delivery_mode, > +void apic_set_max_apic_id(uint32_t max_apic_id); > +void apic_deliver_irq(uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, > uint8_t vector_num, uint8_t trigger_mode); Making it static means this can be removed, of course.
On 3/27/23 18:04, David Woodhouse wrote: > On Sun, 2023-03-26 at 12:20 +0700, Bui Quang Minh wrote: >> This commit extends the APIC ID to 32-bit long and remove the 255 max APIC >> ID limit in userspace APIC. The array that manages local APICs is now >> dynamically allocated based on the max APIC ID of created x86 machine. >> Also, new x2APIC IPI destination determination scheme, self IPI and x2APIC >> mode register access are supported. >> >> Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> >> --- >> hw/i386/x86.c | 8 +- >> hw/intc/apic.c | 229 +++++++++++++++++++++++--------- >> hw/intc/apic_common.c | 8 +- >> include/hw/i386/apic.h | 3 +- >> include/hw/i386/apic_internal.h | 2 +- >> 5 files changed, 184 insertions(+), 66 deletions(-) >> >> diff --git a/hw/i386/x86.c b/hw/i386/x86.c >> index a88a126123..fa9b15190d 100644 >> --- a/hw/i386/x86.c >> +++ b/hw/i386/x86.c >> @@ -132,11 +132,11 @@ void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version) >> * Can we support APIC ID 255 or higher? >> * >> * Under Xen: yes. >> - * With userspace emulated lapic: no >> + * With userspace emulated lapic: yes. > > Are you making this unconditional? It shall not be possible to emulate > a CPU *without* X2APIC? You are right, this should report error when APIC ID is higher than 255 and x2APIC is not supported by the CPU. > >> * With KVM's in-kernel lapic: only if X2APIC API is enabled. >> */ >> if (x86ms->apic_id_limit > 255 && !xen_enabled() && >> - (!kvm_irqchip_in_kernel() || !kvm_enable_x2apic())) { >> + kvm_irqchip_in_kernel() && !kvm_enable_x2apic()) { >> error_report("current -smp configuration requires kernel " >> "irqchip and X2APIC API support."); >> exit(EXIT_FAILURE); > ... >> @@ -276,16 +288,17 @@ static void apic_bus_deliver(const uint32_t *deliver_bitmask, >> apic_set_irq(apic_iter, vector_num, trigger_mode) ); >> } >> >> -void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, uint8_t delivery_mode, >> +void apic_deliver_irq(uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, >> uint8_t vector_num, uint8_t trigger_mode) > > We can make this 'static' while we're here. It isn't actually called > from anywhere else, is it? I'll fix it in the next version. >> >> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, >> - uint8_t dest, uint8_t dest_mode) >> + uint32_t dest, uint8_t dest_mode) >> { >> APICCommonState *apic_iter; >> int i; >> >> + memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); >> + >> + /* x2APIC broadcast id for both physical and logical (cluster) mode */ >> + if (dest == 0xffffffff) { >> + apic_get_broadcast_bitmask(deliver_bitmask, true); >> + return; >> + } >> + >> if (dest_mode == 0) { > > Might be nice to have a constant for DEST_MODE_PHYS vs. > DEST_MODE_LOGICAL to make this clearer? I'll fix it in the next version. >> + apic_find_dest(deliver_bitmask, dest); >> + /* Broadcast to xAPIC mode apics */ >> if (dest == 0xff) { >> - memset(deliver_bitmask, 0xff, MAX_APIC_WORDS * sizeof(uint32_t)); >> - } else { >> - int idx = apic_find_dest(dest); >> - memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); >> - if (idx >= 0) >> - apic_set_bit(deliver_bitmask, idx); >> + apic_get_broadcast_bitmask(deliver_bitmask, false); > > > Hrm... aren't you still interpreting destination 0x000000FF as > broadcast even for X2APIC mode? Or am I misreading this? In case the destination is 0xFF, the IPI will be delivered to CPU has APIC ID 0xFF if it is in x2APIC mode, and it will be delivered to all CPUs that are in xAPIC mode. In case the destination is 0xFFFFFFFF, the IPI is delivered to all CPUs that are in x2APIC mode. I've created apic_get_broadcast_bitmask function and changed the apic_find_dest to implement that logic. >> @@ -366,7 +370,7 @@ static const VMStateDescription vmstate_apic_common = { >> VMSTATE_UINT8(arb_id, APICCommonState), >> VMSTATE_UINT8(tpr, APICCommonState), >> VMSTATE_UINT32(spurious_vec, APICCommonState), >> - VMSTATE_UINT8(log_dest, APICCommonState), >> + VMSTATE_UINT32(log_dest, APICCommonState), >> VMSTATE_UINT8(dest_mode, APICCommonState), >> VMSTATE_UINT32_ARRAY(isr, APICCommonState, 8), >> VMSTATE_UINT32_ARRAY(tmr, APICCommonState, 8), > > > Hm, doesn't this need to be added in a separate subsection, much as > ide_drive/pio_state in the example in docs/devel/migration.rst? Or did > I *not* need to do that in commit ecb0e98b4 (unrelated to x2apic, but > similar addition of state)? > > Can you confirm that you've tested the behaviour when migrating back > from this to an older QEMU, both for a guest *with* X2APIC enabled > (which should fail gracefully), and a guest without X2APIC (which > should work). Oh, thank you for pointing out, I actually don't understand the use of vmstate before, I'll look at the document more and fix it. >> diff --git a/include/hw/i386/apic.h b/include/hw/i386/apic.h >> index 2cebeb4faf..d938bfa8e0 100644 >> --- a/include/hw/i386/apic.h >> +++ b/include/hw/i386/apic.h >> @@ -3,7 +3,8 @@ >> >> >> /* apic.c */ >> -void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, uint8_t delivery_mode, >> +void apic_set_max_apic_id(uint32_t max_apic_id); >> +void apic_deliver_irq(uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, >> uint8_t vector_num, uint8_t trigger_mode); > > Making it static means this can be removed, of course. I'll fix it in next version. Thanks, Quang Minh.
On Mon, 2023-03-27 at 22:33 +0700, Bui Quang Minh wrote: > > > > + memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); > > > + > > > + /* x2APIC broadcast id for both physical and logical (cluster) mode */ > > > + if (dest == 0xffffffff) { > > > + apic_get_broadcast_bitmask(deliver_bitmask, true); > > > + return; > > > + } > > > + > > > if (dest_mode == 0) { > > > > Might be nice to have a constant for DEST_MODE_PHYS vs. > > DEST_MODE_LOGICAL to make this clearer? > > I'll fix it in the next version. > > > > + apic_find_dest(deliver_bitmask, dest); > > > + /* Broadcast to xAPIC mode apics */ > > > if (dest == 0xff) { > > > - memset(deliver_bitmask, 0xff, MAX_APIC_WORDS * sizeof(uint32_t)); > > > - } else { > > > - int idx = apic_find_dest(dest); > > > - memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); > > > - if (idx >= 0) > > > - apic_set_bit(deliver_bitmask, idx); > > > + apic_get_broadcast_bitmask(deliver_bitmask, false); > > > > > > Hrm... aren't you still interpreting destination 0x000000FF as > > broadcast even for X2APIC mode? Or am I misreading this? > > In case the destination is 0xFF, the IPI will be delivered to CPU has > APIC ID 0xFF if it is in x2APIC mode, and it will be delivered to all > CPUs that are in xAPIC mode. In case the destination is 0xFFFFFFFF, the > IPI is delivered to all CPUs that are in x2APIC mode. I've created > apic_get_broadcast_bitmask function and changed the apic_find_dest to > implement that logic. Maybe I'm misreading the patch, but to me it looks that if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in x2apic mode? So delivering to the APIC with physical ID 255 will be misinterpreted as a broadcast?
On 3/27/23 22:37, David Woodhouse wrote: > On Mon, 2023-03-27 at 22:33 +0700, Bui Quang Minh wrote: >> >>>> + memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); >>>> + >>>> + /* x2APIC broadcast id for both physical and logical (cluster) mode */ >>>> + if (dest == 0xffffffff) { >>>> + apic_get_broadcast_bitmask(deliver_bitmask, true); >>>> + return; >>>> + } >>>> + >>>> if (dest_mode == 0) { >>> >>> Might be nice to have a constant for DEST_MODE_PHYS vs. >>> DEST_MODE_LOGICAL to make this clearer? >> >> I'll fix it in the next version. >> >>>> + apic_find_dest(deliver_bitmask, dest); >>>> + /* Broadcast to xAPIC mode apics */ >>>> if (dest == 0xff) { >>>> - memset(deliver_bitmask, 0xff, MAX_APIC_WORDS * sizeof(uint32_t)); >>>> - } else { >>>> - int idx = apic_find_dest(dest); >>>> - memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); >>>> - if (idx >= 0) >>>> - apic_set_bit(deliver_bitmask, idx); >>>> + apic_get_broadcast_bitmask(deliver_bitmask, false); >>> >>> >>> Hrm... aren't you still interpreting destination 0x000000FF as >>> broadcast even for X2APIC mode? Or am I misreading this? >> >> In case the destination is 0xFF, the IPI will be delivered to CPU has >> APIC ID 0xFF if it is in x2APIC mode, and it will be delivered to all >> CPUs that are in xAPIC mode. In case the destination is 0xFFFFFFFF, the >> IPI is delivered to all CPUs that are in x2APIC mode. I've created >> apic_get_broadcast_bitmask function and changed the apic_find_dest to >> implement that logic. > > Maybe I'm misreading the patch, but to me it looks that > if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in > x2apic mode? So delivering to the APIC with physical ID 255 will be > misinterpreted as a broadcast? In case dest == 0xff the second argument to apic_get_broadcast_bitmask is set to false which means this is xAPIC broadcast static void apic_get_broadcast_bitmask(uint32_t *deliver_bitmask, bool is_x2apic_broadcast) { int i; APICCommonState *apic_iter; for (i = 0; i < max_apics; i++) { apic_iter = local_apics[i]; if (apic_iter) { bool apic_in_x2apic = is_x2apic_mode(&apic_iter->parent_obj); if (is_x2apic_broadcast && apic_in_x2apic) { apic_set_bit(deliver_bitmask, i); } else if (!is_x2apic_broadcast && !apic_in_x2apic) { apic_set_bit(deliver_bitmask, i); } } } } In apic_get_broadcast_bitmask, because is_x2apic_broadcast == false, the delivery bit set only if that apic_in_x2apic == false (that CPU is in xAPIC mode)
On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: > > > Maybe I'm misreading the patch, but to me it looks that > > if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in > > x2apic mode? So delivering to the APIC with physical ID 255 will be > > misinterpreted as a broadcast? > > In case dest == 0xff the second argument to apic_get_broadcast_bitmask > is set to false which means this is xAPIC broadcast Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. I think you want (although you don't have 'dev') something like this: static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, uint32_t dest, uint8_t dest_mode) { APICCommonState *apic_iter; int i; memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); /* x2APIC broadcast id for both physical and logical (cluster) mode */ if (dest == 0xffffffff) { apic_get_broadcast_bitmask(deliver_bitmask, true); return; } if (dest_mode == 0) { apic_find_dest(deliver_bitmask, dest); /* Broadcast to xAPIC mode apics */ - if (dest == 0xff) { + if (dest == 0xff && is_x2apic_mode(dev)) { apic_get_broadcast_bitmask(deliver_bitmask, false); } } else {
On 3/27/23 23:22, David Woodhouse wrote: > On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: >> >>> Maybe I'm misreading the patch, but to me it looks that >>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in >>> x2apic mode? So delivering to the APIC with physical ID 255 will be >>> misinterpreted as a broadcast? >> >> In case dest == 0xff the second argument to apic_get_broadcast_bitmask >> is set to false which means this is xAPIC broadcast > > Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. > > I think you want (although you don't have 'dev') something like this: > > > static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > uint32_t dest, uint8_t dest_mode) > { > APICCommonState *apic_iter; > int i; > > memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); > > /* x2APIC broadcast id for both physical and logical (cluster) mode */ > if (dest == 0xffffffff) { > apic_get_broadcast_bitmask(deliver_bitmask, true); > return; > } > > if (dest_mode == 0) { > apic_find_dest(deliver_bitmask, dest); > /* Broadcast to xAPIC mode apics */ > - if (dest == 0xff) { > + if (dest == 0xff && is_x2apic_mode(dev)) { > apic_get_broadcast_bitmask(deliver_bitmask, false); > } > } else { > Hmm, the unicast case is handled in apic_find_dest function, the logic inside the if (dest == 0xff) is for handling the broadcast case only. This is because when dest == 0xff, it can be both a x2APIC unicast and xAPIC broadcast in case we have some CPUs that are in xAPIC and others are in x2APIC. Do you think the code here is tricky and hard to read?
On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote: > On 3/27/23 23:22, David Woodhouse wrote: > > On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: > > > > > > > Maybe I'm misreading the patch, but to me it looks that > > > > if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in > > > > x2apic mode? So delivering to the APIC with physical ID 255 will be > > > > misinterpreted as a broadcast? > > > > > > In case dest == 0xff the second argument to apic_get_broadcast_bitmask > > > is set to false which means this is xAPIC broadcast > > > > Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. > > > > I think you want (although you don't have 'dev') something like this: > > > > > > static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > > uint32_t dest, uint8_t dest_mode) > > { > > APICCommonState *apic_iter; > > int i; > > > > memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); > > > > /* x2APIC broadcast id for both physical and logical (cluster) mode */ > > if (dest == 0xffffffff) { > > apic_get_broadcast_bitmask(deliver_bitmask, true); > > return; > > } > > > > if (dest_mode == 0) { > > apic_find_dest(deliver_bitmask, dest); > > /* Broadcast to xAPIC mode apics */ > > - if (dest == 0xff) { > > + if (dest == 0xff && is_x2apic_mode(dev)) { > > apic_get_broadcast_bitmask(deliver_bitmask, false); > > } > > } else { > > > > Hmm, the unicast case is handled in apic_find_dest function, the logic > inside the if (dest == 0xff) is for handling the broadcast case only. > This is because when dest == 0xff, it can be both a x2APIC unicast and > xAPIC broadcast in case we have some CPUs that are in xAPIC and others > are in x2APIC. Ah! Yes, I see it now. Shouldn't apic_get_broadcast_bitmask(… true) add *all* APICs to the mask, regardless of their mode? An APIC which is still in xAPIC mode will only look at the low 8 bits and see 0xFF which it also interprets as broadcast? Or is that not how real hardware behaves? > Do you think the code here is tricky and hard to read? Well, I completely failed to read it... :) I think changing the existing comment something like this might help... - /* Broadcast to xAPIC mode apics */ + /* Any APIC in xAPIC mode will interpret 0xFF as broadcast */ Coupled with a comment on apic_get_delivery_bitmask() clarifying that it depends on the mode of each APIC it considers — which is obvious enough in retrospect now I read the code and you point it out to me, but empirically, we have to concede that it wasn't obvious *enough* :)
On 3/27/23 23:49, David Woodhouse wrote: > On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote: >> On 3/27/23 23:22, David Woodhouse wrote: >>> On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: >>>> >>>>> Maybe I'm misreading the patch, but to me it looks that >>>>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in >>>>> x2apic mode? So delivering to the APIC with physical ID 255 will be >>>>> misinterpreted as a broadcast? >>>> >>>> In case dest == 0xff the second argument to apic_get_broadcast_bitmask >>>> is set to false which means this is xAPIC broadcast >>> >>> Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. >>> >>> I think you want (although you don't have 'dev') something like this: >>> >>> >>> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, >>> uint32_t dest, uint8_t dest_mode) >>> { >>> APICCommonState *apic_iter; >>> int i; >>> >>> memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); >>> >>> /* x2APIC broadcast id for both physical and logical (cluster) mode */ >>> if (dest == 0xffffffff) { >>> apic_get_broadcast_bitmask(deliver_bitmask, true); >>> return; >>> } >>> >>> if (dest_mode == 0) { >>> apic_find_dest(deliver_bitmask, dest); >>> /* Broadcast to xAPIC mode apics */ >>> - if (dest == 0xff) { >>> + if (dest == 0xff && is_x2apic_mode(dev)) { >>> apic_get_broadcast_bitmask(deliver_bitmask, false); >>> } >>> } else { >>> >> >> Hmm, the unicast case is handled in apic_find_dest function, the logic >> inside the if (dest == 0xff) is for handling the broadcast case only. >> This is because when dest == 0xff, it can be both a x2APIC unicast and >> xAPIC broadcast in case we have some CPUs that are in xAPIC and others >> are in x2APIC. > > Ah! Yes, I see it now. > > Shouldn't apic_get_broadcast_bitmask(… true) add *all* APICs to the > mask, regardless of their mode? An APIC which is still in xAPIC mode > will only look at the low 8 bits and see 0xFF which it also interprets > as broadcast? Or is that not how real hardware behaves? This is interesting. Your point looks reasonable to me but I don't know how to verify it, I'm trying to write kernel module to test it but there are just too many things running on Linux that uses interrupt so the system hangs. This raises another question: when dest == 0x102 in IPI, does the xAPIC mode CPU with APIC ID 0x2 accept the IPI? I can't see this stated clearly in the Intel SDM. > >> Do you think the code here is tricky and hard to read? > > Well, I completely failed to read it... :) > > I think changing the existing comment something like this might help... > > - /* Broadcast to xAPIC mode apics */ > + /* Any APIC in xAPIC mode will interpret 0xFF as broadcast */ > > Coupled with a comment on apic_get_delivery_bitmask() clarifying that > it depends on the mode of each APIC it considers — which is obvious > enough in retrospect now I read the code and you point it out to me, > but empirically, we have to concede that it wasn't obvious *enough* :)
On 3/28/23 22:58, Bui Quang Minh wrote: > On 3/27/23 23:49, David Woodhouse wrote: >> On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote: >>> On 3/27/23 23:22, David Woodhouse wrote: >>>> On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: >>>>> >>>>>> Maybe I'm misreading the patch, but to me it looks that >>>>>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in >>>>>> x2apic mode? So delivering to the APIC with physical ID 255 will be >>>>>> misinterpreted as a broadcast? >>>>> >>>>> In case dest == 0xff the second argument to apic_get_broadcast_bitmask >>>>> is set to false which means this is xAPIC broadcast >>>> >>>> Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. >>>> >>>> I think you want (although you don't have 'dev') something like this: >>>> >>>> >>>> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, >>>> uint32_t dest, uint8_t >>>> dest_mode) >>>> { >>>> APICCommonState *apic_iter; >>>> int i; >>>> >>>> memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); >>>> >>>> /* x2APIC broadcast id for both physical and logical (cluster) >>>> mode */ >>>> if (dest == 0xffffffff) { >>>> apic_get_broadcast_bitmask(deliver_bitmask, true); >>>> return; >>>> } >>>> >>>> if (dest_mode == 0) { >>>> apic_find_dest(deliver_bitmask, dest); >>>> /* Broadcast to xAPIC mode apics */ >>>> - if (dest == 0xff) { >>>> + if (dest == 0xff && is_x2apic_mode(dev)) { >>>> apic_get_broadcast_bitmask(deliver_bitmask, false); >>>> } >>>> } else { >>>> >>> >>> Hmm, the unicast case is handled in apic_find_dest function, the logic >>> inside the if (dest == 0xff) is for handling the broadcast case only. >>> This is because when dest == 0xff, it can be both a x2APIC unicast and >>> xAPIC broadcast in case we have some CPUs that are in xAPIC and others >>> are in x2APIC. >> >> Ah! Yes, I see it now. >> >> Shouldn't apic_get_broadcast_bitmask(… true) add *all* APICs to the >> mask, regardless of their mode? An APIC which is still in xAPIC mode >> will only look at the low 8 bits and see 0xFF which it also interprets >> as broadcast? Or is that not how real hardware behaves? > > This is interesting. Your point looks reasonable to me but I don't know > how to verify it, I'm trying to write kernel module to test it but there > are just too many things running on Linux that uses interrupt so the > system hangs. > > This raises another question: when dest == 0x102 in IPI, does the xAPIC > mode CPU with APIC ID 0x2 accept the IPI? I can't see this stated > clearly in the Intel SDM. I do some more testing on my hardware, your point is correct when dest == 0xffffffff, the interrupt is delivered to all APICs regardless of their mode. And when dest == 0x102 in IPI, xAPIC mode CPU with APIC ID 0x2 also accepts that IPI.
On 3/29/23 21:53, Bui Quang Minh wrote: > On 3/28/23 22:58, Bui Quang Minh wrote: >> On 3/27/23 23:49, David Woodhouse wrote: >>> On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote: >>>> On 3/27/23 23:22, David Woodhouse wrote: >>>>> On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: >>>>>> >>>>>>> Maybe I'm misreading the patch, but to me it looks that >>>>>>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in >>>>>>> x2apic mode? So delivering to the APIC with physical ID 255 will be >>>>>>> misinterpreted as a broadcast? >>>>>> >>>>>> In case dest == 0xff the second argument to >>>>>> apic_get_broadcast_bitmask >>>>>> is set to false which means this is xAPIC broadcast >>>>> >>>>> Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. >>>>> >>>>> I think you want (although you don't have 'dev') something like this: >>>>> >>>>> >>>>> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, >>>>> uint32_t dest, uint8_t >>>>> dest_mode) >>>>> { >>>>> APICCommonState *apic_iter; >>>>> int i; >>>>> >>>>> memset(deliver_bitmask, 0x00, max_apic_words * >>>>> sizeof(uint32_t)); >>>>> >>>>> /* x2APIC broadcast id for both physical and logical >>>>> (cluster) mode */ >>>>> if (dest == 0xffffffff) { >>>>> apic_get_broadcast_bitmask(deliver_bitmask, true); >>>>> return; >>>>> } >>>>> >>>>> if (dest_mode == 0) { >>>>> apic_find_dest(deliver_bitmask, dest); >>>>> /* Broadcast to xAPIC mode apics */ >>>>> - if (dest == 0xff) { >>>>> + if (dest == 0xff && is_x2apic_mode(dev)) { >>>>> apic_get_broadcast_bitmask(deliver_bitmask, false); >>>>> } >>>>> } else { >>>>> >>>> >>>> Hmm, the unicast case is handled in apic_find_dest function, the logic >>>> inside the if (dest == 0xff) is for handling the broadcast case only. >>>> This is because when dest == 0xff, it can be both a x2APIC unicast and >>>> xAPIC broadcast in case we have some CPUs that are in xAPIC and others >>>> are in x2APIC. >>> >>> Ah! Yes, I see it now. >>> >>> Shouldn't apic_get_broadcast_bitmask(… true) add *all* APICs to the >>> mask, regardless of their mode? An APIC which is still in xAPIC mode >>> will only look at the low 8 bits and see 0xFF which it also interprets >>> as broadcast? Or is that not how real hardware behaves? >> >> This is interesting. Your point looks reasonable to me but I don't >> know how to verify it, I'm trying to write kernel module to test it >> but there are just too many things running on Linux that uses >> interrupt so the system hangs. >> >> This raises another question: when dest == 0x102 in IPI, does the >> xAPIC mode CPU with APIC ID 0x2 accept the IPI? I can't see this >> stated clearly in the Intel SDM. > > I do some more testing on my hardware, your point is correct when dest > == 0xffffffff, the interrupt is delivered to all APICs regardless of > their mode. To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI destination mode is physical. In case the destination mode is logical, flat model/cluster model rule applies to determine if the xAPIC CPUs accept the IPI. Wow, this is so complicated :) > And when dest == 0x102 in IPI, xAPIC mode CPU with APIC ID > 0x2 also accepts that IPI.
On Wed, 29 Mar 2023 22:30:44 +0700 Bui Quang Minh <minhquangbui99@gmail.com> wrote: > On 3/29/23 21:53, Bui Quang Minh wrote: > > On 3/28/23 22:58, Bui Quang Minh wrote: > >> On 3/27/23 23:49, David Woodhouse wrote: > >>> On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote: > >>>> On 3/27/23 23:22, David Woodhouse wrote: > >>>>> On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: > >>>>>> > >>>>>>> Maybe I'm misreading the patch, but to me it looks that > >>>>>>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in > >>>>>>> x2apic mode? So delivering to the APIC with physical ID 255 will be > >>>>>>> misinterpreted as a broadcast? > >>>>>> > >>>>>> In case dest == 0xff the second argument to > >>>>>> apic_get_broadcast_bitmask > >>>>>> is set to false which means this is xAPIC broadcast > >>>>> > >>>>> Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. > >>>>> > >>>>> I think you want (although you don't have 'dev') something like this: > >>>>> > >>>>> > >>>>> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > >>>>> uint32_t dest, uint8_t > >>>>> dest_mode) > >>>>> { > >>>>> APICCommonState *apic_iter; > >>>>> int i; > >>>>> > >>>>> memset(deliver_bitmask, 0x00, max_apic_words * > >>>>> sizeof(uint32_t)); > >>>>> > >>>>> /* x2APIC broadcast id for both physical and logical > >>>>> (cluster) mode */ > >>>>> if (dest == 0xffffffff) { > >>>>> apic_get_broadcast_bitmask(deliver_bitmask, true); > >>>>> return; > >>>>> } > >>>>> > >>>>> if (dest_mode == 0) { > >>>>> apic_find_dest(deliver_bitmask, dest); > >>>>> /* Broadcast to xAPIC mode apics */ > >>>>> - if (dest == 0xff) { > >>>>> + if (dest == 0xff && is_x2apic_mode(dev)) { > >>>>> apic_get_broadcast_bitmask(deliver_bitmask, false); > >>>>> } > >>>>> } else { > >>>>> > >>>> > >>>> Hmm, the unicast case is handled in apic_find_dest function, the logic > >>>> inside the if (dest == 0xff) is for handling the broadcast case only. > >>>> This is because when dest == 0xff, it can be both a x2APIC unicast and > >>>> xAPIC broadcast in case we have some CPUs that are in xAPIC and others > >>>> are in x2APIC. > >>> > >>> Ah! Yes, I see it now. > >>> > >>> Shouldn't apic_get_broadcast_bitmask(… true) add *all* APICs to the > >>> mask, regardless of their mode? An APIC which is still in xAPIC mode > >>> will only look at the low 8 bits and see 0xFF which it also interprets > >>> as broadcast? Or is that not how real hardware behaves? > >> > >> This is interesting. Your point looks reasonable to me but I don't > >> know how to verify it, I'm trying to write kernel module to test it > >> but there are just too many things running on Linux that uses > >> interrupt so the system hangs. > >> > >> This raises another question: when dest == 0x102 in IPI, does the > >> xAPIC mode CPU with APIC ID 0x2 accept the IPI? I can't see this > >> stated clearly in the Intel SDM. > > > > I do some more testing on my hardware, your point is correct when dest > > == 0xffffffff, the interrupt is delivered to all APICs regardless of > > their mode. > > To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI > destination mode is physical. In case the destination mode is logical, > flat model/cluster model rule applies to determine if the xAPIC CPUs > accept the IPI. Wow, this is so complicated :) It would be nice if you could update apic kvm unit test with your findings if it doesn't test those variants yet. > > > > And when dest == 0x102 in IPI, xAPIC mode CPU with APIC ID > > 0x2 also accepts that IPI. >
On Wed, 2023-03-29 at 22:30 +0700, Bui Quang Minh wrote: > > > > > I do some more testing on my hardware, your point is correct when dest > > == 0xffffffff, the interrupt is delivered to all APICs regardless of > > their mode. > > To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI > destination mode is physical. In case the destination mode is logical, > flat model/cluster model rule applies to determine if the xAPIC CPUs > accept the IPI. Wow, this is so complicated :) So even if you send to *all* of the first 8 CPUs in a cluster (e.g. cluster 0x0001 giving a destination 0x000100FF, a CPU in xAPIC mode doesn't see that as a broadcast because it's logical mode? I would have assumed that a CPU in xAPIC mode would have looked at the low byte and interpreted it as xAPIC logical mode, with the cluster in the high nybble and the 4-bit mask in the low nybble?
On 3/30/23 15:28, Igor Mammedov wrote: > On Wed, 29 Mar 2023 22:30:44 +0700 > Bui Quang Minh <minhquangbui99@gmail.com> wrote: > >> On 3/29/23 21:53, Bui Quang Minh wrote: >>> On 3/28/23 22:58, Bui Quang Minh wrote: >>>> On 3/27/23 23:49, David Woodhouse wrote: >>>>> On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote: >>>>>> On 3/27/23 23:22, David Woodhouse wrote: >>>>>>> On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote: >>>>>>>> >>>>>>>>> Maybe I'm misreading the patch, but to me it looks that >>>>>>>>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in >>>>>>>>> x2apic mode? So delivering to the APIC with physical ID 255 will be >>>>>>>>> misinterpreted as a broadcast? >>>>>>>> >>>>>>>> In case dest == 0xff the second argument to >>>>>>>> apic_get_broadcast_bitmask >>>>>>>> is set to false which means this is xAPIC broadcast >>>>>>> >>>>>>> Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255. >>>>>>> >>>>>>> I think you want (although you don't have 'dev') something like this: >>>>>>> >>>>>>> >>>>>>> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, >>>>>>> uint32_t dest, uint8_t >>>>>>> dest_mode) >>>>>>> { >>>>>>> APICCommonState *apic_iter; >>>>>>> int i; >>>>>>> >>>>>>> memset(deliver_bitmask, 0x00, max_apic_words * >>>>>>> sizeof(uint32_t)); >>>>>>> >>>>>>> /* x2APIC broadcast id for both physical and logical >>>>>>> (cluster) mode */ >>>>>>> if (dest == 0xffffffff) { >>>>>>> apic_get_broadcast_bitmask(deliver_bitmask, true); >>>>>>> return; >>>>>>> } >>>>>>> >>>>>>> if (dest_mode == 0) { >>>>>>> apic_find_dest(deliver_bitmask, dest); >>>>>>> /* Broadcast to xAPIC mode apics */ >>>>>>> - if (dest == 0xff) { >>>>>>> + if (dest == 0xff && is_x2apic_mode(dev)) { >>>>>>> apic_get_broadcast_bitmask(deliver_bitmask, false); >>>>>>> } >>>>>>> } else { >>>>>>> >>>>>> >>>>>> Hmm, the unicast case is handled in apic_find_dest function, the logic >>>>>> inside the if (dest == 0xff) is for handling the broadcast case only. >>>>>> This is because when dest == 0xff, it can be both a x2APIC unicast and >>>>>> xAPIC broadcast in case we have some CPUs that are in xAPIC and others >>>>>> are in x2APIC. >>>>> >>>>> Ah! Yes, I see it now. >>>>> >>>>> Shouldn't apic_get_broadcast_bitmask(… true) add *all* APICs to the >>>>> mask, regardless of their mode? An APIC which is still in xAPIC mode >>>>> will only look at the low 8 bits and see 0xFF which it also interprets >>>>> as broadcast? Or is that not how real hardware behaves? >>>> >>>> This is interesting. Your point looks reasonable to me but I don't >>>> know how to verify it, I'm trying to write kernel module to test it >>>> but there are just too many things running on Linux that uses >>>> interrupt so the system hangs. >>>> >>>> This raises another question: when dest == 0x102 in IPI, does the >>>> xAPIC mode CPU with APIC ID 0x2 accept the IPI? I can't see this >>>> stated clearly in the Intel SDM. >>> >>> I do some more testing on my hardware, your point is correct when dest >>> == 0xffffffff, the interrupt is delivered to all APICs regardless of >>> their mode. >> >> To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI >> destination mode is physical. In case the destination mode is logical, >> flat model/cluster model rule applies to determine if the xAPIC CPUs >> accept the IPI. Wow, this is so complicated :) > > It would be nice if you could update apic kvm unit test with your > findings if it doesn't test those variants yet. > >> >> >>> And when dest == 0x102 in IPI, xAPIC mode CPU with APIC ID >>> 0x2 also accepts that IPI. KVM does not do the same way as the real hardware in these cases, if the destination of IPI is 0xffffffff, IPI is broadcasted to x2APIC CPUs but not xAPIC CPUs. The same with IPI has destination 0x102 does not deliver to xAPIC CPU with APIC ID 0x2. This is the intended behavior as I see some comments mentioning it. diff --git a/x86/apic.c b/x86/apic.c index 20c3a1a..8c91d27 100644 --- a/x86/apic.c +++ b/x86/apic.c @@ -679,7 +679,7 @@ static void set_ldr(void *__ldr) apic_write(APIC_LDR, ldr << 24); } -static int test_fixed_ipi(u32 dest_mode, u8 dest, u8 vector, +static int test_fixed_ipi(u32 dest_mode, u32 dest, u8 vector, int nr_ipis_expected, const char *mode_name) { u64 start = rdtsc(); @@ -913,6 +913,38 @@ static void test_aliased_xapic_physical_ipi(void) report(!f, "IPI to aliased xAPIC physical IDs"); } +static void reset_apic_cpu(void *arg) +{ + u8 *id = (u8 *)arg; + reset_apic(); + *id = apic_id(); +} + +static void test_physical_ipi_with_x2apic_id(void) +{ + u8 vector = 0xf1; + int f = 0; + u8 apic_id_cpu1; + + if (cpu_count() < 2) + return; + + if (!is_x2apic_enabled()) + return; + + on_cpu(1, reset_apic_cpu, &apic_id_cpu1); + handle_irq(vector, handle_ipi); + + /* + * CPU1 is in xAPIC so it accepts the IPI because the (destination & 0xff) + * matches its APIC ID. + */ + f += test_fixed_ipi(APIC_DEST_PHYSICAL, apic_id_cpu1 | 0x100, vector, 1, "physical"); + f += test_fixed_ipi(APIC_DEST_PHYSICAL, 0xffffffff, vector, cpu_count(), "physical"); + + report(!f, "IPI with x2apic id to xapic CPU"); +} + typedef void (*apic_test_fn)(void); int main(void) @@ -950,6 +982,7 @@ int main(void) test_apic_id, test_apicbase, test_aliased_xapic_physical_ipi, + test_physical_ipi_with_x2apic_id, }; assert_msg(is_apic_hw_enabled() && is_apic_sw_enabled(), With this patch in kvm-unit-test, the version 3 of this series, which I will post soon, passes the test but not KVM. So I am not sure if I should post this test to kvm-unit-test.
On 4/3/23 17:27, David Woodhouse wrote: > On Wed, 2023-03-29 at 22:30 +0700, Bui Quang Minh wrote: >> >>> >>> I do some more testing on my hardware, your point is correct when dest >>> == 0xffffffff, the interrupt is delivered to all APICs regardless of >>> their mode. >> >> To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI >> destination mode is physical. In case the destination mode is logical, >> flat model/cluster model rule applies to determine if the xAPIC CPUs >> accept the IPI. Wow, this is so complicated :) > > So even if you send to *all* of the first 8 CPUs in a cluster (e.g. > cluster 0x0001 giving a destination 0x000100FF, a CPU in xAPIC mode > doesn't see that as a broadcast because it's logical mode? I mean if the destination is 0xffffffff, the xAPIC CPU will see destination as 0xff. 0xff is broadcast in physical destination mode only, in logical destination, it may not be a broadcast. It may depend on the whether it is flat model or cluster model in logical destination mode. In flat model, 8 bits are used as mask, so in theory, this model can only support 8 CPUs, each CPU reserves its own bit by setting the upper 8 bits of APIC LDR register. In Intel SDM, it is said that 0xff can be interpreted as a broadcast, this is true in normal case, but I think if the CPU its APIC LDR to 0, the IPI should not deliver to this CPU. This also matches with the current flat model of logical destination mode implementation of userspace APIC in Qemu before my series. However, I see this seems like a corner case, I didn't test it on real hardware. With cluster model, when writing the above paragraphs, I think that 0xff will be delivered to all APICs (mask = 0xf) of cluster 15 (0xf). However, reading the SDM more carefully, I see that the there are only 15 clusters with address from 0 to 14 so there is no cluster with address 15. 0xff is interpreted as broadcast to all APICs in all clusters too. In conclusion, IPI with destination 0xffffffff can be a broadcast to all xAPIC CPUs too if we just ignore the corner case in flat model of logical destination mode (we may need to test more) > I would have assumed that a CPU in xAPIC mode would have looked at the > low byte and interpreted it as xAPIC logical mode, with the cluster in > the high nybble and the 4-bit mask in the low nybble? Yes, this is the behavior in cluster model of logical destination mode (I try to stick with Intel SDM Section 10.6.2.2 Volume 3A when using those terminologies)
On 4/3/23 23:38, Bui Quang Minh wrote: > On 4/3/23 17:27, David Woodhouse wrote: >> On Wed, 2023-03-29 at 22:30 +0700, Bui Quang Minh wrote: >>> >>>> >>>> I do some more testing on my hardware, your point is correct when dest >>>> == 0xffffffff, the interrupt is delivered to all APICs regardless of >>>> their mode. >>> >>> To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI >>> destination mode is physical. In case the destination mode is logical, >>> flat model/cluster model rule applies to determine if the xAPIC CPUs >>> accept the IPI. Wow, this is so complicated :) >> >> So even if you send to *all* of the first 8 CPUs in a cluster (e.g. >> cluster 0x0001 giving a destination 0x000100FF, a CPU in xAPIC mode >> doesn't see that as a broadcast because it's logical mode? > > I mean if the destination is 0xffffffff, the xAPIC CPU will see > destination as 0xff. 0xff is broadcast in physical destination mode > only, in logical destination, it may not be a broadcast. It may depend > on the whether it is flat model or cluster model in logical destination > mode. > > In flat model, 8 bits are used as mask, so in theory, this model can > only support 8 CPUs, each CPU reserves its own bit by setting the upper > 8 bits of APIC LDR register. In Intel SDM, it is said that 0xff can be > interpreted as a broadcast, this is true in normal case, but I think if > the CPU its APIC LDR to 0, the IPI should not deliver to this CPU. This > also matches with the current flat model of logical destination mode > implementation of userspace APIC in Qemu before my series. However, I > see this seems like a corner case, I didn't test it on real hardware. > > With cluster model, when writing the above paragraphs, I think that 0xff > will be delivered to all APICs (mask = 0xf) of cluster 15 (0xf). > However, reading the SDM more carefully, I see that the there are only > 15 clusters with address from 0 to 14 so there is no cluster with > address 15. 0xff is interpreted as broadcast to all APICs in all > clusters too. > > In conclusion, IPI with destination 0xffffffff can be a broadcast to all > xAPIC CPUs too if we just ignore the corner case in flat model of > logical destination mode (we may need to test more) I do some tests on my machine with custom Linux kernel module (I can't use kvm-unit-tests because the display on my laptop is on embedded display port not serial port so I don't know how to get the output). I find out that - In flat model, if the CPU intentionally set its 8 bit address to 0 in APIC_LDR, the 0xff logical IPI does not deliver to this CPU. - In cluster model, the 4 higher bits used as cluster address, if these 4 bits is equal to 0xf, the IPI is broadcasted to all cluster. The 4 lower bits are used to address APICs in the cluster. If the CPU intentionally set these 4 lower bits to 0 in APIC_LDR, same as the flat model, this CPU does not receive the logical IPI. For example, the CPUs set its address to 0x20 (cluster 2, address 0 in cluster), the logical IPI with destination == 0xff does deliver to cluster 2 but does not deliver to this CPU. So I choose to stick with the current implementation, 0xffffffff in IPI is seen as 0xff IPI in xAPIC CPUs. This IPI if in physical mode is a broadcast but not in logical mode.
diff --git a/hw/i386/x86.c b/hw/i386/x86.c index a88a126123..fa9b15190d 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -132,11 +132,11 @@ void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version) * Can we support APIC ID 255 or higher? * * Under Xen: yes. - * With userspace emulated lapic: no + * With userspace emulated lapic: yes. * With KVM's in-kernel lapic: only if X2APIC API is enabled. */ if (x86ms->apic_id_limit > 255 && !xen_enabled() && - (!kvm_irqchip_in_kernel() || !kvm_enable_x2apic())) { + kvm_irqchip_in_kernel() && !kvm_enable_x2apic()) { error_report("current -smp configuration requires kernel " "irqchip and X2APIC API support."); exit(EXIT_FAILURE); @@ -146,6 +146,10 @@ void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version) kvm_set_max_apic_id(x86ms->apic_id_limit); } + if (!kvm_irqchip_in_kernel()) { + apic_set_max_apic_id(x86ms->apic_id_limit); + } + possible_cpus = mc->possible_cpu_arch_ids(ms); for (i = 0; i < ms->smp.cpus; i++) { x86_cpu_new(x86ms, possible_cpus->cpus[i].arch_id, &error_fatal); diff --git a/hw/intc/apic.c b/hw/intc/apic.c index 61b494b20a..159527af30 100644 --- a/hw/intc/apic.c +++ b/hw/intc/apic.c @@ -31,15 +31,15 @@ #include "hw/i386/apic-msidef.h" #include "qapi/error.h" #include "qom/object.h" - -#define MAX_APICS 255 -#define MAX_APIC_WORDS 8 +#include "tcg/helper-tcg.h" #define SYNC_FROM_VAPIC 0x1 #define SYNC_TO_VAPIC 0x2 #define SYNC_ISR_IRR_TO_VAPIC 0x4 -static APICCommonState *local_apics[MAX_APICS + 1]; +static APICCommonState **local_apics; +static uint32_t max_apics; +static uint32_t max_apic_words; #define TYPE_APIC "apic" /*This is reusing the APICCommonState typedef from APIC_COMMON */ @@ -49,7 +49,19 @@ DECLARE_INSTANCE_CHECKER(APICCommonState, APIC, static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode); static void apic_update_irq(APICCommonState *s); static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, - uint8_t dest, uint8_t dest_mode); + uint32_t dest, uint8_t dest_mode); + +void apic_set_max_apic_id(uint32_t max_apic_id) +{ + int word_size = 32; + + /* round up the max apic id to next multiple of words */ + max_apics = (max_apic_id + word_size - 1) & ~(word_size - 1); + + local_apics = g_malloc0(sizeof(*local_apics) * max_apics); + max_apic_words = max_apics >> 5; +} + /* Find first bit starting from msb */ static int apic_fls_bit(uint32_t value) @@ -199,7 +211,7 @@ static void apic_external_nmi(APICCommonState *s) #define foreach_apic(apic, deliver_bitmask, code) \ {\ int __i, __j;\ - for(__i = 0; __i < MAX_APIC_WORDS; __i++) {\ + for(__i = 0; __i < max_apic_words; __i++) {\ uint32_t __mask = deliver_bitmask[__i];\ if (__mask) {\ for(__j = 0; __j < 32; __j++) {\ @@ -226,7 +238,7 @@ static void apic_bus_deliver(const uint32_t *deliver_bitmask, { int i, d; d = -1; - for(i = 0; i < MAX_APIC_WORDS; i++) { + for(i = 0; i < max_apic_words; i++) { if (deliver_bitmask[i]) { d = i * 32 + apic_ffs_bit(deliver_bitmask[i]); break; @@ -276,16 +288,17 @@ static void apic_bus_deliver(const uint32_t *deliver_bitmask, apic_set_irq(apic_iter, vector_num, trigger_mode) ); } -void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, uint8_t delivery_mode, +void apic_deliver_irq(uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t vector_num, uint8_t trigger_mode) { - uint32_t deliver_bitmask[MAX_APIC_WORDS]; + uint32_t *deliver_bitmask = g_malloc(max_apic_words * sizeof(uint32_t)); trace_apic_deliver_irq(dest, dest_mode, delivery_mode, vector_num, trigger_mode); apic_get_delivery_bitmask(deliver_bitmask, dest, dest_mode); apic_bus_deliver(deliver_bitmask, delivery_mode, vector_num, trigger_mode); + g_free(deliver_bitmask); } bool is_x2apic_mode(DeviceState *dev) @@ -442,57 +455,91 @@ static void apic_eoi(APICCommonState *s) apic_update_irq(s); } -static int apic_find_dest(uint8_t dest) +static bool apic_match_dest(APICCommonState *apic, uint32_t dest) { - APICCommonState *apic = local_apics[dest]; + if (is_x2apic_mode(&apic->parent_obj)) { + return apic->initial_apic_id == dest; + } else { + return apic->id == (uint8_t)dest; + } +} + +static void apic_find_dest(uint32_t *deliver_bitmask, uint32_t dest) +{ + APICCommonState *apic = NULL; int i; - if (apic && apic->id == dest) - return dest; /* shortcut in case apic->id == local_apics[dest]->id */ - - for (i = 0; i < MAX_APICS; i++) { + for (i = 0; i < max_apics; i++) { apic = local_apics[i]; - if (apic && apic->id == dest) - return i; - if (!apic) - break; + if (apic && apic_match_dest(apic, dest)) { + apic_set_bit(deliver_bitmask, i); + } } +} - return -1; +static void apic_get_broadcast_bitmask(uint32_t *deliver_bitmask, + bool is_x2apic_broadcast) +{ + int i; + APICCommonState *apic_iter; + + for (i = 0; i < max_apics; i++) { + apic_iter = local_apics[i]; + if (apic_iter) { + bool apic_in_x2apic = is_x2apic_mode(&apic_iter->parent_obj); + + if (is_x2apic_broadcast && apic_in_x2apic) { + apic_set_bit(deliver_bitmask, i); + } else if (!is_x2apic_broadcast && !apic_in_x2apic) { + apic_set_bit(deliver_bitmask, i); + } + } + } } static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, - uint8_t dest, uint8_t dest_mode) + uint32_t dest, uint8_t dest_mode) { APICCommonState *apic_iter; int i; + memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t)); + + /* x2APIC broadcast id for both physical and logical (cluster) mode */ + if (dest == 0xffffffff) { + apic_get_broadcast_bitmask(deliver_bitmask, true); + return; + } + if (dest_mode == 0) { + apic_find_dest(deliver_bitmask, dest); + /* Broadcast to xAPIC mode apics */ if (dest == 0xff) { - memset(deliver_bitmask, 0xff, MAX_APIC_WORDS * sizeof(uint32_t)); - } else { - int idx = apic_find_dest(dest); - memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); - if (idx >= 0) - apic_set_bit(deliver_bitmask, idx); + apic_get_broadcast_bitmask(deliver_bitmask, false); } } else { /* XXX: cluster mode */ - memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); - for(i = 0; i < MAX_APICS; i++) { + for(i = 0; i < max_apics; i++) { apic_iter = local_apics[i]; if (apic_iter) { - if (apic_iter->dest_mode == 0xf) { - if (dest & apic_iter->log_dest) - apic_set_bit(deliver_bitmask, i); - } else if (apic_iter->dest_mode == 0x0) { - if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) && - (dest & apic_iter->log_dest & 0x0f)) { + /* x2APIC mode */ + if (apic_iter->apicbase & MSR_IA32_APICBASE_EXTD) { + if ((dest & 0xffff0000) == (apic_iter->log_dest & 0xffff0000) && + (dest & apic_iter->log_dest & 0xffff)) { apic_set_bit(deliver_bitmask, i); } + } else { + if (apic_iter->dest_mode == 0xf) { + if (dest & apic_iter->log_dest) { + apic_set_bit(deliver_bitmask, i); + } + } else if (apic_iter->dest_mode == 0x0) { + if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) && + (dest & apic_iter->log_dest & 0x0f)) { + apic_set_bit(deliver_bitmask, i); + } + } } - } else { - break; } } } @@ -516,29 +563,36 @@ void apic_sipi(DeviceState *dev) s->wait_for_sipi = 0; } -static void apic_deliver(DeviceState *dev, uint8_t dest, uint8_t dest_mode, +static void apic_deliver(DeviceState *dev, uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t vector_num, - uint8_t trigger_mode) + uint8_t trigger_mode, uint8_t dest_shorthand) { APICCommonState *s = APIC(dev); - uint32_t deliver_bitmask[MAX_APIC_WORDS]; - int dest_shorthand = (s->icr[0] >> 18) & 3; APICCommonState *apic_iter; + uint32_t deliver_bitmask_size = max_apic_words * sizeof(uint32_t); + uint32_t *deliver_bitmask = g_malloc(deliver_bitmask_size); + uint32_t current_apic_id; + + if (is_x2apic_mode(dev)) { + current_apic_id = s->initial_apic_id; + } else { + current_apic_id = s->id; + } switch (dest_shorthand) { case 0: apic_get_delivery_bitmask(deliver_bitmask, dest, dest_mode); break; case 1: - memset(deliver_bitmask, 0x00, sizeof(deliver_bitmask)); - apic_set_bit(deliver_bitmask, s->id); + memset(deliver_bitmask, 0x00, deliver_bitmask_size); + apic_set_bit(deliver_bitmask, current_apic_id); break; case 2: - memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); + memset(deliver_bitmask, 0xff, deliver_bitmask_size); break; case 3: - memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); - apic_reset_bit(deliver_bitmask, s->id); + memset(deliver_bitmask, 0xff, deliver_bitmask_size); + apic_reset_bit(deliver_bitmask, current_apic_id); break; } @@ -562,6 +616,7 @@ static void apic_deliver(DeviceState *dev, uint8_t dest, uint8_t dest_mode, } apic_bus_deliver(deliver_bitmask, delivery_mode, vector_num, trigger_mode); + g_free(deliver_bitmask); } static bool apic_check_pic(APICCommonState *s) @@ -657,7 +712,11 @@ uint64_t apic_register_read(int index) switch(index) { case 0x02: /* id */ - val = s->id << 24; + if (is_x2apic_mode(dev)) { + val = s->initial_apic_id; + } else { + val = s->id << 24; + } break; case 0x03: /* version */ val = s->version | ((APIC_LVT_NB - 1) << 16); @@ -680,9 +739,17 @@ uint64_t apic_register_read(int index) val = 0; break; case 0x0d: - val = s->log_dest << 24; + if (is_x2apic_mode(dev)) { + val = s->log_dest; + } else { + val = s->log_dest << 24; + } break; case 0x0e: + if (is_x2apic_mode(dev)) { + raise_exception_ra(&s->cpu->env, EXCP0D_GPF, GETPC()); + } + val = (s->dest_mode << 28) | 0xfffffff; break; case 0x0f: @@ -745,7 +812,12 @@ static void apic_send_msi(MSIMessage *msi) { uint64_t addr = msi->address; uint32_t data = msi->data; - uint8_t dest = (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT; + uint32_t dest = (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT; + /* + * The higher 3 bytes of destination id is stored in higher word of + * msi address. See x86_iommu_irq_to_msi_message() + */ + dest = dest | (addr >> 32); uint8_t vector = (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT; uint8_t dest_mode = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1; uint8_t trigger_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1; @@ -769,6 +841,10 @@ void apic_register_write(int index, uint64_t val) switch(index) { case 0x02: + if (is_x2apic_mode(dev)) { + raise_exception_ra(&s->cpu->env, EXCP0D_GPF, GETPC()); + } + s->id = (val >> 24); break; case 0x03: @@ -788,9 +864,17 @@ void apic_register_write(int index, uint64_t val) apic_eoi(s); break; case 0x0d: + if (is_x2apic_mode(dev)) { + raise_exception_ra(&s->cpu->env, EXCP0D_GPF, GETPC()); + } + s->log_dest = val >> 24; break; case 0x0e: + if (is_x2apic_mode(dev)) { + raise_exception_ra(&s->cpu->env, EXCP0D_GPF, GETPC()); + } + s->dest_mode = val >> 28; break; case 0x0f: @@ -802,13 +886,27 @@ void apic_register_write(int index, uint64_t val) case 0x20 ... 0x27: case 0x28: break; - case 0x30: + case 0x30: { + uint32_t dest; + s->icr[0] = val; - apic_deliver(dev, (s->icr[1] >> 24) & 0xff, (s->icr[0] >> 11) & 1, + if (is_x2apic_mode(dev)) { + s->icr[1] = val >> 32; + dest = s->icr[1]; + } else { + dest = (s->icr[1] >> 24) & 0xff; + } + + apic_deliver(dev, dest, (s->icr[0] >> 11) & 1, (s->icr[0] >> 8) & 7, (s->icr[0] & 0xff), - (s->icr[0] >> 15) & 1); + (s->icr[0] >> 15) & 1, (s->icr[0] >> 18) & 3); break; + } case 0x31: + if (is_x2apic_mode(dev)) { + raise_exception_ra(&s->cpu->env, EXCP0D_GPF, GETPC()); + } + s->icr[1] = val; break; case 0x32 ... 0x37: @@ -837,6 +935,23 @@ void apic_register_write(int index, uint64_t val) s->count_shift = (v + 1) & 7; } break; + case 0x3f: { + int vector = val & 0xff; + + if (!is_x2apic_mode(dev)) { + raise_exception_ra(&s->cpu->env, EXCP0D_GPF, GETPC()); + } + + /* + * Self IPI is identical to IPI with + * - Destination shorthand: 1 (Self) + * - Trigger mode: 0 (Edge) + * - Delivery mode: 0 (Fixed) + */ + apic_deliver(dev, 0, 0, APIC_DM_FIXED, vector, 0, 1); + + break; + } default: s->esr |= APIC_ESR_ILLEGAL_ADDRESS; break; @@ -894,12 +1009,6 @@ static void apic_realize(DeviceState *dev, Error **errp) { APICCommonState *s = APIC(dev); - if (s->id >= MAX_APICS) { - error_setg(errp, "%s initialization failed. APIC ID %d is invalid", - object_get_typename(OBJECT(dev)), s->id); - return; - } - if (kvm_enabled()) { warn_report("Userspace local APIC is deprecated for KVM."); warn_report("Do not use kernel-irqchip except for the -M isapc machine type."); @@ -909,7 +1018,7 @@ static void apic_realize(DeviceState *dev, Error **errp) APIC_SPACE_SIZE); s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, apic_timer, s); - local_apics[s->id] = s; + local_apics[s->initial_apic_id] = s; msi_nonbroken = true; } @@ -919,7 +1028,7 @@ static void apic_unrealize(DeviceState *dev) APICCommonState *s = APIC(dev); timer_free(s->timer); - local_apics[s->id] = NULL; + local_apics[s->initial_apic_id] = NULL; } static void apic_class_init(ObjectClass *klass, void *data) diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c index 4a34f03047..39c207bd21 100644 --- a/hw/intc/apic_common.c +++ b/hw/intc/apic_common.c @@ -194,7 +194,11 @@ void apic_init_reset(DeviceState *dev) s = APIC_COMMON(dev); s->tpr = 0; s->spurious_vec = 0xff; - s->log_dest = 0; + + if (!is_x2apic_mode(dev)) { + s->log_dest = 0; + } + s->dest_mode = 0xf; memset(s->isr, 0, sizeof(s->isr)); memset(s->tmr, 0, sizeof(s->tmr)); @@ -366,7 +370,7 @@ static const VMStateDescription vmstate_apic_common = { VMSTATE_UINT8(arb_id, APICCommonState), VMSTATE_UINT8(tpr, APICCommonState), VMSTATE_UINT32(spurious_vec, APICCommonState), - VMSTATE_UINT8(log_dest, APICCommonState), + VMSTATE_UINT32(log_dest, APICCommonState), VMSTATE_UINT8(dest_mode, APICCommonState), VMSTATE_UINT32_ARRAY(isr, APICCommonState, 8), VMSTATE_UINT32_ARRAY(tmr, APICCommonState, 8), diff --git a/include/hw/i386/apic.h b/include/hw/i386/apic.h index 2cebeb4faf..d938bfa8e0 100644 --- a/include/hw/i386/apic.h +++ b/include/hw/i386/apic.h @@ -3,7 +3,8 @@ /* apic.c */ -void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, uint8_t delivery_mode, +void apic_set_max_apic_id(uint32_t max_apic_id); +void apic_deliver_irq(uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t vector_num, uint8_t trigger_mode); int apic_accept_pic_intr(DeviceState *s); void apic_deliver_pic_intr(DeviceState *s, int level); diff --git a/include/hw/i386/apic_internal.h b/include/hw/i386/apic_internal.h index 5f2ba24bfc..5f60cd5e78 100644 --- a/include/hw/i386/apic_internal.h +++ b/include/hw/i386/apic_internal.h @@ -164,7 +164,7 @@ struct APICCommonState { uint8_t arb_id; uint8_t tpr; uint32_t spurious_vec; - uint8_t log_dest; + uint32_t log_dest; uint8_t dest_mode; uint32_t isr[8]; /* in service register */ uint32_t tmr[8]; /* trigger mode register */
This commit extends the APIC ID to 32-bit long and remove the 255 max APIC ID limit in userspace APIC. The array that manages local APICs is now dynamically allocated based on the max APIC ID of created x86 machine. Also, new x2APIC IPI destination determination scheme, self IPI and x2APIC mode register access are supported. Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> --- hw/i386/x86.c | 8 +- hw/intc/apic.c | 229 +++++++++++++++++++++++--------- hw/intc/apic_common.c | 8 +- include/hw/i386/apic.h | 3 +- include/hw/i386/apic_internal.h | 2 +- 5 files changed, 184 insertions(+), 66 deletions(-)