Andy Lutomirski writes:
> There really are virtio devices that are pieces of silicon and not
> figments of a hypervisor's imagination [1].
Hi Andy,
As you're discovering, there's a reason no one has done the DMA
API before.
So the problem is that ppc64's IOMMU is a platform thing, not a
Dear all,
I have a few questions. Vhost is taking out QEMU in virtio device emulation.
But in KVM, Vhost needs QEMU for setting up virtqueue. Why it can't be done in
kernel? Is it because the guest VMs are running in QEMU?
I and my team are developing our own hypervisor. And our guest VMs are n
On Tue, Sep 2, 2014 at 9:29 PM, Rusty Russell wrote:
> This is the only driver which doesn't hand virtqueue_add_inbuf and
> virtqueue_add_outbuf a well-formed, well-terminated sg. Fix it,
> so we can make virtio_add_* simpler.
OK, I get it now: you're reinitializing the table every time, clearin
I resurrected these patches after prompting from Andy Lutomirski's
recent patches. I put them on the back-burner because vring_bench
had a 15% slowdown on my laptop: pktgen testing revealed a speedup,
if anything, so I've cleaned them up.
Rusty Russell (3):
virtio_net: pass well-formed sgs to v
This is the only driver which doesn't hand virtqueue_add_inbuf and
virtqueue_add_outbuf a well-formed, well-terminated sg. Fix it,
so we can make virtio_add_* simpler.
pktgen results:
modprobe pktgen
echo 'add_device eth0' > /proc/net/pktgen/kpktgend_0
echo nowait 1 > /pro
virtqueue_add() populates the virtqueue descriptor table from the sgs
given. If it uses an indirect descriptor table, then it puts a single
descriptor in the descriptor table pointing to the kmalloc'ed indirect
table where the sg is populated.
Previously vring_add_indirect() did the allocation an
We used to have several callers which just used arrays. They're
gone, so we can use sg_next() everywhere, simplifying the code.
On my laptop, this slowed down vring_bench by 15%:
vring_bench before:
936153354-967745359(9.44739e+08+/-6.1e+06)ns
vring_bench after:
1061485790-110480
On Tue, Sep 2, 2014 at 5:25 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote:
>> So here's an ugly proposal:
>>
>> Step 1: Make virtio-pci use the DMA API only on x86. This will at
>> least fix Xen and people experimenting with virtio hardware on x86,
>
On Tue, Sep 2, 2014 at 4:20 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2014-09-02 at 16:11 -0700, Andy Lutomirski wrote:
>
>> I don't think so. I would argue that it's a straight-up bug for QEMU
>> to expose a physically-addressed virtio-pci device to the guest behind
>> an emulated IOMMU. QEMU
On Tue, Sep 2, 2014 at 3:10 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2014-09-02 at 14:37 -0700, Andy Lutomirski wrote:
>
>> Let's take a step back from from the implementation. What is a driver
>> for a virtio PCI device (i.e. a PCI device with vendor 0x1af4)
>> supposed to do on ppc64?
>
> To
On Tue, 2014-09-02 at 14:37 -0700, Andy Lutomirski wrote:
> Let's take a step back from from the implementation. What is a driver
> for a virtio PCI device (i.e. a PCI device with vendor 0x1af4)
> supposed to do on ppc64?
Today, it's supposed to send guest physical addresses. We can make that
op
On Tue, Sep 2, 2014 at 2:10 PM, Michael S. Tsirkin wrote:
> On Mon, Sep 01, 2014 at 10:55:29PM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
>> wrote:
>> > On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
>> >> Changes from v1:
>> >> - Using the
On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
>>
>> On x86, at least, I doubt that we'll ever see a physically addressed
>> PCI virtio device for which ACPI advertises an IOMMU, since any sane
>> hypervisor will just not a
On Mon, Sep 01, 2014 at 10:55:29PM -0700, Andy Lutomirski wrote:
> On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
> wrote:
> > On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
> >> Changes from v1:
> >> - Using the DMA API is optional now. It would be nice to improve the
> >>
On Tue, 2014-09-02 at 16:56 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 03, 2014 at 06:53:33AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
> > >
> > > On x86, at least, I doubt that we'll ever see a physically addressed
> > > PCI virtio
On Wed, Sep 03, 2014 at 06:53:33AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
> >
> > On x86, at least, I doubt that we'll ever see a physically addressed
> > PCI virtio device for which ACPI advertises an IOMMU, since any sane
> > hypervisor w
On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
>
> On x86, at least, I doubt that we'll ever see a physically addressed
> PCI virtio device for which ACPI advertises an IOMMU, since any sane
> hypervisor will just not advertise an IOMMU for the virtio device.
> But are there arm64 or PP
We should check if the map of the table actually succeeds, and also free
resources accordingly.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
Acked-by: Bhavesh Davda
Signed-off-by: Andy King
Reported-by: Tetsuo Handa
---
drivers/net/vmxnet3/vmxnet3_drv.c | 15 ---
drivers/ne
This version addresses Sergei's comments.
o Fixed description and added Reported-by
o Removed NULL check for kfree()
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualizat
Hello.
On 09/02/2014 08:30 PM, Andy King wrote:
We should check if the map of the table actually succeeds, and also free
resources accordingly. This fixes the kernel panic reported by Tetsuo
Handa.
There's "Reported-by:" line for that.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
We should check if the map of the table actually succeeds, and also free
resources accordingly. This fixes the kernel panic reported by Tetsuo
Handa.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
Acked-by: Bhavesh Davda
Signed-off-by: Andy King
---
drivers/net/vmxnet3/vmxnet3_drv.c | 14
21 matches
Mail list logo
