[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Xenhackthon] Virtualized APIC registers - virtual interrupt delivery.

Konrad Rzeszutek Wilk wrote on 2013-05-24:
> On Thu, May 23, 2013 at 08:25:06AM +0000, Zhang, Yang Z wrote:
>> Jan Beulich wrote on 2013-05-23:
>>>>>> On 22.05.13 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>> wrote:
>>>> Which means that if this is set to be higher than the hypervisor timer
>>>> or IPI callback the guest can run unbounded. Also it would seem that
>>>> this value has to be often reset when migrating a guest between the pCPUs.
>>>> And it would appear that this value is static. Meaning the guest only
>>>> sets these vectors once and the hypervisor is responsible for managing
>>>> the priority of that guest and other guests (say dom0) on the CPU.
>>>> For example, we have a guest with a 10gB NIC and the guest has
>>>> decided to use vector 0x80 for it (assume a UP guest). Dom0 has an
>>>> SAS controller and is using event number 30, 31, 32, and 33 (there
>>>> are only 4 PCPUS). The hypervisor maps them to be 0x58, 0x68, 0x78
>>>> and 0x88 and spreads those vectors on each pCPU. The guest is running
>>>> on pCPU1 and there are two vectors - 0x80 and 0x58. The one assigned
>>>> to the guest wins and dom0 SAS controller is preempted.
>>>> The solution for that seems to have some interaction with the
>>>> guest when it allocates the vectors so that they are always below
>>>> the dom0 priority vectors. Or hypervisor has to dynamically shuffle its
>>>> own vectors to be higher priority.
>>>> Or is there an guest vector <-> hypervisor vector lookup table that
>>>> the CPU can use? So the hypervisor can say: the vector 0x80 in the
>>>> guest actually maps to vector 0x48 in the hypervisor?
>>> It is my understanding that the vector spaces are separate, and
>>> hence guest interrupts can't block host ones (like the timer). Iirc
>> Right. virtual interrupt delivery only for delivering guest virtual 
>> interrupt(from
> emulation device and assigned device.) which is located in guest's vector 
> space. It
> has nothing to do with other guest.
> OK, in which case Linux ~v2.6.32 (when the event callback mechanism was
> introduced for HVM guests) will _not_ take advantage of this, right?
Yes, event mechanism cannot benefit from it.

> Is there a way to solve this so that they _will_ take advantage of this.
Perhaps not. virtual interrupt delivery relies on EOI logic to inject the 
pending interrupt. But event channel doesn't have such mechanism.

>>> there's some sort of flag bit in the IRTE to tell whether an interrupt
>>> should get delivered directly to the guest, or to the hypervisor.
>> I think you are talking about Posted interrupt.
>>> Jan
>>> Jan
>> Best regards,
>> Yang
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel

Best regards,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.