All of lore.kernel.org
 help / color / mirror / Atom feed
* Overlaped PIO with multiple ioreq_server (Xen4.6.1)
@ 2016-04-27 19:38 Martin Cerveny
  2016-04-28  8:50 ` George Dunlap
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Cerveny @ 2016-04-27 19:38 UTC (permalink / raw)
  To: xen-devel; +Cc: pbonzini, paul.durrant

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1601 bytes --]

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=d77bac5c064ffb9dbb5b89b55b89853f1b784ebf#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=d77bac5c064ffb9dbb5b89b55b89853f1b784ebf#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 ?) ?
Any other solution ?

Thanks for answers, Martin Cerveny

PS: I programmed workaround to select sever with smaller mapped range (attached).

CC: Paolo Bonzini <pbonzini@redhat.com> - Maintainer qemu - exec.c
CC: Paul Durrant <paul.durrant@citrix.com> - Maintainer X86 I/O EMULATION - ioreq.c

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2977 bytes --]

--- /root/src/xen/xen/arch/x86/hvm/hvm.c	2016-04-20 23:15:33.728000000 +0200
+++ xen-4.6.1/xen/arch/x86/hvm/hvm.c	2016-04-25 14:58:40.040000000 +0200
@@ -2524,6 +2524,9 @@
     uint8_t type;
     uint64_t addr;
 
+    uint64_t range_best = ~0ull;
+    struct hvm_ioreq_server *s_best = NULL;
+
     if ( list_empty(&d->arch.hvm_domain.ioreq_server.list) )
         return NULL;
 
@@ -2572,6 +2575,7 @@
                           list_entry )
     {
         struct rangeset *r;
+        uint64_t _range;
 
         if ( s == d->arch.hvm_domain.default_ioreq_server )
             continue;
@@ -2590,14 +2594,24 @@
 
         case IOREQ_TYPE_PIO:
             end = addr + p->size - 1;
-            if ( rangeset_contains_range(r, addr, end) )
-                return s;
+            if ( 0 < (_range = rangeset_contains_range_size(r, addr, end)) ) {
+                if (_range < range_best) {
+                    s_best = s;
+                    range_best = _range;
+                }
+                continue;
+            }
 
             break;
         case IOREQ_TYPE_COPY:
             end = addr + (p->size * p->count) - 1;
-            if ( rangeset_contains_range(r, addr, end) )
-                return s;
+            if ( 0 < (_range = rangeset_contains_range_size(r, addr, end)) ) {
+                if (_range < range_best) {
+                    s_best = s;
+                    range_best = _range;
+                }
+                continue;
+            }
 
             break;
         case IOREQ_TYPE_PCI_CONFIG:
@@ -2611,6 +2625,10 @@
             break;
         }
     }
+    
+
+    if (s_best) 
+        return s_best;
 
     return d->arch.hvm_domain.default_ioreq_server;
 }
--- /root/src/xen/xen/include/xen/rangeset.h	2016-04-18 13:15:29.828000000 +0200
+++ xen-4.6.1/xen/include/xen/rangeset.h	2016-04-25 13:12:57.203994380 +0200
@@ -67,6 +67,8 @@
 int rangeset_report_ranges(
     struct rangeset *r, unsigned long s, unsigned long e,
     int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
+unsigned long rangeset_contains_range_size(
+    struct rangeset *r, unsigned long s, unsigned long e);
 
 /* Add/remove/query a single number. */
 int __must_check rangeset_add_singleton(
--- /root/src/xen/xen/common/rangeset.c	2016-04-18 13:15:29.740000000 +0200
+++ xen-4.6.1/xen/common/rangeset.c	2016-04-25 13:12:57.203994380 +0200
@@ -264,6 +264,23 @@
     return contains;
 }
 
+unsigned long rangeset_contains_range_size(
+    struct rangeset *r, unsigned long s, unsigned long e)
+{
+    struct range *x;
+    unsigned long size;
+
+    ASSERT(s <= e);
+
+    read_lock(&r->lock);
+    x = find_range(r, s);
+    if (x && (x->e >= e)) size = x->e - x->s + 1;
+    else size = 0;
+    read_unlock(&r->lock);
+
+    return size;
+}
+
 bool_t rangeset_overlaps_range(
     struct rangeset *r, unsigned long s, unsigned long e)
 {

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  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
  0 siblings, 1 reply; 11+ messages in thread
From: George Dunlap @ 2016-04-28  8:50 UTC (permalink / raw)
  To: Martin Cerveny; +Cc: Paolo Bonzini, xen-devel, Paul Durrant

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=d77bac5c064ffb9dbb5b89b55b89853f1b784ebf#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=d77bac5c064ffb9dbb5b89b55b89853f1b784ebf#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.

 -George

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-04-28  8:50 ` George Dunlap
@ 2016-04-28  9:46   ` Paul Durrant
  2016-04-28 11:16     ` Martin Cerveny
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2016-04-28  9:46 UTC (permalink / raw)
  To: George Dunlap, Martin Cerveny; +Cc: Paolo Bonzini, xen-devel

