Re: [Xen-devel] [PATCH v2 00/17] x86/hvm: I/O emulation cleanup and fix

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 11/06/2015 17:42, Paul Durrant ha scritto:
> This patch series re-works much of the code involved in emulation of port
> and memory mapped I/O for HVM guests.
>
> The code has become very convoluted and, at least by inspection, certain
> emulations will apparently malfunction.
>
> The series is broken down into 17 patches (which are also available in
> my xenbits repo: http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git
> on the emulation22 branch) as follows:
>
> 0001-x86-hvm-simplify-hvmemul_do_io.patch
> 0002-x86-hvm-re-name-struct-hvm_mmio_handler-to-hvm_mmio_.patch
> 0003-x86-hvm-unify-internal-portio-and-mmio-intercepts.patch
> 0004-x86-hvm-unify-dpci-portio-intercept-with-standard-po.patch
> 0005-x86-hvm-unify-stdvga-mmio-intercept-with-standard-mm.patch
> 0006-x86-hvm-revert-82ed8716b-fix-direct-PCI-port-I-O-emu.patch
> 0007-x86-hvm-only-call-hvm_io_assist-from-hvm_wait_for_io.patch
> 0008-x86-hvm-split-I-O-completion-handling-from-state-mod.patch
> 0009-x86-hvm-remove-hvm_io_pending-check-in-hvmemul_do_io.patch
> 0010-x86-hvm-remove-HVMIO_dispatched-I-O-state.patch
> 0011-x86-hvm-remove-hvm_io_state-enumeration.patch
> 0012-x86-hvm-use-ioreq_t-to-track-in-flight-state.patch
> 0013-x86-hvm-only-acquire-RAM-pages-for-emulation-when-we.patch
> 0014-x86-hvm-remove-extraneous-parameter-from-hvmtrace_io.patch
> 0015-x86-hvm-make-sure-translated-MMIO-reads-or-writes-fa.patch
> 0016-x86-hvm-remove-multiple-open-coded-chunking-loops.patch
> 0017-x86-hvm-track-large-memory-mapped-accesses-by-buffer.patch
>
> v2:
>   - Removed bogus assertion from patch 16
>   - Re-worked patch 17 after basic testing of back-port onto XenServer
Thanks, I confirm that this new version solves the critical regression 
that causes dom0 insta-reboot.
I tested them on windows and linux hvm domUs, I had strange results...
On windows 7 64 bit sp1 domU (with new winpv drivers) seems there are a 
small performance regression (or probably "only" latency increased) but 
I not found warning/error or something userful in logs, I'm not sure is 
real regression of your patches, if needed I'll retry without.
On linux domU (fedora 21) qxl that had sse2 instructions problem still 
not working, same of latest 2 years not always qemu crash with a gdb 
showing sse2 instruction problem but xorg crash with EQ overflowing 
and/or domU remain with 100% cpu used by xorg qemu process at 100% cpu.
I posted the backtrace similar time ago and a qemu/spice developer told 
that was a conseguence of other problem if I remember good.
How can I be sure that sse2 or similar istructions (with videoram) are 
now working correctly?
If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel