On 12/09/2009 11:06 PM, Alexander Graf wrote:
Am 09.12.2009 um 21:49 schrieb "Michael S. Tsirkin" <mst@xxxxxxxxxx>:
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 <agraf@xxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
