Re: [Qemu-devel] [PATCH] pci: implement bridge filtering

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 20, 2011 at 02:44:26PM +0300, Avi Kivity wrote:
> On 09/20/2011 11:09 AM, Wen Congyang wrote:
> >At 09/14/2011 09:48 AM, Wen Congyang Write:
> >>  At 09/05/2011 02:13 AM, Michael S. Tsirkin Write:
> >>>  Support bridge filtering on top of the memory
> >>>  API as suggested by Avi Kivity:
> >>>
> >>>  Create a memory region for the bridge's address space.  This region is
> >>>  not directly added to system_memory or its descendants.  Devices under
> >>>  the bridge see this region as its pci_address_space().  The region is
> >>>  as large as the entire address space - it does not take into account
> >>>  any windows.
> >>>
> >>>  For each of the three windows (pref, non-pref, vga), create an alias
> >>>  with the appropriate start and size.  Map the alias into the bridge's
> >>>  parent's pci_address_space(), as subregions.
> >>>
> >>>  Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
> >>>  ---
> >>>
> >>>  The below seems to work fine for me so I applied this.
> >>>  Still need to test bridge filtering, any help with this
> >>>  appreciated.
> >>>
> >>
> >>
> >>  I test bridge filtering, and the BAR still can be visible on guest even if
> >>  I change the memory region.
> >
> >Hi Michael S. Tsirkin:
> >I test pci bridge filtering on real hardware, and I find that I can mmap
> >the resource after I change the memory base and memory limit(The BAR should
> >be not visible on OS after changing the memory region).
> >
> >So I try to write and read to the BAR. Here is my test result:
> >1. Before changing the pci bridge's memory region, I can read and write to the memory, and
> >    I can get the same value that I write.
> >
> >2. After changing the pci bridge's memory region, I can still read and write to the memory,
> >    but it is very slow, and I can not get the same value that I write(The value is always 0).
> >
> >Does this result means that pci bridge filtering works fine?
> >
> 
> Yes.  Instead of hitting the BAR, you hit the default mmio handler.

Hmm, not sure what's right in that case.
But, same if BAR is disabled? Would be nice to make
some handler in bridge to get called, to set
master abort flag etc.

> -- 
> error compiling committee.c: too many arguments to function