> -----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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-04-28  9:46   ` Paul Durrant
@ 2016-04-28 11:16     ` Martin Cerveny
  2016-04-28 11:25       ` Paul Durrant
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Cerveny @ 2016-04-28 11:16 UTC (permalink / raw)
  To: Paul Durrant; +Cc: Paolo Bonzini, xen-devel, George Dunlap, Martin Cerveny

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@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.

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@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-04-28 11:16     ` Martin Cerveny
@ 2016-04-28 11:25       ` Paul Durrant
  2016-05-09 12:55         ` Paolo Bonzini
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2016-04-28 11:25 UTC (permalink / raw)
  To: Martin Cerveny; +Cc: Paolo Bonzini, xen-devel, George Dunlap

> -----Original Message-----
> From: Martin Cerveny [mailto:martin@c-home.cz]
> Sent: 28 April 2016 12:17
> To: Paul Durrant
> Cc: George Dunlap; Martin Cerveny; xen-devel@lists.xensource.com; 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@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.
> 
> 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@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-04-28 11:25       ` Paul Durrant
@ 2016-05-09 12:55         ` Paolo Bonzini
  2016-05-09 12:59           ` Paul Durrant
  0 siblings, 1 reply; 11+ messages in thread
From: Paolo Bonzini @ 2016-05-09 12:55 UTC (permalink / raw)
  To: Paul Durrant, Martin Cerveny; +Cc: xen-devel, George Dunlap



On 28/04/2016 13:25, Paul Durrant wrote:
>> Maybe you are lucky, qemu is registered before your own demu
>> emulator.
> 
> I guess I was lucky.

Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
Provide separate handling of unassigned io ports accesses", 2013-09-05).

>> 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.

If the handling of unassigned I/O ports is sane in Xen (in QEMU they
return all ones and discard writes), it would be okay to make the
background 0-65535 range conditional on !xen_enabled().  See
memory_map_init() in QEMU's exec.c file.

Paolo

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-05-09 12:55         ` Paolo Bonzini
@ 2016-05-09 12:59           ` Paul Durrant
  2016-05-09 16:02             ` Paul Durrant
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2016-05-09 12:59 UTC (permalink / raw)
  To: Paolo Bonzini, Martin Cerveny; +Cc: xen-devel, George Dunlap

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: 09 May 2016 13:56
> To: Paul Durrant; Martin Cerveny
> Cc: George Dunlap; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
> 
> 
> 
> On 28/04/2016 13:25, Paul Durrant wrote:
> >> Maybe you are lucky, qemu is registered before your own demu
> >> emulator.
> >
> > I guess I was lucky.
> 
> Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
> Provide separate handling of unassigned io ports accesses", 2013-09-05).
> 
> >> 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.
> 
> If the handling of unassigned I/O ports is sane in Xen (in QEMU they
> return all ones and discard writes),

Yes, it does exactly that.

> it would be okay to make the
> background 0-65535 range conditional on !xen_enabled().  See
> memory_map_init() in QEMU's exec.c file.
> 

Cool. Thanks for the tip. Will have a look at that now.

Cheers,

  Paul

