|
[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, Yang _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |