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

RE: [Xen-ia64-devel] paravirt_ops and its alternatives


  • To: "Kouya Shimura" <kouya@xxxxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Tue, 5 Feb 2008 21:47:13 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 05 Feb 2008 05:49:51 -0800
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: Achn4bLpJPdvKPayTfim/PZgsGPM1wAGnEcw
  • Thread-topic: [Xen-ia64-devel] paravirt_ops and its alternatives

Kouya Shimura wrote:
> Dong, Eddie writes:
>>      3: irq chip paravirt_ops, xen irq chip or vSAPIC?
> 
> Is xen irqchip really necessary?

X86 side already pushed the xen irq chip into upstream, so I think
it should be easy to do same thing in IPF side.

> 
> In current PV implementation, an evtchn interrupt is injected and
> reflected directly to a guest OS. 
> See reflect_event()@xen-unstable.hg/xen/arch/ia64/xen/faults.c and
> xen_event_callback@xxxxxxxxxxxxxxxxxxx/arch/ia64/xen/xenivt.c 
> 

Yes, this is xen irq chip. It should have better performance than
vSAPIC.
We need to re-do this base on upstream xen riq chip code, + debug, it is
more than vSAPIC, but love to see going in this direction since x86
already
pushed it.

> There is no intermediate layer there.
> I think that the same mechanism can work in paravirt_ops.
> 
> Perhaps I might misunderstand something. :-)
> 

Just term difference :) basically we are talking about same thing.

thx, eddie

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

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