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 14:41:42 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Aug 28, 2011 at 10:50:49AM +0300, Avi Kivity wrote:
> On 08/26/2011 12:43 PM, Michael S. Tsirkin wrote:
> >On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote:
> >>  It's correct but insufficient, the filtering code
> >>  (pci_bridge_filter) needs to be updated to use the memory API.
> >>
> >>  Basically it gets simpler and correcter.
> >
> >I've been struggling with the following problem: bridges have two memory
> >ranges: prefetcheable and non-prefetcheable.
> >
> >Memory in the device can be behind the prefetcheable and
> >non-prefetcheable memory range, but things only work correctly if
> >non-prefetcheable memory on the device is put behind a non-prefetcheable
> >range. Prefetcheable memory can go anywhere I think.
> >
> >This didn't work correctly before the memory API change,
> >but it was easy to fix ... Now I'm not sure how.
> 
> 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.

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?


> -- 
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.



reply via email to

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