qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] pci: add standard bridge device


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device
Date: Sun, 28 Aug 2011 16:42:03 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote:
> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
> >>
> >>  If it really matters, you can add a prefetchability attribute to
> >>  MemoryRegions.  Does it though?
> >
> >Well, its another one of these things that
> >guests *probably* won't in practice use.
> >But I don't see a way to be sure.
> >
> >If the guest puts a prefetcheable memory BAR behind
> >a non-prefetcheable range in the bridge, it won't
> >be able to access that BAR, and it should.
> 
> Not sure I understand - on real hardware, does it see the BAR or not?

It does.

> >
> >Prefetcheable BARs on devices are less common than
> >non-prefetcheable, but they do exist:
> >I have a system with 2 devices: a VGA controller from Matrox
> >and an ethernet card from Mellanox have
> >prefetcheable BARs.
> >
> >I'm not sure how prefetcheability attribute will help.
> >Could you explain pls?
> >
> 
> Have an attribute for a region "does not allow prefetchable memory"
> in subregions
> Have an attribute for a region "prefetchable memory"
> 
> When rendering the memory map, ignore any "prefetchable memory"
> regions that are subregions of a "does not allow prefetchable
> memory" region.
> 
> (if I understood correctly - not sure)

Sorry, I've been unclear. Or maybe I misunderstood?

ATM we have each BAR as a memory region, which is
in turn within io or memory address space region.
With bridges, each bridge has a single range
covering legal io addresses below it, and two ranges for memory.

Example from a real system:
        Memory behind bridge: 98200000-982fffff
        Prefetchable memory behind bridge: 0000000097000000-00000000977fffff

And a device can have:

        Region 0: Memory at 98200000 (64-bit, non-prefetchable) [size=1M]
        Region 2: Memory at 97000000 (64-bit, prefetchable) [size=8M]


guest can in theory reprogram this:

        Memory behind bridge: 98200000-98afffff
        Prefetchable memory behind bridge: 0000000097000000-00000000977fffff

and
        Region 0: Memory at 98200000 (64-bit, non-prefetchable) [size=1M]
        Region 2: Memory at 98300000 (64-bit, prefetchable) [size=8M]

and the device will work (presumably, guests will try to avoid this
as they assume prefetchable ranges are faster).

Thus, which range the device BAR is behind depends on the
programmed values. How do we model that?


A side note on bus filtering:
In cases of bus range partially hinding the BAR from the guest, one can
even have multiple non-contigious bits of the BAR visible and the rest
hidden.

I'm not saying it's very important to model this,
I'm guessing the only important cases are all of the
BAR visible and all of the BAR hidden.


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]