virtio-net: MAC filtering
cover virtio-net: MAC filtering
This series is based on some of the work Mark McLoughlin has been doing, so isn't going to apply until that makes it into the tree. The goal is to enable MAC filtering at the qemu/kvm level for virtio-net packets. I start by adding the capability to set the MAC address, naming the bits in the status field, enabling filtering, and finally adding a MAC table for additional MAC addresses. If this looks reasonable, I'll follow up with VLAN filtering support.
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource rounding. The VLAN filter bitmap would increase that by another 512 bytes, making it 1kB and limiting us to something less than 64 such devices per guest. Is anyone worried? Should filter tables live in MMIO space for virtio devices? I'll send out the guest side patches for virtio-net in a separate thread. Thanks,
Alex
Signature · 1 line
Alex Williamson HP Open Source & Linux Org.
Quoted 7 lines
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource rounding. The VLAN filter bitmap would increase that by another 512 bytes, making it 1kB and limiting us to something less than 64 such devices per guest. Is anyone worried? Should filter tables live in MMIO space for virtio devices? I'll send out the guest side patches for virtio-net in a separate thread. Thanks,
This is one reason why IO ports are a reallybad idea. Use memory mapped register spaces like any other sane system and you won't have a problem.
Paul
Quoted 11 lines · Paul Brook
Quoted 8 lines
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource rounding. The VLAN filter bitmap would increase that by another 512 bytes, making it 1kB and limiting us to something less than 64 such devices per guest. Is anyone worried? Should filter tables live in MMIO space for virtio devices? I'll send out the guest side patches for virtio-net in a separate thread. Thanks,
This is one reason why IO ports are a reallybad idea. Use memory mapped register spaces like any other sane system and you won't have a problem.
mmio is slower for virtualization. But I agree pio is baroque.
Luckily we didn't implement the 768 pci slot thing, that wouldn't have flown (for yet another reason).
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Quoted 11 lines · Paul Brook
Quoted 8 lines
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource rounding. The VLAN filter bitmap would increase that by another 512 bytes, making it 1kB and limiting us to something less than 64 such devices per guest. Is anyone worried? Should filter tables live in MMIO space for virtio devices? I'll send out the guest side patches for virtio-net in a separate thread. Thanks,
This is one reason why IO ports are a reallybad idea. Use memory mapped register spaces like any other sane system and you won't have a problem.
IO ports are much faster for notification than MMIO in KVM which is why the space is currently IO ports. It was never meant to hold very large amounts of data.
Regards,
Anthony Liguori
Quoted 6 lines
Paul
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource
This is one reason why IO ports are a reallybad idea. Use memory mapped register spaces like any other sane system and you won't have a problem.
IO ports are much faster for notification than MMIO in KVM which is why the space is currently IO ports. It was never meant to hold very large amounts of data.
Huh, I'm surprised it makes any real difference. Other that initial setup, isn't it just used to "kick" the devieonce after new dscriptors have been added to the ring buffer? I'd expect to be a fairly expensive operation (bouncing back to userspace).
Paul
Quoted 6 lines · Paul Brook
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource
This is one reason why IO ports are a reallybad idea. Use memory mapped register spaces like any other sane system and you won't have a problem.
Quoted 7 lines
Quoted 4 lines
IO ports are much faster for notification than MMIO in KVM which is why the space is currently IO ports. It was never meant to hold very large amounts of data.
Huh, I'm surprised it makes any real difference. Other that initial setup, isn't it just used to "kick" the devieonce after new dscriptors have been added to the ring buffer? I'd expect to be a fairly expensive operation (bouncing back to userspace).
It's about 2x as expensive to go to userspace but only probably 1.5x expensive to do MMIO compared to PIO. In the grand scheme of things, I'm not sure that it matters that much. It's relatively simple for someone to try out the change and do some benchmarking.
The tougher thing is providing backwards compatible support.
Regards,
Anthony Liguori
Quoted 2 lines
Paul
Quoted 10 lines · Anthony Liguori
Quoted 9 lines · Paul Brook
Quoted 8 lines
A concern here is the growing size of the virtio-net I/O port space config. This series brings it up to 256 bytes with PCI resource rounding. The VLAN filter bitmap would increase that by another 512 bytes, making it 1kB and limiting us to something less than 64 such devices per guest. Is anyone worried? Should filter tables live in MMIO space for virtio devices? I'll send out the guest side patches for virtio-net in a separate thread. Thanks,
Quoted 4 lines
Quoted 2 lines
This is one reason why IO ports are a reallybad idea. Use memory mapped register spaces like any other sane system and you won't have a problem.
IO ports are much faster for notification than MMIO in KVM which is why the space is currently IO ports. It was never meant to hold very large amounts of data.
We can, btw, fix the mmio speed issue by adding two new hypercalls: mmio_read() and mmio_write(). We could then hook <asm/io.h> to use the hypercalls instead of reading directly. This would speed up most emulated devices, not just virtio.
I don't know whether Windows drivers access mmio using helpers or directly.
Signature · 1 line
error compiling committee.c: too many arguments to function
cover virtio-net: MAC filtering
In reply to Alex WilliamsonHere's an update to the patches I sent last week. The goal of this series is to add MAC setting and filtering support to the virtio-net backend in qemu/kvm.
This version now makes use of a virtqueue for outbound commands from the guest driver. This allows us to support numerous features without trying to pack them into the virtio-net I/O port config space. A separate patch series shows the guest driver changes to enable this. Please comment. Thanks,
Alex
Signature · 1 line
Alex Williamson HP Open Source & Linux Org.
Quoted 10 lines · Alex Williamson
Here's an update to the patches I sent last week. The goal of this series is to add MAC setting and filtering support to the virtio-net backend in qemu/kvm.
This version now makes use of a virtqueue for outbound commands from the guest driver. This allows us to support numerous features without trying to pack them into the virtio-net I/O port config space. A separate patch series shows the guest driver changes to enable this. Please comment. Thanks,
The backend bits look good to me.
Regards,
Anthony Liguori
Quoted 3 lines
Alex