* Re: [PATCH 1/2] alchemy: add au1000-eth platform device
From: Florian Fainelli @ 2009-08-18 16:01 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Ralf Baechle, linux-mips, Manuel Lauss, David Miller, netdev
In-Reply-To: <4A8AC125.3020602@ru.mvista.com>
Le Tuesday 18 August 2009 16:56:37 Sergei Shtylyov, vous avez écrit :
> Hello.
>
> Florian Fainelli wrote:
> > This patch adds the board code to register a per-board au1000-eth
> > platform device to be used wit the au1000-eth platform driver in a
> > subsequent patch. Note that the au1000-eth driver knows about the
> > default driver settings such that we do not need to pass any
> > platform_data informations in most cases except db1x00.
>
> Sigh, NAK...
> Please don't register the SoC device per board, do it in
> alchemy/common/platfrom.c and find a way to pass the board specific
> platform data from the board file there instead -- something like
> arch/arm/mach-davinci/usb.c does.
Ok, like I promised, this was the per-board device registration. Do you prefer something like this:
--
From fd75b7c7fa3c05c21122c43e43260d2785475a79 Mon Sep 17 00:00:00 2001
From: Florian Fainelli <florian@openwrt.org>
Date: Tue, 18 Aug 2009 17:53:21 +0200
Subject: [PATCH] alchemy: add au1000-eth platform device (v2)
This patch makes the board code register the au1000-eth
platform device. The au1000-eth platform data can be
overriden with the au1xxx_override_eth0_cfg function
like it has to be done for the Bosporus board.
Changes from v1:
- remove per-board platform.c file
- add an override function to pass custom eth0 platform_data PHY settings
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/arch/mips/alchemy/common/platform.c b/arch/mips/alchemy/common/platform.c
index 117f99f..559294a 100644
--- a/arch/mips/alchemy/common/platform.c
+++ b/arch/mips/alchemy/common/platform.c
@@ -19,6 +19,7 @@
#include <asm/mach-au1x00/au1xxx.h>
#include <asm/mach-au1x00/au1xxx_dbdma.h>
#include <asm/mach-au1x00/au1100_mmc.h>
+#include <asm/mach-au1x00/au1xxx_eth.h>
#define PORT(_base, _irq) \
{ \
@@ -331,6 +332,76 @@ static struct platform_device pbdb_smbus_device = {
};
#endif
+/* Macro to help defining the Ethernet MAC resources */
+#define MAC_RES(_base, _enable, _irq) \
+ { \
+ .start = CPHYSADDR(_base), \
+ .end = CPHYSADDR(_base + 0xffff), \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = CPHYSADDR(_enable), \
+ .end = CPHYSADDR(_enable + 0x3), \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = _irq, \
+ .end = _irq, \
+ .flags = IORESOURCE_IRQ \
+ }
+
+static struct resource au1xxx_eth0_resources[] = {
+#if defined(CONFIG_SOC_AU1000)
+ MAC_RES(AU1000_ETH0_BASE, AU1000_MAC0_ENABLE, AU1000_MAC0_DMA_INT),
+#elif defined(CONFIG_SOC_AU1100)
+ MAC_RES(AU1100_ETH0_BASE, AU1100_MAC0_ENABLE, AU1100_MAC0_DMA_INT),
+#elif defined(CONFIG_SOC_AU1550)
+ MAC_RES(AU1550_ETH0_BASE, AU1550_MAC0_ENABLE, AU1550_MAC0_DMA_INT),
+#elif defined(CONFIG_SOC_AU1500)
+ MAC_RES(AU1500_ETH0_BASE, AU1500_MAC0_ENABLE, AU1500_MAC0_DMA_INT),
+#endif
+};
+
+static struct resource au1xxx_eth1_resources[] = {
+#if defined(CONFIG_SOC_AU1000)
+ MAC_RES(AU1000_ETH1_BASE, AU1000_MAC1_ENABLE, AU1000_MAC1_DMA_INT),
+#elif defined(CONFIG_SOC_AU1550)
+ MAC_RES(AU1550_ETH1_BASE, AU1550_MAC1_ENABLE, AU1550_MAC1_DMA_INT),
+#elif defined(CONFIG_SOC_AU1500)
+ MAC_RES(AU1500_ETH1_BASE, AU1500_MAC1_ENABLE, AU1500_MAC1_DMA_INT),
+#endif
+};
+
+static struct au1000_eth_platform_data au1xxx_eth0_platform_data = {
+ .phy1_search_mac0 = 1,
+};
+
+static struct platform_device au1xxx_eth0_device = {
+ .name = "au1000-eth",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(au1xxx_eth0_resources),
+ .resource = au1xxx_eth0_resources,
+ .dev.platform_data = &au1xxx_eth0_platform_data,
+};
+
+#ifndef CONFIG_SOC_AU1100
+static struct platform_device au1xxx_eth1_device = {
+ .name = "au1000-eth",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(au1xxx_eth1_resources),
+ .resource = au1xxx_eth1_resources,
+};
+#endif
+
+void __init au1xxx_override_eth0_cfg(struct au1000_eth_platform_data *eth_data)
+{
+ if (!eth_data)
+ return;
+
+ memcpy(&au1xxx_eth0_platform_data, eth_data,
+ sizeof(struct au1000_eth_platform_data));
+}
+
static struct platform_device *au1xxx_platform_devices[] __initdata = {
&au1xx0_uart_device,
&au1xxx_usb_ohci_device,
@@ -351,17 +422,25 @@ static struct platform_device *au1xxx_platform_devices[] __initdata = {
#ifdef SMBUS_PSC_BASE
&pbdb_smbus_device,
#endif
+ &au1xxx_eth0_device,
};
static int __init au1xxx_platform_init(void)
{
unsigned int uartclk = get_au1x00_uart_baud_base() * 16;
- int i;
+ int i, ni;
/* Fill up uartclk. */
for (i = 0; au1x00_uart_data[i].flags; i++)
au1x00_uart_data[i].uartclk = uartclk;
+ /* Register second MAC if enabled in pinfunc */
+#ifndef CONFIG_SOC_AU1100
+ ni = (int)((au_readl(SYS_PINFUNC) & (u32)(SYS_PF_NI2)) >> 4);
+ if (!(ni + 1))
+ platform_device_register(&au1xxx_eth1_device);
+#endif
+
return platform_add_devices(au1xxx_platform_devices,
ARRAY_SIZE(au1xxx_platform_devices));
}
diff --git a/arch/mips/alchemy/devboards/db1x00/board_setup.c b/arch/mips/alchemy/devboards/db1x00/board_setup.c
index de30d8e..4d2d32c 100644
--- a/arch/mips/alchemy/devboards/db1x00/board_setup.c
+++ b/arch/mips/alchemy/devboards/db1x00/board_setup.c
@@ -32,6 +32,7 @@
#include <asm/mach-au1x00/au1000.h>
#include <asm/mach-db1x00/db1x00.h>
+#include <asm/mach-au1x00/au1xxx_eth.h>
#include <prom.h>
@@ -134,6 +135,22 @@ void __init board_setup(void)
printk(KERN_INFO "AMD Alchemy Au1100/Db1100 Board\n");
#endif
#ifdef CONFIG_MIPS_BOSPORUS
+ struct au1000_eth_platform_data eth0_pdata;
+
+ /*
+ * Micrel/Kendin 5 port switch attached to MAC0,
+ * MAC0 is associated with PHY address 5 (== WAN port)
+ * MAC1 is not associated with any PHY, since it's connected directly
+ * to the switch.
+ * no interrupts are used
+ */
+ eth0_pdata.phy1_search_mac0 = 0;
+ eth0_pdata.phy_static_config = 1;
+ eth0_pdata.phy_addr = 5;
+ eth0_pdata.phy_busid = 0;
+
+ au1xxx_override_eth0_cfg(ð0_pdata);
+
printk(KERN_INFO "AMD Alchemy Bosporus Board\n");
#endif
#ifdef CONFIG_MIPS_MIRAGE
diff --git a/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h b/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h
new file mode 100644
index 0000000..876187e
--- /dev/null
+++ b/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h
@@ -0,0 +1,17 @@
+#ifndef __AU1X00_ETH_DATA_H
+#define __AU1X00_ETH_DATA_H
+
+/* Platform specific PHY configuration passed to the MAC driver */
+struct au1000_eth_platform_data {
+ int phy_static_config;
+ int phy_search_highest_addr;
+ int phy1_search_mac0;
+ int phy_addr;
+ int phy_busid;
+ int phy_irq;
+};
+
+void __init au1xxx_override_eth0_cfg(struct au1000_eth_platform_data *eth_data);
+
+#endif /* __AU1X00_ETH_DATA_H */
+
--
1.6.3.rc3
^ permalink raw reply related
* Re: [Alacrityvm-devel] [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Ira W. Snyder @ 2009-08-18 15:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Haskins, kvm, netdev, linux-kernel, alacrityvm-devel,
Avi Kivity, Anthony Liguori, Ingo Molnar, Gregory Haskins
In-Reply-To: <20090818084606.GA13878@redhat.com>
On Tue, Aug 18, 2009 at 11:46:06AM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 17, 2009 at 04:17:09PM -0400, Gregory Haskins wrote:
> > Michael S. Tsirkin wrote:
> > > On Mon, Aug 17, 2009 at 10:14:56AM -0400, Gregory Haskins wrote:
> > >> Case in point: Take an upstream kernel and you can modprobe the
> > >> vbus-pcibridge in and virtio devices will work over that transport
> > >> unmodified.
> > >>
> > >> See http://lkml.org/lkml/2009/8/6/244 for details.
> > >
> > > The modprobe you are talking about would need
> > > to be done in guest kernel, correct?
> >
> > Yes, and your point is? "unmodified" (pardon the psuedo pun) modifies
> > "virtio", not "guest".
> > It means you can take an off-the-shelf kernel
> > with off-the-shelf virtio (ala distro-kernel) and modprobe
> > vbus-pcibridge and get alacrityvm acceleration.
>
> Heh, by that logic ksplice does not modify running kernel either :)
>
> > It is not a design goal of mine to forbid the loading of a new driver,
> > so I am ok with that requirement.
> >
> > >> OTOH, Michael's patch is purely targeted at improving virtio-net on kvm,
> > >> and its likewise constrained by various limitations of that decision
> > >> (such as its reliance of the PCI model, and the kvm memory scheme).
> > >
> > > vhost is actually not related to PCI in any way. It simply leaves all
> > > setup for userspace to do. And the memory scheme was intentionally
> > > separated from kvm so that it can easily support e.g. lguest.
> > >
> >
> > I think you have missed my point. I mean that vhost requires a separate
> > bus-model (ala qemu-pci).
>
> So? That can be in userspace, and can be anything including vbus.
>
> > And no, your memory scheme is not separated,
> > at least, not very well. It still assumes memory-regions and
> > copy_to_user(), which is very kvm-esque.
>
> I don't think so: works for lguest, kvm, UML and containers
>
> > Vbus has people using things
> > like userspace containers (no regions),
>
> vhost by default works without regions
>
> > and physical hardware (dma
> > controllers, so no regions or copy_to_user) so your scheme quickly falls
> > apart once you get away from KVM.
>
> Someone took a driver and is building hardware for it ... so what?
>
I think Greg is referring to something like my virtio-over-PCI patch.
I'm pretty sure that vhost is completely useless for my situation. I'd
like to see vhost work for my use, so I'll try to explain what I'm
doing.
I've got a system where I have about 20 computers connected via PCI. The
PCI master is a normal x86 system, and the PCI agents are PowerPC
systems. The PCI agents act just like any other PCI card, except they
are running Linux, and have their own RAM and peripherals.
I wrote a custom driver which imitated a network interface and a serial
port. I tried to push it towards mainline, and DavidM rejected it, with
the argument, "use virtio, don't add another virtualization layer to the
kernel." I think he has a decent argument, so I wrote virtio-over-PCI.
Now, there are some things about virtio that don't work over PCI.
Mainly, memory is not truly shared. It is extremely slow to access
memory that is "far away", meaning "across the PCI bus." This can be
worked around by using a DMA controller to transfer all data, along with
an intelligent scheme to perform only writes across the bus. If you're
careful, reads are never needed.
So, in my system, copy_(to|from)_user() is completely wrong. There is no
userspace, only a physical system. In fact, because normal x86 computers
do not have DMA controllers, the host system doesn't actually handle any
data transfer!
I used virtio-net in both the guest and host systems in my example
virtio-over-PCI patch, and succeeded in getting them to communicate.
However, the lack of any setup interface means that the devices must be
hardcoded into both drivers, when the decision could be up to userspace.
I think this is a problem that vbus could solve.
For my own selfish reasons (I don't want to maintain an out-of-tree
driver) I'd like to see *something* useful in mainline Linux. I'm happy
to answer questions about my setup, just ask.
Ira
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-18 15:51 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, Ingo Molnar, Gregory Haskins, kvm,
alacrityvm-devel, linux-kernel, netdev, Michael S. Tsirkin
In-Reply-To: <4A8AB076.6080906@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3807 bytes --]
Avi Kivity wrote:
> On 08/18/2009 04:16 PM, Gregory Haskins wrote:
>> The issue here is that vbus is designed to be a generic solution to
>> in-kernel virtual-IO. It will support (via abstraction of key
>> subsystems) a variety of environments that may or may not be similar in
>> facilities to KVM, and therefore it represents the
>> least-common-denominator as far as what external dependencies it
>> requires.
>>
>
> Maybe it will be easier to evaluate it in the context of these other
> environments. It's difficult to assess this without an example.
When they are ready, I will cross post the announcement to KVM.
>
>> The bottom line is this: despite the tendency for people to jump at
>> "don't put much in the kernel!", the fact is that a "bus" designed for
>> software to software (such as vbus) is almost laughably trivial. Its
>> essentially a list of objects that have an int (dev-id) and char*
>> (dev-type) attribute. All the extra goo that you see me setting up in
>> something like the kvm-connector needs to be done for fast-path
>> _anyway_, so transporting the verbs to query this simple list is not
>> really a big deal.
>>
>
> It's not laughably trivial when you try to support the full feature set
> of kvm (for example, live migration will require dirty memory tracking,
> and exporting all state stored in the kernel to userspace).
Doesn't vhost suffer from the same issue? If not, could I also apply
the same technique to support live-migration in vbus?
>
>> Note that I didn't really want to go that route. As you know, I tried
>> pushing this straight through kvm first since earlier this year, but I
>> was met with reluctance to even bother truly understanding what I was
>> proposing, comments like "tell me your ideas so I can steal them", and
>>
>
> Oh come on, I wrote "steal" as a convenient shorthand for
> "cross-pollinate your ideas into our code according to the letter and
> spirit of the GNU General Public License".
Is that supposed to make me feel better about working with you? I mean,
writing, testing, polishing patches for LKML-type submission is time
consuming. If all you are going to do is take those ideas and rewrite
it yourself, why should I go through that effort?
And its not like that was the first time you have said that to me.
> Since we're all trying to improve Linux we may as well cooperate.
Well, I don't think anyone can say that I haven't been trying.
>
>> "sorry, we are going to reinvent our own instead".
>
> No. Adopting venet/vbus would mean reinventing something that already
> existed.
But yet, it doesn't.
> Continuing to support virtio/pci is not reinventing anything.
No one asked you to do otherwise.
>
>> This isn't exactly
>> going to motivate someone to continue pushing these ideas within that
>> community. I was made to feel (purposely?) unwelcome at times. So I
>> can either roll over and die, or start my own project.
>>
>
> You haven't convinced me that your ideas are worth the effort of
> abandoning virtio/pci or maintaining both venet/vbus and virtio/pci.
With all due respect, I didnt ask you do to anything, especially not
abandon something you are happy with.
All I did was push guest drivers to LKML. The code in question is
independent of KVM, and its proven to improve the experience of using
Linux as a platform. There are people interested in using them (by
virtue of the number of people that have signed up for the AlacrityVM
list, and have mailed me privately about this work).
So where is the problem here?
> I'm sorry if that made you feel unwelcome. There's no reason to
> interpret disagreement as malice though.
>
Ok.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: mlx4 2.6.31-rc5: SW2HW_EQ failed.
From: Christoph Lameter @ 2009-08-18 15:50 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, Yevgeny Petrilin
In-Reply-To: <ada3a7p3o6f.fsf@cisco.com>
On Mon, 17 Aug 2009, Roland Dreier wrote:
> > Device FW??? The log you wanted follows at the end of this message.
>
> Not sure why there are "???" there... the (-5) error code is an
> "internal error" status from the device FW on the event queue
> initialization command. Anyway I think the log shows that the problem
> is exactly the one fixed in the commit I mentioned -- a423b8a0
> ("mlx4_core: Allocate and map sufficient ICM memory for EQ context")
> from my infiniband.git tree should fix this.
Never heard of device FW.
>
> The log
>
> > [ 7425.199430] mlx4_core 0000:04:00.0: irq 70 for MSI/MSI-X
> ...
> > [ 7425.199488] mlx4_core 0000:04:00.0: irq 102 for MSI/MSI-X
>
> shows 33 event queues being allocated (num_possible_cpus() + 1) and that
> will hit the issue fixed in that commit.
>
> Assuming this fixes it for you, I guess I should get this into 2.6.31,
> since it obviously is hitting not-particularly-exotic systems in
> practice. I do wonder why num_possible_cpus() is 32 on your box (since
> 16 threads is really the max with nehalem EP).
The Mellanox NIC has two ports. Could that be it?
> commit a423b8a022d523abe834cefe67bfaf42424150a7
Will get back to you shortly when we have tested this patch.
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-18 15:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ingo Molnar, kvm, Avi Kivity, alacrityvm-devel, linux-kernel,
netdev
In-Reply-To: <20090818095313.GC13878@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]
Michael S. Tsirkin wrote:
> On Mon, Aug 17, 2009 at 03:33:30PM -0400, Gregory Haskins wrote:
>> There is a secondary question of venet (a vbus native device) verses
>> virtio-net (a virtio native device that works with PCI or VBUS). If
>> this contention is really around venet vs virtio-net, I may possibly
>> conceed and retract its submission to mainline.
>
> For me yes, venet+ioq competing with virtio+virtqueue.
>
>> I've been pushing it to date because people are using it and I don't
>> see any reason that the driver couldn't be upstream.
>
> If virtio is just as fast, they can just use it without knowing it.
> Clearly, that's better since we support virtio anyway ...
More specifically: kvm can support whatever it wants. I am not asking
kvm to support venet.
If we (the alacrityvm community) decide to keep maintaining venet, _we_
will support it, and I have no problem with that.
As of right now, we are doing some interesting things with it in the lab
and its certainly more flexible for us as a platform since we maintain
the ABI and feature set. So for now, I do not think its a big deal if
they both co-exist, and it has no bearing on KVM upstream.
>
>> -- Issues --
>>
>> Out of all this, I think the biggest contention point is the design of
>> the vbus-connector that I use in AlacrityVM (Avi, correct me if I am
>> wrong and you object to other aspects as well). I suspect that if I had
>> designed the vbus-connector to surface vbus devices as PCI devices via
>> QEMU, the patches would potentially have been pulled in a while ago.
>>
>> There are, of course, reasons why vbus does *not* render as PCI, so this
>> is the meat of of your question, I believe.
>>
>> At a high level, PCI was designed for software-to-hardware interaction,
>> so it makes assumptions about that relationship that do not necessarily
>> apply to virtualization.
>
> I'm not hung up on PCI, myself. An idea that might help you get Avi
> on-board: do setup in userspace, over PCI.
Note that this is exactly what I do.
In AlacrityVM, the guest learns of the available acceleration by the
presence of the PCI-BRIDGE. It then uses that bridge, using standard
PCI mechanisms, to set everything up in the slow-path.
> Negotiate hypercall support
> (e.g. with a PCI capability) and then switch to that for fastpath. Hmm?
>
>> As another example, the connector design coalesces *all* shm-signals
>> into a single interrupt (by prio) that uses the same context-switch
>> mitigation techniques that help boost things like networking. This
>> effectively means we can detect and optimize out ack/eoi cycles from the
>> APIC as the IO load increases (which is when you need it most). PCI has
>> no such concept.
>
> Could you elaborate on this one for me? How does context-switch
> mitigation work?
What I did was I commoditized the concept of signal-mitigation. I then
reuse that concept all over the place to do "NAPI" like mitigation of
the signal path for everthing: for individual interrupts, of course, but
also for things like hypercalls, kthread wakeups, and the interrupt
controller too.
>
>> In addition, the signals and interrupts are priority aware, which is
>> useful for things like 802.1p networking where you may establish 8-tx
>> and 8-rx queues for your virtio-net device. x86 APIC really has no
>> usable equivalent, so PCI is stuck here.
>
> By the way, multiqueue support in virtio would be very nice to have,
Actually what I am talking about is a little different than MQ, but I
agree that both priority-based and concurrency-based MQ would require
similar facilities.
> and seems mostly unrelated to vbus.
Mostly, but not totally. The priority stuff wouldn't work quite right
without similar provisions to the entire signal path, like vbus does.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* [PATCH] net: add Xilinx emac lite device driver
From: John Linn @ 2009-08-18 15:30 UTC (permalink / raw)
To: netdev, linuxppc-dev, jgarzik, davem
Cc: John Linn, Grant Likely, Josh Boyer, John Williams, Michal Simek,
Sadanand M
This patch adds support for the Xilinx Ethernet Lite device. The
soft logic core from Xilinx is typically used on Virtex and Spartan
designs attached to either a PowerPC or a Microblaze processor.
CC: Grant Likely <grant.likely@secretlab.ca>
CC: Josh Boyer <jwboyer@linux.vnet.ibm.com>
CC: John Williams <john.williams@petalogix.com>
CC: Michal Simek <michal.simek@petalogix.com>
Signed-off-by: Sadanand M <sadanan@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/net/Kconfig | 5 +
drivers/net/Makefile | 1 +
drivers/net/xilinx_emaclite.c | 1040 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 1046 insertions(+), 0 deletions(-)
create mode 100755 drivers/net/xilinx_emaclite.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f6509a..84a5120 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1926,6 +1926,11 @@ config ATL2
To compile this driver as a module, choose M here. The module
will be called atl2.
+config XILINX_EMACLITE
+ tristate "Xilinx 10/100 Ethernet Lite support"
+ help
+ This driver supports the 10/100 Ethernet Lite from Xilinx.
+
source "drivers/net/fs_enet/Kconfig"
endif # NET_ETHERNET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ead8cab..99ae6d7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o
ll_temac-objs := ll_temac_main.o ll_temac_mdio.o
obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o
+obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
obj-$(CONFIG_QLA3XXX) += qla3xxx.o
obj-$(CONFIG_QLGE) += qlge/
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
new file mode 100755
index 0000000..3716e20
--- /dev/null
+++ b/drivers/net/xilinx_emaclite.c
@@ -0,0 +1,1040 @@
+/*
+ * Xilinx EmacLite Linux driver for the Xilinx Ethernet MAC Lite device.
+ *
+ * This is a new flat driver which is based on the original emac_lite
+ * driver from John Williams <john.williams@petalogix.com>.
+ *
+ * 2007-2009 (c) Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/io.h>
+
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+
+#define DRIVER_NAME "xilinx_emaclite"
+
+/* Register offsets for the EmacLite Core */
+#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
+#define XEL_GIER_OFFSET 0x07F8 /* GIE Register */
+#define XEL_TSR_OFFSET 0x07FC /* Tx status */
+#define XEL_TPLR_OFFSET 0x07F4 /* Tx packet length */
+
+#define XEL_RXBUFF_OFFSET 0x1000 /* Receive Buffer */
+#define XEL_RPLR_OFFSET 0x100C /* Rx packet length */
+#define XEL_RSR_OFFSET 0x17FC /* Rx status */
+
+#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset */
+
+/* Global Interrupt Enable Register (GIER) Bit Masks */
+#define XEL_GIER_GIE_MASK 0x80000000 /* Global Enable */
+
+/* Transmit Status Register (TSR) Bit Masks */
+#define XEL_TSR_XMIT_BUSY_MASK 0x00000001 /* Tx complete */
+#define XEL_TSR_PROGRAM_MASK 0x00000002 /* Program the MAC address */
+#define XEL_TSR_XMIT_IE_MASK 0x00000008 /* Tx interrupt enable bit */
+#define XEL_TSR_XMIT_ACTIVE_MASK 0x80000000 /* Buffer is active, SW bit
+ * only. This is not documented
+ * in the HW spec */
+
+/* Define for programming the MAC address into the EmacLite */
+#define XEL_TSR_PROG_MAC_ADDR (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK)
+
+/* Receive Status Register (RSR) */
+#define XEL_RSR_RECV_DONE_MASK 0x00000001 /* Rx complete */
+#define XEL_RSR_RECV_IE_MASK 0x00000008 /* Rx interrupt enable bit */
+
+/* Transmit Packet Length Register (TPLR) */
+#define XEL_TPLR_LENGTH_MASK 0x0000FFFF /* Tx packet length */
+
+/* Receive Packet Length Register (RPLR) */
+#define XEL_RPLR_LENGTH_MASK 0x0000FFFF /* Rx packet length */
+
+#define XEL_HEADER_OFFSET 12 /* Offset to length field */
+#define XEL_HEADER_SHIFT 16 /* Shift value for length */
+
+/* General Ethernet Definitions */
+#define XEL_ARP_PACKET_SIZE 28 /* Max ARP packet size */
+#define XEL_HEADER_IP_LENGTH_OFFSET 16 /* IP Length Offset */
+
+
+
+#define TX_TIMEOUT (60*HZ) /* Tx timeout is 60 seconds. */
+#define ALIGNMENT 4
+
+/* BUFFER_ALIGN(adr) calculates the number of bytes to the next alignment. */
+#define BUFFER_ALIGN(adr) ((ALIGNMENT - ((u32) adr)) % ALIGNMENT)
+
+/**
+ * struct net_local - Our private per device data
+ * @ndev: instance of the network device
+ * @tx_ping_pong: indicates whether Tx Pong buffer is configured in HW
+ * @rx_ping_pong: indicates whether Rx Pong buffer is configured in HW
+ * @next_tx_buf_to_use: next Tx buffer to write to
+ * @next_rx_buf_to_use: next Rx buffer to read from
+ * @base_addr: base address of the Emaclite device
+ * @reset_lock: lock used for synchronization
+ * @deferred_skb: holds an skb (for transmission at a later time) when the
+ * Tx buffer is not free
+ */
+struct net_local {
+
+ struct net_device *ndev;
+
+ bool tx_ping_pong;
+ bool rx_ping_pong;
+ u32 next_tx_buf_to_use;
+ u32 next_rx_buf_to_use;
+ void __iomem *base_addr;
+
+ spinlock_t reset_lock;
+ struct sk_buff *deferred_skb;
+};
+
+
+/*************************/
+/* EmacLite driver calls */
+/*************************/
+
+/**
+ * xemaclite_enable_interrupts - Enable the interrupts for the EmacLite device
+ * @drvdata: Pointer to the Emaclite device private data
+ *
+ * This function enables the Tx and Rx interrupts for the Emaclite device along
+ * with the Global Interrupt Enable.
+ */
+static void xemaclite_enable_interrupts(struct net_local *drvdata)
+{
+ u32 reg_data;
+
+ /* Enable the Tx interrupts for the first Buffer */
+ reg_data = in_be32(drvdata->base_addr + XEL_TSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_TSR_OFFSET,
+ reg_data | XEL_TSR_XMIT_IE_MASK);
+
+ /* Enable the Tx interrupts for the second Buffer if
+ * configured in HW */
+ if (drvdata->tx_ping_pong != 0) {
+ reg_data = in_be32(drvdata->base_addr +
+ XEL_BUFFER_OFFSET + XEL_TSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_TSR_OFFSET,
+ reg_data | XEL_TSR_XMIT_IE_MASK);
+ }
+
+ /* Enable the Rx interrupts for the first buffer */
+ reg_data = in_be32(drvdata->base_addr + XEL_RSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_RSR_OFFSET,
+ reg_data | XEL_RSR_RECV_IE_MASK);
+
+ /* Enable the Rx interrupts for the second Buffer if
+ * configured in HW */
+ if (drvdata->rx_ping_pong != 0) {
+ reg_data = in_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_RSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_RSR_OFFSET,
+ reg_data | XEL_RSR_RECV_IE_MASK);
+ }
+
+ /* Enable the Global Interrupt Enable */
+ out_be32(drvdata->base_addr + XEL_GIER_OFFSET, XEL_GIER_GIE_MASK);
+}
+
+/**
+ * xemaclite_disable_interrupts - Disable the interrupts for the EmacLite device
+ * @drvdata: Pointer to the Emaclite device private data
+ *
+ * This function disables the Tx and Rx interrupts for the Emaclite device,
+ * along with the Global Interrupt Enable.
+ */
+static void xemaclite_disable_interrupts(struct net_local *drvdata)
+{
+ u32 reg_data;
+
+ /* Disable the Global Interrupt Enable */
+ out_be32(drvdata->base_addr + XEL_GIER_OFFSET, XEL_GIER_GIE_MASK);
+
+ /* Disable the Tx interrupts for the first buffer */
+ reg_data = in_be32(drvdata->base_addr + XEL_TSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_TSR_OFFSET,
+ reg_data & (~XEL_TSR_XMIT_IE_MASK));
+
+ /* Disable the Tx interrupts for the second Buffer
+ * if configured in HW */
+ if (drvdata->tx_ping_pong != 0) {
+ reg_data = in_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_TSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_TSR_OFFSET,
+ reg_data & (~XEL_TSR_XMIT_IE_MASK));
+ }
+
+ /* Disable the Rx interrupts for the first buffer */
+ reg_data = in_be32(drvdata->base_addr + XEL_RSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_RSR_OFFSET,
+ reg_data & (~XEL_RSR_RECV_IE_MASK));
+
+ /* Disable the Rx interrupts for the second buffer
+ * if configured in HW */
+ if (drvdata->rx_ping_pong != 0) {
+
+ reg_data = in_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_RSR_OFFSET);
+ out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
+ XEL_RSR_OFFSET,
+ reg_data & (~XEL_RSR_RECV_IE_MASK));
+ }
+}
+
+/**
+ * xemaclite_aligned_write - Write from 16-bit aligned to 32-bit aligned address
+ * @src_ptr: Void pointer to the 16-bit aligned source address
+ * @dest_ptr: Pointer to the 32-bit aligned destination address
+ * @length: Number bytes to write from source to destination
+ *
+ * This function writes data from a 16-bit aligned buffer to a 32-bit aligned
+ * address in the EmacLite device.
+ */
+static void xemaclite_aligned_write(void *src_ptr, u32 *dest_ptr,
+ unsigned length)
+{
+ u32 align_buffer;
+ u32 *to_u32_ptr;
+ u16 *from_u16_ptr, *to_u16_ptr;
+
+ to_u32_ptr = dest_ptr;
+ from_u16_ptr = (u16 *) src_ptr;
+ align_buffer = 0;
+
+ for (; length > 3; length -= 4) {
+ to_u16_ptr = (u16 *) ((void *) &align_buffer);
+ *to_u16_ptr++ = *from_u16_ptr++;
+ *to_u16_ptr++ = *from_u16_ptr++;
+
+ /* Output a word */
+ *to_u32_ptr++ = align_buffer;
+ }
+ if (length) {
+ u8 *from_u8_ptr, *to_u8_ptr;
+
+ /* Set up to output the remaining data */
+ align_buffer = 0;
+ to_u8_ptr = (u8 *) &align_buffer;
+ from_u8_ptr = (u8 *) from_u16_ptr;
+
+ /* Output the remaining data */
+ for (; length > 0; length--)
+ *to_u8_ptr++ = *from_u8_ptr++;
+
+ *to_u32_ptr = align_buffer;
+ }
+}
+
+/**
+ * xemaclite_aligned_read - Read from 32-bit aligned to 16-bit aligned buffer
+ * @src_ptr: Pointer to the 32-bit aligned source address
+ * @dest_ptr: Pointer to the 16-bit aligned destination address
+ * @length: Number bytes to read from source to destination
+ *
+ * This function reads data from a 32-bit aligned address in the EmacLite device
+ * to a 16-bit aligned buffer.
+ */
+static void xemaclite_aligned_read(u32 *src_ptr, u8 *dest_ptr,
+ unsigned length)
+{
+ u16 *to_u16_ptr, *from_u16_ptr;
+ u32 *from_u32_ptr;
+ u32 align_buffer;
+
+ from_u32_ptr = src_ptr;
+ to_u16_ptr = (u16 *) dest_ptr;
+
+ for (; length > 3; length -= 4) {
+ /* Copy each word into the temporary buffer */
+ align_buffer = *from_u32_ptr++;
+ from_u16_ptr = (u16 *)&align_buffer;
+
+ /* Read data from source */
+ *to_u16_ptr++ = *from_u16_ptr++;
+ *to_u16_ptr++ = *from_u16_ptr++;
+ }
+
+ if (length) {
+ u8 *to_u8_ptr, *from_u8_ptr;
+
+ /* Set up to read the remaining data */
+ to_u8_ptr = (u8 *) to_u16_ptr;
+ align_buffer = *from_u32_ptr++;
+ from_u8_ptr = (u8 *) &align_buffer;
+
+ /* Read the remaining data */
+ for (; length > 0; length--)
+ *to_u8_ptr = *from_u8_ptr;
+ }
+}
+
+/**
+ * xemaclite_send_data - Send an Ethernet frame
+ * @drvdata: Pointer to the Emaclite device private data
+ * @data: Pointer to the data to be sent
+ * @byte_count: Total frame size, including header
+ *
+ * This function checks if the Tx buffer of the Emaclite device is free to send
+ * data. If so, it fills the Tx buffer with data for transmission. Otherwise, it
+ * returns an error.
+ *
+ * Return: 0 upon success or -1 if the buffer(s) are full.
+ *
+ * Note: The maximum Tx packet size can not be more than Ethernet header
+ * (14 Bytes) + Maximum MTU (1500 bytes). This is excluding FCS.
+ */
+static int xemaclite_send_data(struct net_local *drvdata, u8 *data,
+ unsigned int byte_count)
+{
+ u32 reg_data;
+ void __iomem *addr;
+
+ /* Determine the expected Tx buffer address */
+ addr = drvdata->base_addr + drvdata->next_tx_buf_to_use;
+
+ /* If the length is too large, truncate it */
+ if (byte_count > ETH_FRAME_LEN)
+ byte_count = ETH_FRAME_LEN;
+
+ /* Check if the expected buffer is available */
+ reg_data = in_be32(addr + XEL_TSR_OFFSET);
+ if ((reg_data & (XEL_TSR_XMIT_BUSY_MASK |
+ XEL_TSR_XMIT_ACTIVE_MASK)) == 0) {
+
+ /* Switch to next buffer if configured */
+ if (drvdata->tx_ping_pong != 0)
+ drvdata->next_tx_buf_to_use ^= XEL_BUFFER_OFFSET;
+ } else if (drvdata->tx_ping_pong != 0) {
+ /* If the expected buffer is full, try the other buffer,
+ * if it is configured in HW */
+
+ addr = (void __iomem __force *)((u32 __force)addr ^
+ XEL_BUFFER_OFFSET);
+ reg_data = in_be32(addr + XEL_TSR_OFFSET);
+
+ if ((reg_data & (XEL_TSR_XMIT_BUSY_MASK |
+ XEL_TSR_XMIT_ACTIVE_MASK)) != 0)
+ return -1; /* Buffers were full, return failure */
+ } else
+ return -1; /* Buffer was full, return failure */
+
+ /* Write the frame to the buffer */
+ xemaclite_aligned_write(data, (u32 __force *) addr, byte_count);
+
+ out_be32(addr + XEL_TPLR_OFFSET, (byte_count & XEL_TPLR_LENGTH_MASK));
+
+ /* Update the Tx Status Register to indicate that there is a
+ * frame to send. Set the XEL_TSR_XMIT_ACTIVE_MASK flag which
+ * is used by the interrupt handler to check whether a frame
+ * has been transmitted */
+ reg_data = in_be32(addr + XEL_TSR_OFFSET);
+ reg_data |= (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_XMIT_ACTIVE_MASK);
+ out_be32(addr + XEL_TSR_OFFSET, reg_data);
+
+ return 0;
+}
+
+/**
+ * xemaclite_recv_data - Receive a frame
+ * @drvdata: Pointer to the Emaclite device private data
+ * @data: Address where the data is to be received
+ *
+ * This function is intended to be called from the interrupt context or
+ * with a wrapper which waits for the receive frame to be available.
+ *
+ * Return: Total number of bytes received
+ */
+static u16 xemaclite_recv_data(struct net_local *drvdata, u8 *data)
+{
+ void __iomem *addr;
+ u16 length, proto_type;
+ u32 reg_data;
+
+ /* Determine the expected buffer address */
+ addr = (drvdata->base_addr + drvdata->next_rx_buf_to_use);
+
+ /* Verify which buffer has valid data */
+ reg_data = in_be32(addr + XEL_RSR_OFFSET);
+
+ if ((reg_data & XEL_RSR_RECV_DONE_MASK) == XEL_RSR_RECV_DONE_MASK) {
+ if (drvdata->rx_ping_pong != 0)
+ drvdata->next_rx_buf_to_use ^= XEL_BUFFER_OFFSET;
+ } else {
+ /* The instance is out of sync, try other buffer if other
+ * buffer is configured, return 0 otherwise. If the instance is
+ * out of sync, do not update the 'next_rx_buf_to_use' since it
+ * will correct on subsequent calls */
+ if (drvdata->rx_ping_pong != 0)
+ addr = (void __iomem __force *)((u32 __force)addr ^
+ XEL_BUFFER_OFFSET);
+ else
+ return 0; /* No data was available */
+
+ /* Verify that buffer has valid data */
+ reg_data = in_be32(addr + XEL_RSR_OFFSET);
+ if ((reg_data & XEL_RSR_RECV_DONE_MASK) !=
+ XEL_RSR_RECV_DONE_MASK)
+ return 0; /* No data was available */
+ }
+
+ /* Get the protocol type of the ethernet frame that arrived */
+ proto_type = ((in_be32(addr + XEL_HEADER_OFFSET +
+ XEL_RXBUFF_OFFSET) >> XEL_HEADER_SHIFT) &
+ XEL_RPLR_LENGTH_MASK);
+
+ /* Check if received ethernet frame is a raw ethernet frame
+ * or an IP packet or an ARP packet */
+ if (proto_type > (ETH_FRAME_LEN + ETH_FCS_LEN)) {
+
+ if (proto_type == ETH_P_IP) {
+ length = ((in_be32(addr +
+ XEL_HEADER_IP_LENGTH_OFFSET +
+ XEL_RXBUFF_OFFSET) >>
+ XEL_HEADER_SHIFT) &
+ XEL_RPLR_LENGTH_MASK);
+ length += ETH_HLEN + ETH_FCS_LEN;
+
+ } else if (proto_type == ETH_P_ARP)
+ length = XEL_ARP_PACKET_SIZE + ETH_HLEN + ETH_FCS_LEN;
+ else
+ /* Field contains type other than IP or ARP, use max
+ * frame size and let user parse it */
+ length = ETH_FRAME_LEN + ETH_FCS_LEN;
+ } else
+ /* Use the length in the frame, plus the header and trailer */
+ length = proto_type + ETH_HLEN + ETH_FCS_LEN;
+
+ /* Read from the EmacLite device */
+ xemaclite_aligned_read((u32 __force *) (addr + XEL_RXBUFF_OFFSET),
+ data, length);
+
+ /* Acknowledge the frame */
+ reg_data = in_be32(addr + XEL_RSR_OFFSET);
+ reg_data &= ~XEL_RSR_RECV_DONE_MASK;
+ out_be32(addr + XEL_RSR_OFFSET, reg_data);
+
+ return length;
+}
+
+/**
+ * xemaclite_set_mac_address - Set the MAC address for this device
+ * @drvdata: Pointer to the Emaclite device private data
+ * @address_ptr:Pointer to the MAC address (MAC address is a 48-bit value)
+ *
+ * Tx must be idle and Rx should be idle for deterministic results.
+ * It is recommended that this function should be called after the
+ * initialization and before transmission of any packets from the device.
+ * The MAC address can be programmed using any of the two transmit
+ * buffers (if configured).
+ */
+static void xemaclite_set_mac_address(struct net_local *drvdata,
+ u8 *address_ptr)
+{
+ void __iomem *addr;
+ u32 reg_data;
+
+ /* Determine the expected Tx buffer address */
+ addr = drvdata->base_addr + drvdata->next_tx_buf_to_use;
+
+ xemaclite_aligned_write(address_ptr, (u32 __force *) addr, ETH_ALEN);
+
+ out_be32(addr + XEL_TPLR_OFFSET, ETH_ALEN);
+
+ /* Update the MAC address in the EmacLite */
+ reg_data = in_be32(addr + XEL_TSR_OFFSET);
+ out_be32(addr + XEL_TSR_OFFSET, reg_data | XEL_TSR_PROG_MAC_ADDR);
+
+ /* Wait for EmacLite to finish with the MAC address update */
+ while ((in_be32(addr + XEL_TSR_OFFSET) &
+ XEL_TSR_PROG_MAC_ADDR) != 0)
+ ;
+}
+
+/**
+ * xemaclite_tx_timeout - Callback for Tx Timeout
+ * @dev: Pointer to the network device
+ *
+ * This function is called when Tx time out occurs for Emaclite device.
+ */
+static void xemaclite_tx_timeout(struct net_device *dev)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ unsigned long flags;
+
+ dev_err(&lp->ndev->dev, "Exceeded transmit timeout of %lu ms\n",
+ TX_TIMEOUT * 1000UL / HZ);
+
+ dev->stats.tx_errors++;
+
+ /* Reset the device */
+ spin_lock_irqsave(&lp->reset_lock, flags);
+
+ /* Shouldn't really be necessary, but shouldn't hurt */
+ netif_stop_queue(dev);
+
+ xemaclite_disable_interrupts(lp);
+ xemaclite_enable_interrupts(lp);
+
+ if (lp->deferred_skb) {
+ dev_kfree_skb(lp->deferred_skb);
+ lp->deferred_skb = NULL;
+ dev->stats.tx_errors++;
+ }
+
+ /* To exclude tx timeout */
+ dev->trans_start = 0xffffffff - TX_TIMEOUT - TX_TIMEOUT;
+
+ /* We're all ready to go. Start the queue */
+ netif_wake_queue(dev);
+ spin_unlock_irqrestore(&lp->reset_lock, flags);
+}
+
+/**********************/
+/* Interrupt Handlers */
+/**********************/
+
+/**
+ * xemaclite_tx_handler - Interrupt handler for frames sent
+ * @dev: Pointer to the network device
+ *
+ * This function updates the number of packets transmitted and handles the
+ * deferred skb, if there is one.
+ */
+static void xemaclite_tx_handler(struct net_device *dev)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+
+ dev->stats.tx_packets++;
+ if (lp->deferred_skb) {
+ if (xemaclite_send_data(lp,
+ (u8 *) lp->deferred_skb->data,
+ lp->deferred_skb->len) != 0)
+ return;
+ else {
+ dev->stats.tx_bytes += lp->deferred_skb->len;
+ dev_kfree_skb_irq(lp->deferred_skb);
+ lp->deferred_skb = NULL;
+ dev->trans_start = jiffies;
+ netif_wake_queue(dev);
+ }
+ }
+}
+
+/**
+ * xemaclite_rx_handler- Interrupt handler for frames received
+ * @dev: Pointer to the network device
+ *
+ * This function allocates memory for a socket buffer, fills it with data
+ * received and hands it over to the TCP/IP stack.
+ */
+static void xemaclite_rx_handler(struct net_device *dev)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ struct sk_buff *skb;
+ unsigned int align;
+ u32 len;
+
+ len = ETH_FRAME_LEN + ETH_FCS_LEN;
+ skb = dev_alloc_skb(len + ALIGNMENT);
+ if (!skb) {
+ /* Couldn't get memory. */
+ dev->stats.rx_dropped++;
+ dev_err(&lp->ndev->dev, "Could not allocate receive buffer\n");
+ return;
+ }
+
+ /*
+ * A new skb should have the data halfword aligned, but this code is
+ * here just in case that isn't true. Calculate how many
+ * bytes we should reserve to get the data to start on a word
+ * boundary */
+ align = BUFFER_ALIGN(skb->data);
+ if (align)
+ skb_reserve(skb, align);
+
+ skb_reserve(skb, 2);
+
+ len = xemaclite_recv_data(lp, (u8 *) skb->data);
+
+ if (!len) {
+ dev->stats.rx_errors++;
+ dev_kfree_skb_irq(skb);
+ return;
+ }
+
+ skb_put(skb, len); /* Tell the skb how much data we got */
+ skb->dev = dev; /* Fill out required meta-data */
+
+ skb->protocol = eth_type_trans(skb, dev);
+ skb->ip_summed = CHECKSUM_NONE;
+
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += len;
+ dev->last_rx = jiffies;
+
+ netif_rx(skb); /* Send the packet upstream */
+}
+
+/**
+ * xemaclite_interrupt - Interrupt handler for this driver
+ * @irq: Irq of the Emaclite device
+ * @dev_id: Void pointer to the network device instance used as callback
+ * reference
+ *
+ * This function handles the Tx and Rx interrupts of the EmacLite device.
+ */
+static irqreturn_t xemaclite_interrupt(int irq, void *dev_id)
+{
+ bool tx_complete = 0;
+ struct net_device *dev = dev_id;
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ void __iomem *base_addr = lp->base_addr;
+ u32 tx_status;
+
+ /* Check if there is Rx Data available */
+ if ((in_be32(base_addr + XEL_RSR_OFFSET) & XEL_RSR_RECV_DONE_MASK) ||
+ (in_be32(base_addr + XEL_BUFFER_OFFSET + XEL_RSR_OFFSET)
+ & XEL_RSR_RECV_DONE_MASK))
+
+ xemaclite_rx_handler(dev);
+
+ /* Check if the Transmission for the first buffer is completed */
+ tx_status = in_be32(base_addr + XEL_TSR_OFFSET);
+ if (((tx_status & XEL_TSR_XMIT_BUSY_MASK) == 0) &&
+ (tx_status & XEL_TSR_XMIT_ACTIVE_MASK) != 0) {
+
+ tx_status &= ~XEL_TSR_XMIT_ACTIVE_MASK;
+ out_be32(base_addr + XEL_TSR_OFFSET, tx_status);
+
+ tx_complete = 1;
+ }
+
+ /* Check if the Transmission for the second buffer is completed */
+ tx_status = in_be32(base_addr + XEL_BUFFER_OFFSET + XEL_TSR_OFFSET);
+ if (((tx_status & XEL_TSR_XMIT_BUSY_MASK) == 0) &&
+ (tx_status & XEL_TSR_XMIT_ACTIVE_MASK) != 0) {
+
+ tx_status &= ~XEL_TSR_XMIT_ACTIVE_MASK;
+ out_be32(base_addr + XEL_BUFFER_OFFSET + XEL_TSR_OFFSET,
+ tx_status);
+
+ tx_complete = 1;
+ }
+
+ /* If there was a Tx interrupt, call the Tx Handler */
+ if (tx_complete != 0)
+ xemaclite_tx_handler(dev);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * xemaclite_open - Open the network device
+ * @dev: Pointer to the network device
+ *
+ * This function sets the MAC address, requests an IRQ and enables interrupts
+ * for the Emaclite device and starts the Tx queue.
+ */
+static int xemaclite_open(struct net_device *dev)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ int retval;
+
+ /* Just to be safe, stop the device first */
+ xemaclite_disable_interrupts(lp);
+
+ /* Set the MAC address each time opened */
+ xemaclite_set_mac_address(lp, dev->dev_addr);
+
+ /* Grab the IRQ */
+ retval = request_irq(dev->irq, &xemaclite_interrupt, 0, dev->name, dev);
+ if (retval) {
+ dev_err(&lp->ndev->dev, "Could not allocate interrupt %d\n",
+ dev->irq);
+ return retval;
+ }
+
+ /* Enable Interrupts */
+ xemaclite_enable_interrupts(lp);
+
+ /* We're ready to go */
+ netif_start_queue(dev);
+
+ return 0;
+}
+
+/**
+ * xemaclite_close - Close the network device
+ * @dev: Pointer to the network device
+ *
+ * This function stops the Tx queue, disables interrupts and frees the IRQ for
+ * the Emaclite device.
+ */
+static int xemaclite_close(struct net_device *dev)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+
+ netif_stop_queue(dev);
+ xemaclite_disable_interrupts(lp);
+ free_irq(dev->irq, dev);
+
+ return 0;
+}
+
+/**
+ * xemaclite_get_stats - Get the stats for the net_device
+ * @dev: Pointer to the network device
+ *
+ * This function returns the address of the 'net_device_stats' structure for the
+ * given network device. This structure holds usage statistics for the network
+ * device.
+ *
+ * Return: Pointer to the net_device_stats structure.
+ */
+static struct net_device_stats *xemaclite_get_stats(struct net_device *dev)
+{
+ return &dev->stats;
+}
+
+/**
+ * xemaclite_send - Transmit a frame
+ * @orig_skb: Pointer to the socket buffer to be transmitted
+ * @dev: Pointer to the network device
+ *
+ * This function checks if the Tx buffer of the Emaclite device is free to send
+ * data. If so, it fills the Tx buffer with data from socket buffer data,
+ * updates the stats and frees the socket buffer. The Tx completion is signaled
+ * by an interrupt. If the Tx buffer isn't free, then the socket buffer is
+ * deferred and the Tx queue is stopped so that the deferred socket buffer can
+ * be transmitted when the Emaclite device is free to transmit data.
+ *
+ * Return: 0, always.
+ */
+static int xemaclite_send(struct sk_buff *orig_skb, struct net_device *dev)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ struct sk_buff *new_skb;
+ unsigned int len;
+ unsigned long flags;
+
+ len = orig_skb->len;
+
+ new_skb = orig_skb;
+
+ spin_lock_irqsave(&lp->reset_lock, flags);
+ if (xemaclite_send_data(lp, (u8 *) new_skb->data, len) != 0) {
+ /* If the Emaclite Tx buffer is busy, stop the Tx queue and
+ * defer the skb for transmission at a later point when the
+ * current transmission is complete */
+ netif_stop_queue(dev);
+ lp->deferred_skb = new_skb;
+ spin_unlock_irqrestore(&lp->reset_lock, flags);
+ return 0;
+ }
+ spin_unlock_irqrestore(&lp->reset_lock, flags);
+
+ dev->stats.tx_bytes += len;
+ dev_kfree_skb(new_skb);
+ dev->trans_start = jiffies;
+
+ return 0;
+}
+
+/**
+ * xemaclite_ioctl - Perform IO Control operations on the network device
+ * @dev: Pointer to the network device
+ * @rq: Pointer to the interface request structure
+ * @cmd: IOCTL command
+ *
+ * The only IOCTL operation supported by this function is setting the MAC
+ * address. An error is reported if any other operations are requested.
+ *
+ * Return: 0 to indicate success, or a negative error for failure.
+ */
+static int xemaclite_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+ struct net_local *lp = (struct net_local *) netdev_priv(dev);
+ struct hw_addr_data *hw_addr = (struct hw_addr_data *) &rq->ifr_hwaddr;
+
+ switch (cmd) {
+ case SIOCETHTOOL:
+ return -EIO;
+
+ case SIOCSIFHWADDR:
+ dev_err(&lp->ndev->dev, "SIOCSIFHWADDR\n");
+
+ /* Copy MAC address in from user space */
+ copy_from_user((void __force *) dev->dev_addr,
+ (void __user __force *) hw_addr,
+ IFHWADDRLEN);
+ xemaclite_set_mac_address(lp, dev->dev_addr);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+/**
+ * xemaclite_remove_ndev - Free the network device
+ * @ndev: Pointer to the network device to be freed
+ *
+ * This function un maps the IO region of the Emaclite device and frees the net
+ * device.
+ */
+static void xemaclite_remove_ndev(struct net_device *ndev)
+{
+ if (ndev) {
+ struct net_local *lp = (struct net_local *) netdev_priv(ndev);
+
+ if (lp->base_addr)
+ iounmap((void __iomem __force *) (lp->base_addr));
+ free_netdev(ndev);
+ }
+}
+
+/**
+ * get_bool - Get a parameter from the OF device
+ * @ofdev: Pointer to OF device structure
+ * @s: Property to be retrieved
+ *
+ * This function looks for a property in the device node and returns the value
+ * of the property if its found or 0 if the property is not found.
+ *
+ * Return: Value of the parameter if the parameter is found, or 0 otherwise
+ */
+static bool get_bool(struct of_device *ofdev, const char *s)
+{
+ u32 *p = (u32 *)of_get_property(ofdev->node, s, NULL);
+
+ if (p) {
+ return (bool)*p;
+ } else {
+ dev_warn(&ofdev->dev, "Parameter %s not found,"
+ "defaulting to false\n", s);
+ return 0;
+ }
+}
+
+static struct net_device_ops xemaclite_netdev_ops;
+
+/**
+ * xemaclite_of_probe - Probe method for the Emaclite device.
+ * @ofdev: Pointer to OF device structure
+ * @match: Pointer to the structure used for matching a device
+ *
+ * This function probes for the Emaclite device in the device tree.
+ * It initializes the driver data structure and the hardware, sets the MAC
+ * address and registers the network device.
+ *
+ * Return: 0, if the driver is bound to the Emaclite device, or
+ * a negative error if there is failure.
+ */
+static int __devinit xemaclite_of_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct resource r_irq; /* Interrupt resources */
+ struct resource r_mem; /* IO mem resources */
+ struct net_device *ndev = NULL;
+ struct net_local *lp = NULL;
+ struct device *dev = &ofdev->dev;
+ const void *mac_address;
+
+ int rc = 0;
+
+ dev_info(dev, "Device Tree Probing\n");
+
+ /* Get iospace for the device */
+ rc = of_address_to_resource(ofdev->node, 0, &r_mem);
+ if (rc) {
+ dev_err(dev, "invalid address\n");
+ return rc;
+ }
+
+ /* Get IRQ for the device */
+ rc = of_irq_to_resource(ofdev->node, 0, &r_irq);
+ if (rc == NO_IRQ) {
+ dev_err(dev, "no IRQ found\n");
+ return rc;
+ }
+
+ /* Create an ethernet device instance */
+ ndev = alloc_etherdev(sizeof(struct net_local));
+ if (!ndev) {
+ dev_err(dev, "Could not allocate network device\n");
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(dev, ndev);
+
+ ndev->irq = r_irq.start;
+ ndev->mem_start = r_mem.start;
+ ndev->mem_end = r_mem.end;
+
+ lp = netdev_priv(ndev);
+ lp->ndev = ndev;
+
+ if (!request_mem_region(ndev->mem_start,
+ ndev->mem_end - ndev->mem_start + 1,
+ DRIVER_NAME)) {
+ dev_err(dev, "Couldn't lock memory region at %p\n",
+ (void *)ndev->mem_start);
+ rc = -EBUSY;
+ goto error2;
+ }
+
+ /* Get the virtual base address for the device */
+ lp->base_addr = ioremap(r_mem.start, r_mem.end - r_mem.start + 1);
+ if (NULL == lp->base_addr) {
+ dev_err(dev, "EmacLite: Could not allocate iomem\n");
+ rc = -EIO;
+ goto error1;
+ }
+
+ lp->next_tx_buf_to_use = 0x0;
+ lp->next_rx_buf_to_use = 0x0;
+ lp->tx_ping_pong = get_bool(ofdev, "xlnx,tx-ping-pong");
+ lp->rx_ping_pong = get_bool(ofdev, "xlnx,rx-ping-pong");
+ mac_address = of_get_mac_address(ofdev->node);
+
+ if (mac_address)
+ /* Set the MAC address. */
+ memcpy(ndev->dev_addr, mac_address, 6);
+ else
+ dev_warn(dev, "No MAC address found\n");
+
+ /* Clear the Tx CSR's in case this is a restart */
+ out_be32(lp->base_addr + XEL_TSR_OFFSET, 0);
+ out_be32(lp->base_addr + XEL_BUFFER_OFFSET + XEL_TSR_OFFSET, 0);
+
+ /* Set the MAC address in the EmacLite device */
+ xemaclite_set_mac_address(lp, ndev->dev_addr);
+
+ dev_info(dev,
+ "MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
+ ndev->dev_addr[0], ndev->dev_addr[1],
+ ndev->dev_addr[2], ndev->dev_addr[3],
+ ndev->dev_addr[4], ndev->dev_addr[5]);
+
+ ndev->netdev_ops = &xemaclite_netdev_ops;
+ ndev->flags &= ~IFF_MULTICAST;
+ ndev->watchdog_timeo = TX_TIMEOUT;
+
+ /* Finally, register the device */
+ rc = register_netdev(ndev);
+ if (rc) {
+ dev_err(dev,
+ "Cannot register network device, aborting\n");
+ goto error1;
+ }
+
+ dev_info(dev,
+ "Xilinx EmacLite at 0x%08X mapped to 0x%08X, irq=%d\n",
+ (unsigned int __force)ndev->mem_start,
+ (unsigned int __force)lp->base_addr, ndev->irq);
+ return 0;
+
+error1:
+ release_mem_region(ndev->mem_start, r_mem.end - r_mem.start + 1);
+
+error2:
+ xemaclite_remove_ndev(ndev);
+ return rc;
+}
+
+/**
+ * xemaclite_of_remove - Unbind the driver from the Emaclite device.
+ * @of_dev: Pointer to OF device structure
+ *
+ * This function is called if a device is physically removed from the system or
+ * if the driver module is being unloaded. It frees any resources allocated to
+ * the device.
+ *
+ * Return: 0, always.
+ */
+static int __devexit xemaclite_of_remove(struct of_device *of_dev)
+{
+ struct device *dev = &of_dev->dev;
+ struct net_device *ndev = dev_get_drvdata(dev);
+
+ unregister_netdev(ndev);
+
+ release_mem_region(ndev->mem_start, ndev->mem_end-ndev->mem_start + 1);
+
+ xemaclite_remove_ndev(ndev);
+
+ dev_set_drvdata(dev, NULL);
+
+ return 0;
+}
+
+static struct net_device_ops xemaclite_netdev_ops = {
+ .ndo_open = xemaclite_open,
+ .ndo_stop = xemaclite_close,
+ .ndo_start_xmit = xemaclite_send,
+ .ndo_do_ioctl = xemaclite_ioctl,
+ .ndo_tx_timeout = xemaclite_tx_timeout,
+ .ndo_get_stats = xemaclite_get_stats,
+};
+
+/* Match table for OF platform binding */
+static struct of_device_id xemaclite_of_match[] __devinitdata = {
+ { .compatible = "xlnx,opb-ethernetlite-1.01.a", },
+ { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
+ { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
+ { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
+ { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
+ { /* end of list */ },
+};
+MODULE_DEVICE_TABLE(of, xemaclite_of_match);
+
+static struct of_platform_driver xemaclite_of_driver = {
+ .name = DRIVER_NAME,
+ .match_table = xemaclite_of_match,
+ .probe = xemaclite_of_probe,
+ .remove = __devexit_p(xemaclite_of_remove),
+};
+
+/**
+ * xgpiopss_init - Initial driver registration call
+ *
+ * Return: 0 upon success, or a negative error upon failure.
+ */
+static int __init xemaclite_init(void)
+{
+ /* No kernel boot options used, we just need to register the driver */
+ return of_register_platform_driver(&xemaclite_of_driver);
+}
+
+/**
+ * xemaclite_cleanup - Driver un-registration call
+ */
+static void __exit xemaclite_cleanup(void)
+{
+ of_unregister_platform_driver(&xemaclite_of_driver);
+}
+
+module_init(xemaclite_init);
+module_exit(xemaclite_cleanup);
+
+MODULE_AUTHOR("Xilinx, Inc.");
+MODULE_DESCRIPTION("Xilinx Ethernet MAC Lite driver");
+MODULE_LICENSE("GPL");
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-18 15:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Haskins, Anthony Liguori, Ingo Molnar, kvm, Avi Kivity,
alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <20090818084606.GA13878@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 6115 bytes --]
Michael S. Tsirkin wrote:
> On Mon, Aug 17, 2009 at 04:17:09PM -0400, Gregory Haskins wrote:
>> Michael S. Tsirkin wrote:
>>> On Mon, Aug 17, 2009 at 10:14:56AM -0400, Gregory Haskins wrote:
>>>> Case in point: Take an upstream kernel and you can modprobe the
>>>> vbus-pcibridge in and virtio devices will work over that transport
>>>> unmodified.
>>>>
>>>> See http://lkml.org/lkml/2009/8/6/244 for details.
>>> The modprobe you are talking about would need
>>> to be done in guest kernel, correct?
>> Yes, and your point is? "unmodified" (pardon the psuedo pun) modifies
>> "virtio", not "guest".
>> It means you can take an off-the-shelf kernel
>> with off-the-shelf virtio (ala distro-kernel) and modprobe
>> vbus-pcibridge and get alacrityvm acceleration.
>
> Heh, by that logic ksplice does not modify running kernel either :)
Sigh...this is just fud.
Again, I never said I do not modify the guest. I only said that virtio
is unmodified and all the existing devices can work unmodified.
I hardly think its fair to compare something like loading a pci-bridge
driver into a running kernel is the same as patching the kernel. You
just load a driver to get access to your IO resources...standard stuff
really.
>
>> It is not a design goal of mine to forbid the loading of a new driver,
>> so I am ok with that requirement.
>>
>>>> OTOH, Michael's patch is purely targeted at improving virtio-net on kvm,
>>>> and its likewise constrained by various limitations of that decision
>>>> (such as its reliance of the PCI model, and the kvm memory scheme).
>>> vhost is actually not related to PCI in any way. It simply leaves all
>>> setup for userspace to do. And the memory scheme was intentionally
>>> separated from kvm so that it can easily support e.g. lguest.
>>>
>> I think you have missed my point. I mean that vhost requires a separate
>> bus-model (ala qemu-pci).
>
> So? That can be in userspace, and can be anything including vbus.
-ENOPARSE
Can you elaborate?
>
>> And no, your memory scheme is not separated,
>> at least, not very well. It still assumes memory-regions and
>> copy_to_user(), which is very kvm-esque.
>
> I don't think so: works for lguest, kvm, UML and containers
kvm _esque_ , meaning anything that follows the region+copy_to_user
model. Not all things do.
>
>> Vbus has people using things
>> like userspace containers (no regions),
>
> vhost by default works without regions
Thats a start, but not good enough if you were trying to achieve the
same thing as vbus. As I said before, I've never said you had to
achieve the same thing, but do note they are distinctly different with
different goals. You are solving a directed problem. I am solving a
general problem, and trying to solve it once.
>
>> and physical hardware (dma
>> controllers, so no regions or copy_to_user) so your scheme quickly falls
>> apart once you get away from KVM.
>
> Someone took a driver and is building hardware for it ... so what?
What is your point?
>
>> Don't get me wrong: That design may have its place. Perhaps you only
>> care about fixing KVM, which is a perfectly acceptable strategy.
>> Its just not a strategy that I think is the best approach. Essentially you
>> are promoting the proliferation of competing backends, and I am trying
>> to unify them (which is ironic that this thread started with concerns I
>> was fragmenting things ;).
>
> So, you don't see how venet fragments things? It's pretty obvious ...
I never said it doesn't. venet started as a test harness, but now it is
inadvertently fragmenting the virtio-net effort. I admit it. It wasn't
intentional, but just worked out that way. Until your vhost idea is
vetted and benchmarked, its not even in the running. Venet is currently
the highest performing 802.x acceleration for KVM that I am aware of, so
it will continue to garner interest from users concerned with performance.
But likewise, vhost has the potential to fragment the back-end model.
That was my point.
>
>> The bottom line is, you have a simpler solution that is more finely
>> targeted at KVM and virtio-networking. It fixes probably a lot of
>> problems with the existing implementation, but it still has limitations.
>>
>> OTOH, what I am promoting is more complex, but more flexible. That is
>> the tradeoff. You can't have both ;)
>
> We can. connect eventfds to hypercalls, and vhost will work with vbus.
-ENOPARSE
vbus doesnt use hypercalls, and I do not see why or how you would
connect two backend models together like this. Can you elaborate.
>
>> So do not for one second think
>> that what you implemented is equivalent, because they are not.
>>
>> In fact, I believe I warned you about this potential problem when you
>> decided to implement your own version. I think I said something to the
>> effect of "you will either have a subset of functionality, or you will
>> ultimately reinvent what I did". Right now you are in the subset phase.
>
> No. Unlike vbus, vhost supports unmodified guests and live migration.
By "subset", I am referring to your interfaces and the scope of its
applicability. The things you need to do to make vhost work and a vbus
device work from a memory and signaling abstration POV are going to be
extremely similar.
The difference in how the guest sees them these backends is all
contained in the vbus-connector. Therefore, what you *could* have done
is simply written a connector that does something like only support
"virtio" backends, and surfaced them as regular PCI devices to the
guest. Then you could have reused all the abstraction features in vbus,
instead of reinventing them (case in point, your region+copy_to_user
code). And likewise, anyone using vbus could use your virtio-net backend.
Instead, I am still left with no virtio-net backend implemented, and you
were left designing, writing, and testing facilities that I've already
completed. So it was duplicative effort.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* pull request: wireless-2.6 2009-08-18
From: John W. Linville @ 2009-08-18 15:14 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
Two more for 2.6.31...
The one from Johannes is actually already in net-next-2.6, but it has
since been reported to cause a possible irq lock inversion dependency in
2.6.31-rc6, as described here:
http://marc.info/?l=linux-wireless&m=125052198303537&w=2
The one from me fixes a minor bounds checking problem in orinoco, as
reported by Dan Carpenter. It is simple and obvious.
Please let me know if there are problems!
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 8cdb045632e5ee22854538619ac6f150eb0a4894:
Tom Goff (1):
gre: Fix MTU calculation for bound GRE tunnels
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (1):
mac80211: fix todo lock
John W. Linville (1):
orinoco: correct key bounds check in orinoco_hw_get_tkip_iv
drivers/net/wireless/orinoco/hw.c | 2 +-
net/mac80211/key.c | 28 +++++++++++++++-------------
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/orinoco/hw.c b/drivers/net/wireless/orinoco/hw.c
index 632fac8..b394627 100644
--- a/drivers/net/wireless/orinoco/hw.c
+++ b/drivers/net/wireless/orinoco/hw.c
@@ -70,7 +70,7 @@ int orinoco_hw_get_tkip_iv(struct orinoco_private *priv, int key, u8 *tsc)
int err = 0;
u8 tsc_arr[4][IW_ENCODE_SEQ_MAX_SIZE];
- if ((key < 0) || (key > 4))
+ if ((key < 0) || (key >= 4))
return -EINVAL;
err = hermes_read_ltv(hw, USER_BAP, HERMES_RID_CURRENT_TKIP_IV,
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index ce26756..659a42d 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -67,6 +67,8 @@ static DECLARE_WORK(todo_work, key_todo);
*
* @key: key to add to do item for
* @flag: todo flag(s)
+ *
+ * Must be called with IRQs or softirqs disabled.
*/
static void add_todo(struct ieee80211_key *key, u32 flag)
{
@@ -140,9 +142,9 @@ static void ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
ret = drv_set_key(key->local, SET_KEY, &sdata->vif, sta, &key->conf);
if (!ret) {
- spin_lock(&todo_lock);
+ spin_lock_bh(&todo_lock);
key->flags |= KEY_FLAG_UPLOADED_TO_HARDWARE;
- spin_unlock(&todo_lock);
+ spin_unlock_bh(&todo_lock);
}
if (ret && ret != -ENOSPC && ret != -EOPNOTSUPP)
@@ -164,12 +166,12 @@ static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
if (!key || !key->local->ops->set_key)
return;
- spin_lock(&todo_lock);
+ spin_lock_bh(&todo_lock);
if (!(key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)) {
- spin_unlock(&todo_lock);
+ spin_unlock_bh(&todo_lock);
return;
}
- spin_unlock(&todo_lock);
+ spin_unlock_bh(&todo_lock);
sta = get_sta_for_key(key);
sdata = key->sdata;
@@ -188,9 +190,9 @@ static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
wiphy_name(key->local->hw.wiphy),
key->conf.keyidx, sta ? sta->addr : bcast_addr, ret);
- spin_lock(&todo_lock);
+ spin_lock_bh(&todo_lock);
key->flags &= ~KEY_FLAG_UPLOADED_TO_HARDWARE;
- spin_unlock(&todo_lock);
+ spin_unlock_bh(&todo_lock);
}
static void __ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata,
@@ -437,14 +439,14 @@ void ieee80211_key_link(struct ieee80211_key *key,
__ieee80211_key_replace(sdata, sta, old_key, key);
- spin_unlock_irqrestore(&sdata->local->key_lock, flags);
-
/* free old key later */
add_todo(old_key, KEY_FLAG_TODO_DELETE);
add_todo(key, KEY_FLAG_TODO_ADD_DEBUGFS);
if (netif_running(sdata->dev))
add_todo(key, KEY_FLAG_TODO_HWACCEL_ADD);
+
+ spin_unlock_irqrestore(&sdata->local->key_lock, flags);
}
static void __ieee80211_key_free(struct ieee80211_key *key)
@@ -547,7 +549,7 @@ static void __ieee80211_key_todo(void)
*/
synchronize_rcu();
- spin_lock(&todo_lock);
+ spin_lock_bh(&todo_lock);
while (!list_empty(&todo_list)) {
key = list_first_entry(&todo_list, struct ieee80211_key, todo);
list_del_init(&key->todo);
@@ -558,7 +560,7 @@ static void __ieee80211_key_todo(void)
KEY_FLAG_TODO_HWACCEL_REMOVE |
KEY_FLAG_TODO_DELETE);
key->flags &= ~todoflags;
- spin_unlock(&todo_lock);
+ spin_unlock_bh(&todo_lock);
work_done = false;
@@ -591,9 +593,9 @@ static void __ieee80211_key_todo(void)
WARN_ON(!work_done);
- spin_lock(&todo_lock);
+ spin_lock_bh(&todo_lock);
}
- spin_unlock(&todo_lock);
+ spin_unlock_bh(&todo_lock);
}
void ieee80211_key_todo(void)
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: bad nat connection tracking performance with ip_gre
From: Patrick McHardy @ 2009-08-18 14:58 UTC (permalink / raw)
To: Timo Teräs; +Cc: netfilter-devel, netdev
In-Reply-To: <4A8AB25A.4000105@iki.fi>
Timo Teräs wrote:
> Patrick McHardy wrote:
>> Timo Teräs wrote:
>>> LOCALLY GENERATED PACKET, hogs CPU
>>> ----------------------------------
>>>
>>> IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344
>>> TOS=0x00 PREC=0x00 TTL=8 ID=41664 DF PROTO=UDP SPT=47920
>>> DPT=1234 LEN=1324 UID=1007 GID=1007
>>> 1. raw:OUTPUT
>>> 2. mangle:OUTPUT
>>> 3. filter:OUTPUT
>>> 4. mangle:POSTROUTING
>>>
>>
>> Please include the complete output, I need to see the devices logged
>> at each hook.
>
> The devices are identical for each hook grouped under same line.
>
> Here are the interesting lines from one packet:
>
> Generation:
>
> raw:OUTPUT:policy:2 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42
> LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977
> DPT=1234 LEN=1324 UID=1007 GID=1007 mangle:OUTPUT:policy:1 IN= OUT=eth1
> SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8
> ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
> (the nat hook is called for initial packet only):
> nat:OUTPUT:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42
> LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36593 DF PROTO=UDP SPT=33977
> DPT=1234 LEN=1324 UID=1007 GID=1007
> filter:OUTPUT:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42
> LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977
> DPT=1234 LEN=1324 UID=1007 GID=1007 mangle:POSTROUTING:policy:1 IN=
> OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00
> TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324
> mangle:POSTROUTING:policy:1 IN= OUT=eth1 SRC=10.252.5.1
> DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF
> PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
> Looped back by multicast routing:
>
> raw:PREROUTING:policy:1 IN=eth1 OUT= MAC= SRC=10.252.5.1
> DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF
> PROTO=UDP SPT=33977 DPT=1234 LEN=1324 mangle:PREROUTING:policy:1 IN=eth1
> OUT= MAC= SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00
> TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324
> The cpu hogging happens somewhere below this, since the more
> multicast destinations I have the more CPU it takes.
So you're sending to multiple destinations? That obviously increases
the time spent in netfilter and the remaining networking stack.
> Multicast forwarded (I hacked this into the code; but similar
> dump happens on local sendto()):
>
> Actually, now that I think, here we should have the inner IP
> contents, and not the incomplete outer yet. So apparently
> the ipgre_header() messes the network_header position.
It shouldn't even have been called at this point. Please retry this
without your changes.
> mangle:FORWARD:policy:1 IN=eth1 OUT=gre1 SRC=0.0.0.0 DST=re.mo.te.ip
> LEN=0 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47 filter:FORWARD:rule:2
> IN=eth1 OUT=gre1 SRC=0.0.0.0 DST=re.mo.te.ip LEN=0 TOS=0x00 PREC=0x00
> TTL=64 ID=0 DF PROTO=47
This looks really broken. Why is the protocol already 47 before it even
reaches the gre tunnel?
> ip_gre xmit sends out:
There should be a POSTROUTING hook here.
> raw:OUTPUT:rule:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372
> TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47 raw:OUTPUT:policy:2 IN=
> OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00
> TTL=64 ID=0 DF PROTO=47 mangle:OUTPUT:policy:1 IN= OUT=eth0
> SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0
> DF PROTO=47
> (nat hook for initial packets)
> nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372
> TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
> filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip
> LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
> - Timo
>
^ permalink raw reply
* Re: [PATCH 1/2] alchemy: add au1000-eth platform device
From: Sergei Shtylyov @ 2009-08-18 14:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Ralf Baechle, linux-mips, Manuel Lauss, David Miller, netdev
In-Reply-To: <200908170105.38154.florian@openwrt.org>
Hello.
Florian Fainelli wrote:
> This patch adds the board code to register a per-board au1000-eth
> platform device to be used wit the au1000-eth platform driver in a
> subsequent patch. Note that the au1000-eth driver knows about the
> default driver settings such that we do not need to pass any
> platform_data informations in most cases except db1x00.
Sigh, NAK...
Please don't register the SoC device per board, do it in
alchemy/common/platfrom.c and find a way to pass the board specific platform
data from the board file there instead -- something like
arch/arm/mach-davinci/usb.c does.
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
[...]
> diff --git a/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h b/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h
> new file mode 100644
> index 0000000..6d1543e
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h
> @@ -0,0 +1,33 @@
> +#ifndef __AU1X00_ETH_DATA_H
> +#define __AU1X00_ETH_DATA_H
> +
> +/* Macro to help defining the Ethernet MAC resources */
> +#define MAC_RES(_base, _enable, _irq) \
> + { \
> + .start = CPHYSADDR(_base), \
> + .end = CPHYSADDR(_base + 0xffff), \
> + .flags = IORESOURCE_MEM, \
> + }, \
> + { \
> + .start = CPHYSADDR(_enable), \
> + .end = CPHYSADDR(_enable + 0x4), \
s/4/3/.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-18 14:46 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, kvm, alacrityvm-devel, linux-kernel, netdev,
Michael S. Tsirkin
In-Reply-To: <4A8A674E.8070200@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 20159 bytes --]
Avi Kivity wrote:
> On 08/17/2009 10:33 PM, Gregory Haskins wrote:
>>
>> There is a secondary question of venet (a vbus native device) verses
>> virtio-net (a virtio native device that works with PCI or VBUS). If
>> this contention is really around venet vs virtio-net, I may possibly
>> conceed and retract its submission to mainline. I've been pushing it to
>> date because people are using it and I don't see any reason that the
>> driver couldn't be upstream.
>>
>
> That's probably the cause of much confusion. The primary kvm pain point
> is now networking, so in any vbus discussion we're concentrating on that
> aspect.
>
>>> Also, are you willing to help virtio to become faster?
>>>
>> Yes, that is not a problem. Note that virtio in general, and
>> virtio-net/venet in particular are not the primary goal here, however.
>> Improved 802.x and block IO are just positive side-effects of the
>> effort. I started with 802.x networking just to demonstrate the IO
>> layer capabilities, and to test it. It ended up being so good on
>> contrast to existing facilities, that developers in the vbus community
>> started using it for production development.
>>
>> Ultimately, I created vbus to address areas of performance that have not
>> yet been addressed in things like KVM. Areas such as real-time guests,
>> or RDMA (host bypass) interfaces.
>
> Can you explain how vbus achieves RDMA?
>
> I also don't see the connection to real time guests.
Both of these are still in development. Trying to stay true to the
"release early and often" mantra, the core vbus technology is being
pushed now so it can be reviewed. Stay tuned for these other developments.
>
>> I also designed it in such a way that
>> we could, in theory, write one set of (linux-based) backends, and have
>> them work across a variety of environments (such as containers/VMs like
>> KVM, lguest, openvz, but also physical systems like blade enclosures and
>> clusters, or even applications running on the host).
>>
>
> Sorry, I'm still confused. Why would openvz need vbus?
Its just an example. The point is that I abstracted what I think are
the key points of fast-io, memory routing, signal routing, etc, so that
it will work in a variety of (ideally, _any_) environments.
There may not be _performance_ motivations for certain classes of VMs
because they already have decent support, but they may want a connector
anyway to gain some of the new features available in vbus.
And looking forward, the idea is that we have commoditized the backend
so we don't need to redo this each time a new container comes along.
> It already has
> zero-copy networking since it's a shared kernel. Shared memory should
> also work seamlessly, you just need to expose the shared memory object
> on a shared part of the namespace. And of course, anything in the
> kernel is already shared.
>
>>> Or do you
>>> have arguments why that is impossible to do so and why the only
>>> possible solution is vbus? Avi says no such arguments were offered
>>> so far.
>>>
>> Not for lack of trying. I think my points have just been missed
>> everytime I try to describe them. ;) Basically I write a message very
>> similar to this one, and the next conversation starts back from square
>> one. But I digress, let me try again..
>>
>> Noting that this discussion is really about the layer *below* virtio,
>> not virtio itself (e.g. PCI vs vbus). Lets start with a little
>> background:
>>
>> -- Background --
>>
>> So on one level, we have the resource-container technology called
>> "vbus". It lets you create a container on the host, fill it with
>> virtual devices, and assign that container to some context (such as a
>> KVM guest). These "devices" are LKMs, and each device has a very simple
>> verb namespace consisting of a synchronous "call()" method, and a
>> "shm()" method for establishing async channels.
>>
>> The async channels are just shared-memory with a signal path (e.g.
>> interrupts and hypercalls), which the device+driver can use to overlay
>> things like rings (virtqueues, IOQs), or other shared-memory based
>> constructs of their choosing (such as a shared table). The signal path
>> is designed to minimize enter/exits and reduce spurious signals in a
>> unified way (see shm-signal patch).
>>
>> call() can be used both for config-space like details, as well as
>> fast-path messaging that require synchronous behavior (such as guest
>> scheduler updates).
>>
>> All of this is managed via sysfs/configfs.
>>
>
> One point of contention is that this is all managementy stuff and should
> be kept out of the host kernel. Exposing shared memory, interrupts, and
> guest hypercalls can all be easily done from userspace (as virtio
> demonstrates). True, some devices need kernel acceleration, but that's
> no reason to put everything into the host kernel.
See my last reply to Anthony. My two points here are that:
a) having it in-kernel makes it a complete subsystem, which perhaps has
diminished value in kvm, but adds value in most other places that we are
looking to use vbus.
b) the in-kernel code is being overstated as "complex". We are not
talking about your typical virt thing, like an emulated ICH/PCI chipset.
Its really a simple list of devices with a handful of attributes. They
are managed using established linux interfaces, like sysfs/configfs.
>
>> On the guest, we have a "vbus-proxy" which is how the guest gets access
>> to devices assigned to its container. (as an aside, "virtio" devices
>> can be populated in the container, and then surfaced up to the
>> virtio-bus via that virtio-vbus patch I mentioned).
>>
>> There is a thing called a "vbus-connector" which is the guest specific
>> part. Its job is to connect the vbus-proxy in the guest, to the vbus
>> container on the host. How it does its job is specific to the connector
>> implementation, but its role is to transport messages between the guest
>> and the host (such as for call() and shm() invocations) and to handle
>> things like discovery and hotswap.
>>
>
> virtio has an exact parallel here (virtio-pci and friends).
>
>> Out of all this, I think the biggest contention point is the design of
>> the vbus-connector that I use in AlacrityVM (Avi, correct me if I am
>> wrong and you object to other aspects as well). I suspect that if I had
>> designed the vbus-connector to surface vbus devices as PCI devices via
>> QEMU, the patches would potentially have been pulled in a while ago.
>>
>
> Exposing devices as PCI is an important issue for me, as I have to
> consider non-Linux guests.
Thats your prerogative, but obviously not everyone agrees with you.
Getting non-Linux guests to work is my problem if you chose to not be
part of the vbus community.
> Another issue is the host kernel management code which I believe is
> superfluous.
In your opinion, right?
>
> But the biggest issue is compatibility. virtio exists and has Windows
> and Linux drivers. Without a fatal flaw in virtio we'll continue to
> support it.
So go ahead.
> Given that, why spread to a new model?
Note: I haven't asked you to (at least, not since April with the vbus-v3
release). Spreading to a new model is currently the role of the
AlacrityVM project, since we disagree on the utility of a new model.
>
> Of course, I understand you're interested in non-ethernet, non-block
> devices. I can't comment on these until I see them. Maybe they can fit
> the virtio model, and maybe they can't.
Yes, that I am not sure. They may. I will certainly explore that angle
at some point.
>
>> There are, of course, reasons why vbus does *not* render as PCI, so this
>> is the meat of of your question, I believe.
>>
>> At a high level, PCI was designed for software-to-hardware interaction,
>> so it makes assumptions about that relationship that do not necessarily
>> apply to virtualization.
>>
>> For instance:
>>
>> A) hardware can only generate byte/word sized requests at a time because
>> that is all the pcb-etch and silicon support. So hardware is usually
>> expressed in terms of some number of "registers".
>>
>
> No, hardware happily DMAs to and fro main memory.
Yes, now walk me through how you set up DMA to do something like a call
when you do not know addresses apriori. Hint: count the number of
MMIO/PIOs you need. If the number is > 1, you've lost.
> Some hardware of
> course uses mmio registers extensively, but not virtio hardware. With
> the recent MSI support no registers are touched in the fast path.
Note we are not talking about virtio here. Just raw PCI and why I
advocate vbus over it.
>
>> C) the target end-point has no visibility into the CPU machine state
>> other than the parameters passed in the bus-cycle (usually an address
>> and data tuple).
>>
>
> That's not an issue. Accessing memory is cheap.
>
>> D) device-ids are in a fixed width register and centrally assigned from
>> an authority (e.g. PCI-SIG).
>>
>
> That's not an issue either. Qumranet/Red Hat has donated a range of
> device IDs for use in virtio.
Yes, and to get one you have to do what? Register it with kvm.git,
right? Kind of like registering a MAJOR/MINOR, would you agree? Maybe
you do not mind (especially given your relationship to kvm.git), but
there are disadvantages to that model for most of the rest of us.
> Device IDs are how devices are associated
> with drivers, so you'll need something similar for vbus.
Nope, just like you don't need to do anything ahead of time for using a
dynamic misc-device name. You just have both the driver and device know
what they are looking for (its part of the ABI).
>
>> E) Interrupt/MSI routing is per-device oriented
>>
>
> Please elaborate. What is the issue? How does vbus solve it?
There are no "interrupts" in vbus..only shm-signals. You can establish
an arbitrary amount of shm regions, each with an optional shm-signal
associated with it. To do this, the driver calls dev->shm(), and you
get back a shm_signal object.
Underneath the hood, the vbus-connector (e.g. vbus-pcibridge) decides
how it maps real interrupts to shm-signals (on a system level, not per
device). This can be 1:1, or any other scheme. vbus-pcibridge uses one
system-wide interrupt per priority level (today this is 8 levels), each
with an IOQ based event channel. "signals" come as an event on that
channel.
So the "issue" is that you have no real choice with PCI. You just get
device oriented interrupts. With vbus, its abstracted. So you can
still get per-device standard MSI, or you can do fancier things like do
coalescing and prioritization.
>
>> F) Interrupts/MSI are assumed cheap to inject
>>
>
> Interrupts are not assumed cheap; that's why interrupt mitigation is
> used (on real and virtual hardware).
Its all relative. IDT dispatch and EOI overhead are "baseline" on real
hardware, whereas they are significantly more expensive to do the
vmenters and vmexits on virt (and you have new exit causes, like
irq-windows, etc, that do not exist in real HW).
>
>> G) Interrupts/MSI are non-priortizable.
>>
>
> They are prioritizable; Linux ignores this though (Windows doesn't).
> Please elaborate on what the problem is and how vbus solves it.
It doesn't work right. The x86 sense of interrupt priority is, sorry to
say it, half-assed at best. I've worked with embedded systems that have
real interrupt priority support in the hardware, end to end, including
the PIC. The LAPIC on the other hand is really weak in this dept, and
as you said, Linux doesn't even attempt to use whats there.
>
>> H) Interrupts/MSI are statically established
>>
>
> Can you give an example of why this is a problem?
Some of the things we are building use the model of having a device that
hands out shm-signal in response to guest events (say, the creation of
an IPC channel). This would generally be handled by a specific device
model instance, and it would need to do this without pre-declaring the
MSI vectors (to use PCI as an example).
>
>> These assumptions and constraints may be completely different or simply
>> invalid in a virtualized guest. For instance, the hypervisor is just
>> software, and therefore it's not restricted to "etch" constraints. IO
>> requests can be arbitrarily large, just as if you are invoking a library
>> function-call or OS system-call. Likewise, each one of those requests is
>> a branch and a context switch, so it has often has greater performance
>> implications than a simple register bus-cycle in hardware. If you use
>> an MMIO variant, it has to run through the page-fault code to be decoded.
>>
>> The result is typically decreased performance if you try to do the same
>> thing real hardware does. This is why you usually see hypervisor
>> specific drivers (e.g. virtio-net, vmnet, etc) a common feature.
>>
>> _Some_ performance oriented items can technically be accomplished in
>> PCI, albeit in a much more awkward way. For instance, you can set up a
>> really fast, low-latency "call()" mechanism using a PIO port on a
>> PCI-model and ioeventfd. As a matter of fact, this is exactly what the
>> vbus pci-bridge does:
>>
>
> What performance oriented items have been left unaddressed?
Well, the interrupt model to name one.
>
> virtio and vbus use three communications channels: call from guest to
> host (implemented as pio and reasonably fast), call from host to guest
> (implemented as msi and reasonably fast) and shared memory (as fast as
> it can be). Where does PCI limit you in any way?
>
>> The problem here is that this is incredibly awkward to setup. You have
>> all that per-cpu goo and the registration of the memory on the guest.
>> And on the host side, you have all the vmapping of the registered
>> memory, and the file-descriptor to manage. In short, its really painful.
>>
>> I would much prefer to do this *once*, and then let all my devices
>> simple re-use that infrastructure. This is, in fact, what I do. Here
>> is the device model that a guest sees:
>>
>
> virtio also reuses the pci code, on both guest and host.
>
>> Moving on: _Other_ items cannot be replicated (at least, not without
>> hacking it into something that is no longer PCI.
>>
>> Things like the pci-id namespace are just silly for software. I would
>> rather have a namespace that does not require central management so
>> people are free to create vbus-backends at will. This is akin to
>> registering a device MAJOR/MINOR, verses using the various dynamic
>> assignment mechanisms. vbus uses a string identifier in place of a
>> pci-id. This is superior IMHO, and not compatible with PCI.
>>
>
> How do you handle conflicts? Again you need a central authority to hand
> out names or prefixes.
Not really, no. If you really wanted to be formal about it, you could
adopt any series of UUID schemes. For instance, perhaps venet should be
"com.novell::virtual-ethernet". Heck, I could use uuidgen.
>
>> As another example, the connector design coalesces *all* shm-signals
>> into a single interrupt (by prio) that uses the same context-switch
>> mitigation techniques that help boost things like networking. This
>> effectively means we can detect and optimize out ack/eoi cycles from the
>> APIC as the IO load increases (which is when you need it most). PCI has
>> no such concept.
>>
>
> That's a bug, not a feature. It means poor scaling as the number of
> vcpus increases and as the number of devices increases.
So the "avi-vbus-connector" can use 1:1, if you prefer. Large vcpu
counts (which are not typical) and irq-affinity is not a target
application for my design, so I prefer the coalescing model in the
vbus-pcibridge included in this series. YMMV
Note: If you really wanted to, you could have priority queues per-cpu,
and get the best of both worlds (irq routing and coalescing/priority).
>
> Note nothing prevents steering multiple MSIs into a single vector. It's
> a bad idea though.
Yes, it is a bad idea...and not the same thing either. This would
effectively create a shared-line scenario in the irq code, which is not
what happens in vbus.
>
>> In addition, the signals and interrupts are priority aware, which is
>> useful for things like 802.1p networking where you may establish 8-tx
>> and 8-rx queues for your virtio-net device. x86 APIC really has no
>> usable equivalent, so PCI is stuck here.
>>
>
> x86 APIC is priority aware.
Have you ever tried to use it?
>
>> Also, the signals can be allocated on-demand for implementing things
>> like IPC channels in response to guest requests since there is no
>> assumption about device-to-interrupt mappings. This is more flexible.
>>
>
> Yes. However given that vectors are a scarce resource you're severely
> limited in that.
The connector I am pushing out does not have this limitation.
> And if you're multiplexing everything on one vector,
> then you can just as well demultiplex your channels in the virtio driver
> code.
Only per-device, not system wide.
>
>> And through all of this, this design would work in any guest even if it
>> doesn't have PCI (e.g. lguest, UML, physical systems, etc).
>>
>
> That is true for virtio which works on pci-less lguest and s390.
Yes, and lguest and s390 had to build their own bus-model to do it, right?
Thank you for bringing this up, because it is one of the main points
here. What I am trying to do is generalize the bus to prevent the
proliferation of more of these isolated models in the future. Build
one, fast, in-kernel model so that we wouldn't need virtio-X, and
virtio-Y in the future. They can just reuse the (performance optimized)
bus and models, and only need to build the connector to bridge them.
>
>> -- Bottom Line --
>>
>> The idea here is to generalize all the interesting parts that are common
>> (fast sync+async io, context-switch mitigation, back-end models, memory
>> abstractions, signal-path routing, etc) that a variety of linux based
>> technologies can use (kvm, lguest, openvz, uml, physical systems) and
>> only require the thin "connector" code to port the system around. The
>> idea is to try to get this aspect of PV right once, and at some point in
>> the future, perhaps vbus will be as ubiquitous as PCI. Well, perhaps
>> not *that* ubiquitous, but you get the idea ;)
>>
>
> That is exactly the design goal of virtio (except it limits itself to
> virtualization).
No, virtio is only part of the picture. It not including the backend
models, or how to do memory/signal-path abstraction for in-kernel, for
instance. But otherwise, virtio as a device model is compatible with
vbus as a bus model. They compliment one another.
>
>> Then device models like virtio can ride happily on top and we end up
>> with a really robust and high-performance Linux-based stack. I don't
>> buy the argument that we already have PCI so lets use it. I don't think
>> its the best design and I am not afraid to make an investment in a
>> change here because I think it will pay off in the long run.
>>
>
> Sorry, I don't think you've shown any quantifiable advantages.
We can agree to disagree then, eh? There are certainly quantifiable
differences. Waving your hand at the differences to say they are not
advantages is merely an opinion, one that is not shared universally.
The bottom line is all of these design distinctions are encapsulated
within the vbus subsystem and do not affect the kvm code-base. So
agreement with kvm upstream is not a requirement, but would be
advantageous for collaboration.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: bad nat connection tracking performance with ip_gre
From: Timo Teräs @ 2009-08-18 13:53 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <4A8AA63D.4000702@trash.net>
Patrick McHardy wrote:
> Timo Teräs wrote:
>> LOCALLY GENERATED PACKET, hogs CPU
>> ----------------------------------
>>
>> IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344
>> TOS=0x00 PREC=0x00 TTL=8 ID=41664 DF PROTO=UDP SPT=47920
>> DPT=1234 LEN=1324 UID=1007 GID=1007
>> 1. raw:OUTPUT
>> 2. mangle:OUTPUT
>> 3. filter:OUTPUT
>> 4. mangle:POSTROUTING
>>
>
> Please include the complete output, I need to see the devices logged
> at each hook.
The devices are identical for each hook grouped under same line.
Here are the interesting lines from one packet:
Generation:
raw:OUTPUT:policy:2 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
mangle:OUTPUT:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
(the nat hook is called for initial packet only):
nat:OUTPUT:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36593 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
filter:OUTPUT:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
mangle:POSTROUTING:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324
mangle:POSTROUTING:policy:1 IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324 UID=1007 GID=1007
Looped back by multicast routing:
raw:PREROUTING:policy:1 IN=eth1 OUT= MAC= SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324
mangle:PREROUTING:policy:1 IN=eth1 OUT= MAC= SRC=10.252.5.1 DST=239.255.12.42 LEN=1344 TOS=0x00 PREC=0x00 TTL=8 ID=36594 DF PROTO=UDP SPT=33977 DPT=1234 LEN=1324
The cpu hogging happens somewhere below this, since the more
multicast destinations I have the more CPU it takes.
Multicast forwarded (I hacked this into the code; but similar
dump happens on local sendto()):
Actually, now that I think, here we should have the inner IP
contents, and not the incomplete outer yet. So apparently
the ipgre_header() messes the network_header position.
mangle:FORWARD:policy:1 IN=eth1 OUT=gre1 SRC=0.0.0.0 DST=re.mo.te.ip LEN=0 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
filter:FORWARD:rule:2 IN=eth1 OUT=gre1 SRC=0.0.0.0 DST=re.mo.te.ip LEN=0 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
ip_gre xmit sends out:
raw:OUTPUT:rule:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
raw:OUTPUT:policy:2 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
mangle:OUTPUT:policy:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
(nat hook for initial packets)
nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=lo.ca.l.ip DST=re.mo.te.ip LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
- Timo
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] lib/vsprintf.c: Add "%pI6c" - print pointer as compressed ipv6 address
From: Jens Rosenboom @ 2009-08-18 13:48 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, chuck.lever, brian.haley, netdev
In-Reply-To: <1250548184.4488.6.camel@Joe-Laptop.home>
On Mon, 2009-08-17 at 15:29 -0700, Joe Perches wrote:
> On Mon, 2009-08-17 at 17:18 +0200, Jens Rosenboom wrote:
[...]
> > Also I'm wondering whether it makes sense to pull the format code
> > checking into all the sub-routines.
>
> It isn't clear to me what you're asking for.
>
> > It might be easier to maintain if it
> > is all kept together in pointer().
>
> Can you explain more thoroughly please?
>
> If you mean not passing const char *fmt to the sub-routines,
> I think not doing so makes it harder to maintain and extend.
>
> I think it will be useful to extend the 'S' resource_string
> capability to use fmt to allow specific bits to be selected
> of the resource identifier to be printed.
>
> See the idea in: http://lkml.org/lkml/2009/4/17/105
You were right in assuming the intention of my seemingly badly explained
comments, but in this context I agree with you, that it makes sense the
way you did it.
> Here's the modified patch with your suggestions:
>
Ran it through my test-cases and they all look fine.
Tested-by: Jens Rosenboom <jens@mcbone.net>
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model
From: Avi Kivity @ 2009-08-18 13:47 UTC (permalink / raw)
To: Gregory Haskins
Cc: Gregory Haskins, mingo, alacrityvm-devel, mst, kvm, linux-kernel,
netdev
In-Reply-To: <4A8AAA67.8060602@gmail.com>
On 08/18/2009 04:19 PM, Gregory Haskins wrote:
> Yeah, exactly. I think MMIO is particularly challenging because I don't
> know if there are any bits left to use. But like I said, its a problem
> for another day IMO.
>
x86_64 only uses 48 bits out of the 64 bits in a virtual address, so
there are several guaranteed-unused bits.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Avi Kivity @ 2009-08-18 13:45 UTC (permalink / raw)
To: Gregory Haskins
Cc: Anthony Liguori, Ingo Molnar, Gregory Haskins, kvm,
alacrityvm-devel, linux-kernel, netdev, Michael S. Tsirkin
In-Reply-To: <4A8AA9BD.2070909@gmail.com>
On 08/18/2009 04:16 PM, Gregory Haskins wrote:
> The issue here is that vbus is designed to be a generic solution to
> in-kernel virtual-IO. It will support (via abstraction of key
> subsystems) a variety of environments that may or may not be similar in
> facilities to KVM, and therefore it represents the
> least-common-denominator as far as what external dependencies it requires.
>
Maybe it will be easier to evaluate it in the context of these other
environments. It's difficult to assess this without an example.
> The bottom line is this: despite the tendency for people to jump at
> "don't put much in the kernel!", the fact is that a "bus" designed for
> software to software (such as vbus) is almost laughably trivial. Its
> essentially a list of objects that have an int (dev-id) and char*
> (dev-type) attribute. All the extra goo that you see me setting up in
> something like the kvm-connector needs to be done for fast-path
> _anyway_, so transporting the verbs to query this simple list is not
> really a big deal.
>
It's not laughably trivial when you try to support the full feature set
of kvm (for example, live migration will require dirty memory tracking,
and exporting all state stored in the kernel to userspace).
> Note that I didn't really want to go that route. As you know, I tried
> pushing this straight through kvm first since earlier this year, but I
> was met with reluctance to even bother truly understanding what I was
> proposing, comments like "tell me your ideas so I can steal them", and
>
Oh come on, I wrote "steal" as a convenient shorthand for
"cross-pollinate your ideas into our code according to the letter and
spirit of the GNU General Public License". Since we're all trying to
improve Linux we may as well cooperate.
> "sorry, we are going to reinvent our own instead".
No. Adopting venet/vbus would mean reinventing something that already
existed. Continuing to support virtio/pci is not reinventing anything.
> This isn't exactly
> going to motivate someone to continue pushing these ideas within that
> community. I was made to feel (purposely?) unwelcome at times. So I
> can either roll over and die, or start my own project.
>
You haven't convinced me that your ideas are worth the effort of
abandoning virtio/pci or maintaining both venet/vbus and virtio/pci.
I'm sorry if that made you feel unwelcome. There's no reason to
interpret disagreement as malice though.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] revert TCP retransmission backoff on ICMP destination unreachable
From: Ilpo Järvinen @ 2009-08-18 13:45 UTC (permalink / raw)
To: Damian Lukowski; +Cc: David Miller, Netdev
In-Reply-To: <4A8553AD.2000601@tvk.rwth-aachen.de>
On Fri, 14 Aug 2009, Damian Lukowski wrote:
>> Longer than 80 columns, and use an inline function instead
>> of a macro in order to get proper type checking.
>> [...]
>> Do not break up the function local variables with spurious new lines
>> like this, please.
>> [...]
>> The indentation and tabbing is messed up in all of the code you are
>> adding, please fix it up to be consistent with the surrounding code
>> and the rest of the TCP stack.
>>
>> Do not use C++ style // comments.
>
> Better?
Please, include the changelog message on resubmits too next time.
> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
> diff -Naur linux-2.6.30.4/include/net/tcp.h linux-2.6.30.4-tcp-icmp/include/net/tcp.h
> --- linux-2.6.30.4/include/net/tcp.h 2009-07-31 00:34:47.000000000 +0200
> +++ linux-2.6.30.4-tcp-icmp/include/net/tcp.h 2009-08-14 12:18:30.846060685 +0200
> @@ -1220,6 +1220,14 @@
> #define tcp_for_write_queue_from_safe(skb, tmp, sk) \
> skb_queue_walk_from_safe(&(sk)->sk_write_queue, skb, tmp)
>
> +static inline bool retrans_overstepped(const struct sock *sk,
> + unsigned int boundary)
> +{
> + return inet_csk(sk)->icsk_retransmits &&
> + (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >=
> + TCP_RTO_MIN*(2 << boundary);
> +}
> +
> static inline struct sk_buff *tcp_send_head(struct sock *sk)
> {
> return sk->sk_send_head;
> diff -Naur linux-2.6.30.4/net/ipv4/tcp_ipv4.c linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_ipv4.c
> --- linux-2.6.30.4/net/ipv4/tcp_ipv4.c 2009-07-31 00:34:47.000000000 +0200
> +++ linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_ipv4.c 2009-08-14 13:19:48.841598908 +0200
> @@ -332,11 +332,13 @@
> {
> struct iphdr *iph = (struct iphdr *)skb->data;
> struct tcphdr *th = (struct tcphdr *)(skb->data + (iph->ihl << 2));
> + struct inet_connection_sock *icsk;
> struct tcp_sock *tp;
> struct inet_sock *inet;
> const int type = icmp_hdr(skb)->type;
> const int code = icmp_hdr(skb)->code;
> struct sock *sk;
> + struct sk_buff *skb_r;
I'd make this called "skb", and change the old skb to icmp_skb.
> __u32 seq;
> int err;
> struct net *net = dev_net(skb->dev);
> @@ -367,6 +369,7 @@
> if (sk->sk_state == TCP_CLOSE)
> goto out;
>
> + icsk = inet_csk(sk);
> tp = tcp_sk(sk);
> seq = ntohl(th->seq);
> if (sk->sk_state != TCP_LISTEN &&
> @@ -393,6 +396,41 @@
> }
>
> err = icmp_err_convert[code].errno;
> + /* check if ICMP unreachable messages allow revert of backoff */
> + if ((code != ICMP_NET_UNREACH && code != ICMP_HOST_UNREACH) ||
> + seq != tp->snd_una || !icsk->icsk_retransmits ||
> + !icsk->icsk_backoff)
I'd recommend you break this into two if()\nbreak's, one for filtering
other icmps and other for filtering mismatching against the socket's
state.
> + break;
> +
> + icsk->icsk_backoff--;
> + icsk->icsk_rto >>= 1;
Are you absolute sure that we don't go to zero here when phase of the
moon is just right? I'd put a max(..., 1) guard there.
> +
> + skb_r = skb_peek(&sk->sk_write_queue);
tcp_write_queue_head(sk)
> + BUG_ON(!skb_r);
> +
> + if (sock_owned_by_user(sk)) {
> + /* Deferring retransmission clocked by ICMP
> + * due to locked socket. */
> + inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
> + min(icsk->icsk_rto, TCP_RESOURCE_PROBE_INTERVAL),
??? (besides having indent wrong). What makes you think HZ/2 is right
value if icsk_rto is large?
> + TCP_RTO_MAX);
Perhaps you lack here something to exit?
> + }
> +
> + if (tcp_time_stamp - TCP_SKB_CB(skb_r)->when >
> + inet_csk(sk)->icsk_rto) {
icsk->icsk_rto !?!
> + /* RTO revert clocked out retransmission. */
> + tcp_retransmit_skb(sk, skb_r);
This is plain wrong, tcp_sock counters will get messed up if
TCPCB_SACKED_RETRANS is already set while calling tcp_retransmit_skb. As a
sidenote, it would be probably useful to move the check + clear of that
bit before doing the retransmission to some common place one day.
> + inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
> + icsk->icsk_rto, TCP_RTO_MAX);
RFC 2988, step 5.5 missing? Have you verified this patch for real?
> + } else {
> + /* RTO revert shortened timer. */
> + inet_csk_reset_xmit_timer(
> + sk, ICSK_TIME_RETRANS,
> + icsk->icsk_rto-
> + (tcp_time_stamp-TCP_SKB_CB(skb_r)->when),
Spacing.
> + TCP_RTO_MAX);
> + }
> +
How about:
u32 remaining;
remaining = icsk->icsk_rto - min(icsk->icsk_rto,
tcp_time_stamp - TCP_SKB_CB(skb_r)->when));
if (!remaining) {
tcp_retransmit_skb(...);
remaining = icsk->icsk_rto;
}
inet_csk_reset_xmit_timer(..., remaining);
But check my note about step 5.5 (see above) to get remaining set right in
the if branch.
> break;
> case ICMP_TIME_EXCEEDED:
> err = EHOSTUNREACH;
> diff -Naur linux-2.6.30.4/net/ipv4/tcp_timer.c linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_timer.c
> --- linux-2.6.30.4/net/ipv4/tcp_timer.c 2009-07-31 00:34:47.000000000 +0200
> +++ linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_timer.c 2009-08-14 13:22:18.068666329 +0200
> @@ -143,7 +143,7 @@
> dst_negative_advice(&sk->sk_dst_cache);
> retry_until = icsk->icsk_syn_retries ? : sysctl_tcp_syn_retries;
> } else {
> - if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
> + if (retrans_overstepped(sk, sysctl_tcp_retries1)) {
??? Could you justify these changes and explain their relation to the
draft and icmp messages? If not, please drop them and try with proper
description and description for them in a separate patch. I fail to see
what you're trying to achieve here. You just ended up redefining the
sysctl meaning too I think...
> /* Black hole detection */
> tcp_mtu_probing(icsk, sk);
>
> @@ -156,12 +156,14 @@
>
> retry_until = tcp_orphan_retries(sk, alive);
>
> - if (tcp_out_of_resources(sk, alive || icsk->icsk_retransmits < retry_until))
> + if (tcp_out_of_resources(
> + sk, alive ||
> + !retrans_overstepped(sk, retry_until)))
???
> return 1;
> }
> }
>
> - if (icsk->icsk_retransmits >= retry_until) {
> + if (retrans_overstepped(sk, retry_until)) {
...
> /* Has it gone just too far? */
> tcp_write_err(sk);
> return 1;
> @@ -385,7 +387,7 @@
> out_reset_timer:
> icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
> - if (icsk->icsk_retransmits > sysctl_tcp_retries1)
> + if (retrans_overstepped(sk, sysctl_tcp_retries1))
...I guess none of these retrans_overstepped are related to the icmp stuff
at all?
> __sk_dst_reset(sk);
>
> out:;
--
i.
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model
From: Gregory Haskins @ 2009-08-18 13:19 UTC (permalink / raw)
To: Avi Kivity
Cc: Gregory Haskins, mingo, alacrityvm-devel, mst, kvm, linux-kernel,
netdev
In-Reply-To: <4A8AA0C6.805@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
Avi Kivity wrote:
> On 08/18/2009 03:36 PM, Gregory Haskins wrote:
>> Yeah, I agree. I am not advocating we expend energy on this now. But
>> my thoughts at the time were that that particular problem can be
>> solved at io-setup time with some kind of call to qualify the address.
>>
>> Iow: a slow path call with the address would return flags on whether
>> iowrite() should do a real io, or a IOoHC.
>>
>
> Yes, it could work, though we'd need somewhere to stow this
> information. IIRC Arnd suggested a bit from the address itself.
>
Yeah, exactly. I think MMIO is particularly challenging because I don't
know if there are any bits left to use. But like I said, its a problem
for another day IMO.
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-18 13:16 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Gregory Haskins, kvm, Avi Kivity, alacrityvm-devel,
linux-kernel, netdev, Michael S. Tsirkin
In-Reply-To: <4A89FF08.30509@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 8228 bytes --]
Anthony Liguori wrote:
> Gregory Haskins wrote:
>> Note: No one has ever proposed to change the virtio-ABI.
>
> virtio-pci is part of the virtio ABI. You are proposing changing that.
I'm sorry, but I respectfully disagree with you here.
virtio has an ABI...I am not modifying that.
virtio-pci has an ABI...I am not modifying that either.
The subsystem in question is virtio-vbus, and is a completely standalone
addition to the virtio ecosystem. By your argument, virtio amd
virtio-pci should fuse together, and virtio-lguest and virtio-s390
should go away because they diverge from the virtio-pci ABI, right?
I seriously doubt you would agree with that statement. The fact is, the
design of virtio not only permits modular replacement of its transport
ABI, it encourages it.
So how is virtio-vbus any different from the other three? I understand
that it means you need to load a new driver in the guest, and I am ok
with that. virtio-pci was once a non-upstream driver too and required
someone to explicitly load it, wasn't it? You gotta crawl before you
can walk...
>
> You cannot add new kernel modules to guests and expect them to remain
> supported.
??? Of course you can. How is this different from any other driver?
> So there is value in reusing existing ABIs
Well, I wont argue with you on that one. There is certainly value there.
My contention is that sometimes the liability of that ABI is greater
than its value, and thats when its time to evaluate the design decisions
that lead to re-use vs re-design.
>
>>> I think the reason vbus gets better performance for networking today is
>>> that vbus' backends are in the kernel while virtio's backends are
>>> currently in userspace.
>>>
>>
>> Well, with all due respect, you also said initially when I announced
>> vbus that in-kernel doesn't matter, and tried to make virtio-net run as
>> fast as venet from userspace ;) Given that we never saw those userspace
>> patches from you that in fact equaled my performance, I assume you were
>> wrong about that statement. Perhaps you were wrong about other things
>> too?
>>
>
> I'm wrong about a lot of things :-) I haven't yet been convinced that
> I'm wrong here though.
>
> One of the gray areas here is what constitutes an in-kernel backend.
> tun/tap is a sort of an in-kernel backend. Userspace is still involved
> in all of the paths. vhost seems to be an intermediate step between
> tun/tap and vbus. The fast paths avoid userspace completely. Many of
> the slow paths involve userspace still (like migration apparently).
> With vbus, userspace is avoided entirely. In some ways, you could argue
> that slirp and vbus are opposite ends of the virtual I/O spectrum.
>
> I believe strongly that we should avoid putting things in the kernel
> unless they absolutely have to be.
I would generally agree with you on that. Particularly in the case of
kvm, having slow-path bus-management code in-kernel is not strictly
necessary because KVM has qemu in userspace.
The issue here is that vbus is designed to be a generic solution to
in-kernel virtual-IO. It will support (via abstraction of key
subsystems) a variety of environments that may or may not be similar in
facilities to KVM, and therefore it represents the
least-common-denominator as far as what external dependencies it requires.
The bottom line is this: despite the tendency for people to jump at
"don't put much in the kernel!", the fact is that a "bus" designed for
software to software (such as vbus) is almost laughably trivial. Its
essentially a list of objects that have an int (dev-id) and char*
(dev-type) attribute. All the extra goo that you see me setting up in
something like the kvm-connector needs to be done for fast-path
_anyway_, so transporting the verbs to query this simple list is not
really a big deal.
If we were talking about full ICH emulation for a PCI bus, I would agree
with you. In the case of vbus, I think its overstated.
> I'm definitely interested in playing
> with vhost to see if there are ways to put even less in the kernel. In
> particular, I think it would be a big win to avoid knowledge of slots in
> the kernel by doing ring translation in userspace.
Ultimately I think that would not be a very good proposition. Ring
translation is actually not that hard, and that would definitely be a
measurable latency source to try and do as you propose. But, I will not
discourage you from trying if that is what you want to do.
> This implies a
> userspace transition in the fast path. This may or may not be
> acceptable. I think this is going to be a very interesting experiment
> and will ultimately determine whether my intuition about the cost of
> dropping to userspace is right or wrong.
I can already tell you its wrong, just based on the fact that even extra
kthread switches can hurt from my own experience playing in this area...
>
>
>> Conversely, I am not afraid of requiring a new driver to optimize the
>> general PV interface. In the long term, this will reduce the amount of
>> reimplementing the same code over and over, reduce system overhead, and
>> it adds new features not previously available (for instance, coalescing
>> and prioritizing interrupts).
>>
>
> I think you have a lot of ideas and I don't know that we've been able to
> really understand your vision. Do you have any plans on writing a paper
> about vbus that goes into some of your thoughts in detail?
I really need to, I know...
>
>>> If that's the case, then I don't see any
>>> reason to adopt vbus unless Greg things there are other compelling
>>> features over virtio.
>>>
>>
>> Aside from the fact that this is another confusion of the vbus/virtio
>> relationship...yes, of course there are compelling features (IMHO) or I
>> wouldn't be expending effort ;) They are at least compelling enough to
>> put in AlacrityVM.
>
> This whole AlactricyVM thing is really hitting this nail with a
> sledgehammer.
Note that I didn't really want to go that route. As you know, I tried
pushing this straight through kvm first since earlier this year, but I
was met with reluctance to even bother truly understanding what I was
proposing, comments like "tell me your ideas so I can steal them", and
"sorry, we are going to reinvent our own instead". This isn't exactly
going to motivate someone to continue pushing these ideas within that
community. I was made to feel (purposely?) unwelcome at times. So I
can either roll over and die, or start my own project.
In addition, almost all of vbus is completely independent of kvm anyway
(I think there are only 3 patches that actually touch KVM, and they are
relatively minor). And vbus doesn't really fit into any other category
of maintained subsystem either. So it really calls for a new branch of
maintainership, of which I currently sit. AlacrityVM will serve as the
collaboration point of that maintainership.
The bottom line is, there are people out there who are interested in
what we are doing (and that number grows everyday). Starting a new
project wasn't what I wanted per se, but I don't think there was much
choice.
While the kernel needs to be very careful about what it
> pulls in, as long as you're willing to commit to ABI compatibility, we
> can pull code into QEMU to support vbus. Then you can just offer vbus
> host and guest drivers instead of forking the kernel.
Ok, I will work on pushing those patches next.
>
>> If upstream KVM doesn't want them, that's KVMs
>> decision and I am fine with that. Simply never apply my qemu patches to
>> qemu-kvm.git, and KVM will be blissfully unaware if vbus is present.
>
> As I mentioned before, if you submit patches to upstream QEMU, we'll
> apply them (after appropriate review). As I said previously, we want to
> avoid user confusion as much as possible. Maybe this means limiting it
> to -device or a separate machine type. I'm not sure, but that's
> something we can discussion on qemu-devel.
Ok.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: bad nat connection tracking performance with ip_gre
From: Patrick McHardy @ 2009-08-18 13:01 UTC (permalink / raw)
To: Timo Teräs; +Cc: netfilter-devel, netdev
In-Reply-To: <4A8AA253.8090300@iki.fi>
Timo Teräs wrote:
> LOCALLY GENERATED PACKET, hogs CPU
> ----------------------------------
>
> IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344
> TOS=0x00 PREC=0x00 TTL=8 ID=41664 DF PROTO=UDP SPT=47920
> DPT=1234 LEN=1324 UID=1007 GID=1007
> 1. raw:OUTPUT
> 2. mangle:OUTPUT
> 3. filter:OUTPUT
> 4. mangle:POSTROUTING
>
Please include the complete output, I need to see the devices logged
at each hook.
^ permalink raw reply
* Re: [Bonding-devel] [PATCH net-next-2.6] bonding: introduce primary_lazy option
From: Jiri Pirko @ 2009-08-18 12:45 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: davem, netdev, fubar, bonding-devel
In-Reply-To: <4A89C3B1.3070509@free.fr>
Mon, Aug 17, 2009 at 10:55:13PM CEST, nicolas.2p.debian@free.fr wrote:
> Jiri Pirko a écrit :
>> Fri, Aug 14, 2009 at 06:27:03PM CEST, nicolas.2p.debian@free.fr wrote:
>>> Jiri Pirko wrote:
>>>> Thu, Aug 13, 2009 at 09:41:02PM CEST, nicolas.2p.debian@free.fr wrote:
>>>>> Jiri Pirko wrote:
>>>>>> In some cases there is not desirable to switch back to primary interface when
>>>>>> it's link recovers and rather stay wiith currently active one. We need to avoid
>>>>>> packetloss as much as we can in some cases. This is solved by introducing
>>>>>> primary_lazy option. Note that enslaved primary slave is set as current
>>>>>> active no matter what.
>>>>> May I suggest that instead of creating a new option to better define how
>>>>> the "primary" option is expected to behave for active-backup
>>>>> mode, we try the "weight" slave option I proposed in the thread
>>>>> "alternative to primary" earlier this year ?
>>>>>
>>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=49D5357E.4020201%40free.fr&forum_name=bonding-devel
>>>> This link does not work for me :(
>>> Nor for me... Sourceforge apparently decided to drop the
>>> bonding-devel list archive just now. 'hope the list archive will be
>>> back soon.
>>>
>>> Originally, the proposed "weight" option for slaves was designed just
>>> to provide a way to better define which slave should become active
>>> when the active one just went down. As you know, the current
>>> "primary" option does not allow for a predictable selection of the
>>> new active slave when the primary loose connectivity. The new active
>>> slave is chosen "at random" between the remaining slaves.
>>>
>>> After a short thread, involving Jay Vosburg and Andy Gospodarek, we
>>> end up with a general configuration interface, that provide a way to
>>> tune many things in slave management :
>>>
>>> - Active slave selection in active/backup mode, even in the presence
>>> of more than two slaves.
>>> - Active aggregator selection in 802.3ad mode.
>>> - Load balancing tuning for most load balancing modes.
>>>
>>> The sysfs interface would be /sys/class/net/eth0/bonding/weight.
>>> Writing a number there would give a "user supplied weight" to a
>>> slave. The speed and link state of the slave would give a "natural
>>> weight" for the slave. And the "effective weight" would be computed
>>> every time one of user supplied or natural weight change (upon speed
>>> or link state changes) and would be used everywhere we need a slave
>>> weight.
>>>
>>> I suggest that :
>>> - slave's natural weight = speed of the slave if link UP, else 0.
>>> - slave's effective weight = slave's natural weight * slave's user
>>> supplied weight.
>>> - aggregator's effective weight = sum of the effective weights of the
>>> slaves inside the aggregator.
>>>
>>> For the active/backup mode, the exact behavior would be :
>>>
>>> - When the active slave disappear, the new active slave is the one
>>> whose effective weight is the highest.
>>> - When a slave comes back, it only becomes active if its effective
>>> weight is strictly higher than the one of the current active slave.
>>> (This stop the flip-flop risk you stated).
>>> - To keep the old "primary" option, we simply give a very high user
>>> supplied weight to the primary slave. Jay suggested :
>>> #define BOND_PRIMARY_PRIO 0x80000000
>>> user_supplied_weight &= BOND_PRIMARY_PRIO /* to set the primary */
>>> user_supplied_weight &= ~BOND_PRIMAY_PRIO /* to clear the primary */
>>>
>>> The same apply to aggregator : Every time a slave enter (link UP) or
>>> leave (link DOWN) an aggregator, the aggregator effective weight is
>>> recomputed. Then, if an aggregator exist with an strictly higher
>>> effective weight than the current active one, the new best aggregator
>>> becomes active.
>>>
>>> For others modes, the weight might be used later to tune the load
>>> balancing logic in some way.
>>>
>>> A default value of 1 for slave weight would cause slave speed to be
>>> used alone, hence the "natural weight".
>>>
>>
>> I read your text and also the original list thread and I must say I see no
>> solution in this "weight" parameter for this issue. Because it's desired for one
>> link to stay active even if second come up, these 2 must have the same weight.
>> But imagine 3 links of the same weight. In that case you cannot insure that the
>> "primary one" will be chosen as active (see my picture in the reply to Jay's
>> post). Correct me if I'm wrong but for that what I want to fix by primary_lazy
>> option, your proposed weight option has no effect.
>>
>> Therefor I still think the primary_lazy is the only solution now.
>>
>> Jirka
>
> Hi Jirka,
>
> From your previous posts (first one and reply to Jay), I understand that
> your want to achieve the following behavior :
>
> eth0 is primary and active.
> eth1 is allowed to be active is eth0 is down.
> Also, eth1 should stay active, even if eth0 comes back up.
> Switch active to eth0 if eth1 eventually fall down.
> Switch active to eth2 only if both eth0 and eth1 are down.
>
> eth0 eth1 eth2
> UP(curr) UP UP
> DOWN UP(curr) UP
> UP UP(curr) UP
> UP(curr) DOWN UP
> DOWN DOWN UP(curr)
>
> Using weight, the following setup should give this result :
>
> echo 1000 > /sys/class/net/eth0/bonding/weight
> echo 1000 > /sys/class/net/eth1/bonding/weight
> echo 1 > /sys/class/net/eth2/bonding/weight
> echo eth0 > /sys/class/net/bond0/bonding/active_slave
>
> I hope this is clear now.
Hmm... I ment the eth1 and eth2 to be the equivalent...
If eth1 is down (let's say for good) and eth0 comes down, eth2 is
selected as current active. But when eth0 comes up then eth0 is selected. That
is not desired.
>
> Nicolas.
>
>>
>>>>> Giving the same "weight" to two different slaves means "chose at random
>>>>> on startup and keep the active one until it fails". And if the "at
>>>>> random" behavior is not appropriate, one can force the active slave
>>>>> using what Jay suggested (/sys/class/net/bond0/bonding/active).
>>>>>
>>>>> The proposed "weight" slave's option is able to prevent the slaves from
>>>>> flip-flopping, by stating the fact that two slaves share the same
>>>>> "primary" level, and may provide several other enhancements as
>>>>> described in the thread.
>>>>>
>>>> Although I cannot reach the thread, this looks interesting. But I'm not sure it
>>>> has real benefits over primary_lazy option (and it doesn't solve initial curr
>>>> active slave setup)
>>> You are right, it doesn't solve the initial active slave selection.
>>> But why would it be so important to properly select the initial
>>> active slave, if you feel comfortable with staying with a new active
>>> slave, after a failure and return of the original active slave ?
>>> This kind of failures may last for only a few seconds (just
>>> unplugging and plugging back the wire), and you configuration may
>>> then stay with the new active slave "forever". If "forever" is
>>> acceptable, may be "at startup" is acceptable too. :-)
>>>
>>> From my point of view (and Andy Gospodarek apparently agreed), the
>>> real benefits of the weight slave option is that is it more generic
>>> and allow for later usage in other modes, that we don't anticipate
>>> for now.
>>>
>>> Quoted from a mail from Andy Gospodarek in the original thread :
>>>
>>> "I really have no objection to that. Adding this as a base part of
>>> bonding for a few modes with known features would be a nice start.
>>> I'm sure others will be kind enough to send suggestions or patches for
>>> ways this could benefit other modes."
>>>
>>> Nicolas.
>>
>
>
^ permalink raw reply
* Re: bad nat connection tracking performance with ip_gre
From: Timo Teräs @ 2009-08-18 12:45 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <4A8A84AF.7050901@trash.net>
Patrick McHardy wrote:
> Timo Teräs wrote:
>> However, if a local process on the router box is sending
>> packets that go to gre tunnel, each packet causes a new
>> lookup on nat table OUTPUT chain. This is easily verified
>> by doing flood ping on router box on private IP and the
>> counters on nat table OUTPUT chain default policy start
>> to get incremented wildly.
So ping test is not good as the connection tracking entry
is apparently removed once ICMP reply is received.
The one way to reliably to reproduce this is when I'm
sending packets with sendto() from user-land to nbma gre
tunnel and specifying the nbma ip address.
>> Monitoring the connection tracking stats, it looks like
>> all packets are reusing the proper connection tracking
>> cache entry. But somehow the nat target still gets
>> called for the locally originating packets to gre.
>>
>> Any ideas how to fix this?
>
> Please use the TRACE target in raw/OUTPUT to trace the flow of
> packets through the netfilter hooks:
>
> modprobe ipt_LOG
> iptables -t raw -A OUTPUT -j TRACE
FORWARDED PACKET, does not hog CPU
----------------------------------
IN=eth1 OUT= MAC=x:x:x:x:x SRC=10.252.5.10 DST=239.255.12.42
LEN=1428 TOS=0x00 PREC=0x00 TTL=8 ID=31320 DF PROTO=UDP
SPT=34757 DPT=50002 LEN=1408
1. mangle:INPUT
2. filter:INPUT
3. raw:PREROUTING
4. mangle:PREROUTING
Next it turns it to GRE encapsulated packet like:
IN=eth1 OUT=gre1 SRC=0.0.0.0 DST=re.mo.te.ip LEN=0
TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=47
1. mangle:FORWARD
2. filter:FORWARD
Gets proper SRC and LEN at this point and:
1. raw:OUTPUT
2. mangle:OUTPUT
3. nat:OUTPUT
4. filter:OUTPUT
LOCALLY GENERATED PACKET, hogs CPU
----------------------------------
IN= OUT=eth1 SRC=10.252.5.1 DST=239.255.12.42 LEN=1344
TOS=0x00 PREC=0x00 TTL=8 ID=41664 DF PROTO=UDP SPT=47920
DPT=1234 LEN=1324 UID=1007 GID=1007
1. raw:OUTPUT
2. mangle:OUTPUT
3. filter:OUTPUT
4. mangle:POSTROUTING
Picked up by multicast routing.
IN=eth1 OUT= MAC= SRC=10.252.5.1 DST=239.255.12.42 LEN=1344
TOS=0x00 PREC=0x00 TTL=8 ID=41664 DF PROTO=UDP SPT=47920
DPT=1234 LEN=1324
1. raw:PREROUTING
2. mangle:PREROUTING
Forwarded to GRE tunnel.
IN=eth1 OUT=gre1 SRC=0.0.0.0 DST=re.mo.te.ip LEN=0 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=47
1. mangle:FORWARD
2. filter:FORWARD
Apparently GRE xmit code fixes it to:
IN= OUT=eth0 SRC=my.pub.lic.ip DST=re.mo.te.ip LEN=1372 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=47
1. raw:OUTPUT
2. mangle:OUTPUT
---
It's starting to smell like ip_gre problem. ipgre_header() seems
to set only the destination IP address. And that probably confuses
the connection tracking code for locally originating packets.
I suppose we should construct almost full IP header in ipgre_header().
- Timo
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model
From: Avi Kivity @ 2009-08-18 12:38 UTC (permalink / raw)
To: Gregory Haskins
Cc: mingo, gregory.haskins, alacrityvm-devel, mst, kvm, linux-kernel,
netdev
In-Reply-To: <4A8A67F70200005A000528F8@sinclair.provo.novell.com>
On 08/18/2009 03:36 PM, Gregory Haskins wrote:
> Yeah, I agree. I am not advocating we expend energy on this now. But my thoughts at the time were that that particular problem can be solved at io-setup time with some kind of call to qualify the address.
>
> Iow: a slow path call with the address would return flags on whether iowrite() should do a real io, or a IOoHC.
>
Yes, it could work, though we'd need somewhere to stow this
information. IIRC Arnd suggested a bit from the address itself.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model
From: Gregory Haskins @ 2009-08-18 12:36 UTC (permalink / raw)
To: avi
Cc: mingo, gregory.haskins, alacrityvm-devel, mst, kvm, linux-kernel,
netdev
In-Reply-To: <4A8A67F70200005A000528F8@sinclair.provo.novell.com>
Yeah, I agree. I am not advocating we expend energy on this now. But my thoughts at the time were that that particular problem can be solved at io-setup time with some kind of call to qualify the address.
Iow: a slow path call with the address would return flags on whether iowrite() should do a real io, or a IOoHC.
-greg
-----Original Message-----
From: Avi Kivity <avi@redhat.com>
To: Gregory Haskins <GHaskins@novell.com>
Cc: <mingo@elte.hu>
Cc: <gregory.haskins@gmail.com>
Cc: <alacrityvm-devel@lists.sourceforge.net>
Cc: <mst@redhat.com>
Cc: <kvm@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: <netdev@vger.kernel.org>
Sent: 8/18/2009 6:29:08 AM
Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for
On 08/18/2009 03:24 PM, Gregory Haskins wrote:
> (Again on the top post)
>
> No, Avi, nothing has changed to my knowledge. I just saw that you and Michael were heading down the same path, so I thought I might interject that we've already covered that ground.
>
> As of right now, I am of the opinion that its not worth any change in the short term, and may be worth IOoHC in the long term (primarily so that mmios get a boost)
>
The primary issue with IOoHC is that while hypercalls are faster than
emulated mmio, they're much slower than assigned mmio. So we have to
distinguish between these two cases, which gets kinda icky.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for
From: Avi Kivity @ 2009-08-18 12:29 UTC (permalink / raw)
To: Gregory Haskins
Cc: mingo, gregory.haskins, alacrityvm-devel, mst, kvm, linux-kernel,
netdev
In-Reply-To: <4A8A65540200005A000528EA@sinclair.provo.novell.com>
On 08/18/2009 03:24 PM, Gregory Haskins wrote:
> (Again on the top post)
>
> No, Avi, nothing has changed to my knowledge. I just saw that you and Michael were heading down the same path, so I thought I might interject that we've already covered that ground.
>
> As of right now, I am of the opinion that its not worth any change in the short term, and may be worth IOoHC in the long term (primarily so that mmios get a boost)
>
The primary issue with IOoHC is that while hypercalls are faster than
emulated mmio, they're much slower than assigned mmio. So we have to
distinguish between these two cases, which gets kinda icky.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for
From: Gregory Haskins @ 2009-08-18 12:24 UTC (permalink / raw)
To: avi
Cc: mingo, gregory.haskins, alacrityvm-devel, mst, kvm, linux-kernel,
netdev
In-Reply-To: <4A8A65540200005A000528EA@sinclair.provo.novell.com>
(Again on the top post)
No, Avi, nothing has changed to my knowledge. I just saw that you and Michael were heading down the same path, so I thought I might interject that we've already covered that ground.
As of right now, I am of the opinion that its not worth any change in the short term, and may be worth IOoHC in the long term (primarily so that mmios get a boost)
-greg.
-----Original Message-----
From: Avi Kivity <avi@redhat.com>
To: Gregory Haskins <GHaskins@novell.com>
Cc: <mingo@elte.hu>
Cc: <gregory.haskins@gmail.com>
Cc: <alacrityvm-devel@lists.sourceforge.net>
Cc: <mst@redhat.com>
Cc: <kvm@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: <netdev@vger.kernel.org>
Sent: 8/18/2009 6:19:53 AM
Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_drive
On 08/18/2009 03:11 PM, Gregory Haskins wrote:
> Sorry for the toppost. Still not at the office.
>
> I just wanted to add that we've already been through this disussion once. (Search "haskins hypercall lkml" on google and I'm sure you are bound to see hits.
>
>
Your numbers showed a 350ns difference on fairly old (by now) hardware.
I doubt the difference will exceed 200ns now.
> The fact is: the original vbus was designed with hypercalls, and it drew much of these same critisims. In the end, hypercalls are only marginally faster than PIO (iirc, 450ns faster, and shrinking), so we decided that it was not worth further discussion at the time.
>
Has anything changed?
> A better solution is probably PIOoHC, so that you retain the best properties of both. The only problem with the entire PIOx approach is that its x86 specific, but that is an entirely different thread.
>
pio is nicely abstracted by PCI. virtio-pci will use pio on x86 and
mmio on non-x86.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox