[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 0/7] PV on HVM: receive interrupts as xen events
On Thu, 2 Sep 2010, Jeremy Fitzhardinge wrote: > On 08/30/2010 04:20 AM, Stefano Stabellini wrote: > > Hi all, > > this patch series introduces some performance improvements for xen PV on > > HVM guests: interacting with the emulated APIC is slow because it causes > > traps in the hypervisor while receiving xen events using the vector callback > > mechanism allow us to skip all that. For this reason we remap interrupts > > and MSIs into xen pirqs so that from that point on we can receive them > > as xen events instead. > > This series is based on Konrad's pcifront series (not upstream yet): > > > > http://lkml.org/lkml/2010/8/4/374 > > > > and requires a patch to xen and a patch to qemu-xen (just sent to > > xen-devel). > > My only concern with this series is the pirq remapping stuff. Why do > pirq and irq need to be non-identical? Is it because pirq is a global > namespace, and dom0 has already assigned it? > > Why do guests need to know about max pirq? Would it be better to make > Xen use a more dynamic structure for pirqs so that any arbitrary value > can be used? > No, pirq is a per-domain namespace, but pirq and irq are conceptually different: pirqs are used by xen as a reference for interrupts of devices assigned to the guest, while linux uses irqs for its internal purposes. The pirq namespace is chosen by xen while the linux irq namespace is chosen by linux. Linux is allowed to choose the pirq number it wants when mapping an interrupt, this is why linux needs to know the max pirq, so that it can safely chose a pirq that is in the allowed range. The difference between pirqs and linux irqs increases when we talk about PV on HVM guests: in this case qemu also maps interrupts in the guests getting pirqs in return, so the linux kernel has to be able to cope with already assigned pirq numbers. The current PHYSDEVOP_map_pirq interface is already flexible enough for that because it provides the possibility for the caller to let xen choose the pirq, something that linux never does in the pure PV case, but it is still possible. Obviously if you let xen choose the pirq number you are safe from conflicts but you must be able to cope with pirq numbers different from linux irq numbers. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |