[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options |
Date: |
Wed, 3 Mar 2010 14:43:29 +0000 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; ) |
> > That sounds like it's likely to come back and bite you. The guest has no
> > idea which areas of ram happen to be contiguous on the host.
>
> Practically speaking, with target-i386 anything that is contiguous in
> guest physical memory is contiguous in the host address space provided
> it's ram.
>
> These assumptions are important. I have a local branch (that I'll send
> out soon) that implements a ram API and converted virtio to make use of
> it. I'm seeing a ~50% increase in tx throughput.
IMO supporting discontiguous regions is a requirement. target-i386 might get
away with contiguous memory, because it omits most of the board level details.
For everything else I'd expect this to be a real problem.
I'm not happy about the not-remapable assumption either. In my experience
this is fairly common. In fact many real x86 machines have this capability
(to workaround the 4G PCI hole).
By my reading the ppc440_bamboo board fails both your assumptions.
I imagine the KVM-PPC folks would be upset if you decided that virtio no
longer worked on this board.
This is all somewhat disappointing, given virtio is supposed to be a DMA based
architecture, and not rely on shared memory semantics.
Paul
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, (continued)
Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Marcelo Tosatti, 2010/03/02