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

Re: [Xen-devel] [PATCH] Simulates the MSIx table read operation


  • To: konrad.wilk@xxxxxxxxxx
  • From: Liu Yuan <yetiboy1230@xxxxxxxxx>
  • Date: Wed, 11 Aug 2010 00:04:15 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 12 Aug 2010 06:24:43 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=faJVb7LkwsmcaL2wG96KMijfwsNJmzUc5G6/lJs0AthzlVG/7hBDyPQkbXrJJukgRF 6nW4a4jcTibkNLZsGdsCl04gaHVPOaoIhbE9fxq3tu2YFl/Jvl4A9lmGTfRa9wc1TBDV BflS5YyA+3rEZ4pYtR37W3G+Y4ZYOrXUAFqgI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

>I am having a hard time understanding this.  Is the issue here that
>read/write of the MSI-X table is being done in QEMU, and it is much
>better to do so in the hypervisor which traps already the mask/unmaks
>operation so that QEMU is not overwhelmed by having to do this?

Yes, having QEMU do this read operation,it needs much more CPU cycles and longer latency.

[before patch]
read path: Guest -> Xen -> QEMU -> XEN -> Guest
[after patch]
read path: Guest -> Xen -> Guest

Xen traps all the MSIx table operation. And before this patch, only mask/unmask is simulated in
Xen. With this patch applied, READ will be simulated and WRITE will *still* be forwarded to QEMU.

>
>With this in patch in place, wouldn't QEMU still do the read operation?
No

Thanks,
Yuan

--
I am Multician, really
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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