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 shelleyg...@vmware.com
Acked-by: Bhavesh Davda bhav...@vmware.com
Signed-off-by: Andy King
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
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
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 shelleyg...@vmware.com
Acked-by: Bhavesh Davda bhav...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
Reported-by: Tetsuo Handa
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 PPC
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 will just
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 device for
On Mon, Sep 01, 2014 at 10:55:29PM -0700, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On Tue, Sep 2, 2014 at 2:10 PM, Michael S. Tsirkin m...@redhat.com 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
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes
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
On Tue, Sep 2, 2014 at 3:10 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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 Tue, Sep 2, 2014 at 4:20 PM, Benjamin Herrenschmidt b...@au1.ibm.com 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
On Tue, Sep 2, 2014 at 5:25 PM, Benjamin Herrenschmidt b...@au1.ibm.com 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
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
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:
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
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
On Tue, Sep 2, 2014 at 9:29 PM, Rusty Russell ru...@rustcorp.com.au 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
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
20 matches
Mail list logo
