From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED Date: Thu, 14 May 2015 13:38:38 +0200 Message-ID: <5554893E.4030105@redhat.com> 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> 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 944EB51482 for ; Thu, 14 May 2015 07:29:45 -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 I99HWZxa11Ar for ; Thu, 14 May 2015 07:29:44 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 68EE651476 for ; Thu, 14 May 2015 07:29:43 -0400 (EDT) In-Reply-To: <20150514113634.GS32765@cbox> 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: Christoffer Dall 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 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. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsrTe-0005Qe-Vk for qemu-devel@nongnu.org; Thu, 14 May 2015 07:38:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsrTa-00058p-PC for qemu-devel@nongnu.org; Thu, 14 May 2015 07:38:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsrTa-00058c-HO for qemu-devel@nongnu.org; Thu, 14 May 2015 07:38:54 -0400 Message-ID: <5554893E.4030105@redhat.com> Date: Thu, 14 May 2015 13:38:38 +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> In-Reply-To: <20150514113634.GS32765@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, 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 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. Paolo