On 2016年04月27日 13:24, Jan Kiszka wrote:
>> > If we don't want the interrupt from internal device delivers to CPU
>>> >>255, do we still need the VT-d interrupt remapping emulation? I think
>> > firmware is able to send IPI to wakeup APs even without IR and OS is
>> > able to do it too. So basically, only KVM and Qemu's support is enough.
Yes, just starting more than 255 APs doesn't need IR.
> What are "internal devices" for you? And which OS do you know that would
> handle such artificial setups without prio massive patching?
>
> We do need VT-d IR emulation in order to present our guest a well
> specified and support architecture for running > 255 CPUs.
Changing guest kernel will be big concern. I found commit ce69a784 did
optimization to use X2APIC without IR in the guest when APIC id is less
than 256 and so I proposed my idea to see everyone's feedback. Whether
it's possible to relax the IR requirement when APIC id > 255 in the guest.
commit ce69a784504222c3ab6f1b3c357d09ec5772127a
Author: Gleb Natapov <gleb@xxxxxxxxxx>
Date: Mon Jul 20 15:24:17 2009 +0300
x86/apic: Enable x2APIC without interrupt remapping under KVM
KVM would like to provide x2APIC interface to a guest without emulating
interrupt remapping device. The reason KVM prefers guest to use x2APIC
is that x2APIC interface is better virtualizable and provides better
performance than mmio xAPIC interface:
- msr exits are faster than mmio (no page table walk, emulation)
- no need to read back ICR to look at the busy bit
- one 64 bit ICR write instead of two 32 bit writes
- shared code with the Hyper-V paravirt interface
Included patch changes x2APIC enabling logic to enable it even if IR
initialization failed, but kernel runs under KVM and no apic id is
greater than 255 (if there is one spec requires BIOS to move to
x2apic mode before starting an OS).
It's great to know Peter already worked on the IR.
--
Best regards
Tianyu Lan
--
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
