2014-12-01 17:30+0100, Paolo Bonzini:
> On 27/11/2014 23:26, Radim Krčmář wrote:
> > We can't deliver xAPIC and x2APIC broadcasts/logical messages at the
> > same time with current KVM and this patch just switches the working case
> > in favour of x2APIC, which is why I didn't think it was necessary ...
> > (And I didn't understand why prefer disabled x2APIC to enabled xAPIC.)
>
> Indeed. A possible thing to do perhaps would be to build two logical
> maps, one for x2APIC and one for xAPIC, and consult both... That would
> slow down the common case when one map is empty, though.
Yeah, that seems like the cleanest solution ... I'll prepare the patch.
(so we can then throw it away :)
We'll need to take a look at the source (IO)APIC now.
Some design points I'm not sure about now:
- Does xAPIC ignore reserved bytes in destination?
(= Is x2APIC broadcast also delivered to xAPICs?)
- we'll probably still have to hack it to deliver IOAPIC requests to
low x2APIC logical addresses for compatibility reasons
- to gain speed, we could try to encode them into the same cache-line
struct {kvm_apic_t *xapic, kvm_apic_t *x2apic} logical_map[16][16];
(and waste some space instead)
---
If we wanted to be super correct, with respect to sw-disabled xAPIC,
there should be three: x2APIC, flat xAPIC, and cluster xAPIC :)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
