From: Paul Durrant <Paul.Durrant@citrix.com>
To: George Dunlap <George.Dunlap@citrix.com>,
Martin Cerveny <M.Cerveny@computer.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
Date: Thu, 28 Apr 2016 09:46:57 +0000 [thread overview]
Message-ID: <2207476cf32b4e8fad39374a6ebd8a1f@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <CAFLBxZYVjs+sKVz51ycWaA64yQxysAG_P4UT7qLV9fxjn3UnAA@mail.gmail.com>
> -----Original Message-----
> From: George Dunlap
> Sent: 28 April 2016 09:51
> To: Martin Cerveny
> Cc: xen-devel@lists.xensource.com; 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@c-home.cz>
> 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.
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.
Paul
> -George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-28 9:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 19:38 Overlaped PIO with multiple ioreq_server (Xen4.6.1) Martin Cerveny
2016-04-28 8:50 ` George Dunlap
2016-04-28 9:46 ` Paul Durrant [this message]
2016-04-28 11:16 ` Martin Cerveny
2016-04-28 11:25 ` Paul Durrant
2016-05-09 12:55 ` Paolo Bonzini
2016-05-09 12:59 ` Paul Durrant
2016-05-09 16:02 ` Paul Durrant
2016-05-09 16:14 ` Paul Durrant
2016-05-09 16:18 ` Paolo Bonzini
2016-05-09 16:19 ` Paul Durrant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2207476cf32b4e8fad39374a6ebd8a1f@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=George.Dunlap@citrix.com \
--cc=M.Cerveny@computer.org \
--cc=pbonzini@redhat.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).