Re: [Xen-devel] (v2) VT-d Posted-interrupt (PI) design for XEN

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Konrad Rzeszutek Wilk wrote on 2015-03-19:
> On Wed, Mar 18, 2015 at 12:44:21PM +0000, Wu, Feng wrote:
>> VT-d Posted-interrupt (PI) design for XEN
>> 
>> Background
>> ==========
>> With the development of virtualization, there are more and more
>> device assignment requirements. However, today when a VM is running
>> with assigned devices (such as, NIC), external interrupt handling
>> for the assigned devices always needs VMM intervention.
>> 
>> VT-d Posted-interrupt is a more enhanced method to handle interrupts
>> in the virtualization environment. Interrupt posting is the process
>> by which an interrupt request is recorded in a memory-resident
>> posted-interrupt-descriptor structure by the root-complex, followed
>> by an optional notification event issued to the CPU complex.
>> 
>> With VT-d Posted-interrupt we can get the following advantages:
>> - Direct delivery of external interrupts to running vCPUs without
>> VMM intervention
> 
> 
> I hadn't digged deep in what Xen has currently - but I would assume
> that this is exactly what we have now in Xen?
> 
> Hm, actually we seem to be still invoking the hypervisor on the
> interrupts -except that if we need to dispatch it to another CPU using
> an normal vector to do so - which would still cause the hypervisor to
> be invoked? Or does it actually go straight in the guest?
> 
> So what kind of support do we currently have in Xen from posted interrupt?
> Could you add a bit about this in the background please?

All virtual interrupts are delivered through CPU side posted interrupt 
regardless the VT-d side PI supporting. The difference is: W/o VT-side PI 
supporting, for the interrupt of assigned device, we deliver it to another 
CPU(different from the CPU which target vcpu is running) and then use PI to 
deliver it to eliminate the vmexit. With VT-d side PI supporting, the interrupt 
is able to be delivered to guest directly without any other CPU's involvement 
and vmexit. 

Is it clear?

> 


Best regards,
Yang


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel