From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED Date: Thu, 14 May 2015 14:00:39 +0200 Message-ID: <20150514120039.GU32765@cbox> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0A6E251494 for ; Thu, 14 May 2015 07:51:27 -0400 (EDT) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsMopF47eCq1 for ; Thu, 14 May 2015 07:51:21 -0400 (EDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 0FB1751492 for ; Thu, 14 May 2015 07:51:20 -0400 (EDT) Received: by layy10 with SMTP id y10so63958066lay.0 for ; Thu, 14 May 2015 05:00:27 -0700 (PDT) Content-Disposition: inline In-Reply-To: <5554893E.4030105@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Paolo Bonzini Cc: ard.biesheuvel@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, qemu-devel@nongnu.org, Laszlo Ersek , kvmarm@lists.cs.columbia.edu List-Id: kvmarm@lists.cs.columbia.edu On Thu, May 14, 2015 at 01:38:38PM +0200, Paolo Bonzini wrote: > > > On 14/05/2015 13:36, Christoffer Dall wrote: > > > > > (It's probably worth looking at the documentation in the first hunk too, > > > > > under the commit message.) > > > > > > > > Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus > > > > not simply that MMIO regions are coherent? > > > > > > Only until device assignment gets into the picture. > > > > Will UEFI have to deal with device assignment in any respect? > > Why not? For example you could do network boot from an assigned network > card. > > In fact, anything that UEFI has to deal with, the OS has to deal with > too. If you need a UEFI hack, chances are you need or will need a Linux > hack too. > Fair enough. I was thinking that UEFI needs to be built with knowledge of all the hardware present including any passthrough devices, but I guess this is plainly not true with PCI (and might not even be true with the level of DT parsing we do for the virtual platform). 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? 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? -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsroV-0006dH-Po for qemu-devel@nongnu.org; Thu, 14 May 2015 08:00:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsroS-0007IL-Ki for qemu-devel@nongnu.org; Thu, 14 May 2015 08:00:31 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:34373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsroS-0007Hw-El for qemu-devel@nongnu.org; Thu, 14 May 2015 08:00:28 -0400 Received: by laat2 with SMTP id t2so63963614laa.1 for ; Thu, 14 May 2015 05:00:27 -0700 (PDT) Date: Thu, 14 May 2015 14:00:39 +0200 From: Christoffer Dall Message-ID: <20150514120039.GU32765@cbox> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5554893E.4030105@redhat.com> 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: Paolo Bonzini Cc: peter.maydell@linaro.org, Andrew Jones , ard.biesheuvel@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, qemu-devel@nongnu.org, agraf@suse.de, j.fanguede@virtualopensystems.com, Laszlo Ersek , kvmarm@lists.cs.columbia.edu, m.smarduch@samsung.com On Thu, May 14, 2015 at 01:38:38PM +0200, Paolo Bonzini wrote: > > > On 14/05/2015 13:36, Christoffer Dall wrote: > > > > > (It's probably worth looking at the documentation in the first hunk too, > > > > > under the commit message.) > > > > > > > > Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus > > > > not simply that MMIO regions are coherent? > > > > > > Only until device assignment gets into the picture. > > > > Will UEFI have to deal with device assignment in any respect? > > Why not? For example you could do network boot from an assigned network > card. > > In fact, anything that UEFI has to deal with, the OS has to deal with > too. If you need a UEFI hack, chances are you need or will need a Linux > hack too. > Fair enough. I was thinking that UEFI needs to be built with knowledge of all the hardware present including any passthrough devices, but I guess this is plainly not true with PCI (and might not even be true with the level of DT parsing we do for the virtual platform). 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? 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? -Christoffer