Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Martin Cerveny [mailto:martin@xxxxxxxxx]
> Sent: 28 April 2016 12:17
> To: Paul Durrant
> Cc: George Dunlap; Martin Cerveny; xen-devel@xxxxxxxxxxxxxxxxxxx; Paolo
> Bonzini
> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
> 
> Hello.
> 
> On Thu, 28 Apr 2016, Paul Durrant wrote:
> 
> >> -----Original Message-----
> >> From: George Dunlap
> >> Sent: 28 April 2016 09:51
> >> To: Martin Cerveny
> >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Paolo Bonzini; Paul Durrant
> >> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> >> (Xen4.6.1)
> >>
> >> On Wed, Apr 27, 2016 at 8:38 PM, Martin Cerveny <martin@xxxxxxxxx>
> >> wrote:
> >>> Hello.
> >>>
> >>> I have problem with multiple ioreq_servers
> >>> server 1 (emulates VGA) and server 2 (qemu).
> >>>
> >>> Emulation VGA server maps VGA PIO registers (3c0-3cf, 3b4-3b5 ...)
> >>> Qemu maps "all" PIO space (0-ffff)
> >>> (ref:
> >>> http://xenbits.xen.org/gitweb/?p=qemu-
> >>
> xen.git;a=blob;f=exec.c;h=46fe70ed49f85d0638061aa5b09f1f9d521b0bd3;hb
> >> =18f2ce4bfe67f9b38143d9d96207e49c92b6881c#l2007
> >>> )
> >>> Xen does not check overlap errors between ioreq_servers
> >>> (ref:
> >>>
> >>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm
> >>
> .c;h=186e01e3b05a0264e8f4538b226da2feed50d11a;hb=d77bac5c064ffb9dbb
> >> 5b89b55b89853f1b784ebf#l1252
> >>> )
> >>> Xen choose "first match"
> >>> (ref:
> >>>
> >>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm
> >>
> .c;h=186e01e3b05a0264e8f4538b226da2feed50d11a;hb=d77bac5c064ffb9dbb
> >> 5b89b55b89853f1b784ebf#l2594
> >>> )
> >>>
> >>> In my case all requests to VGA PIO are sent to qemu (qemu VGA is
> disabled
> >>> with parameter "-display none"/"-vga none") and dropped.
> >>> Emulation VGA server receives only memory updates (eg. a0000-bffff).
> >>>
> >>> Is this problem resolved in updates (actual code looks the same
> (ioreq.c)) ?
> >>> Is there any prioritization between ioreq_servers (but it is probably bad
> >>> idea) ?
> >>> Should the IO mapping check overlap between ioreq_servers (but it is
> >>> probably bad idea) ?
> >>> Should the qemu IO map only emulated areas (why it needs all ?) ?
> >>
> >> I think the idea was that devicemodels should only request IO ports
> >> for devices they actually intend to emulate.  It sounds like this is
> >> an unfinished implementation inside of qemu.
> >>
> >
> > Does QEMU really map all of PIO space? That's not the behaviour I
> observed last time I looked. The memory_region_init_io() function just
> initializes QEMU's internal handlers IIRC; I think the IO ranges get 
> registered
> with Xen when the individual device models initialize. If you look in
> xen_common.h (in QEMU) then you'll note that there are tracepoints on all
> the map/unmap calls, so if you use an events list such as the following:
> >
> > xen_map_mmio_range
> > xen_unmap_mmio_range
> > xen_map_portio_range
> > xen_unmap_portio_range
> > xen_map_pcidev
> > xen_unmap_pcidev
> > xen_ioreq_server_create
> > xen_ioreq_server_destroy
> > xen_ioreq_server_state
> >
> > then you'll be able to see all the individual range registrations and
> deregistrations as well the ioreq server lifecycle.
> 
> Yes, I traced the problem. Used
> hvm_map_io_range_to_ioreq_server/hvm_unmap_io_range_from_ioreq_s
> erver
> (type, start, end).
> 
> My iorq_server begin:
> 
> (XEN) XXX map: 1 a0000 affff
> (XEN) XXX map: 1 b0000 bffff
> (XEN) XXX map: 0 3c0 3cf
> (XEN) XXX map: 0 3b4 3b5
> (XEN) XXX map: 0 3d4 3d5
> (XEN) XXX map: 0 3ba 3ba
> (XEN) XXX map: 0 3da 3da
> (XEN) XXX map: 0 1ce 1d1
> (XEN) XXX map: 0 ff80 ff83
> 
> Qemu continues:
> 
> ....
> (XEN) XXX map: 0 0 ffff <----- cited ref
> (XEN) XXX map: 1 fee00000 feefffff
> (XEN) XXX unmap: 0 0 ffff
> (XEN) XXX map: 0 0 cf7
> (XEN) XXX map: 0 cf8 cfb
> (XEN) XXX map: 0 cfc ffff
> (XEN) XXX unmap: 0 cfc ffff  <----- constatnly remapping to fill the unused
> space
> (XEN) XXX map: 0 cfc cff
> (XEN) XXX map: 0 d00 ffff

... and again here. That really needs fixing.

> (XEN) XXX map: 2 0 0
> (XEN) XXX unmap: 0 cf8 cfb
> (XEN) XXX map: 0 cf8 cf8
> (XEN) XXX map: 0 cf9 cf9
> (XEN) XXX map: 0 cfa cfb
> ...
> (XEN) XXX unmap: 0 3f6 3f6
> (XEN) XXX map: 0 3f6 3f6
> (XEN) XXX unmap: 0 f1 1ef
> (XEN) XXX map: 0 f1 16f
> (XEN) XXX map: 0 170 177
> (XEN) XXX map: 0 178 1ef
> (XEN) XXX unmap: 0 1f8 3f0
> (XEN) XXX map: 0 1f8 375
> (XEN) XXX map: 0 376 376
> (XEN) XXX map: 0 377 3f0 <----- final mapped range (colision to vga)
> (XEN) XXX map: 2 9 9
> ....
> 
> > FWIW, I have my own vga/kbd/mouse emulator which I've happily used
> alongside QEMU (see
> http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git;a=shortlog;h=re
> fs/heads/console), although it's been a while since I last tested it.
> 
> Maybe you are lucky, qemu is registered before your own demu emulator.

I guess I was lucky.

> I used for testing your "demu" 2 years ago, now extending Citrix "vgpu",
> all was fine up to xen 4.5.2 (with qemu 2.0.2) but problem begin when I
> switched to 4.6.1 (with qemu 2.2.1), but it maybe lucky timing in
> registration.

I think Xen should really be spotting range overlaps like this, but the 
QEMU<->Xen interface will clearly need to be fixed to avoid the over-claiming 
of I/O ports like this.

  Paul

> 
> M.C>
> 
> >  Paul
> >
> >>  -George
> >

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