* Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes
From: Michael S. Tsirkin @ 2011-08-03 16:39 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Krishna Kumar2, habanero, kvm, steved, Shirley Ma, virtualization,
borntraeger, Tom Lendacky, avi
In-Reply-To: <4E397425.90808@redhat.com>
On Wed, Aug 03, 2011 at 06:15:33PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >E.g. with 32 bridges, and 32 devices behind each one,
> >the available 64K space gets us only 64 bytes per device.
>
> 15 bridges (with io window enabled) max, the smallest io window you
> can assign to a bridge is 4k, and you need some space for the
> devices on the root bus ...
>
> cheers,
> Gerd
Hmm, wait, we could go 32 bit, then we are not limited to 32
bridges anymore, right? Does our bios support that?
--
MST
^ permalink raw reply
* Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes
From: Michael S. Tsirkin @ 2011-08-03 16:29 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Krishna Kumar2, habanero, kvm, steved, Shirley Ma, virtualization,
borntraeger, Tom Lendacky, avi
In-Reply-To: <4E397425.90808@redhat.com>
On Wed, Aug 03, 2011 at 06:15:33PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >E.g. with 32 bridges, and 32 devices behind each one,
> >the available 64K space gets us only 64 bytes per device.
>
> 15 bridges (with io window enabled) max, the smallest io window you
> can assign to a bridge is 4k,
Hmm true, I missed that. So with 32 devs we get 256 bytes per device.
We can still get low on that space when using
multifunction devices though (there could be up to 256 functions behind
a bridge, which only leaves 16 bytes per device).
BTW, this limitation will be a problem for pci express
devices.
> and you need some space for the
> devices on the root bus ...
>
> cheers,
> Gerd
^ permalink raw reply
* Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes
From: Gerd Hoffmann @ 2011-08-03 16:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, habanero, kvm, steved, Shirley Ma, virtualization,
borntraeger, Tom Lendacky, avi
In-Reply-To: <20110803160518.GA16563@redhat.com>
Hi,
> E.g. with 32 bridges, and 32 devices behind each one,
> the available 64K space gets us only 64 bytes per device.
15 bridges (with io window enabled) max, the smallest io window you can
assign to a bridge is 4k, and you need some space for the devices on the
root bus ...
cheers,
Gerd
^ permalink raw reply
* Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes
From: Michael S. Tsirkin @ 2011-08-03 16:05 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar2, habanero, kvm, steved, Shirley Ma, virtualization,
borntraeger, Tom Lendacky, avi
In-Reply-To: <87ei3dxas0.fsf@rustcorp.com.au>
On Thu, Jun 02, 2011 at 11:19:35AM +0930, Rusty Russell wrote:
> On Wed, 1 Jun 2011 13:25:48 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > Add an option to modify the notificatin
> > hand-off in virtio to be basically like Xen:
> > each side published an index, the other side only triggers
> > an event when it crosses that index value
> > (Xen event indexes start at 1, ours start at 0 for
> > backward-compatiblity, but that's minor).
> >
> > Since we've run out of bits in the 32 bit field,
> > I added another 32 bit and bit 31 enables that.
>
> OK. I've applied this, and published it as the 0.9 draft.
>
> Thanks!
> Rusty.
There's something that is bothering me: each such change
increases the size of the config.
Now, on PCI it's in io space which is much constrained.
It might not seem like 32 or 64 bytes is a lot, but in practice
there's a problem with a bridged setup: bridges
sometimes need resources pre-allocated for all devices
that might land behind them.
E.g. with 32 bridges, and 32 devices behind each one,
the available 64K space gets us only 64 bytes per device.
Thankfully even with this change, we are still below that
limit. But for example, this seems to push the size of the config for
virtio net from 32 to 34 bytes. The PCI BAR is a power of two, so it
will be exactly 64 bytes then.
io seems to work much better than memory on kvm, so
we will need to stick to that for datapath.
But maybe it's time to start putting non-datapath in memory?
Thanks,
--
MST
^ permalink raw reply
* Re: [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1
From: Andrew Lutomirski @ 2011-08-03 13:59 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, keir.xen, x86, Linux Kernel Mailing List,
virtualization, mingo, hpa
In-Reply-To: <20110803135604.GA29761@dumpdata.com>
On Wed, Aug 3, 2011 at 9:56 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Aug 03, 2011 at 09:53:22AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 03, 2011 at 09:31:48AM -0400, Andy Lutomirski wrote:
>> > This fixes various problems that cropped up with the vdso patches.
>> >
>> > - Patch 1 fixes an information leak to userspace.
>> > - Patches 2 and 3 fix the kernel build on gold.
>> > - Patches 4 and 5 fix Xen (I hope).
>> > - Patch 6 (optional) adds a trace event to vsyscall emulation. It will
>> > make it easier to handle performance regression reports :)
>>
>> Hm, you seemed to have the x86 maintainers on your email..
>
> I definitly need some coffee. What I meant was that you missing putting
> the x86 maintainers on this patchset. They are the ones that will handle this.
>
> I put them on the To list for you.
Are you sure about that coffee? I'm pretty sure I had x86@kernel.org in there.
--Andy
^ permalink raw reply
* Re: [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1
From: Konrad Rzeszutek Wilk @ 2011-08-03 13:56 UTC (permalink / raw)
To: Andy Lutomirski, mingo, hpa
Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
keir.xen
In-Reply-To: <20110803135322.GC29501@dumpdata.com>
On Wed, Aug 03, 2011 at 09:53:22AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 03, 2011 at 09:31:48AM -0400, Andy Lutomirski wrote:
> > This fixes various problems that cropped up with the vdso patches.
> >
> > - Patch 1 fixes an information leak to userspace.
> > - Patches 2 and 3 fix the kernel build on gold.
> > - Patches 4 and 5 fix Xen (I hope).
> > - Patch 6 (optional) adds a trace event to vsyscall emulation. It will
> > make it easier to handle performance regression reports :)
>
> Hm, you seemed to have the x86 maintainers on your email..
I definitly need some coffee. What I meant was that you missing putting
the x86 maintainers on this patchset. They are the ones that will handle this.
I put them on the To list for you.
> >
> > [1] https://gitorious.org/linux-test-utils/linux-clock-tests
> >
> > Changes from v1:
> > - Improve changelog message for "x86-64/xen: Enable the vvar mapping"
> > - Fix 32-bit build.
> > - Add patch 6.
> >
> > Andy Lutomirski (6):
> > x86-64: Pad vDSO to a page boundary
> > x86-64: Move the "user" vsyscall segment out of the data segment.
> > x86-64: Work around gold bug 13023
> > x86-64/xen: Enable the vvar mapping
> > x86-64: Add user_64bit_mode paravirt op
> > x86-64: Add vsyscall:emulate_vsyscall trace event
> >
> > arch/x86/include/asm/desc.h | 4 +-
> > arch/x86/include/asm/paravirt_types.h | 6 ++++
> > arch/x86/include/asm/ptrace.h | 19 +++++++++++++
> > arch/x86/kernel/paravirt.c | 4 +++
> > arch/x86/kernel/step.c | 2 +-
> > arch/x86/kernel/vmlinux.lds.S | 46 ++++++++++++++++++---------------
> > arch/x86/kernel/vsyscall_64.c | 12 +++++---
> > arch/x86/kernel/vsyscall_trace.h | 29 ++++++++++++++++++++
> > arch/x86/mm/fault.c | 2 +-
> > arch/x86/vdso/vdso.S | 1 +
> > arch/x86/xen/enlighten.c | 4 +++
> > arch/x86/xen/mmu.c | 4 ++-
> > 12 files changed, 102 insertions(+), 31 deletions(-)
> > create mode 100644 arch/x86/kernel/vsyscall_trace.h
> >
> > --
> > 1.7.6
^ permalink raw reply
* Re: [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1
From: Konrad Rzeszutek Wilk @ 2011-08-03 13:53 UTC (permalink / raw)
To: Andy Lutomirski
Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
keir.xen
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
On Wed, Aug 03, 2011 at 09:31:48AM -0400, Andy Lutomirski wrote:
> This fixes various problems that cropped up with the vdso patches.
>
> - Patch 1 fixes an information leak to userspace.
> - Patches 2 and 3 fix the kernel build on gold.
> - Patches 4 and 5 fix Xen (I hope).
> - Patch 6 (optional) adds a trace event to vsyscall emulation. It will
> make it easier to handle performance regression reports :)
Hm, you seemed to have the x86 maintainers on your email..
>
> [1] https://gitorious.org/linux-test-utils/linux-clock-tests
>
> Changes from v1:
> - Improve changelog message for "x86-64/xen: Enable the vvar mapping"
> - Fix 32-bit build.
> - Add patch 6.
>
> Andy Lutomirski (6):
> x86-64: Pad vDSO to a page boundary
> x86-64: Move the "user" vsyscall segment out of the data segment.
> x86-64: Work around gold bug 13023
> x86-64/xen: Enable the vvar mapping
> x86-64: Add user_64bit_mode paravirt op
> x86-64: Add vsyscall:emulate_vsyscall trace event
>
> arch/x86/include/asm/desc.h | 4 +-
> arch/x86/include/asm/paravirt_types.h | 6 ++++
> arch/x86/include/asm/ptrace.h | 19 +++++++++++++
> arch/x86/kernel/paravirt.c | 4 +++
> arch/x86/kernel/step.c | 2 +-
> arch/x86/kernel/vmlinux.lds.S | 46 ++++++++++++++++++---------------
> arch/x86/kernel/vsyscall_64.c | 12 +++++---
> arch/x86/kernel/vsyscall_trace.h | 29 ++++++++++++++++++++
> arch/x86/mm/fault.c | 2 +-
> arch/x86/vdso/vdso.S | 1 +
> arch/x86/xen/enlighten.c | 4 +++
> arch/x86/xen/mmu.c | 4 ++-
> 12 files changed, 102 insertions(+), 31 deletions(-)
> create mode 100644 arch/x86/kernel/vsyscall_trace.h
>
> --
> 1.7.6
^ permalink raw reply
* Re: [PATCH v2 4/6] x86-64/xen: Enable the vvar mapping
From: Konrad Rzeszutek Wilk @ 2011-08-03 13:49 UTC (permalink / raw)
To: Andy Lutomirski
Cc: xen-devel, x86, Linux Kernel Mailing List, virtualization,
keir.xen
In-Reply-To: <4659478ed2f3480938f96491c2ecbe2b2e113a23.1312378163.git.luto@mit.edu>
On Wed, Aug 03, 2011 at 09:31:52AM -0400, Andy Lutomirski wrote:
> Xen needs to handle VVAR_PAGE, introduced in git commit:
> 9fd67b4ed0714ab718f1f9bd14c344af336a6df7
> x86-64: Give vvars their own page
>
> Otherwise we die during bootup with a message like:
>
> (XEN) mm.c:940:d10 Error getting mfn 1888 (pfn 1e3e48) from L1 entry
> 8000000001888465 for l1e_owner=10, pg_owner=10
> (XEN) mm.c:5049:d10 ptwr_emulate: could not get_page_from_l1e()
> [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 0.000000] IP: [<ffffffff8103a930>] xen_set_pte+0x20/0xe0
>
> Signed-off-by: Andy Lutomirski <luto@mit.edu>
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> arch/x86/xen/mmu.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index f987bde..8cce339 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1916,6 +1916,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
> # endif
> #else
> case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
> + case VVAR_PAGE:
> #endif
> case FIX_TEXT_POKE0:
> case FIX_TEXT_POKE1:
> @@ -1956,7 +1957,8 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
> #ifdef CONFIG_X86_64
> /* Replicate changes to map the vsyscall page into the user
> pagetable vsyscall mapping. */
> - if (idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) {
> + if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
> + idx == VVAR_PAGE) {
> unsigned long vaddr = __fix_to_virt(idx);
> set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
> }
> --
> 1.7.6
^ permalink raw reply
* [PATCH v2 6/6] x86-64: Add vsyscall:emulate_vsyscall trace event
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
Vsyscall emulation is slow, so make it easy to track down.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
---
arch/x86/kernel/vsyscall_64.c | 6 ++++++
arch/x86/kernel/vsyscall_trace.h | 29 +++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/kernel/vsyscall_trace.h
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 1725930..93a0d46 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -50,6 +50,9 @@
#include <asm/vgtod.h>
#include <asm/traps.h>
+#define CREATE_TRACE_POINTS
+#include "vsyscall_trace.h"
+
DEFINE_VVAR(int, vgetcpu_mode);
DEFINE_VVAR(struct vsyscall_gtod_data, vsyscall_gtod_data) =
{
@@ -146,6 +149,9 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
* and int 0xcc is two bytes long.
*/
vsyscall_nr = addr_to_vsyscall_nr(regs->ip - 2);
+
+ trace_emulate_vsyscall(vsyscall_nr);
+
if (vsyscall_nr < 0) {
warn_bad_vsyscall(KERN_WARNING, regs,
"illegal int 0xcc (exploit attempt?)");
diff --git a/arch/x86/kernel/vsyscall_trace.h b/arch/x86/kernel/vsyscall_trace.h
new file mode 100644
index 0000000..a8b2ede
--- /dev/null
+++ b/arch/x86/kernel/vsyscall_trace.h
@@ -0,0 +1,29 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM vsyscall
+
+#if !defined(__VSYSCALL_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define __VSYSCALL_TRACE_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(emulate_vsyscall,
+
+ TP_PROTO(int nr),
+
+ TP_ARGS(nr),
+
+ TP_STRUCT__entry(__field(int, nr)),
+
+ TP_fast_assign(
+ __entry->nr = nr;
+ ),
+
+ TP_printk("nr = %d", __entry->nr)
+);
+
+#endif
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH ../../arch/x86/kernel
+#define TRACE_INCLUDE_FILE vsyscall_trace
+#include <trace/define_trace.h>
--
1.7.6
^ permalink raw reply related
* [PATCH v2 5/6] x86-64: Add user_64bit_mode paravirt op
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
Three places in the kernel assume that the only long mode CPL 3
selector is __USER_CS. This is not true on Xen -- Xen's sysretq
changes cs to the magic value 0xe033.
Two of the places are corner cases, but as of "x86-64: Improve
vsyscall emulation CS and RIP handling"
(c9712944b2a12373cb6ff8059afcfb7e826a6c54), vsyscalls will segfault
if called with Xen's extra CS selector. This causes a panic when
older init builds die.
It seems impossible to make Xen use __USER_CS reliably without
taking a performance hit on every system call, so this fixes the
tests instead with a new paravirt op. It's a little ugly because
ptrace.h can't include paravirt.h.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/include/asm/desc.h | 4 ++--
arch/x86/include/asm/paravirt_types.h | 6 ++++++
arch/x86/include/asm/ptrace.h | 19 +++++++++++++++++++
arch/x86/kernel/paravirt.c | 4 ++++
arch/x86/kernel/step.c | 2 +-
arch/x86/kernel/vsyscall_64.c | 6 +-----
arch/x86/mm/fault.c | 2 +-
arch/x86/xen/enlighten.c | 4 ++++
8 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 7b439d9..41935fa 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -27,8 +27,8 @@ static inline void fill_ldt(struct desc_struct *desc, const struct user_desc *in
desc->base2 = (info->base_addr & 0xff000000) >> 24;
/*
- * Don't allow setting of the lm bit. It is useless anyway
- * because 64bit system calls require __USER_CS:
+ * Don't allow setting of the lm bit. It would confuse
+ * user_64bit_mode and would get overridden by sysret anyway.
*/
desc->l = 0;
}
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 2c76521..8e8b9a4 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -41,6 +41,7 @@
#include <asm/desc_defs.h>
#include <asm/kmap_types.h>
+#include <asm/pgtable_types.h>
struct page;
struct thread_struct;
@@ -63,6 +64,11 @@ struct paravirt_callee_save {
struct pv_info {
unsigned int kernel_rpl;
int shared_kernel_pmd;
+
+#ifdef CONFIG_X86_64
+ u16 extra_user_64bit_cs; /* __USER_CS if none */
+#endif
+
int paravirt_enabled;
const char *name;
};
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 94e7618..3566454 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -131,6 +131,9 @@ struct pt_regs {
#ifdef __KERNEL__
#include <linux/init.h>
+#ifdef CONFIG_PARAVIRT
+#include <asm/paravirt_types.h>
+#endif
struct cpuinfo_x86;
struct task_struct;
@@ -187,6 +190,22 @@ static inline int v8086_mode(struct pt_regs *regs)
#endif
}
+#ifdef CONFIG_X86_64
+static inline bool user_64bit_mode(struct pt_regs *regs)
+{
+#ifndef CONFIG_PARAVIRT
+ /*
+ * On non-paravirt systems, this is the only long mode CPL 3
+ * selector. We do not allow long mode selectors in the LDT.
+ */
+ return regs->cs == __USER_CS;
+#else
+ /* Headers are too twisted for this to go in paravirt.h. */
+ return regs->cs == __USER_CS || regs->cs == pv_info.extra_user_64bit_cs;
+#endif
+}
+#endif
+
/*
* X86_32 CPUs don't save ss and esp if the CPU is already in kernel mode
* when it traps. The previous stack will be directly underneath the saved
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 613a793..d90272e 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -307,6 +307,10 @@ struct pv_info pv_info = {
.paravirt_enabled = 0,
.kernel_rpl = 0,
.shared_kernel_pmd = 1, /* Only used when CONFIG_X86_PAE is set */
+
+#ifdef CONFIG_X86_64
+ .extra_user_64bit_cs = __USER_CS,
+#endif
};
struct pv_init_ops pv_init_ops = {
diff --git a/arch/x86/kernel/step.c b/arch/x86/kernel/step.c
index 7977f0c..c346d11 100644
--- a/arch/x86/kernel/step.c
+++ b/arch/x86/kernel/step.c
@@ -74,7 +74,7 @@ static int is_setting_trap_flag(struct task_struct *child, struct pt_regs *regs)
#ifdef CONFIG_X86_64
case 0x40 ... 0x4f:
- if (regs->cs != __USER_CS)
+ if (!user_64bit_mode(regs))
/* 32-bit mode: register increment */
return 0;
/* 64-bit mode: REX prefix */
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index dda7dff..1725930 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -127,11 +127,7 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
local_irq_enable();
- /*
- * Real 64-bit user mode code has cs == __USER_CS. Anything else
- * is bogus.
- */
- if (regs->cs != __USER_CS) {
+ if (!user_64bit_mode(regs)) {
/*
* If we trapped from kernel mode, we might as well OOPS now
* instead of returning to some random address and OOPSing
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 4d09df0..decd51a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -105,7 +105,7 @@ check_prefetch_opcode(struct pt_regs *regs, unsigned char *instr,
* but for now it's good enough to assume that long
* mode only uses well known segments or kernel.
*/
- return (!user_mode(regs)) || (regs->cs == __USER_CS);
+ return (!user_mode(regs) || user_64bit_mode(regs));
#endif
case 0x60:
/* 0x64 thru 0x67 are valid prefixes in all modes. */
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 974a528..e2345af 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -951,6 +951,10 @@ static const struct pv_info xen_info __initconst = {
.paravirt_enabled = 1,
.shared_kernel_pmd = 0,
+#ifdef CONFIG_X86_64
+ .extra_user_64bit_cs = FLAT_USER_CS64,
+#endif
+
.name = "Xen",
};
--
1.7.6
^ permalink raw reply related
* [PATCH v2 4/6] x86-64/xen: Enable the vvar mapping
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
Xen needs to handle VVAR_PAGE, introduced in git commit:
9fd67b4ed0714ab718f1f9bd14c344af336a6df7
x86-64: Give vvars their own page
Otherwise we die during bootup with a message like:
(XEN) mm.c:940:d10 Error getting mfn 1888 (pfn 1e3e48) from L1 entry
8000000001888465 for l1e_owner=10, pg_owner=10
(XEN) mm.c:5049:d10 ptwr_emulate: could not get_page_from_l1e()
[ 0.000000] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 0.000000] IP: [<ffffffff8103a930>] xen_set_pte+0x20/0xe0
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/xen/mmu.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f987bde..8cce339 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1916,6 +1916,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
# endif
#else
case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
+ case VVAR_PAGE:
#endif
case FIX_TEXT_POKE0:
case FIX_TEXT_POKE1:
@@ -1956,7 +1957,8 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
#ifdef CONFIG_X86_64
/* Replicate changes to map the vsyscall page into the user
pagetable vsyscall mapping. */
- if (idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) {
+ if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
+ idx == VVAR_PAGE) {
unsigned long vaddr = __fix_to_virt(idx);
set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
}
--
1.7.6
^ permalink raw reply related
* [PATCH v2 3/6] x86-64: Work around gold bug 13023
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
Gold has trouble assigning numbers to the location counter inside of
an output section description. The bug was triggered by
9fd67b4ed0714ab718f1f9bd14c344af336a6df7, which consolidated all of
the vsyscall sections into a single section. The workaround is IMO
still nicer than the old way of doing it.
This produces an apparently valid kernel image and passes my vdso
tests on both GNU ld version 2.21.51.0.6-2.fc15 20110118 and GNU
gold (version 2.21.51.0.6-2.fc15 20110118) 1.10 as distributed by
Fedora 15.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
---
arch/x86/kernel/vmlinux.lds.S | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index e79fb39..8f3a265 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -158,10 +158,12 @@ SECTIONS
__vvar_page = .;
.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
+ /* work around gold bug 13023 */
+ __vvar_beginning_hack = .;
- /* Place all vvars at the offsets in asm/vvar.h. */
-#define EMIT_VVAR(name, offset) \
- . = offset; \
+ /* Place all vvars at the offsets in asm/vvar.h. */
+#define EMIT_VVAR(name, offset) \
+ . = __vvar_beginning_hack + offset; \
*(.vvar_ ## name)
#define __VVAR_KERNEL_LDS
#include <asm/vvar.h>
@@ -184,15 +186,17 @@ SECTIONS
. = VSYSCALL_ADDR;
.vsyscall : AT(VLOAD(.vsyscall)) {
+ /* work around gold bug 13023 */
+ __vsyscall_beginning_hack = .;
*(.vsyscall_0)
- . = 1024;
+ . = __vsyscall_beginning_hack + 1024;
*(.vsyscall_1)
- . = 2048;
+ . = __vsyscall_beginning_hack + 2048;
*(.vsyscall_2)
- . = 4096; /* Pad the whole page. */
+ . = __vsyscall_beginning_hack + 4096; /* Pad the whole page. */
} :user =0xcc
. = ALIGN(__vsyscall_0 + PAGE_SIZE, PAGE_SIZE);
--
1.7.6
^ permalink raw reply related
* [PATCH v2 2/6] x86-64: Move the "user" vsyscall segment out of the data segment.
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
The kernel's loader doesn't seem to care, but gold complains.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
---
arch/x86/kernel/vmlinux.lds.S | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 4aa9c54..e79fb39 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -154,6 +154,24 @@ SECTIONS
#ifdef CONFIG_X86_64
+ . = ALIGN(PAGE_SIZE);
+ __vvar_page = .;
+
+ .vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
+
+ /* Place all vvars at the offsets in asm/vvar.h. */
+#define EMIT_VVAR(name, offset) \
+ . = offset; \
+ *(.vvar_ ## name)
+#define __VVAR_KERNEL_LDS
+#include <asm/vvar.h>
+#undef __VVAR_KERNEL_LDS
+#undef EMIT_VVAR
+
+ } :data
+
+ . = ALIGN(__vvar_page + PAGE_SIZE, PAGE_SIZE);
+
#define VSYSCALL_ADDR (-10*1024*1024)
#define VLOAD_OFFSET (VSYSCALL_ADDR - __vsyscall_0 + LOAD_OFFSET)
@@ -162,7 +180,6 @@ SECTIONS
#define VVIRT_OFFSET (VSYSCALL_ADDR - __vsyscall_0)
#define VVIRT(x) (ADDR(x) - VVIRT_OFFSET)
- . = ALIGN(4096);
__vsyscall_0 = .;
. = VSYSCALL_ADDR;
@@ -185,23 +202,6 @@ SECTIONS
#undef VVIRT_OFFSET
#undef VVIRT
- __vvar_page = .;
-
- .vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
-
- /* Place all vvars at the offsets in asm/vvar.h. */
-#define EMIT_VVAR(name, offset) \
- . = offset; \
- *(.vvar_ ## name)
-#define __VVAR_KERNEL_LDS
-#include <asm/vvar.h>
-#undef __VVAR_KERNEL_LDS
-#undef EMIT_VVAR
-
- } :data
-
- . = ALIGN(__vvar_page + PAGE_SIZE, PAGE_SIZE);
-
#endif /* CONFIG_X86_64 */
/* Init code and data - will be freed after init */
--
1.7.6
^ permalink raw reply related
* [PATCH v2 1/6] x86-64: Pad vDSO to a page boundary
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
This avoids an information leak to userspace.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
---
arch/x86/vdso/vdso.S | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S
index 1b979c1..01f5e3b 100644
--- a/arch/x86/vdso/vdso.S
+++ b/arch/x86/vdso/vdso.S
@@ -9,6 +9,7 @@ __PAGE_ALIGNED_DATA
vdso_start:
.incbin "arch/x86/vdso/vdso.so"
vdso_end:
+ .align PAGE_SIZE /* extra data here leaks to userspace. */
.previous
--
1.7.6
^ permalink raw reply related
* [PATCH v2 1/6] x86-64: Pad vDSO to a page boundary
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
In-Reply-To: <cover.1312378163.git.luto@mit.edu>
This avoids an information leak to userspace.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
---
arch/x86/vdso/vdso.S | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S
index 1b979c1..01f5e3b 100644
--- a/arch/x86/vdso/vdso.S
+++ b/arch/x86/vdso/vdso.S
@@ -9,6 +9,7 @@ __PAGE_ALIGNED_DATA
vdso_start:
.incbin "arch/x86/vdso/vdso.so"
vdso_end:
+ .align PAGE_SIZE /* extra data here leaks to userspace. */
.previous
--
1.7.6
^ permalink raw reply related
* [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1
From: Andy Lutomirski @ 2011-08-03 13:31 UTC (permalink / raw)
To: x86, Konrad Rzeszutek Wilk
Cc: xen-devel, Linux Kernel Mailing List, virtualization, keir.xen,
Andy Lutomirski
This fixes various problems that cropped up with the vdso patches.
- Patch 1 fixes an information leak to userspace.
- Patches 2 and 3 fix the kernel build on gold.
- Patches 4 and 5 fix Xen (I hope).
- Patch 6 (optional) adds a trace event to vsyscall emulation. It will
make it easier to handle performance regression reports :)
[1] https://gitorious.org/linux-test-utils/linux-clock-tests
Changes from v1:
- Improve changelog message for "x86-64/xen: Enable the vvar mapping"
- Fix 32-bit build.
- Add patch 6.
Andy Lutomirski (6):
x86-64: Pad vDSO to a page boundary
x86-64: Move the "user" vsyscall segment out of the data segment.
x86-64: Work around gold bug 13023
x86-64/xen: Enable the vvar mapping
x86-64: Add user_64bit_mode paravirt op
x86-64: Add vsyscall:emulate_vsyscall trace event
arch/x86/include/asm/desc.h | 4 +-
arch/x86/include/asm/paravirt_types.h | 6 ++++
arch/x86/include/asm/ptrace.h | 19 +++++++++++++
arch/x86/kernel/paravirt.c | 4 +++
arch/x86/kernel/step.c | 2 +-
arch/x86/kernel/vmlinux.lds.S | 46 ++++++++++++++++++---------------
arch/x86/kernel/vsyscall_64.c | 12 +++++---
arch/x86/kernel/vsyscall_trace.h | 29 ++++++++++++++++++++
arch/x86/mm/fault.c | 2 +-
arch/x86/vdso/vdso.S | 1 +
arch/x86/xen/enlighten.c | 4 +++
arch/x86/xen/mmu.c | 4 ++-
12 files changed, 102 insertions(+), 31 deletions(-)
create mode 100644 arch/x86/kernel/vsyscall_trace.h
--
1.7.6
^ permalink raw reply
* [PATCH 1/1] Staging: hv: Integrate the time source driver with Hyper-V detection code
From: K. Y. Srinivasan @ 2011-08-02 16:03 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, andi, akpm, tglx,
x86
Cc: K. Y. Srinivasan, Haiyang Zhang
The Hyper-V timesource driver is best integrated with Hyper-V detection code
since: (a) Linux guests running on Hyper-V need this timesource and (b)
by integrating with Hyper-V detection, we could significantly minimize the
code in the timesource driver.
Andrew, could you take this patch for the -mm tree. I have sent this patch
out multiple times and I have not recived any response or comments.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
arch/x86/kernel/cpu/mshyperv.c | 24 ++++++++
drivers/staging/hv/Makefile | 2 +-
drivers/staging/hv/hv_timesource.c | 102 ------------------------------------
3 files changed, 25 insertions(+), 103 deletions(-)
delete mode 100644 drivers/staging/hv/hv_timesource.c
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index d944bf6..c97f88d 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -11,6 +11,8 @@
*/
#include <linux/types.h>
+#include <linux/time.h>
+#include <linux/clocksource.h>
#include <linux/module.h>
#include <asm/processor.h>
#include <asm/hypervisor.h>
@@ -36,6 +38,25 @@ static bool __init ms_hyperv_platform(void)
!memcmp("Microsoft Hv", hyp_signature, 12);
}
+static cycle_t read_hv_clock(struct clocksource *arg)
+{
+ cycle_t current_tick;
+ /*
+ * Read the partition counter to get the current tick count. This count
+ * is set to 0 when the partition is created and is incremented in
+ * 100 nanosecond units.
+ */
+ rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
+ return current_tick;
+}
+
+static struct clocksource hyperv_cs = {
+ .name = "hyperv_clocksource",
+ .rating = 400, /* use this when running on Hyperv*/
+ .read = read_hv_clock,
+ .mask = CLOCKSOURCE_MASK(64),
+};
+
static void __init ms_hyperv_init_platform(void)
{
/*
@@ -46,6 +67,9 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
ms_hyperv.features, ms_hyperv.hints);
+
+
+ clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
diff --git a/drivers/staging/hv/Makefile b/drivers/staging/hv/Makefile
index bd176b1..3e0d7e6 100644
--- a/drivers/staging/hv/Makefile
+++ b/drivers/staging/hv/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_HYPERV) += hv_vmbus.o hv_timesource.o
+obj-$(CONFIG_HYPERV) += hv_vmbus.o
obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
obj-$(CONFIG_HYPERV_NET) += hv_netvsc.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
diff --git a/drivers/staging/hv/hv_timesource.c b/drivers/staging/hv/hv_timesource.c
deleted file mode 100644
index 0efb049..0000000
--- a/drivers/staging/hv/hv_timesource.c
+++ /dev/null
@@ -1,102 +0,0 @@
-/*
- * A clocksource for Linux running on HyperV.
- *
- *
- * Copyright (C) 2010, Novell, Inc.
- * Author : K. Y. Srinivasan <ksrinivasan@novell.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
- * NON INFRINGEMENT. See the GNU General Public License for more
- * details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
- *
- */
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include <linux/version.h>
-#include <linux/clocksource.h>
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/pci.h>
-#include <linux/dmi.h>
-#include <asm/hyperv.h>
-#include <asm/mshyperv.h>
-#include <asm/hypervisor.h>
-
-#define HV_CLOCK_SHIFT 22
-
-static cycle_t read_hv_clock(struct clocksource *arg)
-{
- cycle_t current_tick;
- /*
- * Read the partition counter to get the current tick count. This count
- * is set to 0 when the partition is created and is incremented in
- * 100 nanosecond units.
- */
- rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
- return current_tick;
-}
-
-static struct clocksource hyperv_cs = {
- .name = "hyperv_clocksource",
- .rating = 400, /* use this when running on Hyperv*/
- .read = read_hv_clock,
- .mask = CLOCKSOURCE_MASK(64),
- /*
- * The time ref counter in HyperV is in 100ns units.
- * The definition of mult is:
- * mult/2^shift = ns/cyc = 100
- * mult = (100 << shift)
- */
- .mult = (100 << HV_CLOCK_SHIFT),
- .shift = HV_CLOCK_SHIFT,
-};
-
-static const struct dmi_system_id __initconst
-hv_timesource_dmi_table[] __maybe_unused = {
- {
- .ident = "Hyper-V",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
- DMI_MATCH(DMI_BOARD_NAME, "Virtual Machine"),
- },
- },
- { },
-};
-MODULE_DEVICE_TABLE(dmi, hv_timesource_dmi_table);
-
-static const struct pci_device_id __initconst
-hv_timesource_pci_table[] __maybe_unused = {
- { PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
- { 0 }
-};
-MODULE_DEVICE_TABLE(pci, hv_timesource_pci_table);
-
-
-static int __init init_hv_clocksource(void)
-{
- if ((x86_hyper != &x86_hyper_ms_hyperv) ||
- !(ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE))
- return -ENODEV;
-
- if (!dmi_check_system(hv_timesource_dmi_table))
- return -ENODEV;
-
- pr_info("Registering HyperV clock source\n");
- return clocksource_register(&hyperv_cs);
-}
-
-module_init(init_hv_clocksource);
-MODULE_DESCRIPTION("HyperV based clocksource");
-MODULE_AUTHOR("K. Y. Srinivasan <ksrinivasan@novell.com>");
-MODULE_LICENSE("GPL");
--
1.7.4.1
^ permalink raw reply related
* Cloudviews2011: Deadline extended to Aug 8, 2011
From: Ming Zhao @ 2011-08-01 16:27 UTC (permalink / raw)
To: virtualization
Update: Deadline extended to Aug 8th, 2011
--------------------------------------------------------------
"Cloud Computing & You"
3rd Cloud Computing International Conference (CloudViews 2011)
October 17-18, 2011
Porto, Portugal
EuroCloud Portugal
2011.cloudviews.org
--------------------------------------------------------------
Recognizing the potential of the Cloud Computing paradigm for ICT evolution, the CloudViews.Org project was launched in the end of 2007. Initially created by independent entrepreneurs, researchers and technical staff of the Porto Polytechnic Institute, CloudViews.Org aimed at promoting and discussing technologies related with Cloud Computing. Following the CloudViews.Org spirit, the EuroCloud Portugal Association (www.eurocloud.pt), a non profit organization, was created in January 2010.
The CloudViews project has already organized two international conferences on Cloud Computing. "To Cloud or not to Cloud" was the main theme of the first edition, held in Porto, Portugal, in 2009. "Cloud Ecosystem" was the theme of CloudViews 2010, which was also held in Porto, Portugal with the help of the Eurocloud Association. In that edition, academia, business people and decision makers gathered together to present their views, which motivated a lively debate where all ICT players were challenged to think about how to achieve a true Cloud Ecosystem.
CloudViews 2011, in its third edition, moves a step forward by defying academia, business people and decision makers to think about their relationship with the clouds. "Cloud Computing & You", the main theme of the third edition of CloudViews has as its main goal to raise awareness and analyse the impact of Cloud Computing on small and medium business (SME), as well as on individual users.
Around the theme "Cloud Computing & You", CloudViews 2011 welcomes contributions from several fields related to cloud computing, including, but not limited to, scientific computing applications, performance evaluation and resource management, predictability and provision platforms, storage clouds architectures and implementations, cloud computing security: models and frameworks, cloud interoperability, scheduling mechanisms, elastic platforms, service level agreements, fault tolerant architectures and implementations, human factors in computing systems, cloud usability, and business models in the cloud.
Submissions of full (8 pages maximum) and short papers (4 pages maximum) must conform to 2 columns IEEE style, in PDF format and offer new, unpublished, original contributions. All contributions must be written in English and submitted electronically through the CV2011 Easy Chair conference system at http://www.easychair.org/conferences/?conf=cloudviews2011.
Reviews will be double-blinded. Prepare your paper without any authors names or affiliations and avoid explicit self-references such as "in a previous work, we [ref]...". Give preference to sentences like: "in a previous work, Smith et al [ref]...". Also avoid the inclusion of acknowledgements and references to funding agencies in your submission version.
Program Committee (list not yet closed)
InêDutra, University of Porto, Portugal (general chair)
Alysson Bessani, University of Lisbon, Portugal
Ana Aguiar, University of Porto, Portugal
Antó Costa, Porto Polytechnic, Portugal
Antó Pinto, Porto Polytechnic, Portugal
Benedita Malheiro, Porto Polytechnic, Portugal (co-chair)
Grzegorz Malewicz, Google Research, USA
Ignacio Llorente, Complutense University of Madrid, Spain
Jack Dongarra, University of Tennessee, USA
Joaquim Filipe, Polytechnic Institute of Setú Portugal
Jorge Barbosa, University of Porto, Portugal
Jorge Gomes, LIP Lisbon, Portugal
Joséortes, University of Florida, USA
Joséogado, University Lusóa, Portugal
Jonathan Dudek, Dudek Global Partners, USA
Juan Carlos Burguillo, University of Vigo, Spain
Kate Keahey, University of Chicago & ANL, USA
Kui Ren, Illinois Institute of Technology, USA
LÃa Ribeiro, University of Porto, Portugal
Marcel Kunze, Karlsruhe Institute of Technology, Germany
Marcelo Pasin, University of Lisbon, Portugal
Miguel Correia, Technical University of Lisbon, Portugal
Miguel Leitã Porto Polytechnic, Portugal (co-chair)
Paolo Romano, INESC-ID, Portugal
Paulo Calça, University of Porto, Portugal (co-chair)
Pedro Assis, Porto Polytechnic, Portugal (co-chair)
Pedro Medeiros, New University of Lisbon, Portugal
Rajkumar Buyya, University of Melbourne, Australia
Ricardo Costa, Porto Polytechnic, Portugal
Ricardo Machado, University of Minho, Portugal
Sebastian Goasguen, Clemson University, USA
Ulrich Schwickerath, CERN, Switzerland
Yong Zhao, University of Electronic Science and Technology of China, People's Republic of China
Important Dates
Submission deadline 8th August, 2011
Acceptance notification 10th September, 2011
Camera-ready deadline 10th October, 2011
Early registration deadline 15th September, 2011
^ permalink raw reply
* Re: [PATCH RFC net-next] virtio_net: refill buffer right after being used
From: Shirley Ma @ 2011-07-31 5:16 UTC (permalink / raw)
To: Mike Waychison; +Cc: virtualization, netdev, kvm, mst
In-Reply-To: <CAGTjWtCsgcf664HJ_prmcRyUzLcSSKhjfbaM0KnsxhDJo6k7Fg@mail.gmail.com>
On Fri, 2011-07-29 at 16:58 -0700, Mike Waychison wrote:
> On Fri, Jul 29, 2011 at 3:55 PM, Shirley Ma <mashirle@us.ibm.com>
> wrote:
> > Resubmit it with a typo fix.
> >
> > Signed-off-by: Shirley Ma <xma@us.ibm.com>
> > ---
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 0c7321c..c8201d4 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct
> virtnet_info *vi, gfp_t gfp)
> > return err;
> > }
> >
> > +static int fill_one(struct virtnet_info *vi, gfp_t gfp)
> > +{
> > + int err;
> > +
> > + if (vi->mergeable_rx_bufs)
> > + err = add_recvbuf_mergeable(vi, gfp);
> > + else if (vi->big_packets)
> > + err = add_recvbuf_big(vi, gfp);
> > + else
> > + err = add_recvbuf_small(vi, gfp);
> > +
> > + if (err >= 0)
> > + ++vi->num;
> > + return err;
> > +}
> > +
> > /* Returns false if we couldn't fill entirely (OOM). */
> > static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
> > {
> > @@ -436,17 +452,10 @@ static bool try_fill_recv(struct virtnet_info
> *vi, gfp_t gfp)
> > bool oom;
> >
> > do {
> > - if (vi->mergeable_rx_bufs)
> > - err = add_recvbuf_mergeable(vi, gfp);
> > - else if (vi->big_packets)
> > - err = add_recvbuf_big(vi, gfp);
> > - else
> > - err = add_recvbuf_small(vi, gfp);
> > -
> > + err = fill_one(vi, gfp);
> > oom = err == -ENOMEM;
> > if (err < 0)
> > break;
> > - ++vi->num;
> > } while (err > 0);
> > if (unlikely(vi->num > vi->max))
> > vi->max = vi->num;
> > @@ -506,13 +515,13 @@ again:
> > receive_buf(vi->dev, buf, len);
> > --vi->num;
> > received++;
> > - }
> > -
> > - if (vi->num < vi->max / 2) {
> > - if (!try_fill_recv(vi, GFP_ATOMIC))
> > + if (fill_one(vi, GFP_ATOMIC) < 0)
> > schedule_delayed_work(&vi->refill, 0);
> > }
> >
> > + /* notify buffers are refilled */
> > + virtqueue_kick(vi->rvq);
> > +
>
> How does this reduce latency? We are doing the same amount of work
> in both cases, and in both cases the newly available buffers are not
> visible to the device until the virtqueue_kick..
It averages the latency between each receive by filling only one set of
buffers vs. either none buffers or 1/2 ring size buffers fill between
receives.
>
> > /* Out of packets? */
> > if (received < budget) {
> > napi_complete(napi);
> >
> >
> > --
^ permalink raw reply
* Re: [PATCH RFC net-next] virtio_net: refill buffer right after being used
From: Mike Waychison @ 2011-07-29 23:58 UTC (permalink / raw)
To: Shirley Ma; +Cc: Rusty Russell, mst, kvm, virtualization, netdev
In-Reply-To: <1311980131.24300.30.camel@localhost.localdomain>
On Fri, Jul 29, 2011 at 3:55 PM, Shirley Ma <mashirle@us.ibm.com> wrote:
> Resubmit it with a typo fix.
>
> Signed-off-by: Shirley Ma <xma@us.ibm.com>
> ---
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 0c7321c..c8201d4 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi, gfp_t gfp)
> return err;
> }
>
> +static int fill_one(struct virtnet_info *vi, gfp_t gfp)
> +{
> + int err;
> +
> + if (vi->mergeable_rx_bufs)
> + err = add_recvbuf_mergeable(vi, gfp);
> + else if (vi->big_packets)
> + err = add_recvbuf_big(vi, gfp);
> + else
> + err = add_recvbuf_small(vi, gfp);
> +
> + if (err >= 0)
> + ++vi->num;
> + return err;
> +}
> +
> /* Returns false if we couldn't fill entirely (OOM). */
> static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
> {
> @@ -436,17 +452,10 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
> bool oom;
>
> do {
> - if (vi->mergeable_rx_bufs)
> - err = add_recvbuf_mergeable(vi, gfp);
> - else if (vi->big_packets)
> - err = add_recvbuf_big(vi, gfp);
> - else
> - err = add_recvbuf_small(vi, gfp);
> -
> + err = fill_one(vi, gfp);
> oom = err == -ENOMEM;
> if (err < 0)
> break;
> - ++vi->num;
> } while (err > 0);
> if (unlikely(vi->num > vi->max))
> vi->max = vi->num;
> @@ -506,13 +515,13 @@ again:
> receive_buf(vi->dev, buf, len);
> --vi->num;
> received++;
> - }
> -
> - if (vi->num < vi->max / 2) {
> - if (!try_fill_recv(vi, GFP_ATOMIC))
> + if (fill_one(vi, GFP_ATOMIC) < 0)
> schedule_delayed_work(&vi->refill, 0);
> }
>
> + /* notify buffers are refilled */
> + virtqueue_kick(vi->rvq);
> +
How does this reduce latency? We are doing the same amount of work
in both cases, and in both cases the newly available buffers are not
visible to the device until the virtqueue_kick..
> /* Out of packets? */
> if (received < budget) {
> napi_complete(napi);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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 RFC net-next] virtio_net: refill buffer right after being used
From: Shirley Ma @ 2011-07-29 22:55 UTC (permalink / raw)
To: Rusty Russell; +Cc: mst, kvm, virtualization, netdev
In-Reply-To: <1311979448.24300.28.camel@localhost.localdomain>
Resubmit it with a typo fix.
Signed-off-by: Shirley Ma <xma@us.ibm.com>
---
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0c7321c..c8201d4 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi, gfp_t gfp)
return err;
}
+static int fill_one(struct virtnet_info *vi, gfp_t gfp)
+{
+ int err;
+
+ if (vi->mergeable_rx_bufs)
+ err = add_recvbuf_mergeable(vi, gfp);
+ else if (vi->big_packets)
+ err = add_recvbuf_big(vi, gfp);
+ else
+ err = add_recvbuf_small(vi, gfp);
+
+ if (err >= 0)
+ ++vi->num;
+ return err;
+}
+
/* Returns false if we couldn't fill entirely (OOM). */
static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
{
@@ -436,17 +452,10 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
bool oom;
do {
- if (vi->mergeable_rx_bufs)
- err = add_recvbuf_mergeable(vi, gfp);
- else if (vi->big_packets)
- err = add_recvbuf_big(vi, gfp);
- else
- err = add_recvbuf_small(vi, gfp);
-
+ err = fill_one(vi, gfp);
oom = err == -ENOMEM;
if (err < 0)
break;
- ++vi->num;
} while (err > 0);
if (unlikely(vi->num > vi->max))
vi->max = vi->num;
@@ -506,13 +515,13 @@ again:
receive_buf(vi->dev, buf, len);
--vi->num;
received++;
- }
-
- if (vi->num < vi->max / 2) {
- if (!try_fill_recv(vi, GFP_ATOMIC))
+ if (fill_one(vi, GFP_ATOMIC) < 0)
schedule_delayed_work(&vi->refill, 0);
}
+ /* notify buffers are refilled */
+ virtqueue_kick(vi->rvq);
+
/* Out of packets? */
if (received < budget) {
napi_complete(napi);
^ permalink raw reply related
* [PATCH RFC net-next] virtio_net: refill buffer right after being used
From: Shirley Ma @ 2011-07-29 22:44 UTC (permalink / raw)
To: Rusty Russell, mst; +Cc: kvm, virtualization, netdev
To even the latency, refill buffer right after being used.
Sign-off-by: Shirley Ma <xma@us.ibm.com>
---
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0c7321c..c8201d4 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi, gfp_t gfp)
return err;
}
+static bool fill_one(struct virtio_net *vi, gfp_t gfp)
+{
+ int err;
+
+ if (vi->mergeable_rx_bufs)
+ err = add_recvbuf_mergeable(vi, gfp);
+ else if (vi->big_packets)
+ err = add_recvbuf_big(vi, gfp);
+ else
+ err = add_recvbuf_small(vi, gfp);
+
+ if (err >= 0)
+ ++vi->num;
+ return err;
+}
+
/* Returns false if we couldn't fill entirely (OOM). */
static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
{
@@ -436,17 +452,10 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
bool oom;
do {
- if (vi->mergeable_rx_bufs)
- err = add_recvbuf_mergeable(vi, gfp);
- else if (vi->big_packets)
- err = add_recvbuf_big(vi, gfp);
- else
- err = add_recvbuf_small(vi, gfp);
-
+ err = fill_one(vi, gfp);
oom = err == -ENOMEM;
if (err < 0)
break;
- ++vi->num;
} while (err > 0);
if (unlikely(vi->num > vi->max))
vi->max = vi->num;
@@ -506,13 +515,13 @@ again:
receive_buf(vi->dev, buf, len);
--vi->num;
received++;
- }
-
- if (vi->num < vi->max / 2) {
- if (!try_fill_recv(vi, GFP_ATOMIC))
+ if (fill_one(vi, GFP_ATOMIC) < 0)
schedule_delayed_work(&vi->refill, 0);
}
+ /* notify buffers are refilled */
+ virtqueue_kick(vi->rvq);
+
/* Out of packets? */
if (received < budget) {
napi_complete(napi);
^ permalink raw reply related
* Re: [RFC PATCH 8/8] virtio: net: Add freeze, restore handlers to support S4
From: Amit Shah @ 2011-07-29 5:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Virtualization List
In-Reply-To: <20110729043116.GG31888@redhat.com>
On (Fri) 29 Jul 2011 [07:31:16], Michael S. Tsirkin wrote:
> On Fri, Jul 29, 2011 at 09:58:02AM +0530, Amit Shah wrote:
> > On (Fri) 29 Jul 2011 [07:13:35], Michael S. Tsirkin wrote:
> > > > +static int virtnet_restore(struct virtio_device *vdev)
> > > > +{
> > > > + struct virtnet_info *vi = vdev->priv;
> > > > + struct virtqueue *vqs[3];
> > > > + vq_callback_t *callbacks[] = { skb_recv_done, skb_xmit_done, NULL};
> > > > + const char *names[] = { "input", "output", "control" };
> > > > + int nvqs, err;
> > > > +
> > > > + /* We expect two virtqueues, receive then send,
> > > > + * and optionally control. */
> > > > + nvqs = virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ) ? 3 : 2;
> > > > +
> > > > + err = vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + vi->rvq = vqs[0];
> > > > + vi->svq = vqs[1];
> > > > +
> > > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ)) {
> > > > + vi->cvq = vqs[2];
> > > > + }
> > > > +
> > > > + /* Last of all, set up some receive buffers. */
> > > > + try_fill_recv(vi, GFP_KERNEL);
>
> I guess we should schedule work on failure, as well.
>
> > >
> > > should probably update carrier status too.
> >
> > Will add that.
> >
> > I think most of these restore routines are incomplete; I just pulled
> > in the most important things from the probe routines, but before the
> > final submission I'll do a thorough walk-through and ensure I get all
> > the bits necessary.
>
> In some cases, it might be a good idea to use common
> code for that.
Absolutely.
Amit
^ permalink raw reply
* Re: [RFC PATCH 8/8] virtio: net: Add freeze, restore handlers to support S4
From: Michael S. Tsirkin @ 2011-07-29 4:31 UTC (permalink / raw)
To: Amit Shah; +Cc: Virtualization List
In-Reply-To: <20110729042802.GD24868@amit-x200.redhat.com>
On Fri, Jul 29, 2011 at 09:58:02AM +0530, Amit Shah wrote:
> On (Fri) 29 Jul 2011 [07:13:35], Michael S. Tsirkin wrote:
> > > +static int virtnet_restore(struct virtio_device *vdev)
> > > +{
> > > + struct virtnet_info *vi = vdev->priv;
> > > + struct virtqueue *vqs[3];
> > > + vq_callback_t *callbacks[] = { skb_recv_done, skb_xmit_done, NULL};
> > > + const char *names[] = { "input", "output", "control" };
> > > + int nvqs, err;
> > > +
> > > + /* We expect two virtqueues, receive then send,
> > > + * and optionally control. */
> > > + nvqs = virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ) ? 3 : 2;
> > > +
> > > + err = vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names);
> > > + if (err)
> > > + return err;
> > > +
> > > + vi->rvq = vqs[0];
> > > + vi->svq = vqs[1];
> > > +
> > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ)) {
> > > + vi->cvq = vqs[2];
> > > + }
> > > +
> > > + /* Last of all, set up some receive buffers. */
> > > + try_fill_recv(vi, GFP_KERNEL);
I guess we should schedule work on failure, as well.
> >
> > should probably update carrier status too.
>
> Will add that.
>
> I think most of these restore routines are incomplete; I just pulled
> in the most important things from the probe routines, but before the
> final submission I'll do a thorough walk-through and ensure I get all
> the bits necessary.
>
> Amit
In some cases, it might be a good idea to use common
code for that.
--
MST
^ permalink raw reply
* Re: [RFC PATCH 8/8] virtio: net: Add freeze, restore handlers to support S4
From: Amit Shah @ 2011-07-29 4:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Virtualization List
In-Reply-To: <20110729041335.GD31888@redhat.com>
On (Fri) 29 Jul 2011 [07:13:35], Michael S. Tsirkin wrote:
> > +static int virtnet_restore(struct virtio_device *vdev)
> > +{
> > + struct virtnet_info *vi = vdev->priv;
> > + struct virtqueue *vqs[3];
> > + vq_callback_t *callbacks[] = { skb_recv_done, skb_xmit_done, NULL};
> > + const char *names[] = { "input", "output", "control" };
> > + int nvqs, err;
> > +
> > + /* We expect two virtqueues, receive then send,
> > + * and optionally control. */
> > + nvqs = virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ) ? 3 : 2;
> > +
> > + err = vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names);
> > + if (err)
> > + return err;
> > +
> > + vi->rvq = vqs[0];
> > + vi->svq = vqs[1];
> > +
> > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ)) {
> > + vi->cvq = vqs[2];
> > + }
> > +
> > + /* Last of all, set up some receive buffers. */
> > + try_fill_recv(vi, GFP_KERNEL);
>
> should probably update carrier status too.
Will add that.
I think most of these restore routines are incomplete; I just pulled
in the most important things from the probe routines, but before the
final submission I'll do a thorough walk-through and ensure I get all
the bits necessary.
Amit
^ 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