On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote: > > > On 14/05/2015 14:24, Christoffer Dall wrote: > > On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote: > >> > >> > >> On 14/05/2015 14:00, Christoffer Dall wrote: > >>> So, getting back to my original question. Is the point then that UEFI > >>> must assume (from ACPI/DT) the cache-coherency properties of the PCI > >>> controller which exists in hardware on the system you're running on, > >>> even for the virtual PCI bus because that will be the semantics for > >>> assigned devices? > >>> > >>> And in that case, we have no way to distinguish between passthrough > >>> devices and virtual devices plugged into the virtual PCI bus? > >> > >> Well, we could use the subsystem id. But it's a hack, and may cause > >> incompatibilities with some drivers. Michael, any ideas? > >> > >>> What about the idea of having two virtual PCI buses on your system where > >>> one is always cache-coherent and uses for virtual devices, and the other > >>> is whatever the hardware is and used for passthrough devices? > >> > >> I think that was rejected before. > > > > Do you remember where? I just remember Catalin mentioning the idea to > > me verbally. > > In the last centithread on the subject. :) > > At least I and Peter disagreed. It's not about the heavy added use of > resources, it's more about it being really easy to misconfigure. > > > But I'm still not sure why UEFI/Linux currently sees our PCI bus as > > being non-coherent when in fact it is and we have no passthrough issues > > currently. Are all PCI controllers always non-coherent for some reason > > and therefore we model it as such too? > > Well, PCI BARs are generally MMIO resources, and hence should not be cached. > > As an optimization, OS drivers can mark them as cacheable or > write-combining or something like that, but in general it's a safe > default to leave them uncached---one would think. > ok, I guess this series makes sense then, assuming it works, and assuming we don't kill performance by going to RAM all the time when we don't have to... Thanks, -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
