From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Enable non page boundary BAR device assignment Date: Thu, 10 Dec 2009 12:35:05 +0200 Message-ID: <4B20CED9.3090908@redhat.com> References: <1260380334-8323-1-git-send-email-agraf@suse.de> <20091209204941.GA7873@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , "kvm@vger.kernel.org" To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41396 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933514AbZLJKfC (ORCPT ); Thu, 10 Dec 2009 05:35:02 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 12/09/2009 11:06 PM, Alexander Graf wrote: > > Am 09.12.2009 um 21:49 schrieb "Michael S. Tsirkin" : > >> On Wed, Dec 09, 2009 at 06:38:54PM +0100, Alexander Graf wrote: >>> While trying to get device passthrough working with an emulex hba, kvm >>> refused to pass it through because it has a BAR of 256 bytes: >>> >>> Region 0: Memory at d2100000 (64-bit, non-prefetchable) >>> [size=4K] >>> Region 2: Memory at d2101000 (64-bit, non-prefetchable) >>> [size=256] >>> Region 4: I/O ports at b100 [size=256] >>> >>> Since the page boundary is an arbitrary optimization to allow 1:1 >>> mapping of >>> physical to virtual addresses, we can still take the old MMIO >>> callback route. >>> >>> So let's add a second code path that allows for size & 0xFFF != 0 >>> sized regions >>> by looping it through userspace. >>> >>> I verified that it works by passing through an e1000 with this >>> additional patch >>> applied and the card acted the same way it did without this patch: >>> >>> map_func = assigned_dev_iomem_map; >>> - if (cur_region->size & 0xFFF) { >>> + if (i != PCI_ROM_SLOT){ >>> fprintf(stderr, "PCI region %d at address 0x%llx " >>> >>> Signed-off-by: Alexander Graf >> >> Good idea. >> >> One thing I am concerned with, is that some users might >> see performance degradation and not see the error message. >> Maybe we can have a flag to optionally fail unless >> passthrough can be fast? I'm not really sure it's worth it >> to add such a flag though - what do others think? > > It only kicks in on small BARs which are usually not _that_ > performance critical. We're mostly talking about ack and status bits. > Well, ack and status are pretty important if accessed every interrupt. > Also not failing > failing IMHO :). Even if it's not as fast as native. Yes. -- error compiling committee.c: too many arguments to function