Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754903AbeALK6o (ORCPT + 1 other); Fri, 12 Jan 2018 05:58:44 -0500 Received: from foss.arm.com ([217.140.101.70]:43674 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754576AbeALK6m (ORCPT ); Fri, 12 Jan 2018 05:58:42 -0500 Subject: Re: [PATCH v1 01/16] virtio: Validate queue pfn for 32bit transports To: Peter Maydell Cc: "Michael S. Tsirkin" , Suzuki Poulose , arm-mail-list , kvm-devel , "kvmarm@lists.cs.columbia.edu" , Christoffer Dall , Marc Zyngier , lkml - Kernel Mailing List , Kristina Martsenko , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Will Deacon , Ard Biesheuvel , Mark Rutland , Catalin Marinas , Jason Wang , Christoffer Dall References: <20180109190414.4017-1-suzuki.poulose@arm.com> <20180109190414.4017-2-suzuki.poulose@arm.com> <20180110012429-mutt-send-email-mst@kernel.org> <20180110130230-mutt-send-email-mst@kernel.org> <2aacb81b-0efb-87b9-f70c-a61e66dd0331@arm.com> From: Jean-Philippe Brucker Message-ID: Date: Fri, 12 Jan 2018 11:01:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 12/01/18 10:21, Peter Maydell wrote: > On 10 January 2018 at 11:25, Jean-Philippe Brucker > wrote: >> Hi Peter, >> >> On 10/01/18 11:19, Peter Maydell wrote: >>> Are there uses that make it worthwhile to get virtio-1 >>> support added to virtio-mmio, rather than just getting >>> people to move over to virtio-pci instead ? >> >> virtio-iommu uses virtio-mmio transport. It makes little sense to have an >> IOMMU presented as a PCI endpoint. > > Having an entire transport just for the IOMMU doesn't make > a great deal of sense either though :-) If we didn't already > have virtio-mmio kicking around would we really have designed > it that way? Possibly. It certainly was on the table during early investigations. It does beat the alternative, having to redesign firmware interfaces and rewrite core driver code to cater for unrealistic device topologies. Thanks, Jean