[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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_server (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 (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=refs/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 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. M.C> Paul-George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |