From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YssGA-0000rr-CT for qemu-devel@nongnu.org; Thu, 14 May 2015 08:29:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YssG2-0005gr-80 for qemu-devel@nongnu.org; Thu, 14 May 2015 08:29:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YssG2-0005gU-2W for qemu-devel@nongnu.org; Thu, 14 May 2015 08:28:58 -0400 Message-ID: <55549501.2010000@redhat.com> Date: Thu, 14 May 2015 14:28:49 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1431516714-25816-1-git-send-email-drjones@redhat.com> <20150514103018.GM32765@cbox> <5554826E.1040706@redhat.com> <20150514112910.GR32765@cbox> <55548777.9000702@redhat.com> <20150514113634.GS32765@cbox> <5554893E.4030105@redhat.com> <20150514120039.GU32765@cbox> <55549051.1090007@redhat.com> <20150514122413.GV32765@cbox> In-Reply-To: <20150514122413.GV32765@cbox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoffer Dall Cc: peter.maydell@linaro.org, Andrew Jones , ard.biesheuvel@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, agraf@suse.de, j.fanguede@virtualopensystems.com, Laszlo Ersek , kvmarm@lists.cs.columbia.edu, m.smarduch@samsung.com 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. Paolo