KVM & VT-d2?

KVM & VT-d2?

[Fischer, Anna]

Does KVM already take advantage of Intel VT-d2 features, e.g. interrupt remapping support? Has anyone verified how it improves interrupt delivery for PCI pass-through devices?

Thanks,
Anna

RE: KVM & VT-d2?

[Kay, Allen M]

We have verified VT-d2 features works with PCI passthrough on KVM.  To enable it, you need to turn on interrupt remapping in kernel config.

Interrupt remapping is a security/isolation feature where interrupt delivery is qualified with device's bus/device/function in interrupt remapping table entry when source ID checking is turn on.  It does not directly inject interrupt to the guest OS.

-----Original Message-----
From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Fischer, Anna
Sent: Thursday, May 14, 2009 2:53 PM
To: kvm@vger.kernel.org
Subject: KVM & VT-d2?

Does KVM already take advantage of Intel VT-d2 features, e.g. interrupt remapping support? Has anyone verified how it improves interrupt delivery for PCI pass-through devices?

Thanks,
Anna


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: KVM & VT-d2?

[Fischer, Anna]

I thought that one use case of VT-d2 interrupt remapping was to be able to safely and more efficiently deliver interrupts to the CPU that runs the particular VCPU of the guest that owns the I/O device that issues the interrupt. Shouldn't there at least be some performance (e.g. latency) improvement doing the remapping and checking in HW with a predefined table rather than multiplexing this in software in the hypervisor layer?

> -----Original Message-----
> From: Kay, Allen M [mailto:allen.m.kay@intel.com]
> Sent: 14 May 2009 15:02
> To: Fischer, Anna; kvm@vger.kernel.org
> Subject: RE: KVM & VT-d2?
> 
> We have verified VT-d2 features works with PCI passthrough on KVM.  To
> enable it, you need to turn on interrupt remapping in kernel config.
> 
> Interrupt remapping is a security/isolation feature where interrupt
> delivery is qualified with device's bus/device/function in interrupt
> remapping table entry when source ID checking is turn on.  It does not
> directly inject interrupt to the guest OS.
> 
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
> Behalf Of Fischer, Anna
> Sent: Thursday, May 14, 2009 2:53 PM
> To: kvm@vger.kernel.org
> Subject: KVM & VT-d2?
> 
> Does KVM already take advantage of Intel VT-d2 features, e.g. interrupt
> remapping support? Has anyone verified how it improves interrupt
> delivery for PCI pass-through devices?
> 
> Thanks,
> Anna
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: KVM & VT-d2?

[Kay, Allen M]

In both interrupt remapping and no interrupt remapping cases, interrupts from the passthrough device are still delivered to the host kernel.  KVM then injects the interrupt to guest via vlapic->vioapic->vmcs path.

The value add from interrupt remapping is that a new source ID field in interrupt remapping table entry is checked before the interrupt is delivered to the host kernel.  This prevents malicious guests with PCI passthrough devices to generate DOS attacks via DMA writes to the apic area.

-----Original Message-----
From: Fischer, Anna [mailto:anna.fischer@hp.com] 
Sent: Thursday, May 14, 2009 4:12 PM
To: Kay, Allen M
Cc: kvm@vger.kernel.org
Subject: RE: KVM & VT-d2?

I thought that one use case of VT-d2 interrupt remapping was to be able to safely and more efficiently deliver interrupts to the CPU that runs the particular VCPU of the guest that owns the I/O device that issues the interrupt. Shouldn't there at least be some performance (e.g. latency) improvement doing the remapping and checking in HW with a predefined table rather than multiplexing this in software in the hypervisor layer?

> -----Original Message-----
> From: Kay, Allen M [mailto:allen.m.kay@intel.com]
> Sent: 14 May 2009 15:02
> To: Fischer, Anna; kvm@vger.kernel.org
> Subject: RE: KVM & VT-d2?
> 
> We have verified VT-d2 features works with PCI passthrough on KVM.  To
> enable it, you need to turn on interrupt remapping in kernel config.
> 
> Interrupt remapping is a security/isolation feature where interrupt
> delivery is qualified with device's bus/device/function in interrupt
> remapping table entry when source ID checking is turn on.  It does not
> directly inject interrupt to the guest OS.
> 
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
> Behalf Of Fischer, Anna
> Sent: Thursday, May 14, 2009 2:53 PM
> To: kvm@vger.kernel.org
> Subject: KVM & VT-d2?
> 
> Does KVM already take advantage of Intel VT-d2 features, e.g. interrupt
> remapping support? Has anyone verified how it improves interrupt
> delivery for PCI pass-through devices?
> 
> Thanks,
> Anna
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM & VT-d2?

[Avi Kivity]

Fischer, Anna wrote:
> I thought that one use case of VT-d2 interrupt remapping was to be able to safely and more efficiently deliver interrupts to the CPU that runs the particular VCPU of the guest that owns the I/O device that issues the interrupt. Shouldn't there at least be some performance (e.g. latency) improvement doing the remapping and checking in HW with a predefined table rather than multiplexing this in software in the hypervisor layer?
>   

This can be done even without VT-d.  Since qemu knows how the guest 
affines its interrupts (via the MSI entry), it can affine the 
corresponding host interrupt.

Right now Linux can affine the host interrupt to a cpu; this requires 
periodic polling since the vcpu thread can move around.  It would be 
interesting to add an API to affine an interrupt to a thread, so 
whenever the thread is migrated to a different cpu, the interrupt 
follows it around.  I imagine it would be useful for non-virtualization 
applications as well.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.