[PATCH 2/4] kvm: Resolve missing-field-initializers warnings
From: Mark Rustad mark.d.rus...@intel.com
Resolve missing-field-initializers warnings seen in W=2 kernel
builds by having macros generate more elaborated initializers.
That is enough to silence the warnings.
Signed-off-by: Mark Rustad mark.d.rus...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
virt/kvm/irq_comm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index ced4a54..a228ee8 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -323,13 +323,13 @@ out:
#define IOAPIC_ROUTING_ENTRY(irq) \
{ .gsi = irq, .type = KVM_IRQ_ROUTING_IRQCHIP, \
- .u.irqchip.irqchip = KVM_IRQCHIP_IOAPIC, .u.irqchip.pin = (irq) }
+ .u.irqchip = { .irqchip = KVM_IRQCHIP_IOAPIC, .pin = (irq) } }
#define ROUTING_ENTRY1(irq) IOAPIC_ROUTING_ENTRY(irq)
#ifdef CONFIG_X86
# define PIC_ROUTING_ENTRY(irq) \
{ .gsi = irq, .type = KVM_IRQ_ROUTING_IRQCHIP, \
- .u.irqchip.irqchip = SELECT_PIC(irq), .u.irqchip.pin = (irq) % 8 }
+ .u.irqchip = { .irqchip = SELECT_PIC(irq), .pin = (irq) % 8 } }
# define ROUTING_ENTRY2(irq) \
IOAPIC_ROUTING_ENTRY(irq), PIC_ROUTING_ENTRY(irq)
#else
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] x86/kvm: Resolve shadow warning from min macro
From: Mark Rustad mark.d.rus...@intel.com Resolve a shadow warning generated in W=2 builds by the nested use of the min macro by instead using the min3 macro for the minimum of 3 values. Signed-off-by: Mark Rustad mark.d.rus...@intel.com Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- arch/x86/kvm/emulate.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index e4e833d..2d6c97a 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -1315,8 +1315,7 @@ static int pio_in_emulated(struct x86_emulate_ctxt *ctxt, in_page = (ctxt-eflags EFLG_DF) ? offset_in_page(reg_read(ctxt, VCPU_REGS_RDI)) : PAGE_SIZE - offset_in_page(reg_read(ctxt, VCPU_REGS_RDI)); - n = min(min(in_page, (unsigned int)sizeof(rc-data)) / size, - count); + n = min3(in_page, (unsigned int)sizeof(rc-data) / size, count); if (n == 0) n = 1; rc-pos = rc-end = 0; -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] x86/kvm: Resolve some missing-initializers warnings
From: Mark Rustad mark.d.rus...@intel.com Resolve some missing-initializers warnings that appear in W=2 builds. They are resolved by using a designated initialization, which is enough to resolve the warning. Signed-off-by: Mark Rustad mark.d.rus...@intel.com Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ef432f8..6d0f47208 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -82,8 +82,8 @@ u64 __read_mostly efer_reserved_bits = ~((u64)(EFER_SCE | EFER_LME | EFER_LMA)); static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); #endif -#define VM_STAT(x) offsetof(struct kvm, stat.x), KVM_STAT_VM -#define VCPU_STAT(x) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU +#define VM_STAT(x) .offset = offsetof(struct kvm, stat.x), KVM_STAT_VM +#define VCPU_STAT(x) .offset = offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] x86/kvm: Resolve shadow warnings in macro expansion
From: Mark Rustad mark.d.rus...@intel.com
Resolve shadow warnings that appear in W=2 builds. In this case,
a macro declared an inner local variable with the same name as an
outer one. This can be a serious hazard in the event that the outer
variable is ever passed as a parameter, as the inner variable will
be referenced instead of what was intended. This macro doesn't have
any parameters - at this time - but prepend an _ to all of the
macro-declared variables as is the custom, to resolve the warnings
and eliminate any future hazard.
Signed-off-by: Mark Rustad mark.d.rus...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
arch/x86/kvm/mmutrace.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index 9d2e0ff..2d8d00c 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -22,26 +22,26 @@
__entry-unsync = sp-unsync;
#define KVM_MMU_PAGE_PRINTK() ({ \
- const char *ret = p-buffer + p-len; \
- static const char *access_str[] = { \
+ const char *_ret = p-buffer + p-len; \
+ static const char *_access_str[] = {\
---, --x, w--, w-x, -u-, -ux, wu-, wux \
}; \
- union kvm_mmu_page_role role; \
+ union kvm_mmu_page_role _role; \
\
- role.word = __entry-role; \
+ _role.word = __entry-role; \
\
trace_seq_printf(p, sp gen %lx gfn %llx %u%s q%u%s %s%s \
%snxe root %u %s%c, __entry-mmu_valid_gen, \
-__entry-gfn, role.level, \
-role.cr4_pae ? pae : ,\
-role.quadrant, \
-role.direct ? direct : , \
-access_str[role.access], \
-role.invalid ? invalid : ,\
-role.nxe ? : !, \
+__entry-gfn, _role.level, \
+_role.cr4_pae ? pae : , \
+_role.quadrant,\
+_role.direct ? direct : , \
+_access_str[_role.access], \
+_role.invalid ? invalid : , \
+_role.nxe ? : !, \
__entry-root_count, \
__entry-unsync ? unsync : sync, 0); \
- ret;\
+ _ret; \
})
#define kvm_mmu_trace_pferr_flags \
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] x86: Resolve shadow warnings from apic_io.h
From: Mark Rustad mark.d.rus...@intel.com
Change the name of formal parameters in some static inlines from
apic, which shadows a global of the same name, to apicid. Also
change the formal parameter name on some trace functions for the
same reason. This eliminates many thousands of shadow warnings
in my W=2 kernel build.
Signed-off-by: Mark Rustad mark.d.rus...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
arch/x86/include/asm/io_apic.h | 14 +-
arch/x86/kernel/apic/io_apic.c | 211 ++--
arch/x86/kvm/lapic.c | 758 +
arch/x86/kvm/lapic.h | 23 +-
arch/x86/kvm/trace.h | 12 +-
5 files changed, 518 insertions(+), 500 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 0aeed5c..d2205d6 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -211,18 +211,20 @@ extern int native_ioapic_set_affinity(struct irq_data *,
const struct cpumask *,
bool);
-static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+static inline unsigned int io_apic_read(unsigned int apicid, unsigned int reg)
{
- return x86_io_apic_ops.read(apic, reg);
+ return x86_io_apic_ops.read(apicid, reg);
}
-static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned
int value)
+static inline void io_apic_write(unsigned int apicid, unsigned int reg,
+unsigned int value)
{
- x86_io_apic_ops.write(apic, reg, value);
+ x86_io_apic_ops.write(apicid, reg, value);
}
-static inline void io_apic_modify(unsigned int apic, unsigned int reg,
unsigned int value)
+static inline void io_apic_modify(unsigned int apicid, unsigned int reg,
+ unsigned int value)
{
- x86_io_apic_ops.modify(apic, reg, value);
+ x86_io_apic_ops.modify(apicid, reg, value);
}
extern void io_apic_eoi(unsigned int apic, unsigned int vector);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a44dce8..03f9f46 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -335,22 +335,23 @@ static __attribute_const__ struct io_apic __iomem
*io_apic_base(int idx)
+ (mpc_ioapic_addr(idx) ~PAGE_MASK);
}
-void io_apic_eoi(unsigned int apic, unsigned int vector)
+void io_apic_eoi(unsigned int apicid, unsigned int vector)
{
- struct io_apic __iomem *io_apic = io_apic_base(apic);
+ struct io_apic __iomem *io_apic = io_apic_base(apicid);
writel(vector, io_apic-eoi);
}
-unsigned int native_io_apic_read(unsigned int apic, unsigned int reg)
+unsigned int native_io_apic_read(unsigned int apicid, unsigned int reg)
{
- struct io_apic __iomem *io_apic = io_apic_base(apic);
+ struct io_apic __iomem *io_apic = io_apic_base(apicid);
writel(reg, io_apic-index);
return readl(io_apic-data);
}
-void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int
value)
+void native_io_apic_write(unsigned int apicid, unsigned int reg,
+ unsigned int value)
{
- struct io_apic __iomem *io_apic = io_apic_base(apic);
+ struct io_apic __iomem *io_apic = io_apic_base(apicid);
writel(reg, io_apic-index);
writel(value, io_apic-data);
@@ -362,9 +363,10 @@ void native_io_apic_write(unsigned int apic, unsigned int
reg, unsigned int valu
*
* Older SiS APIC requires we rewrite the index register
*/
-void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int
value)
+void native_io_apic_modify(unsigned int apicid, unsigned int reg,
+ unsigned int value)
{
- struct io_apic __iomem *io_apic = io_apic_base(apic);
+ struct io_apic __iomem *io_apic = io_apic_base(apicid);
if (sis_apic_bug)
writel(reg, io_apic-index);
@@ -376,23 +378,23 @@ union entry_union {
struct IO_APIC_route_entry entry;
};
-static struct IO_APIC_route_entry __ioapic_read_entry(int apic, int pin)
+static struct IO_APIC_route_entry __ioapic_read_entry(int apicid, int pin)
{
union entry_union eu;
- eu.w1 = io_apic_read(apic, 0x10 + 2 * pin);
- eu.w2 = io_apic_read(apic, 0x11 + 2 * pin);
+ eu.w1 = io_apic_read(apicid, 0x10 + 2 * pin);
+ eu.w2 = io_apic_read(apicid, 0x11 + 2 * pin);
return eu.entry;
}
-static struct IO_APIC_route_entry ioapic_read_entry(int apic, int pin)
+static struct IO_APIC_route_entry ioapic_read_entry(int apicid, int pin)
{
union entry_union eu;
unsigned long flags;
raw_spin_lock_irqsave(ioapic_lock, flags);
- eu.entry = __ioapic_read_entry(apic, pin);
+ eu.entry = __ioapic_read_entry(apicid, pin);
raw_spin_unlock_irqrestore(ioapic_lock, flags
Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
On 11/08/2012 03:15 AM, pkill.2012 wrote: Hello, I installed kvm and tried to use SR-IOV virtualizaton for 82599EB(Intel XT-520 T2) dual port card with latest ixgbe driver(version:3.11.33) , kernel2.6.32-279.14.1(OS:Centos6.3) ,after configuration and reboot It seems that only first port of the card's VFs works,second port of the card's VFs didn't work I found some errors in /var/log messages: Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: not enough MMIO resources for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (unregistered net_device): Failed to enable PCI sriov: -12 How to fix it,any help would be greatly appreciated. below is the related information: Server: R710 OS: centos6.3 NIC: X520-T2(dual port) kernel: 2.6.32-279.14.1.el6.x86_64 BIOSVersion: 6.3.0(latest) BIOS:Inter VT/VT-d or SR-IOV(enabled) ixgbe:3.11.33(latest) ixgbevf:2.7.12(latest) grub config:intel_iommu=on appended /var/log/messages: Nov 8 14:56:54 12 kernel: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.11.33 Nov 8 14:56:54 12 kernel: Copyright (c) 1999-2012 Intel Corporation. Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: PCI INT B - GSI 50 (level, low) - IRQ 50 Nov 8 14:56:54 12 kernel: ixgbe: I/O Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel: ixgbe: :07:00.0: ixgbe_check_options: FCoE Offload feature enabled Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: (unregistered net_device): SR-IOV enabled with 2 VFs Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: FCoE offload feature is not available. Disabling FCoE offload feature Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: (PCI Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e2 Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: Enabled Features: RxQ: 1 TxQ: 1 LRO Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: IOV: VF 0 is enabled mac 0E:15:B9:26:B3:7D Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: IOV: VF 1 is enabled mac 32:69:2D:16:B9:40 Nov 8 14:56:54 12 kernel: ixgbe :07:00.0: eth4: Intel(R) 10 Gigabit Network Connection Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: PCI INT A - GSI 40 (level, low) - IRQ 40 Nov 8 14:56:54 12 kernel: ixgbe: I/O Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel: ixgbe: :07:00.1: ixgbe_check_options: FCoE Offload feature enabled Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: not enough MMIO resources for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (unregistered net_device): Failed to enable PCI sriov: -12 Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: FCoE offload feature is not available. Disabling FCoE offload feature Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: (PCI Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e3 Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: Enabled Features: RxQ: 16 TxQ: 16 FdirHash RSC Nov 8 14:56:54 12 kernel: ixgbe :07:00.1: eth5: Intel(R) 10 Gigabit Network Connection # dmesg |grep -E 'DMA|IOMMU' ACPI: DMAR bf3b3668 001C0 (v01 DELL PE_SC3 0001 DELL 0001) DMA 0x0001 - 0x1000 DMA320x1000 - 0x0010 DMA zone: 56 pages used for memmap DMA zone: 102 pages reserved DMA zone: 3839 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 764849 pages, LIFO batch:31 Intel-IOMMU: enabled DMAR: Host address width 40 DMAR: DRHD base: 0x00fed9 flags: 0x1 IOMMU fed9: ver 1:0 cap c90780106f0462 ecap f020fe DMAR: RMRR base: 0x00bf4c8000 end: 0x00bf4d DMAR: RMRR base: 0x00bf4b1000 end: 0x00bf4b DMAR: RMRR base: 0x00bf4a1000 end: 0x00bf4a1fff DMAR: RMRR base: 0x00bf4a3000 end: 0x00bf4a3fff DMAR: RMRR base: 0x00bf4a5000 end: 0x00bf4a5fff DMAR: RMRR base: 0x00bf4a7000 end: 0x00bf4a7fff DMAR: RMRR base: 0x00bf4c end: 0x00bf4c0fff DMAR: RMRR base: 0x00bf4c2000 end: 0x00bf4c2fff DMAR: ATSR flags: 0x0 DMAR: Device scope device [:00:1a.02] not found DMAR: Device scope device [:00:1a.02] not found DMAR: Device scope device [:00:1d.02] not found DMAR: Device scope device [:00:1d.02] not found IOMMU 0xfed9: using Queued invalidation IOMMU: Setting RMRR: IOMMU: Setting identity map for device :00:1d.7 [0xbf4c2000 - 0xbf4c3000] IOMMU: Setting identity map for device :00:1a.7 [0xbf4c - 0xbf4c1000] IOMMU: Setting identity map for device :00:1d.1 [0xbf4a7000 - 0xbf4a8000] IOMMU: Setting identity map for device :00:1d.0 [0xbf4a5000 - 0xbf4a6000] IOMMU: Setting identity map for device :00:1a.1 [0xbf4a3000 - 0xbf4a4000] IOMMU: Setting identity map for device :00:1a.0 [0xbf4a1000 - 0xbf4a2000] IOMMU: Setting identity map for device :00:1a.0 [0xbf4b1000 - 0xbf4c]
Re: [net-next PATCH v0 5/5] ixgbe: allow RAR table to be updated in promisc mode
On Sun, 2012-03-18 at 23:52 -0700, Fastabend, John R wrote: This allows RAR table updates while in promiscuous. With SR-IOV enabled it is valuable to allow the RAR table to be updated even when in promisc mode to configure forwarding Signed-off-by: John Fastabend john.r.fastab...@intel.com --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 21 +++-- 1 files changed, 11 insertions(+), 10 deletions(-) Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com signature.asc Description: This is a digitally signed message part
Re: [net-next PATCH v0 4/5] ixgbe: enable FDB netdevice ops
On Sun, 2012-03-18 at 23:52 -0700, Fastabend, John R wrote: Enable FDB ops on ixgbe when in SR-IOV mode. Signed-off-by: John Fastabend john.r.fastab...@intel.com --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 59 + 1 files changed, 59 insertions(+), 0 deletions(-) Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com signature.asc Description: This is a digitally signed message part
Re: [PATCH net-next] ixgbe: make macvlan on PF working when SRIOV is enabled
On Tue, May 25, 2010 at 09:55, Shirley Ma mashi...@us.ibm.com wrote: When SRIOV is enabled, if we create macvlan on PF and load the VF driver in host domain, when macvlan/PF and VF interfaces are all up, the macvlan incoming network traffics are directed to VF interface not PF interface. This patch has fixed this issue. Signed-off-by: Shirley Ma x...@us.ibm.com --- drivers/net/ixgbe/ixgbe_common.c | 26 -- 1 files changed, 16 insertions(+), 10 deletions(-) Thanks, I have added the patch to my queue. -- Cheers, Jeff -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] ixgbe: return error in set_rar when index out of range
On Tue, May 18, 2010 at 08:34, Shirley Ma mashi...@us.ibm.com wrote:
Return -1 when set_rar index is out of range
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/ixgbe/ixgbe_common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
I think this should use IXGBE_ERR_blah instead and there is another
spot where this could be used. Instead I propose this patch
instead...
ixgbe: return IXGBE_ERR_RAR_INDEX when out of range
From: Jeff Kirsher jeffrey.t.kirs...@intel.com
Based on patch from Shirley Ma x...@us.ibm.com
Return IXGBE_ERR_RAR_INDEX when RAR index is out of range, instead of
returning IXGBE_SUCCESS.
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
Acked-by: Don Skidmore donald.c.skidm...@intel.com
---
drivers/net/ixgbe/ixgbe_common.c |2 ++
drivers/net/ixgbe/ixgbe_type.h |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c b/drivers/net/ixgbe/ixgbe_common.c
index 1159d91..9595b1b 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1188,6 +1188,7 @@ s32 ixgbe_set_rar_generic(struct ixgbe_hw *hw,
u32 index, u8 *addr, u32 vmdq,
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, RAR index %d is out of range.\n, index);
+ return IXGBE_ERR_RAR_INDEX;
}
return 0;
@@ -1219,6 +1220,7 @@ s32 ixgbe_clear_rar_generic(struct ixgbe_hw *hw,
u32 index)
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, RAR index %d is out of range.\n, index);
+ return IXGBE_ERR_RAR_INDEX;
}
/* clear VMDq pool/queue selection for this RAR */
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index bd69196..37d2807 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -2600,6 +2600,7 @@ struct ixgbe_info {
#define IXGBE_ERR_FDIR_REINIT_FAILED-23
#define IXGBE_ERR_EEPROM_VERSION-24
#define IXGBE_ERR_NO_SPACE -25
+#define IXGBE_ERR_RAR_INDEX -26
#define IXGBE_NOT_IMPLEMENTED 0x7FFF
#endif /* _IXGBE_TYPE_H_ */
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] ixgbevf: Enable GRO by default
On Thu, May 13, 2010 at 12:51, Shirley Ma mashi...@us.ibm.com wrote: Enable GRO by default for performance. Signed-off-by: Shirley Ma x...@us.ibm.com --- drivers/net/ixgbevf/ixgbevf_main.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c index 40f47b8..1bbb05e 100644 --- a/drivers/net/ixgbevf/ixgbevf_main.c +++ b/drivers/net/ixgbevf/ixgbevf_main.c @@ -3415,6 +3415,7 @@ static int __devinit ixgbevf_probe(struct pci_dev *pdev, netdev-features |= NETIF_F_IPV6_CSUM; netdev-features |= NETIF_F_TSO; netdev-features |= NETIF_F_TSO6; + netdev-features |= NETIF_F_GRO; netdev-vlan_features |= NETIF_F_TSO; netdev-vlan_features |= NETIF_F_TSO6; netdev-vlan_features |= NETIF_F_IP_CSUM; Thanks, I have added the patch to my queue. -- Cheers, Jeff -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 2/2] igb: add PF to pool if adding a VLVF register value and the VFTA bit is
From: Alexander Duyck alexander.h.du...@intel.com
already set.
This patch addresses the unlikely situation that the PF adds a vlan
entry when the vlvf is full, and a vf later adds the vlan to the vlvf.
Signed-off-by: Alexander Duyck alexander.h.du...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
drivers/net/igb/e1000_mac.c | 21 ++---
drivers/net/igb/e1000_mac.h |2 +-
drivers/net/igb/igb_main.c |9 +++--
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/net/igb/e1000_mac.c b/drivers/net/igb/e1000_mac.c
index 2804db0..f11592f 100644
--- a/drivers/net/igb/e1000_mac.c
+++ b/drivers/net/igb/e1000_mac.c
@@ -126,19 +126,26 @@ void igb_write_vfta(struct e1000_hw *hw, u32 offset, u32
value)
* Sets or clears a bit in the VLAN filter table array based on VLAN id
* and if we are adding or removing the filter
**/
-void igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add)
+s32 igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add)
{
u32 index = (vid E1000_VFTA_ENTRY_SHIFT) E1000_VFTA_ENTRY_MASK;
u32 mask = 1 (vid E1000_VFTA_ENTRY_BIT_SHIFT_MASK);
- u32 vfta;
+ u32 vfta = array_rd32(E1000_VFTA, index);
+ s32 ret_val = 0;
- vfta = array_rd32(E1000_VFTA, index);
- if (add)
- vfta |= mask;
- else
- vfta = ~mask;
+ /* bit was set/cleared before we started */
+ if ((!!(vfta mask)) == add) {
+ ret_val = -E1000_ERR_CONFIG;
+ } else {
+ if (add)
+ vfta |= mask;
+ else
+ vfta = ~mask;
+ }
igb_write_vfta(hw, index, vfta);
+
+ return ret_val;
}
/**
diff --git a/drivers/net/igb/e1000_mac.h b/drivers/net/igb/e1000_mac.h
index eccc353..a34de52 100644
--- a/drivers/net/igb/e1000_mac.h
+++ b/drivers/net/igb/e1000_mac.h
@@ -58,7 +58,7 @@ s32 igb_write_8bit_ctrl_reg(struct e1000_hw *hw, u32 reg,
void igb_clear_hw_cntrs_base(struct e1000_hw *hw);
void igb_clear_vfta(struct e1000_hw *hw);
-void igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add);
+s32 igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add);
void igb_config_collision_dist(struct e1000_hw *hw);
void igb_mta_set(struct e1000_hw *hw, u32 hash_value);
void igb_put_hw_semaphore(struct e1000_hw *hw);
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 78558f8..579435d 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -3894,10 +3894,15 @@ static s32 igb_vlvf_set(struct igb_adapter *adapter,
u32 vid, bool add, u32 vf)
/* if !enabled we need to set this up in vfta */
if (!(reg E1000_VLVF_VLANID_ENABLE)) {
- /* add VID to filter table */
- igb_vfta_set(hw, vid, true);
+ /* add VID to filter table, if bit already set
+* PF must have added it outside of table */
+ if (igb_vfta_set(hw, vid, true))
+ reg |= 1 (E1000_VLVF_POOLSEL_SHIFT +
+ adapter-vfs_allocated_count);
reg |= E1000_VLVF_VLANID_ENABLE;
}
+ reg = ~E1000_VLVF_VLANID_MASK;
+ reg |= vid;
wr32(E1000_VLVF(i), reg);
return 0;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SR-IOV driver example 0/3 resend] introduction
On Tue, Dec 2, 2008 at 1:27 AM, Yu Zhao [EMAIL PROTECTED] wrote: SR-IOV drivers of Intel 82576 NIC are available. There are two parts of the drivers: Physical Function driver and Virtual Function driver. The PF driver is based on the IGB driver and is used to control PF to allocate hardware specific resources and interface with the SR-IOV core. The VF driver is a new NIC driver that is same as the traditional PCI device driver. It works in both the host and the guest (Xen and KVM) environment. These two drivers are testing versions and they are *only* intended to show how to use SR-IOV API. Intel 82576 NIC specification can be found at: http://download.intel.com/design/network/datashts/82576_Datasheet_v2p1.pdf [SR-IOV driver example 0/3 resend] introduction [SR-IOV driver example 1/3 resend] PF driver: hardware specific operations [SR-IOV driver example 2/3 resend] PF driver: integrate with SR-IOV core [SR-IOV driver example 3/3 resend] VF driver: an independent PCI NIC driver -- First of all, we (e1000-devel) do support the SR-IOV API. With that said, NAK on the driver changes. We were not involved in these changes and are currently working on a version of the drivers that will make them acceptable for kernel inclusion. -- Cheers, Jeff -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