> Paolo

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-05-09 12:59           ` Paul Durrant
@ 2016-05-09 16:02             ` Paul Durrant
  2016-05-09 16:14               ` Paul Durrant
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2016-05-09 16:02 UTC (permalink / raw)
  To: Paul Durrant, Paolo Bonzini, Martin Cerveny; +Cc: xen-devel, George Dunlap

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 09 May 2016 14:00
> To: Paolo Bonzini; Martin Cerveny
> Cc: xen-devel@lists.xensource.com; George Dunlap
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
> 
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > Sent: 09 May 2016 13:56
> > To: Paul Durrant; Martin Cerveny
> > Cc: George Dunlap; xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> > (Xen4.6.1)
> >
> >
> >
> > On 28/04/2016 13:25, Paul Durrant wrote:
> > >> Maybe you are lucky, qemu is registered before your own demu
> > >> emulator.
> > >
> > > I guess I was lucky.
> >
> > Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
> > Provide separate handling of unassigned io ports accesses", 2013-09-05).
> >
> > >> 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.
> >
> > If the handling of unassigned I/O ports is sane in Xen (in QEMU they
> > return all ones and discard writes),
> 
> Yes, it does exactly that.
> 
> > it would be okay to make the
> > background 0-65535 range conditional on !xen_enabled().  See
> > memory_map_init() in QEMU's exec.c file.
> >
> 
> Cool. Thanks for the tip. Will have a look at that now.
> 

Looks like creation of the background range is required. (Well, when I simply #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to be able to spot, from the memory listener callback in Xen, when a background range is being added so it can be ignored. Same actually goes for memory as well as I/O, since Xen will handle access to unimplemented MMIO ranges in a similar fashion.

  Paul 

> Cheers,
> 
>   Paul
> 
> > Paolo
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-05-09 16:02             ` Paul Durrant
@ 2016-05-09 16:14               ` Paul Durrant
  2016-05-09 16:18                 ` Paolo Bonzini
  0 siblings, 1 reply; 11+ messages in thread
From: Paul Durrant @ 2016-05-09 16:14 UTC (permalink / raw)
  To: Paolo Bonzini, Martin Cerveny; +Cc: xen-devel, George Dunlap

> -----Original Message-----
> From: Paul Durrant
> Sent: 09 May 2016 17:02
> To: Paul Durrant; Paolo Bonzini; Martin Cerveny
> Cc: xen-devel@lists.xensource.com; George Dunlap
> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
> 
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> > Paul Durrant
> > Sent: 09 May 2016 14:00
> > To: Paolo Bonzini; Martin Cerveny
> > Cc: xen-devel@lists.xensource.com; George Dunlap
> > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> > (Xen4.6.1)
> >
> > > -----Original Message-----
> > > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > > Sent: 09 May 2016 13:56
> > > To: Paul Durrant; Martin Cerveny
> > > Cc: George Dunlap; xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> > > (Xen4.6.1)
> > >
> > >
> > >
> > > On 28/04/2016 13:25, Paul Durrant wrote:
> > > >> Maybe you are lucky, qemu is registered before your own demu
> > > >> emulator.
> > > >
> > > > I guess I was lucky.
> > >
> > > Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
> > > Provide separate handling of unassigned io ports accesses", 2013-09-05).
> > >
> > > >> 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.
> > >
> > > If the handling of unassigned I/O ports is sane in Xen (in QEMU they
> > > return all ones and discard writes),
> >
> > Yes, it does exactly that.
> >
> > > it would be okay to make the
> > > background 0-65535 range conditional on !xen_enabled().  See
> > > memory_map_init() in QEMU's exec.c file.
> > >
> >
> > Cool. Thanks for the tip. Will have a look at that now.
> >
> 
> Looks like creation of the background range is required. (Well, when I simply
> #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to be
> able to spot, from the memory listener callback in Xen, when a background
> range is being added so it can be ignored. Same actually goes for memory as
> well as I/O, since Xen will handle access to unimplemented MMIO ranges in a
> similar fashion.
> 

In fact, this patch seems to do the trick for I/O:

diff --git a/xen-hvm.c b/xen-hvm.c
index 039680a..8ab44f0 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener,
                        MemoryRegionSection *section)
 {
     XenIOState *state = container_of(listener, XenIOState, io_listener);
+    MemoryRegion *mr = section->mr;

-    memory_region_ref(section->mr);
+    if (mr->ops == &unassigned_io_ops)
+        return;
+
+    memory_region_ref(mr);

     xen_map_io_section(xen_xc, xen_domid, state->ioservid, section);
 }
