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

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 10/06/2015 11:13, Fabio Fantoni ha scritto:
> Il 09/06/2015 17:21, Paul Durrant ha scritto:
> > > -----Original Message-----
> > > From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> > > Sent: 09 June 2015 15:44
> > > To: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH 00/17] x86/hvm: I/O emulation 
> > > cleanup and
> > > fix
> > >
> > > Il 08/06/2015 16:33, 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 emulation18 branch) as follows:
> > > Big thanks for your work.
> > > I tested them taking the patches from emulation18 branch.
> > > I tried xl create of a window 7 domU but during xl create dom0
> > > istant-reboot and there isn't anything about the problem in the logs
> > > (kern.log, syslog, qemu log, xl log ecc...)
> > > I tried also with linux (hvm) domU and with stdvga instead qxl I had
> > > setted but same result.
> > >
> > > For debug the problem I must enable all xen debug in grub entry and
> > > redirect output to serial, similar to debug of dom0 boot problem or I
> > > must do different thing?
> > Having serial is very useful in these cases. I've been debugging with 
> > a 32-bit Win 7 VM so it would be useful if you could bisect bit. 
> > There are natural boundaries in the series you could try first:
> > Apply everything up to and including 'x86/hvm: unify stdvga mmio 
> > intercept with standard mmio intercept'
> > Then try everything up to and including ' x86/hvm: remove extraneous 
> > parameter from hvmtrace_io_assist()'
> > Then, if you get that far, try the rest one at a time.
> >
> >    Paul
Found the patch that cause dom0 insta-reboot:
 x86/hvm: remove multiple open coded 'chunking' loops in 
hvmemul_read/write()
In attachments also xl -vvv create output until the crash if can be 
useful, I not found useful information in logs after reboot :(
If you need more informations/tests tell me and I'll post them.

> Thanks for reply.
> I tried to boot with full debug enabled and with serial on lan but 
> server insta-reboot without show error or useful output on redirected 
> output or monitor.
> I used same parameters of other debug I did long time ago if I 
> remember good, here the grub2 entry:
> > menuentry 'Wheezy con Linux 3.16.0-0.bpo.4-amd64 e XEN - RAID - Debug 
> > su Seriale' --class debian --class gnu-linux --class gnu --class os {
> >     set root='(RAID-ROOT)'
> >     echo    'Caricamento Hypervisor Xen...'
> >     multiboot    /boot/xen.gz placeholder dom0_mem=2G,max:3G 
> > swiotlb=65762 loglvl=all guest_loglvl=all sync_console 
> > console_to_ring com2=19200,8n1 console=com2
> >     echo    'Caricamento Linux 3.16.0-0.bpo.4-amd64...'
> >     linux    /boot/vmlinuz-3.16.0-0.bpo.4-amd64 placeholder 
> > root=/dev/mapper/RAID-ROOT ro console=hvc0 earlyprintk=xen nomodeset
> >     echo    'Caricamento ramdisk iniziale...'
> >     initrd    /boot/initrd.img-3.16.0-0.bpo.4-amd64
> > }
> Here the entry without debug working:
> > menuentry 'RAID - Debian 7.8 (wheezy) con Linux 3.16.0-0.bpo.4-amd64 
> > e XEN 4.6-unstable' --class debian --class gnu-linux --class gnu 
> > --class os --class xen {
> >     set fallback="1"
> >     set root='(RAID-ROOT)'
> >     echo    'Caricamento Hypervisor Xen 4.6-unstable...'
> >     multiboot    /boot/xen.gz placeholder dom0_mem=2G,max:3G
> >     echo    'Caricamento Linux 3.16.0-0.bpo.4-amd64 ...'
> >     module    /boot/vmlinuz-3.16.0-0.bpo.4-amd64 placeholder 
> > root=/dev/mapper/RAID-ROOT ro swiotlb=65762 quiet
> >     echo    'Caricamento ramdisk iniziale...'
> >     module    /boot/initrd.img-3.16.0-0.bpo.4-amd64
> > }
> I did something wrong?
>
> Now I'll try to bisect the patch serie following your advice.
>
> > > Thanks for any reply and sorry for my bad english.
> > >
> > > > x86/hvm: simplify hvmemul_do_io()
> > > > x86/hvm: re-name struct hvm_mmio_handler to hvm_mmio_ops
> > > > x86/hvm: unify internal portio and mmio intercepts
> > > > x86/hvm: unify dpci portio intercept with standard portio intercept
> > > > x86/hvm: unify stdvga mmio intercept with standard mmio intercept
> > > > x86/hvm: revert 82ed8716b "fix direct PCI port I/O emulation retry...
> > > > x86/hvm: only call hvm_io_assist() from hvm_wait_for_io()
> > > > x86/hvm: split I/O completion handling from state model
> > > > x86/hvm: remove hvm_io_pending() check in hvmemul_do_io()
> > > > x86/hvm: remove HVMIO_dispatched I/O state
> > > > x86/hvm: remove hvm_io_state enumeration
> > > > x86/hvm: use ioreq_t to track in-flight state
> > > > x86/hvm: only acquire RAM pages for emulation when we need to
> > > > x86/hvm: remove extraneous parameter from hvmtrace_io_assist()
> > > > x86/hvm: make sure translated MMIO reads or writes fall within a page
> > > > x86/hvm: remove multiple open coded 'chunking' loops
> > > > x86/hvm: track large memory mapped accesses by linear address
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@xxxxxxxxxxxxx
> > > > http://lists.xen.org/xen-devel

Attachment: mmio-patches-problem.log
Description: Text document

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