[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
|