@@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener,
                        MemoryRegionSection *section)
 {
     XenIOState *state = container_of(listener, XenIOState, io_listener);
+    MemoryRegion *mr = section->mr;
+
+    if (mr->ops == &unassigned_io_ops)
+        return;

     xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section);

-    memory_region_unref(section->mr);
+    memory_region_unref(mr);
 }

  Paul

>   Paul
> 
> > Cheers,
> >
> >   Paul
> >
> > > Paolo
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-05-09 16:14               ` Paul Durrant
@ 2016-05-09 16:18                 ` Paolo Bonzini
  2016-05-09 16:19                   ` Paul Durrant
  0 siblings, 1 reply; 11+ messages in thread
From: Paolo Bonzini @ 2016-05-09 16:18 UTC (permalink / raw)
  To: Paul Durrant, Martin Cerveny; +Cc: xen-devel, George Dunlap



On 09/05/2016 18:14, Paul Durrant wrote:
>> -----Original Message-----
>> From: Paul Durrant
>> Sent: 09 May 2016 17:02
>> To: Paul Durrant; Paolo Bonzini; Martin Cerveny
>> Cc: xen-devel@lists.xensource.com; George Dunlap
>> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
>> (Xen4.6.1)
>>
>>> -----Original Message-----
>>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
>>> Paul Durrant
>>> Sent: 09 May 2016 14:00
>>> To: Paolo Bonzini; Martin Cerveny
>>> Cc: xen-devel@lists.xensource.com; George Dunlap
>>> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
>>> (Xen4.6.1)
>>>
>>>> -----Original Message-----
>>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>>>> Sent: 09 May 2016 13:56
>>>> To: Paul Durrant; Martin Cerveny
>>>> Cc: George Dunlap; xen-devel@lists.xensource.com
>>>> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
>>>> (Xen4.6.1)
>>>>
>>>>
>>>>
>>>> On 28/04/2016 13:25, Paul Durrant wrote:
>>>>>> Maybe you are lucky, qemu is registered before your own demu
>>>>>> emulator.
>>>>>
>>>>> I guess I was lucky.
>>>>
>>>> Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
>>>> Provide separate handling of unassigned io ports accesses", 2013-09-05).
>>>>
>>>>>> 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.
>>>>
>>>> If the handling of unassigned I/O ports is sane in Xen (in QEMU they
>>>> return all ones and discard writes),
>>>
>>> Yes, it does exactly that.
>>>
>>>> it would be okay to make the
>>>> background 0-65535 range conditional on !xen_enabled().  See
>>>> memory_map_init() in QEMU's exec.c file.
>>>>
>>>
>>> Cool. Thanks for the tip. Will have a look at that now.
>>>
>>
>> Looks like creation of the background range is required. (Well, when I simply
>> #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to be
>> able to spot, from the memory listener callback in Xen, when a background
>> range is being added so it can be ignored. Same actually goes for memory as
>> well as I/O, since Xen will handle access to unimplemented MMIO ranges in a
>> similar fashion.
>>
> 
> In fact, this patch seems to do the trick for I/O:
> 
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 039680a..8ab44f0 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener,
>                         MemoryRegionSection *section)
>  {
>      XenIOState *state = container_of(listener, XenIOState, io_listener);
> +    MemoryRegion *mr = section->mr;
> 
> -    memory_region_ref(section->mr);
> +    if (mr->ops == &unassigned_io_ops)
> +        return;
> +
> +    memory_region_ref(mr);
> 
>      xen_map_io_section(xen_xc, xen_domid, state->ioservid, section);
>  }
> @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener,
>                         MemoryRegionSection *section)
>  {
>      XenIOState *state = container_of(listener, XenIOState, io_listener);
> +    MemoryRegion *mr = section->mr;
> +
> +    if (mr->ops == &unassigned_io_ops)
> +        return;
> 
>      xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section);
> 
> -    memory_region_unref(section->mr);
> +    memory_region_unref(mr);
>  }

Looks good, feel free to Cc me if you send it to qemu-devel (though I'll
let Anthony merge it).

Paolo

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Overlaped PIO with multiple ioreq_server (Xen4.6.1)
  2016-05-09 16:18                 ` Paolo Bonzini
@ 2016-05-09 16:19                   ` Paul Durrant
  0 siblings, 0 replies; 11+ messages in thread
From: Paul Durrant @ 2016-05-09 16:19 UTC (permalink / raw)
  To: Paolo Bonzini, Martin Cerveny; +Cc: xen-devel, George Dunlap

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: 09 May 2016 17:18
> To: Paul Durrant; Martin Cerveny
> Cc: xen-devel@lists.xensource.com; George Dunlap
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
> 
> 
> 
> On 09/05/2016 18:14, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Paul Durrant
> >> Sent: 09 May 2016 17:02
> >> To: Paul Durrant; Paolo Bonzini; Martin Cerveny
> >> Cc: xen-devel@lists.xensource.com; George Dunlap
> >> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
> >> (Xen4.6.1)
> >>
> >>> -----Original Message-----
> >>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf
> Of
> >>> Paul Durrant
> >>> Sent: 09 May 2016 14:00
> >>> To: Paolo Bonzini; Martin Cerveny
> >>> Cc: xen-devel@lists.xensource.com; George Dunlap
> >>> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> >>> (Xen4.6.1)
> >>>
> >>>> -----Original Message-----
> >>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> >>>> Sent: 09 May 2016 13:56
> >>>> To: Paul Durrant; Martin Cerveny
> >>>> Cc: George Dunlap; xen-devel@lists.xensource.com
> >>>> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> >>>> (Xen4.6.1)
> >>>>
> >>>>
> >>>>
> >>>> On 28/04/2016 13:25, Paul Durrant wrote:
> >>>>>> Maybe you are lucky, qemu is registered before your own demu
> >>>>>> emulator.
> >>>>>
> >>>>> I guess I was lucky.
> >>>>
> >>>> Yeah, QEMU has been doing that since 2013 (commit 3bb28b7,
> "memory:
> >>>> Provide separate handling of unassigned io ports accesses", 2013-09-
> 05).
> >>>>
> >>>>>> 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.
> >>>>
> >>>> If the handling of unassigned I/O ports is sane in Xen (in QEMU they
> >>>> return all ones and discard writes),
> >>>
> >>> Yes, it does exactly that.
> >>>
> >>>> it would be okay to make the
> >>>> background 0-65535 range conditional on !xen_enabled().  See
> >>>> memory_map_init() in QEMU's exec.c file.
> >>>>
> >>>
> >>> Cool. Thanks for the tip. Will have a look at that now.
> >>>
> >>
> >> Looks like creation of the background range is required. (Well, when I
> simply
> >> #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to
> be
> >> able to spot, from the memory listener callback in Xen, when a
> background
> >> range is being added so it can be ignored. Same actually goes for memory
> as
> >> well as I/O, since Xen will handle access to unimplemented MMIO ranges
> in a
> >> similar fashion.
> >>
> >
> > In fact, this patch seems to do the trick for I/O:
> >
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 039680a..8ab44f0 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener,
> >                         MemoryRegionSection *section)
> >  {
> >      XenIOState *state = container_of(listener, XenIOState, io_listener);
> > +    MemoryRegion *mr = section->mr;
> >
> > -    memory_region_ref(section->mr);
> > +    if (mr->ops == &unassigned_io_ops)
> > +        return;
> > +
> > +    memory_region_ref(mr);
> >
> >      xen_map_io_section(xen_xc, xen_domid, state->ioservid, section);
> >  }
> > @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener,
> >                         MemoryRegionSection *section)
> >  {
> >      XenIOState *state = container_of(listener, XenIOState, io_listener);
> > +    MemoryRegion *mr = section->mr;
> > +
> > +    if (mr->ops == &unassigned_io_ops)
> > +        return;
> >
> >      xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section);
> >
> > -    memory_region_unref(section->mr);
> > +    memory_region_unref(mr);
> >  }
> 
> Looks good, feel free to Cc me if you send it to qemu-devel (though I'll
> let Anthony merge it).

Cool, thanks.

  Paul

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-05-09 16:19 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.