linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [patch 06/21] Xen-paravirt: remove ctor for pgd cache
       [not found] ` <20070213221829.929261125@goop.org>
@ 2007-02-13 22:39   ` Zachary Amsden
  0 siblings, 0 replies; 45+ messages in thread
From: Zachary Amsden @ 2007-02-13 22:39 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright

Jeremy Fitzhardinge wrote:
>  
> @@ -261,10 +261,12 @@ void pgd_ctor(void *pgd, struct kmem_cac
>  	spin_unlock_irqrestore(&pgd_lock, flags);
>  }
>  
> -/* never called when PTRS_PER_PMD > 1 */
> -void pgd_dtor(void *pgd, struct kmem_cache *cache, unsigned long unused)
> +static void pgd_dtor(pgd_t *pgd)
>  {
>  	unsigned long flags; /* can be called from interrupt context */
> +
> +	if (PTRS_PER_PMD == 1)
> +		return;
>  
>  	paravirt_release_pd(__pa(pgd) >> PAGE_SHIFT);
>  	spin_lock_irqsave(&pgd_lock, flags);
>   


Acked, with exceptions.  This bit breaks VMI.  The paravirt_release_pd 
must happen unconditionally.  But I would rather fix it after patches 
get applied just to make sure the entire allocation / deallocation order 
constraints are intact.

Zach

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes
       [not found] ` <20070213221830.466651996@goop.org>
@ 2007-02-13 22:45   ` Zachary Amsden
  2007-02-13 22:49     ` Jeremy Fitzhardinge
  2007-02-14  5:38     ` [Xen-devel] " Rusty Russell
  0 siblings, 2 replies; 45+ messages in thread
From: Zachary Amsden @ 2007-02-13 22:45 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Ian Pratt, Christian Limpach

Jeremy Fitzhardinge wrote:
> Add the "nosegneg" fake capabilty to the vsyscall page notes. This is
> used by the runtime linker to select a glibc version which then
> disables negative-offset accesses to the thread-local segment via
> %gs. These accesses require emulation in Xen (because segments are
> truncated to protect the hypervisor address space) and avoiding them
> provides a measurable performance boost.
>   

I don't like this because now a kernel compiled with both CONFIG_XEN and 
CONFIG_VMI has "nosegneg" turned on.  We don't actually require this for 
performance or correctness, so it would be nice to be able to 
dynamically turn it off instead of having it forced.

Zach

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes
  2007-02-13 22:45   ` [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes Zachary Amsden
@ 2007-02-13 22:49     ` Jeremy Fitzhardinge
  2007-02-13 22:54       ` Zachary Amsden
  2007-02-14  5:38     ` [Xen-devel] " Rusty Russell
  1 sibling, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-13 22:49 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Ian Pratt, Christian Limpach

Zachary Amsden wrote:
> I don't like this because now a kernel compiled with both CONFIG_XEN
> and CONFIG_VMI has "nosegneg" turned on.  We don't actually require
> this for performance or correctness, so it would be nice to be able to
> dynamically turn it off instead of having it forced. 

Any suggestions about how to do this?  It seems hard to have a note
dynamically appear and disappear in the vsyscall.so.

I wasn't terribly concerned about this, since there is effectively zero
performance difference between the two library implementations.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
       [not found] ` <20070213221830.542511707@goop.org>
@ 2007-02-13 22:53   ` Dan Hecht
  2007-02-13 23:29     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Dan Hecht @ 2007-02-13 22:53 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, Ian Pratt, linux-kernel

On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
> The XEN config option enables the Xen paravirt_ops interface, which is
> installed when the kernel finds itself running under Xen. (By some
> as-yet fully defined mechanism, implemented in a future patch.)
> 
> Xen is no longer a sub-architecture, so the X86_XEN subarch config
> option has gone.
> 
> The disabled config options are:
> - PREEMPT: Xen doesn't support it
> - HZ: set to 100Hz for now, to cut down on VCPU context switch rate.
>   This will be adapted to use tickless later.
> - kexec: not yet supported
> 

I assume you plan to eventually get all this stuff working but just want 
to prevent configurations that the Xen paravirt-ops isn't ready for at 
the moment?

Instead can you do it this way:

config XEN
     depends on PARAVIRT && !PREEMPT && HZ_100 && !DOUBLEFAULT && !KEXEC


thanks,
Dan


> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
> Signed-off-by: Ian Pratt <ian.pratt@xensource.com>
> Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> 
> ---
>  arch/i386/Kconfig       |    7 +++++--
>  arch/i386/Kconfig.debug |    1 +
>  arch/i386/xen/Kconfig   |   10 ++++++++++
>  kernel/Kconfig.hz       |    4 ++--
>  kernel/Kconfig.preempt  |    1 +
>  5 files changed, 19 insertions(+), 4 deletions(-)
> 
> ===================================================================
> --- a/arch/i386/Kconfig
> +++ b/arch/i386/Kconfig
> @@ -192,6 +192,8 @@ config PARAVIRT
>  	  under a hypervisor, improving performance significantly.
>  	  However, when run without a hypervisor the kernel is
>  	  theoretically slower.  If in doubt, say N.
> +
> +source "arch/i386/xen/Kconfig"
>  
>  config ACPI_SRAT
>  	bool
> @@ -298,12 +300,12 @@ config X86_UP_IOAPIC
>  
>  config X86_LOCAL_APIC
>  	bool
> -	depends on X86_UP_APIC || ((X86_VISWS || SMP) && !X86_VOYAGER) || X86_GENERICARCH
> +	depends on X86_UP_APIC || (((X86_VISWS || SMP) && !X86_VOYAGER) || X86_GENERICARCH)
>  	default y
>  
>  config X86_IO_APIC
>  	bool
> -	depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER)) || X86_GENERICARCH
> +	depends on X86_UP_IOAPIC || ((SMP && !(X86_VISWS || X86_VOYAGER)) || X86_GENERICARCH)
>  	default y
>  
>  config X86_VISWS_APIC
> @@ -743,6 +745,7 @@ source kernel/Kconfig.hz
>  
>  config KEXEC
>  	bool "kexec system call"
> +	depends on !XEN
>  	help
>  	  kexec is a system call that implements the ability to shutdown your
>  	  current kernel, and to start another kernel.  It is like a reboot
> ===================================================================
> --- a/arch/i386/Kconfig.debug
> +++ b/arch/i386/Kconfig.debug
> @@ -79,6 +79,7 @@ config DOUBLEFAULT
>  config DOUBLEFAULT
>  	default y
>  	bool "Enable doublefault exception handler" if EMBEDDED
> +	depends on !XEN
>  	help
>            This option allows trapping of rare doublefault exceptions that
>            would otherwise cause a system to silently reboot. Disabling this
> ===================================================================
> --- /dev/null
> +++ b/arch/i386/xen/Kconfig
> @@ -0,0 +1,10 @@
> +#
> +# This Kconfig describes xen options
> +#
> +
> +config XEN
> +	bool "Enable support for Xen hypervisor"
> +	depends PARAVIRT
> +	default y
> +	help
> +	  This is the Linux Xen port.
> ===================================================================
> --- a/kernel/Kconfig.hz
> +++ b/kernel/Kconfig.hz
> @@ -3,7 +3,7 @@
>  #
>  
>  choice
> -	prompt "Timer frequency"
> +	prompt "Timer frequency" if !XEN
>  	default HZ_250
>  	help
>  	 Allows the configuration of the timer frequency. It is customary
> @@ -49,7 +49,7 @@ endchoice
>  
>  config HZ
>  	int
> -	default 100 if HZ_100
> +	default 100 if HZ_100 || XEN
>  	default 250 if HZ_250
>  	default 300 if HZ_300
>  	default 1000 if HZ_1000
> ===================================================================
> --- a/kernel/Kconfig.preempt
> +++ b/kernel/Kconfig.preempt
> @@ -35,6 +35,7 @@ config PREEMPT_VOLUNTARY
>  
>  config PREEMPT
>  	bool "Preemptible Kernel (Low-Latency Desktop)"
> +	depends on !XEN
>  	help
>  	  This option reduces the latency of the kernel by making
>  	  all kernel code (that is not executing in a critical section)
> 


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes
  2007-02-13 22:49     ` Jeremy Fitzhardinge
@ 2007-02-13 22:54       ` Zachary Amsden
  2007-02-13 23:13         ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Zachary Amsden @ 2007-02-13 22:54 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Ian Pratt, Christian Limpach

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>   
>> I don't like this because now a kernel compiled with both CONFIG_XEN
>> and CONFIG_VMI has "nosegneg" turned on.  We don't actually require
>> this for performance or correctness, so it would be nice to be able to
>> dynamically turn it off instead of having it forced. 
>>     
>
> Any suggestions about how to do this?  It seems hard to have a note
> dynamically appear and disappear in the vsyscall.so.
>
> I wasn't terribly concerned about this, since there is effectively zero
> performance difference between the two library implementations.
>   

I'm not super concerned either, but I still don't like it.  There 
already is dynamic replacement for vsyscall.so, so you could have just 
dropped in an an-note-ated version.

Zach

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes
  2007-02-13 22:54       ` Zachary Amsden
@ 2007-02-13 23:13         ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-13 23:13 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Ian Pratt, Christian Limpach

Zachary Amsden wrote:
> I'm not super concerned either, but I still don't like it.  There
> already is dynamic replacement for vsyscall.so, so you could have just
> dropped in an an-note-ated version.

Ah, OK.  I'll have a look at that.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
  2007-02-13 22:53   ` [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options Dan Hecht
@ 2007-02-13 23:29     ` Jeremy Fitzhardinge
  2007-02-13 23:58       ` [Xen-devel] " Zachary Amsden
  2007-02-13 23:58       ` Dan Hecht
  0 siblings, 2 replies; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-13 23:29 UTC (permalink / raw)
  To: Dan Hecht
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, Ian Pratt, linux-kernel

Dan Hecht wrote:
> I assume you plan to eventually get all this stuff working but just
> want to prevent configurations that the Xen paravirt-ops isn't ready
> for at the moment?
>
> Instead can you do it this way:
>
> config XEN
>     depends on PARAVIRT && !PREEMPT && HZ_100 && !DOUBLEFAULT && !KEXEC

That's a bit simpler code-wise, but it does make it pretty complex to
get everything just-so to even see the CONFIG_XEN option.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
       [not found] ` <20070213221830.707197267@goop.org>
@ 2007-02-13 23:54   ` Andi Kleen
  2007-02-14  0:39     ` Jeremy Fitzhardinge
  2007-02-14 18:53     ` Jeremy Fitzhardinge
  2007-02-14 20:33   ` Eric W. Biederman
  1 sibling, 2 replies; 45+ messages in thread
From: Andi Kleen @ 2007-02-13 23:54 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, linux-kernel, virtualization, xen-devel,
	Chris Wright, Zachary Amsden

> --- a/arch/i386/kernel/entry.S
> +++ b/arch/i386/kernel/entry.S
> @@ -1001,6 +1001,83 @@ ENTRY(kernel_thread_helper)
>  	CFI_ENDPROC
>  ENDPROC(kernel_thread_helper)
>  
> +#ifdef CONFIG_XEN
> +/* Xen only supports sysenter/sysexit in ring0 guests,
> +   and only if it the guest asks for it.  So for now,
> +   this should never be used. */
> +ENTRY(xen_sti_sysexit)
> +	CFI_STARTPROC
> +	ud2
> +	CFI_ENDPROC

Please add ENDPROC()s too, otherwise Jan will be unhappy.

Could be written in C with a real BUG? 

> +ENTRY(xen_failsafe_callback)
> +	CFI_STARTPROC
> +	pushl %eax
> +	CFI_ADJUST_CFA_OFFSET 4
> +	movl $1,%eax
> +1:	mov 4(%esp),%ds
> +2:	mov 8(%esp),%es
> +3:	mov 12(%esp),%fs
> +4:	mov 16(%esp),%gs
> +	testl %eax,%eax
> +	popl %eax
> +	CFI_ADJUST_CFA_OFFSET -4
> +	jz 5f
> +	addl $16,%esp		# EAX != 0 => Category 2 (Bad IRET)
> +	CFI_ADJUST_CFA_OFFSET -16
> +	jmp iret_exc
> +5:	addl $16,%esp		# EAX == 0 => Category 1 (Bad segment)

If you use lea you could move the two adds before the jz

> +#ifdef CONFIG_XEN
> +#include "../xen/xen-head.S"
> +#endif

Can this really not be linked separately? 

> +	
>  /*
>   * Real beginning of normal "text" segment
>   */
> @@ -528,7 +532,7 @@ ENTRY(_stext)
>  /*
>   * BSS section
>   */
> -.section ".bss.page_aligned","w"
> +.section ".bss.page_aligned"

Why? 

> -static fastcall void native_clts(void)
> +fastcall void native_clts(void)

Fastcalls should all go now

> --- a/arch/i386/kernel/vmlinux.lds.S
> +++ b/arch/i386/kernel/vmlinux.lds.S
> @@ -93,6 +93,7 @@ SECTIONS
>  
>    . = ALIGN(4096);
>    .data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
> +	*(.data.page_aligned)

Weird that that didn't work before -- we already had page aligned data
and it somehow managed to work. But ok.

>  	*(.data.idt)
>    }
>  
> ===================================================================
> --- a/arch/i386/mm/pgtable.c
> +++ b/arch/i386/mm/pgtable.c
> @@ -267,6 +267,7 @@ static void pgd_ctor(pgd_t *pgd)
>  					swapper_pg_dir + USER_PTRS_PER_PGD,
>  					KERNEL_PGD_PTRS);
>  		} else {
> +			memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));

That looks strange here. Belongs in a different patch? 

> +
> +extern struct Xgt_desc_struct cpu_gdt_descr;
> +extern struct i386_pda boot_pda;
> +extern unsigned long init_pg_tables_end;

No externs in .c files

> +
> +static DEFINE_PER_CPU(unsigned, lazy_mode);
> +
> +/* Code defined in entry.S (not a function) */
> +extern const char xen_sti_sysexit[];

Ok except that

> +{
> +	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
> +	       paravirt_ops.name);

Say something about Xen here?

> +}
> +
> +static fastcall void xen_restore_fl(unsigned long flags)
> +{
> +	struct vcpu_info *vcpu;
> +
> +	preempt_disable();
> +
> +	/* convert from IF type flag */
> +	flags = !(flags & X86_EFLAGS_IF);
> +	vcpu = read_pda(xen.vcpu);
> +	vcpu->evtchn_upcall_mask = flags;
> +	if (flags == 0) {
> +		barrier(); /* unmask then check (avoid races) */

If the barrier is needed shouldn't it be a rmb() ? 

> +	vcpu = read_pda(xen.vcpu);
> +	vcpu->evtchn_upcall_mask = 0;
> +	barrier(); /* unmask then check (avoid races) */

Similar.

> +static fastcall void xen_load_gdt(const struct Xgt_desc_struct *dtr)
> +{
> +        unsigned long va;
> +        int f;
> +	unsigned size = dtr->size + 1;
> +	unsigned long frames[16];
> +
> +	BUG_ON(size > 16*PAGE_SIZE);
> +

Indentation broken

(more occurences in this file) 
> +	type = (high >> 8) & 0x1f;
> +	dpl = (high >> 13) & 3;
> +
> +	if (type != 0xf && type != 0xe)
> +		return 0;
> +
> +	info->vector = vector;
> +	info->address = (high & 0xffff0000) | (low & 0x0000ffff);
> +	info->cs = low >> 16;
> +	info->flags = dpl;
> +	/* interrupt gates clear IF */
> +	if (type == 0xe)
> +		info->flags |= 4;

Nasty magic numbers? 

> +	return 1;
> +}
> +
> +#if 0
> +static void unpack_desc(u32 low, u32 high,
> +			unsigned long *base, unsigned long *limit,
> +			unsigned char *type, unsigned char *flags)
> +{
> +	*base = (high & 0xff000000) | ((high << 16) & 0x00ff0000) | ((low >> 16) & 0xffff);
> +	*limit = (high & 0x000f0000) | (low & 0xffff);
> +	*type = (high >> 8) & 0xff;
> +	*flags = (high >> 20) & 0xf;
> +}
> +#endif

Remove? 

> +
> +/* Locations of each CPU's IDT */
> +static DEFINE_PER_CPU(struct Xgt_desc_struct, idt_desc);

Why is that private here? 

> +	/* Switch to new pagetable.  This is done before
> +	   pagetable_init has done anything so that the new pages
> +	   added to the table can be prepared properly for Xen.  */
> +	printk("about to switch to new pagetable %p...\n", base);
> +	xen_write_cr3(__pa(base));
> +	printk("done\n");

KERN_* ?

> +	if (HYPERVISOR_update_descriptor(virt_to_machine(cpu_gdt_table +
> +							 GDT_ENTRY_PDA).maddr,
> +					 (u64)high << 32 | low))
> +		BUG();

Does a BUG that early actually do anything good?

> +
> +/*
> + * Accessors for packed IRQ information.
> + */

Wouldn't it be a little simpler to just use a bit field? 

> +static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> +{
> +	int irq = evtchn_to_irq[chn];
> +
> +	BUG_ON(irq == -1);
> +	set_native_irq_info(irq, cpumask_of_cpu(cpu));
> +
> +	__clear_bit(chn, (unsigned long *)cpu_evtchn_mask[cpu_evtchn[chn]]);

Why is the mask not unsigned long in the first place ?

> +  level is a bitset of pending events themselves.
> +*/
> +asmlinkage fastcall void xen_evtchn_do_upcall(struct pt_regs *regs)
> +{
> +	int cpu = smp_processor_id();

Doesn't a preemptive kernel complain about this?

> +	set_64bit((u64 *)ptep, pte_val_ma(pte));
> +}
> +
> +void fastcall xen_pte_clear(struct mm_struct *mm, u32 addr,pte_t *ptep)
> +{
> +#if 1
> +	ptep->pte_low = 0;
> +	smp_wmb();
> +	ptep->pte_high = 0;	
> +#else
> +	set_64bit((u64 *)ptep, 0);

Eliminate #if please

> +fastcall unsigned long long xen_pgd_val(pgd_t pgd)
> +{
> +	unsigned long long ret = pgd.pgd;
> +	if (ret)
> +		ret = machine_to_phys(XMADDR(ret)).paddr | 1;

Why can they be 0 here anyways?

Normally they are all considered undefined when not present

> +	rdtscll(now);
> +	delta = now - shadow->tsc_timestamp;
> +	return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow->tsc_shift);
> +}
> +
> +
> +static void xen_timer_interrupt_hook(void)

Timer code ... hopefully dyntick will not all mess this up. It is scheduled
to go into mainline RSN. You might have to do some more merging.
> +
> +char * __init xen_memory_setup(void);

Prototypes don't need __init

> +void __init xen_arch_setup(void);
> +void __init xen_init_IRQ(void);
> +
> @@ -53,6 +54,7 @@ struct paravirt_ops
>  	void (*arch_setup)(void);
>  	char *(*memory_setup)(void);
>  	void (*init_IRQ)(void);
> +	void (*init_pda)(struct i386_pda *, int cpu);

Hmm weird. For what was that needed again? 

-AndI

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
  2007-02-13 23:29     ` Jeremy Fitzhardinge
@ 2007-02-13 23:58       ` Zachary Amsden
  2007-02-13 23:58       ` Dan Hecht
  1 sibling, 0 replies; 45+ messages in thread
From: Zachary Amsden @ 2007-02-13 23:58 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Dan Hecht, Andrew Morton, xen-devel, Ian Pratt, linux-kernel,
	Chris Wright, Andi Kleen, virtualization

Jeremy Fitzhardinge wrote:
> Dan Hecht wrote:
>   
>> I assume you plan to eventually get all this stuff working but just
>> want to prevent configurations that the Xen paravirt-ops isn't ready
>> for at the moment?
>>
>> Instead can you do it this way:
>>
>> config XEN
>>     depends on PARAVIRT && !PREEMPT && HZ_100 && !DOUBLEFAULT && !KEXEC
>>     
>
> That's a bit simpler code-wise, but it does make it pretty complex to
> get everything just-so to even see the CONFIG_XEN option.
>   

Yes, but that is what you need to do to compile Xen - logically, to 
build a Xen kernel, you need to have a kernel configuration which can 
enable Xen - not limit the configuration of a kernel because Xen has 
been enabled.  This is because  with paravirt-ops, Xen compiled kernels 
may not actually run on Xen, so you can't arbitrarily drop features 
because you assume Xen is there.

One of these has an easy solution - doublefault.  You don't need to 
install the doublefault gate if you don't want it, and the hypervisor 
doesn't need to freak out if you install it, it can just ignore the gate 
entirely and claim #DF is not supported.

Zach

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
  2007-02-13 23:29     ` Jeremy Fitzhardinge
  2007-02-13 23:58       ` [Xen-devel] " Zachary Amsden
@ 2007-02-13 23:58       ` Dan Hecht
  1 sibling, 0 replies; 45+ messages in thread
From: Dan Hecht @ 2007-02-13 23:58 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, Ian Pratt, linux-kernel

On 02/13/2007 03:29 PM, Jeremy Fitzhardinge wrote:
> Dan Hecht wrote:
>> I assume you plan to eventually get all this stuff working but just
>> want to prevent configurations that the Xen paravirt-ops isn't ready
>> for at the moment?
>>
>> Instead can you do it this way:
>>
>> config XEN
>>     depends on PARAVIRT && !PREEMPT && HZ_100 && !DOUBLEFAULT && !KEXEC
> 
> That's a bit simpler code-wise, but it does make it pretty complex to
> get everything just-so to even see the CONFIG_XEN option.
> 

Not only is it simpler code-wise, but it is more to the point... it is 
CONFIG_XEN that needs to be fixed to handle PREEMPT, KEXEC, different HZ 
values, etc.  Not the other way around.

Enabling the compile of any paravirt-ops backend shouldn't cripple the 
kernel in any way... instead, the burden should be on the xen 
paravirt-ops backend to be completed.  CONFIG_PREEMPT shouldn't care 
about which paravirt-ops are compiled in.  Instead, CONFIG_XEN is the 
one that needs !PREEMPT.

Dan

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-13 23:54   ` [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen Andi Kleen
@ 2007-02-14  0:39     ` Jeremy Fitzhardinge
  2007-02-14  8:56       ` [Xen-devel] " Jan Beulich
  2007-02-14 18:53     ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14  0:39 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, linux-kernel, virtualization, xen-devel,
	Chris Wright, Zachary Amsden

Andi Kleen wrote:
>> --- a/arch/i386/kernel/entry.S
>> +++ b/arch/i386/kernel/entry.S
>> @@ -1001,6 +1001,83 @@ ENTRY(kernel_thread_helper)
>>  	CFI_ENDPROC
>>  ENDPROC(kernel_thread_helper)
>>  
>> +#ifdef CONFIG_XEN
>> +/* Xen only supports sysenter/sysexit in ring0 guests,
>> +   and only if it the guest asks for it.  So for now,
>> +   this should never be used. */
>> +ENTRY(xen_sti_sysexit)
>> +	CFI_STARTPROC
>> +	ud2
>> +	CFI_ENDPROC
>>     
>
> Please add ENDPROC()s too, otherwise Jan will be unhappy.
>   

Will do.

> Could be written in C with a real BUG? 
>   

I guess, but this seems simpler.  It could be removed altogether, but it
would be nice to make sure it never happens.

>> +ENTRY(xen_failsafe_callback)
>> +	CFI_STARTPROC
>> +	pushl %eax
>> +	CFI_ADJUST_CFA_OFFSET 4
>> +	movl $1,%eax
>> +1:	mov 4(%esp),%ds
>> +2:	mov 8(%esp),%es
>> +3:	mov 12(%esp),%fs
>> +4:	mov 16(%esp),%gs
>> +	testl %eax,%eax
>> +	popl %eax
>> +	CFI_ADJUST_CFA_OFFSET -4
>> +	jz 5f
>> +	addl $16,%esp		# EAX != 0 => Category 2 (Bad IRET)
>> +	CFI_ADJUST_CFA_OFFSET -16
>> +	jmp iret_exc
>> +5:	addl $16,%esp		# EAX == 0 => Category 1 (Bad segment)
>>     
>
> If you use lea you could move the two adds before the jz
>   

Yep.

>> +#ifdef CONFIG_XEN
>> +#include "../xen/xen-head.S"
>> +#endif
>>     
>
> Can this really not be linked separately? 
>   
xen-head.S jumps back to startup_paravirt.  That could be exported, and
then it could be linked separately.  There used to be a requirement that
the code in xen-head.S be at a compile-time known address, but that's no
longer the case.

>> +	
>>  /*
>>   * Real beginning of normal "text" segment
>>   */
>> @@ -528,7 +532,7 @@ ENTRY(_stext)
>>  /*
>>   * BSS section
>>   */
>> -.section ".bss.page_aligned","w"
>> +.section ".bss.page_aligned"
>>     
>
> Why? 
>   

I got complaints about section attribute mismatches without it.

>> -static fastcall void native_clts(void)
>> +fastcall void native_clts(void)
>>     
>
> Fastcalls should all go now
>   

Killing them here as we speak.

>> --- a/arch/i386/kernel/vmlinux.lds.S
>> +++ b/arch/i386/kernel/vmlinux.lds.S
>> @@ -93,6 +93,7 @@ SECTIONS
>>  
>>    . = ALIGN(4096);
>>    .data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
>> +	*(.data.page_aligned)
>>     
>
> Weird that that didn't work before -- we already had page aligned data
> and it somehow managed to work. But ok.
>
>   
>>  	*(.data.idt)
>>    }
>>  
>> ===================================================================
>> --- a/arch/i386/mm/pgtable.c
>> +++ b/arch/i386/mm/pgtable.c
>> @@ -267,6 +267,7 @@ static void pgd_ctor(pgd_t *pgd)
>>  					swapper_pg_dir + USER_PTRS_PER_PGD,
>>  					KERNEL_PGD_PTRS);
>>  		} else {
>> +			memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));
>>     
>
> That looks strange here. Belongs in a different patch? 
>   

This is a big rollup patch of all the core Xen stuff; the subject is
wrong.  But I added this for Xen because it needs to make sure the page
is all zero and doesn't have some left-over pieces of old pagetable.

>> +
>> +extern struct Xgt_desc_struct cpu_gdt_descr;
>> +extern struct i386_pda boot_pda;
>> +extern unsigned long init_pg_tables_end;
>>     
>
> No externs in .c files
>   

OK.

>> +
>> +static DEFINE_PER_CPU(unsigned, lazy_mode);
>> +
>> +/* Code defined in entry.S (not a function) */
>> +extern const char xen_sti_sysexit[];
>>     
>
> Ok except that
>
>   
>> +{
>> +	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
>> +	       paravirt_ops.name);
>>     
>
> Say something about Xen here?
>   

paravirt_ops.name mentions Xen.

>> +}
>> +
>> +static fastcall void xen_restore_fl(unsigned long flags)
>> +{
>> +	struct vcpu_info *vcpu;
>> +
>> +	preempt_disable();
>> +
>> +	/* convert from IF type flag */
>> +	flags = !(flags & X86_EFLAGS_IF);
>> +	vcpu = read_pda(xen.vcpu);
>> +	vcpu->evtchn_upcall_mask = flags;
>> +	if (flags == 0) {
>> +		barrier(); /* unmask then check (avoid races) */
>>     
>
> If the barrier is needed shouldn't it be a rmb() ? 
>
>   
>> +	vcpu = read_pda(xen.vcpu);
>> +	vcpu->evtchn_upcall_mask = 0;
>> +	barrier(); /* unmask then check (avoid races) */
>>     
>
> Similar.
>   

Erm, not sure.  The write needs to be complete before the read happens. 
Which is the right barrier for that?

>> +static fastcall void xen_load_gdt(const struct Xgt_desc_struct *dtr)
>> +{
>> +        unsigned long va;
>> +        int f;
>> +	unsigned size = dtr->size + 1;
>> +	unsigned long frames[16];
>> +
>> +	BUG_ON(size > 16*PAGE_SIZE);
>> +
>>     
>
> Indentation broken
>
> (more occurences in this file) 
>   

OK.

>> +	type = (high >> 8) & 0x1f;
>> +	dpl = (high >> 13) & 3;
>> +
>> +	if (type != 0xf && type != 0xe)
>> +		return 0;
>> +
>> +	info->vector = vector;
>> +	info->address = (high & 0xffff0000) | (low & 0x0000ffff);
>> +	info->cs = low >> 16;
>> +	info->flags = dpl;
>> +	/* interrupt gates clear IF */
>> +	if (type == 0xe)
>> +		info->flags |= 4;
>>     
>
> Nasty magic numbers? 
>   

Yeah.  Are there any existing definitions of the x86 gate types?

>> +	return 1;
>> +}
>> +
>> +#if 0
>> +static void unpack_desc(u32 low, u32 high,
>> +			unsigned long *base, unsigned long *limit,
>> +			unsigned char *type, unsigned char *flags)
>> +{
>> +	*base = (high & 0xff000000) | ((high << 16) & 0x00ff0000) | ((low >> 16) & 0xffff);
>> +	*limit = (high & 0x000f0000) | (low & 0xffff);
>> +	*type = (high >> 8) & 0xff;
>> +	*flags = (high >> 20) & 0xf;
>> +}
>> +#endif
>>     
>
> Remove? 
>   

Yep.

>> +
>> +/* Locations of each CPU's IDT */
>> +static DEFINE_PER_CPU(struct Xgt_desc_struct, idt_desc);
>>     
>
> Why is that private here? 
>   

It's a local per-cpu cache of the idt as set by the kernel.  Xen doesn't
use the idt directly, but it remembers what idt has been set so it can
tell if an idt descriptor update is affecting the current idt or
something else.  Its a bit over-engineered, since the idt isn't really
touched much at all.

>> +	/* Switch to new pagetable.  This is done before
>> +	   pagetable_init has done anything so that the new pages
>> +	   added to the table can be prepared properly for Xen.  */
>> +	printk("about to switch to new pagetable %p...\n", base);
>> +	xen_write_cr3(__pa(base));
>> +	printk("done\n");
>>     
>
> KERN_* ?
>   

Delete.  Don't really need it any more.

>> +	if (HYPERVISOR_update_descriptor(virt_to_machine(cpu_gdt_table +
>> +							 GDT_ENTRY_PDA).maddr,
>> +					 (u64)high << 32 | low))
>> +		BUG();
>>     
>
> Does a BUG that early actually do anything good?
>   

Under Xen, an early BUG gets a nice register dump and backtrack from the
hypervisor, so its pretty useful for debugging.

>> +
>> +/*
>> + * Accessors for packed IRQ information.
>> + */
>>     
>
> Wouldn't it be a little simpler to just use a bit field? 
>   

Yeah, or even just a simple structure, since the elements are
short/byte/byte.

>> +static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>> +{
>> +	int irq = evtchn_to_irq[chn];
>> +
>> +	BUG_ON(irq == -1);
>> +	set_native_irq_info(irq, cpumask_of_cpu(cpu));
>> +
>> +	__clear_bit(chn, (unsigned long *)cpu_evtchn_mask[cpu_evtchn[chn]]);
>>     
>
> Why is the mask not unsigned long in the first place ?
>   

Hm, it was.  Seems completely redundant.

>> +  level is a bitset of pending events themselves.
>> +*/
>> +asmlinkage fastcall void xen_evtchn_do_upcall(struct pt_regs *regs)
>> +{
>> +	int cpu = smp_processor_id();
>>     
>
> Doesn't a preemptive kernel complain about this?
>   

Xen doesn't support preempt.

>> +	set_64bit((u64 *)ptep, pte_val_ma(pte));
>> +}
>> +
>> +void fastcall xen_pte_clear(struct mm_struct *mm, u32 addr,pte_t *ptep)
>> +{
>> +#if 1
>> +	ptep->pte_low = 0;
>> +	smp_wmb();
>> +	ptep->pte_high = 0;	
>> +#else
>> +	set_64bit((u64 *)ptep, 0);
>>     
>
> Eliminate #if please
>   

I need to test this a bit.  This is here because set_64bit doesn't work
properly under qemu (its emulation mis-reports the eip if the
instruction faults), but I haven't tested this under native.

>> +fastcall unsigned long long xen_pgd_val(pgd_t pgd)
>> +{
>> +	unsigned long long ret = pgd.pgd;
>> +	if (ret)
>> +		ret = machine_to_phys(XMADDR(ret)).paddr | 1;
>>     
>
> Why can they be 0 here anyways?
>
> Normally they are all considered undefined when not present
>   

Not sure.

>> +	rdtscll(now);
>> +	delta = now - shadow->tsc_timestamp;
>> +	return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow->tsc_shift);
>> +}
>> +
>> +
>> +static void xen_timer_interrupt_hook(void)
>>     
>
> Timer code ... hopefully dyntick will not all mess this up. It is scheduled
> to go into mainline RSN. You might have to do some more merging.
>   

Yep.

>> +
>> +char * __init xen_memory_setup(void);
>>     
>
> Prototypes don't need __init
>   

OK.

>> +void __init xen_arch_setup(void);
>> +void __init xen_init_IRQ(void);
>> +
>> @@ -53,6 +54,7 @@ struct paravirt_ops
>>  	void (*arch_setup)(void);
>>  	char *(*memory_setup)(void);
>>  	void (*init_IRQ)(void);
>> +	void (*init_pda)(struct i386_pda *, int cpu);
>>     
>
> Hmm weird. For what was that needed again? 
>   

The PDA structure contains some Xen-specific (or generally, paravirt
backend specific) parts, which need initialization when the rest of the
PDA is.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
       [not found] ` <20070213221830.238235953@goop.org>
@ 2007-02-14  1:06   ` Zachary Amsden
  2007-02-14  1:16     ` Jeremy Fitzhardinge
                       ` (2 more replies)
  0 siblings, 3 replies; 45+ messages in thread
From: Zachary Amsden @ 2007-02-14  1:06 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Rusty Russell

Jeremy Fitzhardinge wrote:
> Wrap the paravirt_ops members we want to export in wrapper functions.
> Since we binary-patch the critical ones, this doesn't make a speed
> impact.
>
> I moved drm_follow_page into the core, to avoid having to wrap the
> various pte ops.  Unlining kernel_fpu_end and using that in the RAID6
> code would remove the need to export clts/read_cr0/write_cr0 too.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
>
> ===================================================================
> --- a/arch/i386/kernel/paravirt.c
> +++ b/arch/i386/kernel/paravirt.c
> @@ -596,6 +596,123 @@ static int __init print_banner(void)
>  	return 0;
>  }
>  core_initcall(print_banner);
> +
> +unsigned long paravirt_save_flags(void)
> +{
> +	return paravirt_ops.save_fl();
> +}
> +EXPORT_SYMBOL(paravirt_save_flags);
> +
> +void paravirt_restore_flags(unsigned long flags)
> +{
> +	paravirt_ops.restore_fl(flags);
> +}
> +EXPORT_SYMBOL(paravirt_restore_flags);
> +
> +void paravirt_irq_disable(void)
> +{
> +	paravirt_ops.irq_disable();
> +}
> +EXPORT_SYMBOL(paravirt_irq_disable);
> +
> +void paravirt_irq_enable(void)
> +{
> +	paravirt_ops.irq_enable();
> +}
> +EXPORT_SYMBOL(paravirt_irq_enable);
>   

This turned out really hideous looking to me.  Can't we split the struct 
into GPL'd and non-GPL'd functions instead?  We still have the same 
granularity, and none of this function call to an indirect function call 
nonsense.

Zach

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:06   ` [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions Zachary Amsden
@ 2007-02-14  1:16     ` Jeremy Fitzhardinge
  2007-02-14  1:18       ` Zachary Amsden
  2007-02-14  5:51     ` Rusty Russell
  2007-02-14 19:36     ` Christoph Hellwig
  2 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14  1:16 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Rusty Russell

Zachary Amsden wrote:
> This turned out really hideous looking to me.  Can't we split the
> struct into GPL'd and non-GPL'd functions instead?  We still have the
> same granularity, and none of this function call to an indirect
> function call nonsense. 

It's not pretty, but I think having paravirt_ops and paravirt_ops_gpl
would be worse.  I'd be sympathetic to the idea of splitting
paravirt_ops up by function groupings, but splitting it by license seems
like a maintenance headache with no real upside.  Besides, patching will
solve everything (tm).

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:16     ` Jeremy Fitzhardinge
@ 2007-02-14  1:18       ` Zachary Amsden
  2007-02-14  1:37         ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Zachary Amsden @ 2007-02-14  1:18 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Rusty Russell

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>   
>> This turned out really hideous looking to me.  Can't we split the
>> struct into GPL'd and non-GPL'd functions instead?  We still have the
>> same granularity, and none of this function call to an indirect
>> function call nonsense. 
>>     
>
> It's not pretty, but I think having paravirt_ops and paravirt_ops_gpl
> would be worse.  I'd be sympathetic to the idea of splitting
> paravirt_ops up by function groupings, but splitting it by license seems
> like a maintenance headache with no real upside.  Besides, patching will
> solve everything (tm).
>   

Ok.  As long as we plan on patching CR2 and CR0 / clts accessors for FPU 
save during context switch and page fault paths in the future.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
       [not found] ` <20070213221829.845132535@goop.org>
@ 2007-02-14  1:23   ` Dan Hecht
  2007-02-14  1:36     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Dan Hecht @ 2007-02-14  1:23 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, linux-kernel

On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
> Allocate a fixmap slot for use by a paravirt_ops implementation.  Xen
> uses this to map the hypervisor's shared info page, which doesn't have
> a pseudo-physical page number, and therefore can't be mapped
> ordinarily.
> 

Why doesn't Xen allocate the shared_info page from the pseudo-physical 
space?  Doesn't it already have to steal pages from the pseudo-physical 
space for e.g. initial page tables, console, etc?  Why not do the same 
for shared_info, and then you don't need a reserve the fixmap slot.

Dan

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
  2007-02-14  1:23   ` [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot Dan Hecht
@ 2007-02-14  1:36     ` Jeremy Fitzhardinge
  2007-02-14  2:34       ` Dan Hecht
  2007-02-14  8:37       ` [Xen-devel] " Jan Beulich
  0 siblings, 2 replies; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14  1:36 UTC (permalink / raw)
  To: Dan Hecht
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, linux-kernel

Dan Hecht wrote:
> Why doesn't Xen allocate the shared_info page from the pseudo-physical
> space?  Doesn't it already have to steal pages from the
> pseudo-physical space for e.g. initial page tables, console, etc?  Why
> not do the same for shared_info, and then you don't need a reserve the
> fixmap slot.

Unlike the pagetable pages or the console page, the shared info page
doesn't have a pseudo-physical address, so in order to map it we need to
directly construct a pte containing the mfn for that page.  Inserting
this mapping into the fixmap space seems like the easiest way to do
this.  It's not like a fixmap slot costs anything.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:18       ` Zachary Amsden
@ 2007-02-14  1:37         ` Jeremy Fitzhardinge
  2007-02-14  1:43           ` Zachary Amsden
  0 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14  1:37 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Rusty Russell

Zachary Amsden wrote:
> Ok.  As long as we plan on patching CR2 and CR0 / clts accessors for
> FPU save during context switch and page fault paths in the future.

That's up to each backend, right?  Or do these need to be patched for a
correctness reason?

    J


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:37         ` Jeremy Fitzhardinge
@ 2007-02-14  1:43           ` Zachary Amsden
  2007-02-14  1:44             ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Zachary Amsden @ 2007-02-14  1:43 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Rusty Russell

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>   
>> Ok.  As long as we plan on patching CR2 and CR0 / clts accessors for
>> FPU save during context switch and page fault paths in the future.
>>     
>
> That's up to each backend, right?  Or do these need to be patched for a
> correctness reason?
>   

No, it needs to be part of the general patch list first, which is still 
hand listed rather than just any op being patchable.  Then it can be up 
to the backend.

Zach

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:43           ` Zachary Amsden
@ 2007-02-14  1:44             ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14  1:44 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Rusty Russell

Zachary Amsden wrote:
> No, it needs to be part of the general patch list first, which is
> still hand listed rather than just any op being patchable.  Then it
> can be up to the backend. 

Ah, right, yes.  We need to add all (most? some?) of the pte operations
to that list too.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
  2007-02-14  1:36     ` Jeremy Fitzhardinge
@ 2007-02-14  2:34       ` Dan Hecht
  2007-02-14  8:43         ` Gerd Hoffmann
  2007-02-14  8:37       ` [Xen-devel] " Jan Beulich
  1 sibling, 1 reply; 45+ messages in thread
From: Dan Hecht @ 2007-02-14  2:34 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, linux-kernel

On 02/13/2007 05:36 PM, Jeremy Fitzhardinge wrote:
> Dan Hecht wrote:
>> Why doesn't Xen allocate the shared_info page from the pseudo-physical
>> space?  Doesn't it already have to steal pages from the
>> pseudo-physical space for e.g. initial page tables, console, etc?  Why
>> not do the same for shared_info, and then you don't need a reserve the
>> fixmap slot.
> 
> Unlike the pagetable pages or the console page, the shared info page
> doesn't have a pseudo-physical address, so in order to map it we need to
> directly construct a pte containing the mfn for that page. 

Right.  But that is only because Xen decides to allocate the page from 
the (machine) physical space, rather than from the pseudo-physical 
space.  My question is: why doesn't Xen allocate shared_info from the 
pseudo-physical space?  If it had, then this page wouldn't need to be 
treated specially.  I'm not sure, but I seem to remember on 64-bit 
Xen/XenLinux allocated shared_info from pseudo-physical space already...

  Inserting
> this mapping into the fixmap space seems like the easiest way to do
> this.  It's not like a fixmap slot costs anything.
> 
>

I don't really have an objection to stealing a fixmap slot, just seems 
cleaner if you didn't have to special case the shared_info.

Dan

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [Xen-devel] Re: [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes
  2007-02-13 22:45   ` [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes Zachary Amsden
  2007-02-13 22:49     ` Jeremy Fitzhardinge
@ 2007-02-14  5:38     ` Rusty Russell
  1 sibling, 0 replies; 45+ messages in thread
From: Rusty Russell @ 2007-02-14  5:38 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Jeremy Fitzhardinge, Andrew Morton, xen-devel, Ian Pratt,
	virtualization, linux-kernel, Chris Wright, Andi Kleen,
	Christian Limpach

On Tue, 2007-02-13 at 14:45 -0800, Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
> > Add the "nosegneg" fake capabilty to the vsyscall page notes. This is
> > used by the runtime linker to select a glibc version which then
> > disables negative-offset accesses to the thread-local segment via
> > %gs. These accesses require emulation in Xen (because segments are
> > truncated to protect the hypervisor address space) and avoiding them
> > provides a measurable performance boost.
> >   
> 
> I don't like this because now a kernel compiled with both CONFIG_XEN and 
> CONFIG_VMI has "nosegneg" turned on.  We don't actually require this for 
> performance or correctness, so it would be nice to be able to 
> dynamically turn it off instead of having it forced.

Ditto for lguest.

Rusty.



^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:06   ` [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions Zachary Amsden
  2007-02-14  1:16     ` Jeremy Fitzhardinge
@ 2007-02-14  5:51     ` Rusty Russell
  2007-02-14 19:36     ` Christoph Hellwig
  2 siblings, 0 replies; 45+ messages in thread
From: Rusty Russell @ 2007-02-14  5:51 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Jeremy Fitzhardinge, Andi Kleen, Andrew Morton, linux-kernel,
	virtualization, xen-devel, Chris Wright

On Tue, 2007-02-13 at 17:06 -0800, Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
> > Wrap the paravirt_ops members we want to export in wrapper functions.
> > Since we binary-patch the critical ones, this doesn't make a speed
> > impact.
> 
> This turned out really hideous looking to me.  Can't we split the struct 
> into GPL'd and non-GPL'd functions instead?  We still have the same 
> granularity, and none of this function call to an indirect function call 
> nonsense.

This patch, indeed, should not have been pushed in this series.  But not
for that reason: I actually prefer explicit exports.

KVM and lguest need more symbols, so the real patch will make them use
native_XXX versions explicitly...

Cheers,
Rusty.



^ permalink raw reply	[flat|nested] 45+ messages in thread

* [Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
  2007-02-14  1:36     ` Jeremy Fitzhardinge
  2007-02-14  2:34       ` Dan Hecht
@ 2007-02-14  8:37       ` Jan Beulich
  2007-02-14  9:15         ` Andi Kleen
  1 sibling, 1 reply; 45+ messages in thread
From: Jan Beulich @ 2007-02-14  8:37 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: virtualization, xen-devel, Andi Kleen, Andrew Morton,
	Chris Wright, linux-kernel, Dan Hecht

>>> Jeremy Fitzhardinge <jeremy@goop.org> 14.02.07 02:36 >>>
>Dan Hecht wrote:
>> Why doesn't Xen allocate the shared_info page from the pseudo-physical
>> space?  Doesn't it already have to steal pages from the
>> pseudo-physical space for e.g. initial page tables, console, etc?  Why
>> not do the same for shared_info, and then you don't need a reserve the
>> fixmap slot.
>
>Unlike the pagetable pages or the console page, the shared info page
>doesn't have a pseudo-physical address, so in order to map it we need to
>directly construct a pte containing the mfn for that page.  Inserting
>this mapping into the fixmap space seems like the easiest way to do
>this.  It's not like a fixmap slot costs anything.

Otoh there are many fixmap slots not used under Xen, perhaps it would
be possible to use one of those... One slot certainly doesn't cost a lot,
but many (like the IO-APIC group) may already matter, especially on
PAE systems with lots of memory). Consequently, if these can't be
squeezed out as needed, re-using would seem more appropriate than
adding.
(I would certainly favor [conditionally] removing them, but can't easily
see how to do this under CONFIG_PARAVIRT. Background being that
we've already been hit by those [namely the LAPIC one] remaining
present, hence the build not being able to detect that accesses to the
LAPIC page can't work. While no such access was ever left in the base
kernel, modules are more susceptible to this, and in our case it was
the [native, i.e. pre-xenoprof] oprofile driver that had been forgotten
to be disabled.)

Jan

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
  2007-02-14  2:34       ` Dan Hecht
@ 2007-02-14  8:43         ` Gerd Hoffmann
  0 siblings, 0 replies; 45+ messages in thread
From: Gerd Hoffmann @ 2007-02-14  8:43 UTC (permalink / raw)
  To: Dan Hecht
  Cc: Jeremy Fitzhardinge, Andrew Morton, Andi Kleen, xen-devel,
	Chris Wright, virtualization, linux-kernel

Dan Hecht wrote:
> Right.  But that is only because Xen decides to allocate the page from 
> the (machine) physical space, rather than from the pseudo-physical 
> space.  My question is: why doesn't Xen allocate shared_info from the 
> pseudo-physical space?

Historical reasons ...

> If it had, then this page wouldn't need to be 
> treated specially.  I'm not sure, but I seem to remember on 64-bit 
> Xen/XenLinux allocated shared_info from pseudo-physical space already...

Yep, the ia64 port which came later handles some things differently,
specifically some "magic" pages are allocated more clever ;)

Changing that for x86 would break existing guests though.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* [Xen-devel] Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-14  0:39     ` Jeremy Fitzhardinge
@ 2007-02-14  8:56       ` Jan Beulich
  0 siblings, 0 replies; 45+ messages in thread
From: Jan Beulich @ 2007-02-14  8:56 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: virtualization, xen-devel, Andi Kleen, Andrew Morton,
	Chris Wright, linux-kernel, Zachary Amsden

>>> @@ -528,7 +532,7 @@ ENTRY(_stext)
>>>  /*
>>>   * BSS section
>>>   */
>>> -.section ".bss.page_aligned","w"
>>> +.section ".bss.page_aligned"
>>>     
>>
>> Why? 
>>   
>
>I got complaints about section attribute mismatches without it.

Then perhaps ... "aw" is meant?

>>> +fastcall unsigned long long xen_pgd_val(pgd_t pgd)
>>> +{
>>> +	unsigned long long ret = pgd.pgd;
>>> +	if (ret)
>>> +		ret = machine_to_phys(XMADDR(ret)).paddr | 1;
>>>     
>>
>> Why can they be 0 here anyways?
>>
>> Normally they are all considered undefined when not present
>>   
>
>Not sure.

This should probably get sync-ed up with the page table handling changes
submitted to xen-devel yesterday. Using zero/non-zero tests in contexts
like this was always broken; should check for _PAGE_PRESENT.

Jan

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
  2007-02-14  8:37       ` [Xen-devel] " Jan Beulich
@ 2007-02-14  9:15         ` Andi Kleen
  0 siblings, 0 replies; 45+ messages in thread
From: Andi Kleen @ 2007-02-14  9:15 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Jeremy Fitzhardinge, virtualization, xen-devel, Andrew Morton,
	Chris Wright, linux-kernel, Dan Hecht

On Wed, Feb 14, 2007 at 08:37:26AM +0000, Jan Beulich wrote:
> >>> Jeremy Fitzhardinge <jeremy@goop.org> 14.02.07 02:36 >>>
> >Dan Hecht wrote:
> >> Why doesn't Xen allocate the shared_info page from the pseudo-physical
> >> space?  Doesn't it already have to steal pages from the
> >> pseudo-physical space for e.g. initial page tables, console, etc?  Why
> >> not do the same for shared_info, and then you don't need a reserve the
> >> fixmap slot.
> >
> >Unlike the pagetable pages or the console page, the shared info page
> >doesn't have a pseudo-physical address, so in order to map it we need to
> >directly construct a pte containing the mfn for that page.  Inserting
> >this mapping into the fixmap space seems like the easiest way to do
> >this.  It's not like a fixmap slot costs anything.
> 
> Otoh there are many fixmap slots not used under Xen, perhaps it would
> be possible to use one of those... One slot certainly doesn't cost a lot,

I don't have a problem with reserving one page for this.

-Andi

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 02/21] Xen-paravirt: Handle a zero-sized VT console
       [not found] ` <20070213221829.513618819@goop.org>
@ 2007-02-14  9:24   ` Gerd Hoffmann
  0 siblings, 0 replies; 45+ messages in thread
From: Gerd Hoffmann @ 2007-02-14  9:24 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Alan

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Jeremy Fitzhardinge wrote:
> If we're running under Xen, then there's no VT console.  This results
> in vc->vc_screenbuf_size == 0, which causes alloc_bootmem to panic.
> Don't bother allocating a vc_screenbuf if its going to be 0 sized.

NAK.

The *real* problem is that the real-mode boot code never ever runs, thus
SCREEN_INFO is not initialized (all zeros), and vgacon doesn't catch
that case.  Instead it thinks it runs on a EGA card with 0 lines and 0
columns.

So better fix vgacon to catch this and switch to the 80x25 dummy console
instead, patch attached.

cheers,

  Gerd


[-- Attachment #2: vgacon --]
[-- Type: text/plain, Size: 779 bytes --]

---
 drivers/video/console/vgacon.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: paravirt-2.6.20-hg749/drivers/video/console/vgacon.c
===================================================================
--- paravirt-2.6.20-hg749.orig/drivers/video/console/vgacon.c
+++ paravirt-2.6.20-hg749/drivers/video/console/vgacon.c
@@ -372,7 +372,8 @@ static const char *vgacon_startup(void)
 	}
 
 	/* VGA16 modes are not handled by VGACON */
-	if ((ORIG_VIDEO_MODE == 0x0D) ||	/* 320x200/4 */
+	if ((ORIG_VIDEO_MODE == 0x00) ||	/* SCREEN_INFO not initialized */
+	    (ORIG_VIDEO_MODE == 0x0D) ||	/* 320x200/4 */
 	    (ORIG_VIDEO_MODE == 0x0E) ||	/* 640x200/4 */
 	    (ORIG_VIDEO_MODE == 0x10) ||	/* 640x350/4 */
 	    (ORIG_VIDEO_MODE == 0x12) ||	/* 640x480/4 */

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-13 23:54   ` [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen Andi Kleen
  2007-02-14  0:39     ` Jeremy Fitzhardinge
@ 2007-02-14 18:53     ` Jeremy Fitzhardinge
  2007-02-14 20:10       ` Eric W. Biederman
  1 sibling, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14 18:53 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, linux-kernel, virtualization, xen-devel,
	Chris Wright, Zachary Amsden, Eric W. Biederman, Ian Campbell

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

Andi Kleen wrote:
>> +#ifdef CONFIG_XEN
>> +#include "../xen/xen-head.S"
>> +#endif
>>     
>
> Can this really not be linked separately? 

I did a patch to do this (attached).  In principle it should be pretty
simple, but I think I'm running into toolchain issues.  If I link
xen-head.S separately (with appropriate headers added), it compiles OK
and contains the right notes, but they don't appear in the final vmlinux
properly.  The note segment and section are there, but no tools will
parse them as notes:

: ezr:pts/1; readelf -n vmlinux 
: ezr:pts/1; ../../unstable/tools/xcutils/readnotes vmlinux 
: ezr:pts/1; readelf -l vmlinux 

Elf file type is EXEC (Executable file)
Entry point 0x2e1f70
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0xc0100000 0x00100000 0x2a8920 0x2a8920 R E 0x1000
  LOAD           0x2aa000 0xc03a9000 0x003a9000 0x5f085 0xaf000 RWE 0x1000
  NOTE           0x26d2910 0x00239010 0x00239010 0x000e8 0x00000 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .text.head __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __bug_table 
   01     .data .paravirtprobe .data_nosave .data.page_aligned .data.cacheline_aligned .data.read_mostly .data.init_task .init.text .init.data .init.setup .initcall.init .con_initcall.init .altinstructions .altinstr_replacement .parainstructions .exit.text .init.ramfs .bss 
   02     .notes 
: ezr:pts/1; objdump -j .notes -s vmlinux 

vmlinux:     file format elf32-i386

Contents of section .notes:
 239010 04000000 06000000 06000000 58656e00  ............Xen.
 239020 6c696e75 78000000 04000000 04000000  linux...........
 239030 07000000 58656e00 322e3600 04000000  ....Xen.2.6.....
 239040 08000000 05000000 58656e00 78656e2d  ........Xen.xen-
 239050 332e3000 04000000 04000000 03000000  3.0.............
 239060 58656e00 000000c0 04000000 04000000  Xen.............
 239070 01000000 58656e00 c80710c0 04000000  ....Xen.........
 239080 04000000 02000000 58656e00 00b040c0  ........Xen...@.
 239090 04000000 2a000000 0a000000 58656e00  ....*.......Xen.
 2390a0 21777269 7461626c 655f7061 67655f74  !writable_page_t
 2390b0 61626c65 737c7061 655f7067 6469725f  ables|pae_pgdir_
 2390c0 61626f76 655f3467 62000000 04000000  above_4gb.......
 2390d0 04000000 09000000 58656e00 79657300  ........Xen.yes.
 2390e0 04000000 08000000 08000000 58656e00  ............Xen.
 2390f0 67656e65 72696300                    generic.        


I can't see what the problem is here, but it looks like a toolchain
problem to me (I'm using binutils-2.17.50.0.6-2.fc6).

Any clues?

Thanks,
    J

[-- Attachment #2: xen-head.patch --]
[-- Type: text/x-patch, Size: 1322 bytes --]

diff -r 4721c1690d24 arch/i386/kernel/head.S
--- a/arch/i386/kernel/head.S	Wed Feb 14 03:16:30 2007 -0800
+++ b/arch/i386/kernel/head.S	Wed Feb 14 04:01:58 2007 -0800
@@ -504,7 +504,7 @@ ignore_int:
 
 .section .text
 #ifdef CONFIG_PARAVIRT
-startup_paravirt:
+ENTRY(startup_paravirt)
 	cld
  	movl $(init_thread_union+THREAD_SIZE),%esp
 
@@ -535,10 +535,6 @@ unhandled_paravirt:
 	ud2
 #endif
 
-#ifdef CONFIG_XEN
-#include "../xen/xen-head.S"
-#endif
-	
 /*
  * Real beginning of normal "text" segment
  */
diff -r 4721c1690d24 arch/i386/xen/Makefile
--- a/arch/i386/xen/Makefile	Wed Feb 14 03:16:30 2007 -0800
+++ b/arch/i386/xen/Makefile	Wed Feb 14 04:01:58 2007 -0800
@@ -1,2 +1,2 @@ obj-y		:= enlighten.o setup.o events.o t
-obj-y		:= enlighten.o setup.o events.o time.o \
+obj-y		:= xen-head.o enlighten.o setup.o events.o time.o \
 			features.o mmu.o multicalls.o
diff -r 4721c1690d24 arch/i386/xen/xen-head.S
--- a/arch/i386/xen/xen-head.S	Wed Feb 14 03:16:30 2007 -0800
+++ b/arch/i386/xen/xen-head.S	Wed Feb 14 04:01:58 2007 -0800
@@ -1,8 +1,11 @@
 /* Xen-specific pieces of head.S, intended to be included in the right
 	place in head.S */
 
+.text
 #include <linux/elfnote.h>
+#include <linux/linkage.h>
 #include <asm/boot.h>
+#include <asm/page.h>
 #include <xen/interface/elfnote.h>
 
 ENTRY(startup_xen)

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
  2007-02-14  1:06   ` [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions Zachary Amsden
  2007-02-14  1:16     ` Jeremy Fitzhardinge
  2007-02-14  5:51     ` Rusty Russell
@ 2007-02-14 19:36     ` Christoph Hellwig
  2 siblings, 0 replies; 45+ messages in thread
From: Christoph Hellwig @ 2007-02-14 19:36 UTC (permalink / raw)
  To: Zachary Amsden
  Cc: Jeremy Fitzhardinge, Andi Kleen, Andrew Morton, linux-kernel,
	virtualization, xen-devel, Chris Wright, Rusty Russell

On Tue, Feb 13, 2007 at 05:06:42PM -0800, Zachary Amsden wrote:
> >I moved drm_follow_page into the core, to avoid having to wrap the
> >various pte ops.  Unlining kernel_fpu_end and using that in the RAID6
> >code would remove the need to export clts/read_cr0/write_cr0 too.

Please don't push the drm_follow_page part.  Dave and I fixed drm
to not need this junk anymore, and it should be part of the next drm merge.


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-14 18:53     ` Jeremy Fitzhardinge
@ 2007-02-14 20:10       ` Eric W. Biederman
  2007-02-14 20:41         ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-14 20:10 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Andi Kleen wrote:
>>> +#ifdef CONFIG_XEN
>>> +#include "../xen/xen-head.S"
>>> +#endif
>>>     
>>
>> Can this really not be linked separately? 
>
> I did a patch to do this (attached).  In principle it should be pretty
> simple, but I think I'm running into toolchain issues.  If I link
> xen-head.S separately (with appropriate headers added), it compiles OK
> and contains the right notes, but they don't appear in the final vmlinux
> properly.  The note segment and section are there, but no tools will
> parse them as notes:
>
> : ezr:pts/1; readelf -n vmlinux 
> : ezr:pts/1; ../../unstable/tools/xcutils/readnotes vmlinux 
> : ezr:pts/1; readelf -l vmlinux 
>
> Elf file type is EXEC (Executable file)
> Entry point 0x2e1f70
> There are 3 program headers, starting at offset 52
>
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x001000 0xc0100000 0x00100000 0x2a8920 0x2a8920 R E 0x1000
>   LOAD           0x2aa000 0xc03a9000 0x003a9000 0x5f085 0xaf000 RWE 0x1000
>   NOTE           0x26d2910 0x00239010 0x00239010 0x000e8 0x00000 R   0x4
>
>  Section to Segment mapping:
>   Segment Sections...
>    00 .text .text.head __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> __kcrctab __kcrctab_gpl __ksymtab_strings __param __bug_table
>    01 .data .paravirtprobe .data_nosave .data.page_aligned
> .data.cacheline_aligned .data.read_mostly .data.init_task .init.text .init.data
> .init.setup .initcall.init .con_initcall.init .altinstructions
> .altinstr_replacement .parainstructions .exit.text .init.ramfs .bss
>    02     .notes 
> : ezr:pts/1; objdump -j .notes -s vmlinux 
>
> vmlinux:     file format elf32-i386
>
> Contents of section .notes:
>  239010 04000000 06000000 06000000 58656e00  ............Xen.
>  239020 6c696e75 78000000 04000000 04000000  linux...........
>  239030 07000000 58656e00 322e3600 04000000  ....Xen.2.6.....
>  239040 08000000 05000000 58656e00 78656e2d  ........Xen.xen-
>  239050 332e3000 04000000 04000000 03000000  3.0.............
>  239060 58656e00 000000c0 04000000 04000000  Xen.............
>  239070 01000000 58656e00 c80710c0 04000000  ....Xen.........
>  239080 04000000 02000000 58656e00 00b040c0  ........Xen...@.
>  239090 04000000 2a000000 0a000000 58656e00  ....*.......Xen.
>  2390a0 21777269 7461626c 655f7061 67655f74  !writable_page_t
>  2390b0 61626c65 737c7061 655f7067 6469725f  ables|pae_pgdir_
>  2390c0 61626f76 655f3467 62000000 04000000  above_4gb.......
>  2390d0 04000000 09000000 58656e00 79657300  ........Xen.yes.
>  2390e0 04000000 08000000 08000000 58656e00  ............Xen.
>  2390f0 67656e65 72696300                    generic.        
>
>
> I can't see what the problem is here, but it looks like a toolchain
> problem to me (I'm using binutils-2.17.50.0.6-2.fc6).

Well I did a little by hand parsing and the not I parsed looked ok.

How does the output differ from a what you get when xen-head.S is
included?

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
       [not found] ` <20070213221830.707197267@goop.org>
  2007-02-13 23:54   ` [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen Andi Kleen
@ 2007-02-14 20:33   ` Eric W. Biederman
  2007-02-14 20:42     ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-14 20:33 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, linux-kernel

Jeremy Fitzhardinge <jeremy@goop.org> writes:

There need to be alignment directives for the page aligned chunks.

Placing the page aligned chunks in a special section is nice in that
it ensures the linker packs everything tightly but should be
completely unnecessary if the alignment is correct.

>  
> ===================================================================
> --- a/arch/i386/kernel/head.S
> +++ b/arch/i386/kernel/head.S
> @@ -519,6 +519,10 @@ 1:
>  	jmp	1b
>  #endif
>  
> +#ifdef CONFIG_XEN
> +#include "../xen/xen-head.S"
> +#endif
> +	
>  /*
>   * Real beginning of normal "text" segment
>   */
> @@ -528,7 +532,7 @@ ENTRY(_stext)
>  /*
>   * BSS section
>   */
> -.section ".bss.page_aligned","w"
> +.section ".bss.page_aligned"
>  ENTRY(swapper_pg_dir)
>  	.fill 1024,4,0
>  ENTRY(empty_zero_page)
> @@ -598,7 +602,8 @@ ENTRY(boot_gdt_table)
>  /*
>   * The Global Descriptor Table contains 28 quadwords, per-CPU.
>   */
> -	.align L1_CACHE_BYTES
> +	.section ".data.page_aligned"
> +	.align PAGE_SIZE_asm
>  ENTRY(cpu_gdt_table)
>  	.quad 0x0000000000000000	/* NULL descriptor */
>  	.quad 0x0000000000000000	/* 0x0b reserved */
> @@ -647,3 +652,6 @@ ENTRY(cpu_gdt_table)
>  	.quad 0x0000000000000000	/* 0xf0 - unused */
>  	.quad 0x0000000000000000 /* 0xf8 - GDT entry 31: double-fault TSS */
>  
> +	/* Be sure this is zeroed to avoid false validations in Xen */
> +	.fill PAGE_SIZE_asm / 8 - GDT_ENTRIES,8,0
> +	.previous

> ===================================================================
> --- a/arch/i386/kernel/vmlinux.lds.S
> +++ b/arch/i386/kernel/vmlinux.lds.S
> @@ -93,6 +93,7 @@ SECTIONS
>  
>    . = ALIGN(4096);
>    .data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
> +	*(.data.page_aligned)
>  	*(.data.idt)
>    }
>  

> --- /dev/null
> +++ b/arch/i386/xen/xen-head.S
> @@ -0,0 +1,29 @@
> +/* Xen-specific pieces of head.S, intended to be included in the right
> +	place in head.S */
> +
> +#include <linux/elfnote.h>
> +#include <asm/boot.h>
> +#include <xen/interface/elfnote.h>
> +
> +ENTRY(startup_xen)
> +	movl %esi,xen_start_info
> +	jmp startup_paravirt
> +	
> +.pushsection ".bss.page_aligned"
> +ENTRY(hypercall_page)
> +	.skip 0x1000
> +.popsection
> +
> +	ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,       .asciz, "linux")
> +	ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION,  .asciz, "2.6")
> +	ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION,    .asciz, "xen-3.0")
> +	ELFNOTE(Xen, XEN_ELFNOTE_VIRT_BASE,      .long,  __PAGE_OFFSET)
> +	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          .long,  startup_xen)
> +	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, .long,  hypercall_page)
> + ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz,
> "!writable_page_tables|pae_pgdir_above_4gb")
> +#ifdef CONFIG_X86_PAE
> +	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz, "yes")
> +#else
> +	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz, "no")
> +#endif
> +	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz, "generic")

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 21/21] Xen-paravirt: Add the Xen virtual network device driver.
       [not found] ` <20070213221831.150207238@goop.org>
@ 2007-02-14 20:40   ` Eric W. Biederman
  0 siblings, 0 replies; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-14 20:40 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, Ian Pratt, netdev, linux-kernel

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> +++ b/drivers/xen/Kconfig.net
> @@ -0,0 +1,14 @@
> +menu "Xen network device drivers"
> +        depends on NETDEVICES && XEN
> +
> +config XEN_NETDEV_FRONTEND
> +	tristate "Network-device frontend driver"
> +	depends on XEN
> +	default y
> +	help
> +	  The network-device frontend driver allows the kernel to access
> +	  network interfaces within another guest OS. Unless you are building a
> +	  dedicated device-driver domain, or your master control domain
> +	  (domain 0), then you almost certainly want to say Y here.

Am I reading this correctly I can directly use the network interface
of another guest OS (no protection)?

I think this description is misleading, and probably say something
about virtual hardware.

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-14 20:10       ` Eric W. Biederman
@ 2007-02-14 20:41         ` Jeremy Fitzhardinge
  2007-02-14 21:06           ` Eric W. Biederman
  0 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14 20:41 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Eric W. Biederman wrote:
> Well I did a little by hand parsing and the not I parsed looked ok.
>
> How does the output differ from a what you get when xen-head.S is
> included?
>   
Ah!

The .notes section gets SHT_NOTE in vmlinux when xen-head.S is included;
PROGBITS when linked.  I tried putting @note on the .section in
linux/elfnote.h, but that didn't seem to help (xen-note.o got a SHT_NOTE
entry, but it didn't make it into vmlinux).  I couldn't see any way of
forcing the section type in vmlinux.lds; my experiments all ended with
ld dumping core.

    J


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-14 20:33   ` Eric W. Biederman
@ 2007-02-14 20:42     ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-14 20:42 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, linux-kernel

Eric W. Biederman wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>
> There need to be alignment directives for the page aligned chunks.
>   

OK.

> Placing the page aligned chunks in a special section is nice in that
> it ensures the linker packs everything tightly but should be
> completely unnecessary if the alignment is correct.
>   
Yes, I made the extra section to get better packing.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 15/21] Xen-paravirt: Add Xen interface header files
       [not found] ` <20070213221830.619562494@goop.org>
@ 2007-02-14 20:45   ` Eric W. Biederman
  2007-02-15  0:10     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-14 20:45 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, Ian Pratt, linux-kernel

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Add Xen interface header files. These are taken fairly directly from
> the Xen tree and hence the style is not entirely in accordance with
> Linux guidelines. There is a tension between fitting with Linux coding
> rules and ease of maintenance.
>
> Define macros and inline functions for doing hypercalls into the
> hypervisor.
>
> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
> Signed-off-by: Ian Pratt <ian.pratt@xensource.com>
> Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
>
>
> --
>  include/asm-i386/hypercall.h          |  416 +++++++++++++++++++++++++++++
>  include/asm-i386/hypervisor.h         |   72 +++++

Are hypercall.h and hypervisor.h generic or are they Xen specific.
If they are Xen specific (as it appears) then are inappropriately
named.

>  include/xen/interface/arch-x86_32.h   |  187 +++++++++++++
Why isn't this file include-asm-i386/xen/arch-x86_32.h ?

>  include/xen/interface/elfnote.h       |  133 +++++++++
>  include/xen/interface/event_channel.h |  195 ++++++++++++++
>  include/xen/interface/features.h      |   43 +++
>  include/xen/interface/grant_table.h   |  301 +++++++++++++++++++++
>  include/xen/interface/io/blkif.h      |   96 ++++++
>  include/xen/interface/io/console.h    |   23 +
>  include/xen/interface/io/netif.h      |  152 ++++++++++
>  include/xen/interface/io/ring.h       |  260 ++++++++++++++++++
>  include/xen/interface/io/xenbus.h     |   42 +++
>  include/xen/interface/io/xs_wire.h    |   87 ++++++
>  include/xen/interface/memory.h        |  145 ++++++++++
>  include/xen/interface/physdev.h       |   61 ++++
>  include/xen/interface/sched.h         |   77 +++++
>  include/xen/interface/vcpu.h          |  109 +++++++
>  include/xen/interface/version.h       |   60 ++++
>  include/xen/interface/xen.h           |  445 ++++++++++++++++++++++++++++++++
>  19 files changed, 2904 insertions(+)

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-14 20:41         ` Jeremy Fitzhardinge
@ 2007-02-14 21:06           ` Eric W. Biederman
  2007-02-15  0:13             ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-14 21:06 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> Well I did a little by hand parsing and the not I parsed looked ok.
>>
>> How does the output differ from a what you get when xen-head.S is
>> included?
>>   
> Ah!
>
> The .notes section gets SHT_NOTE in vmlinux when xen-head.S is included;
> PROGBITS when linked.  I tried putting @note on the .section in
> linux/elfnote.h, but that didn't seem to help (xen-note.o got a SHT_NOTE
> entry, but it didn't make it into vmlinux).  I couldn't see any way of
> forcing the section type in vmlinux.lds; my experiments all ended with
> ld dumping core.

Ok.  If that is all this may be a difference that makes no difference.
binutils has a bad habit of looking at sections (which are fully
optional) instead of segments on ET_EXEC and ET_DYN objects.  Only
ET_REL objects (.o files) are required to have sections.

It is worth checking but as long as something looking strictly at the
program headers can find the notes and read them we are in good shape.

That readelf -n has a problem there concerns me a little but as
usually that program is better than the rest of binutils.

So I recommend for testing write a 100 line program that includes
elf.h and reads out the note segment.  If all is well we can split
this code out.

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 15/21] Xen-paravirt: Add Xen interface header files
  2007-02-14 20:45   ` [patch 15/21] Xen-paravirt: Add Xen interface header files Eric W. Biederman
@ 2007-02-15  0:10     ` Jeremy Fitzhardinge
  2007-02-15 17:32       ` Christoph Hellwig
  0 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-15  0:10 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Andrew Morton, virtualization, xen-devel,
	Chris Wright, Ian Pratt, linux-kernel

Eric W. Biederman wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>
>   
>> Add Xen interface header files. These are taken fairly directly from
>> the Xen tree and hence the style is not entirely in accordance with
>> Linux guidelines. There is a tension between fitting with Linux coding
>> rules and ease of maintenance.
>>
>> Define macros and inline functions for doing hypercalls into the
>> hypervisor.
>>
>> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
>> Signed-off-by: Ian Pratt <ian.pratt@xensource.com>
>> Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
>> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
>>
>>
>> --
>>  include/asm-i386/hypercall.h          |  416 +++++++++++++++++++++++++++++
>>  include/asm-i386/hypervisor.h         |   72 +++++
>>     
>
> Are hypercall.h and hypervisor.h generic or are they Xen specific.
> If they are Xen specific (as it appears) then are inappropriately
> named.
>   

Thanks for the reminder; I've been meaning to move/rename these.

>>  include/xen/interface/arch-x86_32.h   |  187 +++++++++++++
>>     
> Why isn't this file include-asm-i386/xen/arch-x86_32.h ?
>   

Those files are more or less directly copied from the Xen tree, and its
easier if they don't drift too far in name and directory structure.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-14 21:06           ` Eric W. Biederman
@ 2007-02-15  0:13             ` Jeremy Fitzhardinge
  2007-02-15  1:39               ` Eric W. Biederman
  0 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-15  0:13 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Eric W. Biederman wrote:
> Ok.  If that is all this may be a difference that makes no difference.
> binutils has a bad habit of looking at sections (which are fully
> optional) instead of segments on ET_EXEC and ET_DYN objects.  Only
> ET_REL objects (.o files) are required to have sections.
>   

The Xen domain loader will have to be changed to deal with that, which
isn't too much of a problem.

My main concern is the randomness of it, and whether it will fail in
some more harmful way on other versions of binutils.

> So I recommend for testing write a 100 line program that includes
> elf.h and reads out the note segment.  If all is well we can split
> this code out.
>   

The Xen readnotes utility is essentially that.  I'll hack it.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-15  0:13             ` Jeremy Fitzhardinge
@ 2007-02-15  1:39               ` Eric W. Biederman
  2007-02-15  1:52                 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-15  1:39 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> Ok.  If that is all this may be a difference that makes no difference.
>> binutils has a bad habit of looking at sections (which are fully
>> optional) instead of segments on ET_EXEC and ET_DYN objects.  Only
>> ET_REL objects (.o files) are required to have sections.
>>   
>
> The Xen domain loader will have to be changed to deal with that, which
> isn't too much of a problem.

Ok.  Please fix the Xen domain loader to not look at sections.  It
is a bug for any kind of executable loader to look at anything other
then segments.

> My main concern is the randomness of it, and whether it will fail in
> some more harmful way on other versions of binutils.

Reasonable and it's probably worth letting the binutils developer know.
I do agree that it is weird.   It might be that something in binutils
doesn't like us dropping some of the notes.

>> So I recommend for testing write a 100 line program that includes
>> elf.h and reads out the note segment.  If all is well we can split
>> this code out.
>>   
>
> The Xen readnotes utility is essentially that.  I'll hack it.

Sounds good.

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-15  1:39               ` Eric W. Biederman
@ 2007-02-15  1:52                 ` Jeremy Fitzhardinge
  2007-02-15  2:18                   ` Eric W. Biederman
  0 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-15  1:52 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Eric W. Biederman wrote:
> Reasonable and it's probably worth letting the binutils developer know.
> I do agree that it is weird.   It might be that something in binutils
> doesn't like us dropping some of the notes.
>   

What do you mean by "dropping some of the notes"?  I think the only
notes (at least in this case) are the Xen ones, and they're all included.

    J

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-15  1:52                 ` Jeremy Fitzhardinge
@ 2007-02-15  2:18                   ` Eric W. Biederman
  2007-02-15  2:23                     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-15  2:18 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> Reasonable and it's probably worth letting the binutils developer know.
>> I do agree that it is weird.   It might be that something in binutils
>> doesn't like us dropping some of the notes.
>>   
>
> What do you mean by "dropping some of the notes"?  I think the only
> notes (at least in this case) are the Xen ones, and they're all included.

I'm pretty certain we explicitly drop the weird GNU note that
is automatically generated by gcc and specifies something informational.

Basically into .note we include *(.note.*) but not *(.note).

I don't think anything we are doing is wrong but ld gets confused easily
in the corner cases.  I'm modestly surprised we didn't have to mark our
.note.xxx scions as ".section .note.xxx @note"  or whatever the proper
gas syntax is.

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-15  2:18                   ` Eric W. Biederman
@ 2007-02-15  2:23                     ` Jeremy Fitzhardinge
  2007-02-15  2:41                       ` Eric W. Biederman
  0 siblings, 1 reply; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-15  2:23 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Eric W. Biederman wrote:
> I'm pretty certain we explicitly drop the weird GNU note that
> is automatically generated by gcc and specifies something informational.
>   
But that's something else again, since it appears as a PT_GNU_STACK phdr.

> I don't think anything we are doing is wrong but ld gets confused easily
> in the corner cases.  I'm modestly surprised we didn't have to mark our
> .note.xxx scions as ".section .note.xxx @note"  or whatever the proper
> gas syntax is.

I did try that, and it didn't make a difference.  The manual says that
the output section type follows the input section type, so I agree its a
bit surprising we ever get a SHT_NOTE out of it without the @note stuff.

    J


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
  2007-02-15  2:23                     ` Jeremy Fitzhardinge
@ 2007-02-15  2:41                       ` Eric W. Biederman
  0 siblings, 0 replies; 45+ messages in thread
From: Eric W. Biederman @ 2007-02-15  2:41 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andi Kleen, Andrew Morton, linux-kernel, virtualization,
	xen-devel, Chris Wright, Zachary Amsden, Ian Campbell

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> I'm pretty certain we explicitly drop the weird GNU note that
>> is automatically generated by gcc and specifies something informational.
>>   
> But that's something else again, since it appears as a PT_GNU_STACK phdr.

Not that.  It's more like abi version or gcc version or something
like.  At least there used to be one of those notes in every .o file
and compiled program.

>> I don't think anything we are doing is wrong but ld gets confused easily
>> in the corner cases.  I'm modestly surprised we didn't have to mark our
>> .note.xxx scions as ".section .note.xxx @note"  or whatever the proper
>> gas syntax is.
>
> I did try that, and it didn't make a difference.  The manual says that
> the output section type follows the input section type, so I agree its a
> bit surprising we ever get a SHT_NOTE out of it without the @note stuff.

Right.  So the surprise is that SHT_NOTE got set.  There are some
defaults based on the section name somewhere that appear to have done
the right thing.

My best hunch really is that ld treated the .note sections normally
and just mist the handling of the magic SHT_NOTE type.  Which is why
I'm not to worried.

Eric

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [patch 15/21] Xen-paravirt: Add Xen interface header files
  2007-02-15  0:10     ` Jeremy Fitzhardinge
@ 2007-02-15 17:32       ` Christoph Hellwig
  0 siblings, 0 replies; 45+ messages in thread
From: Christoph Hellwig @ 2007-02-15 17:32 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Eric W. Biederman, Andi Kleen, Andrew Morton, virtualization,
	xen-devel, Chris Wright, Ian Pratt, linux-kernel

On Wed, Feb 14, 2007 at 04:10:50PM -0800, Jeremy Fitzhardinge wrote:
> Eric W. Biederman wrote:
> > Jeremy Fitzhardinge <jeremy@goop.org> writes:
> >
> >   
> >> Add Xen interface header files. These are taken fairly directly from
> >> the Xen tree and hence the style is not entirely in accordance with
> >> Linux guidelines. There is a tension between fitting with Linux coding
> >> rules and ease of maintenance.
> >>
> >> Define macros and inline functions for doing hypercalls into the
> >> hypervisor.
> >>
> >> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
> >> Signed-off-by: Ian Pratt <ian.pratt@xensource.com>
> >> Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
> >> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> >>
> >>
> >> --
> >>  include/asm-i386/hypercall.h          |  416 +++++++++++++++++++++++++++++
> >>  include/asm-i386/hypervisor.h         |   72 +++++
> >>     
> >
> > Are hypercall.h and hypervisor.h generic or are they Xen specific.
> > If they are Xen specific (as it appears) then are inappropriately
> > named.
> >   
> 
> Thanks for the reminder; I've been meaning to move/rename these.
> 
> >>  include/xen/interface/arch-x86_32.h   |  187 +++++++++++++
> >>     
> > Why isn't this file include-asm-i386/xen/arch-x86_32.h ?
> >   
> 
> Those files are more or less directly copied from the Xen tree, and its
> easier if they don't drift too far in name and directory structure.

Nack, we don't put per-arch crap there.  Either you'll have it in separate
places, or you clean up the utterly braindead scheme in the Xen tree
aswell.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* [patch 21/21] Xen-paravirt: Add the Xen virtual network device driver.
  2007-02-16  2:24 [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface Jeremy Fitzhardinge
@ 2007-02-16  2:25 ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 45+ messages in thread
From: Jeremy Fitzhardinge @ 2007-02-16  2:25 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, linux-kernel, virtualization, xen-devel,
	Chris Wright, Zachary Amsden, Ian Pratt, Christian Limpach,
	netdev

[-- Attachment #1: xen-netfront.patch --]
[-- Type: text/plain, Size: 56730 bytes --]

The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.

Signed-off-by: Ian Pratt <ian.pratt@xensource.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: netdev@vger.kernel.org

---
 drivers/net/Kconfig        |   12 
 drivers/net/Makefile       |    2 
 drivers/net/xen-netfront.c | 2066 ++++++++++++++++++++++++++++++++++++++++++++
 include/xen/events.h       |    2 
 4 files changed, 2082 insertions(+)

===================================================================
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2525,6 +2525,18 @@ source "drivers/atm/Kconfig"
 
 source "drivers/s390/net/Kconfig"
 
+config XEN_NETDEV_FRONTEND
+	tristate "Xen network device frontend driver"
+	depends on XEN
+	default y
+	help
+	  The network device frontend driver allows the kernel to
+	  access network devices exported exported by a virtual
+	  machine containing a physical network device driver. The
+	  frontend driver is intended for unprivileged guest domains;
+	  if you are compiling a kernel for a Xen guest, you almost
+	  certainly want to enable this.
+
 config ISERIES_VETH
 	tristate "iSeries Virtual Ethernet driver support"
 	depends on PPC_ISERIES
===================================================================
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -218,3 +218,5 @@ obj-$(CONFIG_FS_ENET) += fs_enet/
 obj-$(CONFIG_FS_ENET) += fs_enet/
 
 obj-$(CONFIG_NETXEN_NIC) += netxen/
+
+obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o
===================================================================
--- /dev/null
+++ b/drivers/net/xen-netfront.c
@@ -0,0 +1,2066 @@
+/******************************************************************************
+ * Virtual network driver for conversing with remote driver backends.
+ *
+ * Copyright (c) 2002-2005, K A Fraser
+ * Copyright (c) 2005, XenSource Ltd
+ *
+ * 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; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/netdevice.h>
+#include <linux/inetdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/init.h>
+#include <linux/bitops.h>
+#include <linux/ethtool.h>
+#include <linux/in.h>
+#include <linux/if_ether.h>
+#include <linux/io.h>
+#include <linux/moduleparam.h>
+#include <net/sock.h>
+#include <net/pkt_sched.h>
+#include <net/arp.h>
+#include <net/route.h>
+#include <asm/uaccess.h>
+#include <xen/xenbus.h>
+#include <xen/interface/io/netif.h>
+#include <xen/interface/memory.h>
+#ifdef CONFIG_XEN_BALLOON
+#include <xen/balloon.h>
+#endif
+#include <asm/page.h>
+#include <xen/interface/grant_table.h>
+
+#include <xen/events.h>
+#include <xen/page.h>
+#include <xen/grant_table.h>
+
+/*
+ * Mutually-exclusive module options to select receive data path:
+ *  rx_copy : Packets are copied by network backend into local memory
+ *  rx_flip : Page containing packet data is transferred to our ownership
+ * For fully-virtualised guests there is no option - copying must be used.
+ * For paravirtualised guests, flipping is the default.
+ */
+#ifdef CONFIG_XEN
+static int MODPARM_rx_copy = 0;
+module_param_named(rx_copy, MODPARM_rx_copy, bool, 0);
+MODULE_PARM_DESC(rx_copy, "Copy packets from network card (rather than flip)");
+static int MODPARM_rx_flip = 0;
+module_param_named(rx_flip, MODPARM_rx_flip, bool, 0);
+MODULE_PARM_DESC(rx_flip, "Flip packets from network card (rather than copy)");
+#else
+static const int MODPARM_rx_copy = 1;
+static const int MODPARM_rx_flip = 0;
+#endif
+
+#define RX_COPY_THRESHOLD 256
+
+#define GRANT_INVALID_REF	0
+
+#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
+#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
+
+struct netfront_info {
+	struct list_head list;
+	struct net_device *netdev;
+
+	struct net_device_stats stats;
+
+	struct netif_tx_front_ring tx;
+	struct netif_rx_front_ring rx;
+
+	spinlock_t   tx_lock;
+	spinlock_t   rx_lock;
+
+	unsigned int evtchn, irq;
+	unsigned int copying_receiver;
+
+	/* Receive-ring batched refills. */
+#define RX_MIN_TARGET 8
+#define RX_DFL_MIN_TARGET 64
+#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+	unsigned rx_min_target, rx_max_target, rx_target;
+	struct sk_buff_head rx_batch;
+
+	struct timer_list rx_refill_timer;
+
+	/*
+	 * {tx,rx}_skbs store outstanding skbuffs. The first entry in tx_skbs
+	 * is an index into a chain of free entries.
+	 */
+	struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1];
+	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+
+#define TX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+	grant_ref_t gref_tx_head;
+	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE + 1];
+	grant_ref_t gref_rx_head;
+	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
+
+	struct xenbus_device *xbdev;
+	int tx_ring_ref;
+	int rx_ring_ref;
+	u8 mac[ETH_ALEN];
+
+	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
+};
+
+struct netfront_rx_info {
+	struct netif_rx_response rx;
+	struct netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX - 1];
+};
+
+/*
+ * Access macros for acquiring freeing slots in tx_skbs[].
+ */
+
+static inline void add_id_to_freelist(struct sk_buff **list, unsigned short id)
+{
+	list[id] = list[0];
+	list[0]  = (void *)(unsigned long)id;
+}
+
+static inline unsigned short get_id_from_freelist(struct sk_buff **list)
+{
+	unsigned int id = (unsigned int)(unsigned long)list[0];
+	list[0] = list[id];
+	return id;
+}
+
+static inline int xennet_rxidx(RING_IDX idx)
+{
+	return idx & (NET_RX_RING_SIZE - 1);
+}
+
+static inline struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
+						RING_IDX ri)
+{
+	int i = xennet_rxidx(ri);
+	struct sk_buff *skb = np->rx_skbs[i];
+	np->rx_skbs[i] = NULL;
+	return skb;
+}
+
+static inline grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
+					    RING_IDX ri)
+{
+	int i = xennet_rxidx(ri);
+	grant_ref_t ref = np->grant_rx_ref[i];
+	np->grant_rx_ref[i] = GRANT_INVALID_REF;
+	return ref;
+}
+
+#define DPRINTK(fmt, args...)				\
+	pr_debug("netfront (%s:%d) " fmt,		\
+		 __FUNCTION__, __LINE__, ##args)
+#define IPRINTK(fmt, args...)				\
+	printk(KERN_INFO "netfront: " fmt, ##args)
+#define WPRINTK(fmt, args...)				\
+	printk(KERN_WARNING "netfront: " fmt, ##args)
+
+static int setup_device(struct xenbus_device *, struct netfront_info *);
+static struct net_device *create_netdev(struct xenbus_device *);
+
+static void netfront_closing(struct xenbus_device *);
+
+static void end_access(int, void *);
+static void netif_disconnect_backend(struct netfront_info *);
+static int open_netdev(struct netfront_info *);
+static void close_netdev(struct netfront_info *);
+
+static int network_connect(struct net_device *);
+static void network_tx_buf_gc(struct net_device *);
+static void network_alloc_rx_buffers(struct net_device *);
+static int send_fake_arp(struct net_device *);
+
+static irqreturn_t netif_int(int irq, void *dev_id);
+
+#ifdef CONFIG_SYSFS
+static int xennet_sysfs_addif(struct net_device *netdev);
+static void xennet_sysfs_delif(struct net_device *netdev);
+#else /* !CONFIG_SYSFS */
+#define xennet_sysfs_addif(dev) (0)
+#define xennet_sysfs_delif(dev) do { } while(0)
+#endif
+
+static inline int xennet_can_sg(struct net_device *dev)
+{
+	return dev->features & NETIF_F_SG;
+}
+
+/**
+ * Entry point to this code when a new device is created.  Allocate the basic
+ * structures and the ring buffers for communication with the backend, and
+ * inform the backend of the appropriate details for those.
+ */
+static int __devinit netfront_probe(struct xenbus_device *dev,
+				    const struct xenbus_device_id *id)
+{
+	int err;
+	struct net_device *netdev;
+	struct netfront_info *info;
+
+	netdev = create_netdev(dev);
+	if (IS_ERR(netdev)) {
+		err = PTR_ERR(netdev);
+		xenbus_dev_fatal(dev, err, "creating netdev");
+		return err;
+	}
+
+	info = netdev_priv(netdev);
+	dev->dev.driver_data = info;
+
+	err = open_netdev(info);
+	if (err)
+		goto fail;
+
+	return 0;
+
+ fail:
+	free_netdev(netdev);
+	dev->dev.driver_data = NULL;
+	return err;
+}
+
+
+/**
+ * We are reconnecting to the backend, due to a suspend/resume, or a backend
+ * driver restart.  We tear down our netif structure and recreate it, but
+ * leave the device-layer structures intact so that this is transparent to the
+ * rest of the kernel.
+ */
+static int netfront_resume(struct xenbus_device *dev)
+{
+	struct netfront_info *info = dev->dev.driver_data;
+
+	DPRINTK("%s\n", dev->nodename);
+
+	netif_disconnect_backend(info);
+	return 0;
+}
+
+static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
+{
+	char *s, *e, *macstr;
+	int i;
+
+	macstr = s = xenbus_read(XBT_NIL, dev->nodename, "mac", NULL);
+	if (IS_ERR(macstr))
+		return PTR_ERR(macstr);
+
+	for (i = 0; i < ETH_ALEN; i++) {
+		mac[i] = simple_strtoul(s, &e, 16);
+		if ((s == e) || (*e != ((i == ETH_ALEN-1) ? '\0' : ':'))) {
+			kfree(macstr);
+			return -ENOENT;
+		}
+		s = e+1;
+	}
+
+	kfree(macstr);
+	return 0;
+}
+
+/* Common code used when first setting up, and when resuming. */
+static int talk_to_backend(struct xenbus_device *dev,
+			   struct netfront_info *info)
+{
+	const char *message;
+	struct xenbus_transaction xbt;
+	int err;
+
+	err = xen_net_read_mac(dev, info->mac);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "parsing %s/mac", dev->nodename);
+		goto out;
+	}
+
+	/* Create shared ring, alloc event channel. */
+	err = setup_device(dev, info);
+	if (err)
+		goto out;
+
+again:
+	err = xenbus_transaction_start(&xbt);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "starting transaction");
+		goto destroy_ring;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref","%u",
+			    info->tx_ring_ref);
+	if (err) {
+		message = "writing tx ring-ref";
+		goto abort_transaction;
+	}
+	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref","%u",
+			    info->rx_ring_ref);
+	if (err) {
+		message = "writing rx ring-ref";
+		goto abort_transaction;
+	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "event-channel", "%u", info->evtchn);
+	if (err) {
+		message = "writing event-channel";
+		goto abort_transaction;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
+			    info->copying_receiver);
+	if (err) {
+		message = "writing request-rx-copy";
+		goto abort_transaction;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "feature-rx-notify", "%d", 1);
+	if (err) {
+		message = "writing feature-rx-notify";
+		goto abort_transaction;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "feature-sg", "%d", 1);
+	if (err) {
+		message = "writing feature-sg";
+		goto abort_transaction;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "feature-gso-tcpv4", "%d", 1);
+	if (err) {
+		message = "writing feature-gso-tcpv4";
+		goto abort_transaction;
+	}
+
+	err = xenbus_transaction_end(xbt, 0);
+	if (err) {
+		if (err == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, err, "completing transaction");
+		goto destroy_ring;
+	}
+
+	return 0;
+
+ abort_transaction:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, err, "%s", message);
+ destroy_ring:
+	netif_disconnect_backend(info);
+ out:
+	return err;
+}
+
+static int setup_device(struct xenbus_device *dev, struct netfront_info *info)
+{
+	struct netif_tx_sring *txs;
+	struct netif_rx_sring *rxs;
+	int err;
+	struct net_device *netdev = info->netdev;
+
+	info->tx_ring_ref = GRANT_INVALID_REF;
+	info->rx_ring_ref = GRANT_INVALID_REF;
+	info->rx.sring = NULL;
+	info->tx.sring = NULL;
+	info->irq = 0;
+
+	txs = (struct netif_tx_sring *)get_zeroed_page(GFP_KERNEL);
+	if (!txs) {
+		err = -ENOMEM;
+		xenbus_dev_fatal(dev, err, "allocating tx ring page");
+		goto fail;
+	}
+	SHARED_RING_INIT(txs);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+
+	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	if (err < 0) {
+		free_page((unsigned long)txs);
+		goto fail;
+	}
+
+	info->tx_ring_ref = err;
+	rxs = (struct netif_rx_sring *)get_zeroed_page(GFP_KERNEL);
+	if (!rxs) {
+		err = -ENOMEM;
+		xenbus_dev_fatal(dev, err, "allocating rx ring page");
+		goto fail;
+	}
+	SHARED_RING_INIT(rxs);
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
+
+	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
+	if (err < 0) {
+		free_page((unsigned long)rxs);
+		goto fail;
+	}
+	info->rx_ring_ref = err;
+
+	err = xenbus_alloc_evtchn(dev, &info->evtchn);
+	if (err)
+		goto fail;
+
+	memcpy(netdev->dev_addr, info->mac, ETH_ALEN);
+	err = bind_evtchn_to_irqhandler(info->evtchn, netif_int,
+					SA_SAMPLE_RANDOM, netdev->name,
+					netdev);
+	if (err < 0)
+		goto fail;
+	info->irq = err;
+	return 0;
+
+ fail:
+	return err;
+}
+
+/**
+ * Callback received when the backend's state changes.
+ */
+static void backend_changed(struct xenbus_device *dev,
+			    enum xenbus_state backend_state)
+{
+	struct netfront_info *np = dev->dev.driver_data;
+	struct net_device *netdev = np->netdev;
+
+	DPRINTK("%s\n", xenbus_strstate(backend_state));
+
+	switch (backend_state) {
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateConnected:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		if (dev->state != XenbusStateInitialising)
+			break;
+		if (network_connect(netdev) != 0)
+			break;
+		xenbus_switch_state(dev, XenbusStateConnected);
+		(void)send_fake_arp(netdev);
+		break;
+
+	case XenbusStateClosing:
+		if (dev->state == XenbusStateClosed)
+			break;
+		netfront_closing(dev);
+		break;
+	}
+}
+
+/** Send a packet on a net device to encourage switches to learn the
+ * MAC. We send a fake ARP request.
+ *
+ * @param dev device
+ * @return 0 on success, error code otherwise
+ */
+static int send_fake_arp(struct net_device *dev)
+{
+	struct sk_buff *skb;
+	u32             src_ip, dst_ip;
+
+	dst_ip = INADDR_BROADCAST;
+	src_ip = inet_select_addr(dev, dst_ip, RT_SCOPE_LINK);
+
+	/* No IP? Then nothing to do. */
+	if (src_ip == 0)
+		return 0;
+
+	skb = arp_create(ARPOP_REPLY, ETH_P_ARP,
+			 dst_ip, dev, src_ip,
+			 /*dst_hw*/ NULL, /*src_hw*/ NULL,
+			 /*target_hw*/ dev->dev_addr);
+	if (skb == NULL)
+		return -ENOMEM;
+
+	return dev_queue_xmit(skb);
+}
+
+static int network_open(struct net_device *dev)
+{
+	struct netfront_info *np = netdev_priv(dev);
+
+	memset(&np->stats, 0, sizeof(np->stats));
+
+	spin_lock(&np->rx_lock);
+	if (netif_carrier_ok(dev)) {
+		network_alloc_rx_buffers(dev);
+		np->rx.sring->rsp_event = np->rx.rsp_cons + 1;
+		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
+			netif_rx_schedule(dev);
+	}
+	spin_unlock(&np->rx_lock);
+
+	netif_start_queue(dev);
+
+	return 0;
+}
+
+static inline int netfront_tx_slot_available(struct netfront_info *np)
+{
+	return RING_FREE_REQUESTS(&np->tx) >= MAX_SKB_FRAGS + 2;
+}
+
+static inline void network_maybe_wake_tx(struct net_device *dev)
+{
+	struct netfront_info *np = netdev_priv(dev);
+
+	if (unlikely(netif_queue_stopped(dev)) &&
+	    netfront_tx_slot_available(np) &&
+	    likely(netif_running(dev)))
+		netif_wake_queue(dev);
+}
+
+static void network_tx_buf_gc(struct net_device *dev)
+{
+	RING_IDX cons, prod;
+	unsigned short id;
+	struct netfront_info *np = netdev_priv(dev);
+	struct sk_buff *skb;
+
+	BUG_ON(!netif_carrier_ok(dev));
+
+	do {
+		prod = np->tx.sring->rsp_prod;
+		rmb(); /* Ensure we see responses up to 'rp'. */
+
+		for (cons = np->tx.rsp_cons; cons != prod; cons++) {
+			struct netif_tx_response *txrsp;
+
+			txrsp = RING_GET_RESPONSE(&np->tx, cons);
+			if (txrsp->status == NETIF_RSP_NULL)
+				continue;
+
+			id  = txrsp->id;
+			skb = np->tx_skbs[id];
+			if (unlikely(gnttab_query_foreign_access(
+				np->grant_tx_ref[id]) != 0)) {
+				printk(KERN_ALERT "network_tx_buf_gc: warning "
+				       "-- grant still in use by backend "
+				       "domain.\n");
+				BUG();
+			}
+			gnttab_end_foreign_access_ref(
+				np->grant_tx_ref[id], GNTMAP_readonly);
+			gnttab_release_grant_reference(
+				&np->gref_tx_head, np->grant_tx_ref[id]);
+			np->grant_tx_ref[id] = GRANT_INVALID_REF;
+			add_id_to_freelist(np->tx_skbs, id);
+			dev_kfree_skb_irq(skb);
+		}
+
+		np->tx.rsp_cons = prod;
+
+		/*
+		 * Set a new event, then check for race with update of tx_cons.
+		 * Note that it is essential to schedule a callback, no matter
+		 * how few buffers are pending. Even if there is space in the
+		 * transmit ring, higher layers may be blocked because too much
+		 * data is outstanding: in such cases notification from Xen is
+		 * likely to be the only kick that we'll get.
+		 */
+		np->tx.sring->rsp_event =
+			prod + ((np->tx.sring->req_prod - prod) >> 1) + 1;
+		mb();
+	} while ((cons == prod) && (prod != np->tx.sring->rsp_prod));
+
+	network_maybe_wake_tx(dev);
+}
+
+static void rx_refill_timeout(unsigned long data)
+{
+	struct net_device *dev = (struct net_device *)data;
+	netif_rx_schedule(dev);
+}
+
+static void network_alloc_rx_buffers(struct net_device *dev)
+{
+	unsigned short id;
+	struct netfront_info *np = netdev_priv(dev);
+	struct sk_buff *skb;
+	struct page *page;
+	int i, batch_target, notify;
+	RING_IDX req_prod = np->rx.req_prod_pvt;
+	struct xen_memory_reservation reservation;
+	grant_ref_t ref;
+	unsigned long pfn;
+	void *vaddr;
+	int nr_flips;
+	struct netif_rx_request *req;
+
+	if (unlikely(!netif_carrier_ok(dev)))
+		return;
+
+	/*
+	 * Allocate skbuffs greedily, even though we batch updates to the
+	 * receive ring. This creates a less bursty demand on the memory
+	 * allocator, so should reduce the chance of failed allocation requests
+	 * both for ourself and for other kernel subsystems.
+	 */
+	batch_target = np->rx_target - (req_prod - np->rx.rsp_cons);
+	for (i = skb_queue_len(&np->rx_batch); i < batch_target; i++) {
+		/*
+		 * Allocate an skb and a page. Do not use __dev_alloc_skb as
+		 * that will allocate page-sized buffers which is not
+		 * necessary here.
+		 * 16 bytes added as necessary headroom for netif_receive_skb.
+		 */
+		skb = alloc_skb(RX_COPY_THRESHOLD + 16 + NET_IP_ALIGN,
+				GFP_ATOMIC | __GFP_NOWARN);
+		if (unlikely(!skb))
+			goto no_skb;
+
+		page = alloc_page(GFP_ATOMIC | __GFP_NOWARN);
+		if (!page) {
+			kfree_skb(skb);
+no_skb:
+			/* Any skbuffs queued for refill? Force them out. */
+			if (i != 0)
+				goto refill;
+			/* Could not allocate any skbuffs. Try again later. */
+			mod_timer(&np->rx_refill_timer,
+				  jiffies + (HZ/10));
+			break;
+		}
+
+		skb_reserve(skb, 16 + NET_IP_ALIGN); /* mimic dev_alloc_skb() */
+		skb_shinfo(skb)->frags[0].page = page;
+		skb_shinfo(skb)->nr_frags = 1;
+		__skb_queue_tail(&np->rx_batch, skb);
+	}
+
+	/* Is the batch large enough to be worthwhile? */
+	if (i < (np->rx_target/2)) {
+		if (req_prod > np->rx.sring->req_prod)
+			goto push;
+		return;
+	}
+
+	/* Adjust our fill target if we risked running out of buffers. */
+	if (((req_prod - np->rx.sring->rsp_prod) < (np->rx_target / 4)) &&
+	    ((np->rx_target *= 2) > np->rx_max_target))
+		np->rx_target = np->rx_max_target;
+
+ refill:
+	for (nr_flips = i = 0; ; i++) {
+		if ((skb = __skb_dequeue(&np->rx_batch)) == NULL)
+			break;
+
+		skb->dev = dev;
+
+		id = xennet_rxidx(req_prod + i);
+
+		BUG_ON(np->rx_skbs[id]);
+		np->rx_skbs[id] = skb;
+
+		ref = gnttab_claim_grant_reference(&np->gref_rx_head);
+		BUG_ON((signed short)ref < 0);
+		np->grant_rx_ref[id] = ref;
+
+		pfn = page_to_pfn(skb_shinfo(skb)->frags[0].page);
+		vaddr = page_address(skb_shinfo(skb)->frags[0].page);
+
+		req = RING_GET_REQUEST(&np->rx, req_prod + i);
+		if (!np->copying_receiver) {
+			gnttab_grant_foreign_transfer_ref(ref,
+							  np->xbdev->otherend_id,
+							  pfn);
+			np->rx_pfn_array[nr_flips] = pfn_to_mfn(pfn);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				/* Remove this page before passing
+				 * back to Xen. */
+				set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+				MULTI_update_va_mapping(np->rx_mcl+i,
+							(unsigned long)vaddr,
+							__pte(0), 0);
+			}
+			nr_flips++;
+		} else {
+			gnttab_grant_foreign_access_ref(ref,
+							np->xbdev->otherend_id,
+							pfn_to_mfn(pfn),
+							0);
+		}
+
+		req->id = id;
+		req->gref = ref;
+	}
+
+	if ( nr_flips != 0 ) {
+#ifdef CONFIG_XEN_BALLOON
+		/* Tell the ballon driver what is going on. */
+		balloon_update_driver_allowance(i);
+#endif
+
+		reservation.extent_start = np->rx_pfn_array;
+		reservation.nr_extents   = nr_flips;
+		reservation.extent_order = 0;
+		reservation.address_bits = 0;
+		reservation.domid        = DOMID_SELF;
+
+		if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+			/* After all PTEs have been zapped, flush the TLB. */
+			np->rx_mcl[i-1].args[MULTI_UVMFLAGS_INDEX] =
+				UVMF_TLB_FLUSH|UVMF_ALL;
+
+			/* Give away a batch of pages. */
+			np->rx_mcl[i].op = __HYPERVISOR_memory_op;
+			np->rx_mcl[i].args[0] = XENMEM_decrease_reservation;
+			np->rx_mcl[i].args[1] = (unsigned long)&reservation;
+
+			/* Zap PTEs and give away pages in one big
+			 * multicall. */
+			(void)HYPERVISOR_multicall(np->rx_mcl, i+1);
+
+			/* Check return status of HYPERVISOR_memory_op(). */
+			if (unlikely(np->rx_mcl[i].result != i))
+				panic("Unable to reduce memory reservation\n");
+		} else {
+			if (HYPERVISOR_memory_op(XENMEM_decrease_reservation,
+						 &reservation) != i)
+				panic("Unable to reduce memory reservation\n");
+		}
+	} else {
+		wmb();
+	}
+
+	/* Above is a suitable barrier to ensure backend will see requests. */
+	np->rx.req_prod_pvt = req_prod + i;
+ push:
+	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
+	if (notify)
+		notify_remote_via_irq(np->irq);
+}
+
+static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
+				grant_ref_t ref)
+{
+	int new = xennet_rxidx(np->rx.req_prod_pvt);
+
+	BUG_ON(np->rx_skbs[new]);
+	np->rx_skbs[new] = skb;
+	np->grant_rx_ref[new] = ref;
+	RING_GET_REQUEST(&np->rx, np->rx.req_prod_pvt)->id = new;
+	RING_GET_REQUEST(&np->rx, np->rx.req_prod_pvt)->gref = ref;
+	np->rx.req_prod_pvt++;
+}
+
+static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
+			      struct netif_tx_request *tx)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	char *data = skb->data;
+	unsigned long mfn;
+	RING_IDX prod = np->tx.req_prod_pvt;
+	int frags = skb_shinfo(skb)->nr_frags;
+	unsigned int offset = offset_in_page(data);
+	unsigned int len = skb_headlen(skb);
+	unsigned int id;
+	grant_ref_t ref;
+	int i;
+
+	while (len > PAGE_SIZE - offset) {
+		tx->size = PAGE_SIZE - offset;
+		tx->flags |= NETTXF_more_data;
+		len -= tx->size;
+		data += tx->size;
+		offset = 0;
+
+		id = get_id_from_freelist(np->tx_skbs);
+		np->tx_skbs[id] = skb_get(skb);
+		tx = RING_GET_REQUEST(&np->tx, prod++);
+		tx->id = id;
+		ref = gnttab_claim_grant_reference(&np->gref_tx_head);
+		BUG_ON((signed short)ref < 0);
+
+		mfn = virt_to_mfn(data);
+		gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
+						mfn, GNTMAP_readonly);
+
+		tx->gref = np->grant_tx_ref[id] = ref;
+		tx->offset = offset;
+		tx->size = len;
+		tx->flags = 0;
+	}
+
+	for (i = 0; i < frags; i++) {
+		skb_frag_t *frag = skb_shinfo(skb)->frags + i;
+
+		tx->flags |= NETTXF_more_data;
+
+		id = get_id_from_freelist(np->tx_skbs);
+		np->tx_skbs[id] = skb_get(skb);
+		tx = RING_GET_REQUEST(&np->tx, prod++);
+		tx->id = id;
+		ref = gnttab_claim_grant_reference(&np->gref_tx_head);
+		BUG_ON((signed short)ref < 0);
+
+		mfn = pfn_to_mfn(page_to_pfn(frag->page));
+		gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
+						mfn, GNTMAP_readonly);
+
+		tx->gref = np->grant_tx_ref[id] = ref;
+		tx->offset = frag->page_offset;
+		tx->size = frag->size;
+		tx->flags = 0;
+	}
+
+	np->tx.req_prod_pvt = prod;
+}
+  
+static int network_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	unsigned short id;
+	struct netfront_info *np = netdev_priv(dev);
+	struct netif_tx_request *tx;
+	struct netif_extra_info *extra;
+	char *data = skb->data;
+	RING_IDX i;
+	grant_ref_t ref;
+	unsigned long mfn;
+	int notify;
+	int frags = skb_shinfo(skb)->nr_frags;
+	unsigned int offset = offset_in_page(data);
+	unsigned int len = skb_headlen(skb);
+
+	frags += (offset + len + PAGE_SIZE - 1) / PAGE_SIZE;
+	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
+		printk(KERN_ALERT "xennet: skb rides the rocket: %d frags\n",
+		       frags);
+		dump_stack();
+		goto drop;
+	}
+
+	spin_lock_irq(&np->tx_lock);
+
+	if (unlikely(!netif_carrier_ok(dev) ||
+		     (frags > 1 && !xennet_can_sg(dev)) ||
+		     netif_needs_gso(dev, skb))) {
+		spin_unlock_irq(&np->tx_lock);
+		goto drop;
+	}
+
+	i = np->tx.req_prod_pvt;
+
+	id = get_id_from_freelist(np->tx_skbs);
+	np->tx_skbs[id] = skb;
+
+	tx = RING_GET_REQUEST(&np->tx, i);
+
+	tx->id   = id;
+	ref = gnttab_claim_grant_reference(&np->gref_tx_head);
+	BUG_ON((signed short)ref < 0);
+	mfn = virt_to_mfn(data);
+	gnttab_grant_foreign_access_ref(
+		ref, np->xbdev->otherend_id, mfn, GNTMAP_readonly);
+	tx->gref = np->grant_tx_ref[id] = ref;
+	tx->offset = offset;
+	tx->size = len;
+	extra = NULL;
+
+ 	tx->flags = 0;
+ 	if (skb->ip_summed == CHECKSUM_PARTIAL) /* local packet? */
+ 		tx->flags |= NETTXF_csum_blank | NETTXF_data_validated;
+
+	if (skb_shinfo(skb)->gso_size) {
+		struct netif_extra_info *gso = (struct netif_extra_info *)
+			RING_GET_REQUEST(&np->tx, ++i);
+
+		if (extra)
+			extra->flags |= XEN_NETIF_EXTRA_FLAG_MORE;
+		else
+			tx->flags |= NETTXF_extra_info;
+
+		gso->u.gso.size = skb_shinfo(skb)->gso_size;
+		gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
+		gso->u.gso.pad = 0;
+		gso->u.gso.features = 0;
+
+		gso->type = XEN_NETIF_EXTRA_TYPE_GSO;
+		gso->flags = 0;
+		extra = gso;
+	}
+
+	np->tx.req_prod_pvt = i + 1;
+
+	xennet_make_frags(skb, dev, tx);
+	tx->size = skb->len;
+
+	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
+	if (notify)
+		notify_remote_via_irq(np->irq);
+
+	network_tx_buf_gc(dev);
+
+	if (!netfront_tx_slot_available(np))
+		netif_stop_queue(dev);
+
+	spin_unlock_irq(&np->tx_lock);
+
+	np->stats.tx_bytes += skb->len;
+	np->stats.tx_packets++;
+
+	return 0;
+
+ drop:
+	np->stats.tx_dropped++;
+	dev_kfree_skb(skb);
+	return 0;
+}
+
+static irqreturn_t netif_int(int irq, void *dev_id)
+{
+	struct net_device *dev = dev_id;
+	struct netfront_info *np = netdev_priv(dev);
+	unsigned long flags;
+
+	spin_lock_irqsave(&np->tx_lock, flags);
+
+	if (likely(netif_carrier_ok(dev))) {
+		network_tx_buf_gc(dev);
+		/* Under tx_lock: protects access to rx shared-ring indexes. */
+		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
+			netif_rx_schedule(dev);
+	}
+
+	spin_unlock_irqrestore(&np->tx_lock, flags);
+
+	return IRQ_HANDLED;
+}
+
+static void handle_incoming_queue(struct net_device *dev, struct sk_buff_head *rxq)
+{
+	struct sk_buff *skb;
+
+	while ((skb = __skb_dequeue(rxq)) != NULL) {
+		struct page *page = (struct page *)skb->nh.raw;
+		void *vaddr = page_address(page);
+
+		memcpy(skb->data, vaddr + (skb->h.raw - skb->nh.raw),
+		       skb_headlen(skb));
+
+		if (page != skb_shinfo(skb)->frags[0].page)
+			__free_page(page);
+
+		/* Ethernet work: Delayed to here as it peeks the header. */
+		skb->protocol = eth_type_trans(skb, dev);
+
+		/* Pass it up. */
+		netif_receive_skb(skb);
+		dev->last_rx = jiffies;
+	}
+}
+
+int xennet_get_extras(struct netfront_info *np,
+		      struct netif_extra_info *extras, RING_IDX rp)
+
+{
+	struct netif_extra_info *extra;
+	RING_IDX cons = np->rx.rsp_cons;
+	int err = 0;
+
+	do {
+		struct sk_buff *skb;
+		grant_ref_t ref;
+
+		if (unlikely(cons + 1 == rp)) {
+			if (net_ratelimit())
+				WPRINTK("Missing extra info\n");
+			err = -EBADR;
+			break;
+		}
+
+		extra = (struct netif_extra_info *)
+			RING_GET_RESPONSE(&np->rx, ++cons);
+
+		if (unlikely(!extra->type ||
+			     extra->type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
+			if (net_ratelimit())
+				WPRINTK("Invalid extra type: %d\n",
+					extra->type);
+			err = -EINVAL;
+		} else {
+			memcpy(&extras[extra->type - 1], extra,
+			       sizeof(*extra));
+		}
+
+		skb = xennet_get_rx_skb(np, cons);
+		ref = xennet_get_rx_ref(np, cons);
+		xennet_move_rx_slot(np, skb, ref);
+	} while (extra->flags & XEN_NETIF_EXTRA_FLAG_MORE);
+
+	np->rx.rsp_cons = cons;
+	return err;
+}
+
+static int xennet_get_responses(struct netfront_info *np,
+				struct netfront_rx_info *rinfo, RING_IDX rp,
+				struct sk_buff_head *list,
+				int *pages_flipped_p)
+{
+	int pages_flipped = *pages_flipped_p;
+	struct mmu_update *mmu;
+	struct multicall_entry *mcl;
+	struct netif_rx_response *rx = &rinfo->rx;
+	struct netif_extra_info *extras = rinfo->extras;
+	RING_IDX cons = np->rx.rsp_cons;
+	struct sk_buff *skb = xennet_get_rx_skb(np, cons);
+	grant_ref_t ref = xennet_get_rx_ref(np, cons);
+	int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD);
+	int frags = 1;
+	int err = 0;
+	unsigned long ret;
+
+	if (rx->flags & NETRXF_extra_info) {
+		err = xennet_get_extras(np, extras, rp);
+		cons = np->rx.rsp_cons;
+	}
+
+	for (;;) {
+		unsigned long mfn;
+
+		if (unlikely(rx->status < 0 ||
+			     rx->offset + rx->status > PAGE_SIZE)) {
+			if (net_ratelimit())
+				WPRINTK("rx->offset: %x, size: %u\n",
+					rx->offset, rx->status);
+			xennet_move_rx_slot(np, skb, ref);
+			err = -EINVAL;
+			goto next;
+		}
+
+		/*
+		 * This definitely indicates a bug, either in this driver or in
+		 * the backend driver. In future this should flag the bad
+		 * situation to the system controller to reboot the backed.
+		 */
+		if (ref == GRANT_INVALID_REF) {
+			if (net_ratelimit())
+				WPRINTK("Bad rx response id %d.\n", rx->id);
+			err = -EINVAL;
+			goto next;
+		}
+
+		if (!np->copying_receiver) {
+			/* Memory pressure, insufficient buffer
+			 * headroom, ... */
+			mfn = gnttab_end_foreign_transfer_ref(ref);
+			if (!mfn) {
+				if (net_ratelimit())
+					WPRINTK("Unfulfilled rx req "
+						"(id=%d, st=%d).\n",
+						rx->id, rx->status);
+				xennet_move_rx_slot(np, skb, ref);
+				err = -ENOMEM;
+				goto next;
+			}
+
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				/* Remap the page. */
+				struct page *page =
+					skb_shinfo(skb)->frags[0].page;
+				unsigned long pfn = page_to_pfn(page);
+				void *vaddr = page_address(page);
+
+				mcl = np->rx_mcl + pages_flipped;
+				mmu = np->rx_mmu + pages_flipped;
+
+				MULTI_update_va_mapping(mcl,
+							(unsigned long)vaddr,
+							mfn_pte(mfn, PAGE_KERNEL),
+							0);
+				mmu->ptr = ((u64)mfn << PAGE_SHIFT)
+					| MMU_MACHPHYS_UPDATE;
+				mmu->val = pfn;
+
+				set_phys_to_machine(pfn, mfn);
+			}
+			pages_flipped++;
+		} else {
+			ret = gnttab_end_foreign_access_ref(ref, 0);
+			BUG_ON(!ret);
+		}
+
+		gnttab_release_grant_reference(&np->gref_rx_head, ref);
+
+		__skb_queue_tail(list, skb);
+
+next:
+		if (!(rx->flags & NETRXF_more_data))
+			break;
+
+		if (cons + frags == rp) {
+			if (net_ratelimit())
+				WPRINTK("Need more frags\n");
+			err = -ENOENT;
+			break;
+		}
+
+		rx = RING_GET_RESPONSE(&np->rx, cons + frags);
+		skb = xennet_get_rx_skb(np, cons + frags);
+		ref = xennet_get_rx_ref(np, cons + frags);
+		frags++;
+	}
+
+	if (unlikely(frags > max)) {
+		if (net_ratelimit())
+			WPRINTK("Too many frags\n");
+		err = -E2BIG;
+	}
+
+	if (unlikely(err))
+		np->rx.rsp_cons = cons + frags;
+
+	*pages_flipped_p = pages_flipped;
+
+	return err;
+}
+
+static RING_IDX xennet_fill_frags(struct netfront_info *np,
+				  struct sk_buff *skb,
+				  struct sk_buff_head *list)
+{
+	struct skb_shared_info *shinfo = skb_shinfo(skb);
+	int nr_frags = shinfo->nr_frags;
+	RING_IDX cons = np->rx.rsp_cons;
+	skb_frag_t *frag = shinfo->frags + nr_frags;
+	struct sk_buff *nskb;
+
+	while ((nskb = __skb_dequeue(list))) {
+		struct netif_rx_response *rx =
+			RING_GET_RESPONSE(&np->rx, ++cons);
+
+		frag->page = skb_shinfo(nskb)->frags[0].page;
+		frag->page_offset = rx->offset;
+		frag->size = rx->status;
+
+		skb->data_len += rx->status;
+
+		skb_shinfo(nskb)->nr_frags = 0;
+		kfree_skb(nskb);
+
+		frag++;
+		nr_frags++;
+	}
+
+	shinfo->nr_frags = nr_frags;
+	return cons;
+}
+
+static int xennet_set_skb_gso(struct sk_buff *skb, struct netif_extra_info *gso)
+{
+	if (!gso->u.gso.size) {
+		if (net_ratelimit())
+			WPRINTK("GSO size must not be zero.\n");
+		return -EINVAL;
+	}
+
+	/* Currently only TCPv4 S.O. is supported. */
+	if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) {
+		if (net_ratelimit())
+			WPRINTK("Bad GSO type %d.\n", gso->u.gso.type);
+		return -EINVAL;
+	}
+
+	skb_shinfo(skb)->gso_size = gso->u.gso.size;
+	skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
+
+	/* Header must be checked, and gso_segs computed. */
+	skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
+	skb_shinfo(skb)->gso_segs = 0;
+
+	return 0;
+}
+
+static int netif_poll(struct net_device *dev, int *pbudget)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	struct sk_buff *skb;
+	struct netfront_rx_info rinfo;
+	struct netif_rx_response *rx = &rinfo.rx;
+	struct netif_extra_info *extras = rinfo.extras;
+	RING_IDX i, rp;
+	struct multicall_entry *mcl;
+	int work_done, budget, more_to_do = 1;
+	struct sk_buff_head rxq;
+	struct sk_buff_head errq;
+	struct sk_buff_head tmpq;
+	unsigned long flags;
+	unsigned int len;
+	int pages_flipped = 0;
+	int err;
+
+	spin_lock(&np->rx_lock);
+
+	if (unlikely(!netif_carrier_ok(dev))) {
+		spin_unlock(&np->rx_lock);
+		return 0;
+	}
+
+	skb_queue_head_init(&rxq);
+	skb_queue_head_init(&errq);
+	skb_queue_head_init(&tmpq);
+
+	if ((budget = *pbudget) > dev->quota)
+		budget = dev->quota;
+	rp = np->rx.sring->rsp_prod;
+	rmb(); /* Ensure we see queued responses up to 'rp'. */
+
+	i = np->rx.rsp_cons;
+	work_done = 0;
+	while ((i != rp) && (work_done < budget)) {
+		memcpy(rx, RING_GET_RESPONSE(&np->rx, i), sizeof(*rx));
+		memset(extras, 0, sizeof(extras));
+
+		err = xennet_get_responses(np, &rinfo, rp, &tmpq,
+					   &pages_flipped);
+
+		if (unlikely(err)) {
+err:	
+			while ((skb = __skb_dequeue(&tmpq)))
+				__skb_queue_tail(&errq, skb);
+			np->stats.rx_errors++;
+			i = np->rx.rsp_cons;
+			continue;
+		}
+
+		skb = __skb_dequeue(&tmpq);
+
+		if (extras[XEN_NETIF_EXTRA_TYPE_GSO - 1].type) {
+			struct netif_extra_info *gso;
+			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
+
+			if (unlikely(xennet_set_skb_gso(skb, gso))) {
+				__skb_queue_head(&tmpq, skb);
+				np->rx.rsp_cons += skb_queue_len(&tmpq);
+				goto err;
+			}
+		}
+
+		skb->nh.raw = (void *)skb_shinfo(skb)->frags[0].page;
+		skb->h.raw = skb->nh.raw + rx->offset;
+
+		len = rx->status;
+		if (len > RX_COPY_THRESHOLD)
+			len = RX_COPY_THRESHOLD;
+		skb_put(skb, len);
+
+		if (rx->status > len) {
+			skb_shinfo(skb)->frags[0].page_offset =
+				rx->offset + len;
+			skb_shinfo(skb)->frags[0].size = rx->status - len;
+			skb->data_len = rx->status - len;
+		} else {
+			skb_shinfo(skb)->frags[0].page = NULL;
+			skb_shinfo(skb)->nr_frags = 0;
+		}
+
+		i = xennet_fill_frags(np, skb, &tmpq);
+
+		/*
+		 * Truesize must approximates the size of true data plus
+		 * any supervisor overheads. Adding hypervisor overheads
+		 * has been shown to significantly reduce achievable
+		 * bandwidth with the default receive buffer size. It is
+		 * therefore not wise to account for it here.
+		 *
+		 * After alloc_skb(RX_COPY_THRESHOLD), truesize is set to
+		 * RX_COPY_THRESHOLD + the supervisor overheads. Here, we
+		 * add the size of the data pulled in xennet_fill_frags().
+		 *
+		 * We also adjust for any unused space in the main data
+		 * area by subtracting (RX_COPY_THRESHOLD - len). This is
+		 * especially important with drivers which split incoming
+		 * packets into header and data, using only 66 bytes of
+		 * the main data area (see the e1000 driver for example.)
+		 * On such systems, without this last adjustement, our
+		 * achievable receive throughout using the standard receive
+		 * buffer size was cut by 25%(!!!).
+		 */
+		skb->truesize += skb->data_len - (RX_COPY_THRESHOLD - len);
+		skb->len += skb->data_len;
+
+		if (rx->flags & NETRXF_data_validated)
+			skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+		np->stats.rx_packets++;
+		np->stats.rx_bytes += skb->len;
+
+		__skb_queue_tail(&rxq, skb);
+
+		np->rx.rsp_cons = ++i;
+		work_done++;
+	}
+
+	if (pages_flipped) {
+#ifdef CONFIG_XEN_BALLOON
+		/* Some pages are no longer absent... */
+		balloon_update_driver_allowance(-pages_flipped);
+#endif
+		/* Do all the remapping work, and M2P updates. */
+		if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+			mcl = np->rx_mcl + pages_flipped;
+			MULTI_mmu_update(mcl, np->rx_mmu,
+					 pages_flipped, 0, DOMID_SELF);
+			(void)HYPERVISOR_multicall(np->rx_mcl,
+						   pages_flipped + 1);
+		}
+	}
+
+	while ((skb = __skb_dequeue(&errq)))
+		kfree_skb(skb);
+
+	handle_incoming_queue(dev, &rxq);
+
+	/* If we get a callback with very few responses, reduce fill target. */
+	/* NB. Note exponential increase, linear decrease. */
+	if (((np->rx.req_prod_pvt - np->rx.sring->rsp_prod) >
+	     ((3*np->rx_target) / 4)) &&
+	    (--np->rx_target < np->rx_min_target))
+		np->rx_target = np->rx_min_target;
+
+	network_alloc_rx_buffers(dev);
+
+	*pbudget   -= work_done;
+	dev->quota -= work_done;
+
+	if (work_done < budget) {
+		local_irq_save(flags);
+
+		RING_FINAL_CHECK_FOR_RESPONSES(&np->rx, more_to_do);
+		if (!more_to_do)
+			__netif_rx_complete(dev);
+
+		local_irq_restore(flags);
+	}
+
+	spin_unlock(&np->rx_lock);
+
+	return more_to_do;
+}
+
+static void netif_release_tx_bufs(struct netfront_info *np)
+{
+	struct sk_buff *skb;
+	int i;
+
+	for (i = 1; i <= NET_TX_RING_SIZE; i++) {
+		if ((unsigned long)np->tx_skbs[i] < PAGE_OFFSET)
+			continue;
+
+		skb = np->tx_skbs[i];
+		gnttab_end_foreign_access_ref(
+			np->grant_tx_ref[i], GNTMAP_readonly);
+		gnttab_release_grant_reference(
+			&np->gref_tx_head, np->grant_tx_ref[i]);
+		np->grant_tx_ref[i] = GRANT_INVALID_REF;
+		add_id_to_freelist(np->tx_skbs, i);
+		dev_kfree_skb_irq(skb);
+	}
+}
+
+static void netif_release_rx_bufs(struct netfront_info *np)
+{
+	struct mmu_update      *mmu = np->rx_mmu;
+	struct multicall_entry *mcl = np->rx_mcl;
+	struct sk_buff_head free_list;
+	struct sk_buff *skb;
+	unsigned long mfn;
+	int xfer = 0, noxfer = 0, unused = 0;
+	int id, ref;
+
+	if (np->copying_receiver) {
+		printk("%s: fix me for copying receiver.\n", __FUNCTION__);
+		return;
+	}
+
+	skb_queue_head_init(&free_list);
+
+	spin_lock(&np->rx_lock);
+
+	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+		if ((ref = np->grant_rx_ref[id]) == GRANT_INVALID_REF) {
+			unused++;
+			continue;
+		}
+
+		skb = np->rx_skbs[id];
+		mfn = gnttab_end_foreign_transfer_ref(ref);
+		gnttab_release_grant_reference(&np->gref_rx_head, ref);
+		np->grant_rx_ref[id] = GRANT_INVALID_REF;
+		add_id_to_freelist(np->rx_skbs, id);
+
+		if (0 == mfn) {
+#ifdef CONFIG_XEN_BALLOON
+			struct page *page = skb_shinfo(skb)->frags[0].page;
+			balloon_release_driver_page(page);
+#endif
+			skb_shinfo(skb)->nr_frags = 0;
+			dev_kfree_skb(skb);
+			noxfer++;
+			continue;
+		}
+
+		if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+			/* Remap the page. */
+			struct page *page = skb_shinfo(skb)->frags[0].page;
+			unsigned long pfn = page_to_pfn(page);
+			void *vaddr = page_address(page);
+
+			MULTI_update_va_mapping(mcl, (unsigned long)vaddr,
+						mfn_pte(mfn, PAGE_KERNEL),
+						0);
+			mcl++;
+			mmu->ptr = ((u64)mfn << PAGE_SHIFT)
+				| MMU_MACHPHYS_UPDATE;
+			mmu->val = pfn;
+			mmu++;
+
+			set_phys_to_machine(pfn, mfn);
+		}
+		__skb_queue_tail(&free_list, skb);
+		xfer++;
+	}
+
+	printk("%s: %d xfer, %d noxfer, %d unused\n",
+	       __FUNCTION__, xfer, noxfer, unused);
+
+	if (xfer) {
+#ifdef CONFIG_XEN_BALLOON
+		/* Some pages are no longer absent... */
+		balloon_update_driver_allowance(-xfer);
+#endif
+
+		if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+			/* Do all the remapping work and M2P updates. */
+			mcl->op = __HYPERVISOR_mmu_update;
+			mcl->args[0] = (unsigned long)np->rx_mmu;
+			mcl->args[1] = mmu - np->rx_mmu;
+			mcl->args[2] = 0;
+			mcl->args[3] = DOMID_SELF;
+			mcl++;
+			HYPERVISOR_multicall(np->rx_mcl, mcl - np->rx_mcl);
+		}
+	}
+
+	while ((skb = __skb_dequeue(&free_list)) != NULL)
+		dev_kfree_skb(skb);
+
+	spin_unlock(&np->rx_lock);
+}
+
+static int network_close(struct net_device *dev)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	netif_stop_queue(np->netdev);
+	return 0;
+}
+
+
+static struct net_device_stats *network_get_stats(struct net_device *dev)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	return &np->stats;
+}
+
+static int xennet_change_mtu(struct net_device *dev, int mtu)
+{
+	int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN;
+
+	if (mtu > max)
+		return -EINVAL;
+	dev->mtu = mtu;
+	return 0;
+}
+
+static int xennet_set_sg(struct net_device *dev, u32 data)
+{
+	if (data) {
+		struct netfront_info *np = netdev_priv(dev);
+		int val;
+
+		if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-sg",
+				 "%d", &val) < 0)
+			val = 0;
+		if (!val)
+			return -ENOSYS;
+	} else if (dev->mtu > ETH_DATA_LEN)
+		dev->mtu = ETH_DATA_LEN;
+
+	return ethtool_op_set_sg(dev, data);
+}
+
+static int xennet_set_tso(struct net_device *dev, u32 data)
+{
+	if (data) {
+		struct netfront_info *np = netdev_priv(dev);
+		int val;
+
+		if (xenbus_scanf(XBT_NIL, np->xbdev->otherend,
+				 "feature-gso-tcpv4", "%d", &val) < 0)
+			val = 0;
+		if (!val)
+			return -ENOSYS;
+	}
+
+	return ethtool_op_set_tso(dev, data);
+}
+
+static void xennet_set_features(struct net_device *dev)
+{
+	/* Turn off all GSO bits except ROBUST. */
+	dev->features &= (1 << NETIF_F_GSO_SHIFT) - 1;
+	dev->features |= NETIF_F_GSO_ROBUST;
+	xennet_set_sg(dev, 0);
+
+	/* We need checksum offload to enable scatter/gather and TSO. */
+	if (!(dev->features & NETIF_F_IP_CSUM))
+		return;
+
+	if (!xennet_set_sg(dev, 1))
+		xennet_set_tso(dev, 1);
+}
+
+static int network_connect(struct net_device *dev)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	int i, requeue_idx, err;
+	struct sk_buff *skb;
+	grant_ref_t ref;
+	struct netif_rx_request *req;
+	unsigned int feature_rx_copy, feature_rx_flip;
+
+	err = xenbus_scanf(XBT_NIL, np->xbdev->otherend,
+			   "feature-rx-copy", "%u", &feature_rx_copy);
+	if (err != 1)
+		feature_rx_copy = 0;
+	err = xenbus_scanf(XBT_NIL, np->xbdev->otherend,
+			   "feature-rx-flip", "%u", &feature_rx_flip);
+	if (err != 1)
+		feature_rx_flip = 1;
+
+	/*
+	 * Copy packets on receive path if:
+	 *  (a) This was requested by user, and the backend supports it; or
+	 *  (b) Flipping was requested, but this is unsupported by the backend.
+	 */
+	np->copying_receiver = ((MODPARM_rx_copy && feature_rx_copy) ||
+				(MODPARM_rx_flip && !feature_rx_flip));
+
+	err = talk_to_backend(np->xbdev, np);
+	if (err)
+		return err;
+
+	xennet_set_features(dev);
+
+	IPRINTK("device %s has %sing receive path.\n",
+		dev->name, np->copying_receiver ? "copy" : "flipp");
+
+	spin_lock_irq(&np->tx_lock);
+	spin_lock(&np->rx_lock);
+
+	/*
+	 * Recovery procedure:
+	 *  NB. Freelist index entries are always going to be less than
+	 *  PAGE_OFFSET, whereas pointers to skbs will always be equal or
+	 *  greater than PAGE_OFFSET: we use this property to distinguish
+	 *  them.
+	 */
+
+	/* Step 1: Discard all pending TX packet fragments. */
+	netif_release_tx_bufs(np);
+
+	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+		if (!np->rx_skbs[i])
+			continue;
+
+		skb = np->rx_skbs[requeue_idx] = xennet_get_rx_skb(np, i);
+		ref = np->grant_rx_ref[requeue_idx] = xennet_get_rx_ref(np, i);
+		req = RING_GET_REQUEST(&np->rx, requeue_idx);
+
+		if (!np->copying_receiver) {
+			gnttab_grant_foreign_transfer_ref(
+				ref, np->xbdev->otherend_id,
+				page_to_pfn(skb_shinfo(skb)->frags->page));
+		} else {
+			gnttab_grant_foreign_access_ref(
+				ref, np->xbdev->otherend_id,
+				pfn_to_mfn(page_to_pfn(skb_shinfo(skb)->
+						       frags->page)),
+				0);
+		}
+		req->gref = ref;
+		req->id   = requeue_idx;
+
+		requeue_idx++;
+	}
+
+	np->rx.req_prod_pvt = requeue_idx;
+
+	/*
+	 * Step 3: All public and private state should now be sane.  Get
+	 * ready to start sending and receiving packets and give the driver
+	 * domain a kick because we've probably just requeued some
+	 * packets.
+	 */
+	netif_carrier_on(dev);
+	notify_remote_via_irq(np->irq);
+	network_tx_buf_gc(dev);
+	network_alloc_rx_buffers(dev);
+
+	spin_unlock(&np->rx_lock);
+	spin_unlock_irq(&np->tx_lock);
+
+	return 0;
+}
+
+static void netif_uninit(struct net_device *dev)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	netif_release_tx_bufs(np);
+	netif_release_rx_bufs(np);
+	gnttab_free_grant_references(np->gref_tx_head);
+	gnttab_free_grant_references(np->gref_rx_head);
+}
+
+static struct ethtool_ops network_ethtool_ops =
+{
+	.get_tx_csum = ethtool_op_get_tx_csum,
+	.set_tx_csum = ethtool_op_set_tx_csum,
+	.get_sg = ethtool_op_get_sg,
+	.set_sg = xennet_set_sg,
+	.get_tso = ethtool_op_get_tso,
+	.set_tso = xennet_set_tso,
+	.get_link = ethtool_op_get_link,
+};
+
+#ifdef CONFIG_SYSFS
+static ssize_t show_rxbuf_min(struct device *dev, 
+			      struct device_attribute *attr, char *buf)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct netfront_info *info = netdev_priv(netdev);
+
+	return sprintf(buf, "%u\n", info->rx_min_target);
+}
+
+static ssize_t store_rxbuf_min(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t len)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct netfront_info *np = netdev_priv(netdev);
+	char *endp;
+	unsigned long target;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	target = simple_strtoul(buf, &endp, 0);
+	if (endp == buf)
+		return -EBADMSG;
+
+	if (target < RX_MIN_TARGET)
+		target = RX_MIN_TARGET;
+	if (target > RX_MAX_TARGET)
+		target = RX_MAX_TARGET;
+
+	spin_lock(&np->rx_lock);
+	if (target > np->rx_max_target)
+		np->rx_max_target = target;
+	np->rx_min_target = target;
+	if (target > np->rx_target)
+		np->rx_target = target;
+
+	network_alloc_rx_buffers(netdev);
+
+	spin_unlock(&np->rx_lock);
+	return len;
+}
+
+static ssize_t show_rxbuf_max(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct netfront_info *info = netdev_priv(netdev);
+
+	return sprintf(buf, "%u\n", info->rx_max_target);
+}
+
+static ssize_t store_rxbuf_max(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t len)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct netfront_info *np = netdev_priv(netdev);
+	char *endp;
+	unsigned long target;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	target = simple_strtoul(buf, &endp, 0);
+	if (endp == buf)
+		return -EBADMSG;
+
+	if (target < RX_MIN_TARGET)
+		target = RX_MIN_TARGET;
+	if (target > RX_MAX_TARGET)
+		target = RX_MAX_TARGET;
+
+	spin_lock(&np->rx_lock);
+	if (target < np->rx_min_target)
+		np->rx_min_target = target;
+	np->rx_max_target = target;
+	if (target < np->rx_target)
+		np->rx_target = target;
+
+	network_alloc_rx_buffers(netdev);
+
+	spin_unlock(&np->rx_lock);
+	return len;
+}
+
+static ssize_t show_rxbuf_cur(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct netfront_info *info = netdev_priv(netdev);
+
+	return sprintf(buf, "%u\n", info->rx_target);
+}
+
+static struct device_attribute xennet_attrs[] = {
+	__ATTR(rxbuf_min, S_IRUGO|S_IWUSR, show_rxbuf_min, store_rxbuf_min),
+	__ATTR(rxbuf_max, S_IRUGO|S_IWUSR, show_rxbuf_max, store_rxbuf_max),
+	__ATTR(rxbuf_cur, S_IRUGO, show_rxbuf_cur, NULL),
+};
+
+static int xennet_sysfs_addif(struct net_device *netdev)
+{
+	int i;
+	int error = 0;
+
+	for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++) {
+		error = device_create_file(&netdev->dev, 
+					   &xennet_attrs[i]);
+		if (error)
+			goto fail;
+	}
+	return 0;
+
+ fail:
+	while (--i >= 0)
+		device_remove_file(&netdev->dev, &xennet_attrs[i]);
+	return error;
+}
+
+static void xennet_sysfs_delif(struct net_device *netdev)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++) {
+		device_remove_file(&netdev->dev, &xennet_attrs[i]);
+	}
+}
+
+#endif /* CONFIG_SYSFS */
+
+
+/*
+ * Nothing to do here. Virtual interface is point-to-point and the
+ * physical interface is probably promiscuous anyway.
+ */
+static void network_set_multicast_list(struct net_device *dev)
+{
+}
+
+static struct net_device * __devinit create_netdev(struct xenbus_device *dev)
+{
+	int i, err = 0;
+	struct net_device *netdev = NULL;
+	struct netfront_info *np = NULL;
+
+	netdev = alloc_etherdev(sizeof(struct netfront_info));
+	if (!netdev) {
+		printk(KERN_WARNING "%s> alloc_etherdev failed.\n",
+		       __FUNCTION__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	np                   = netdev_priv(netdev);
+	np->xbdev            = dev;
+
+	netif_carrier_off(netdev);
+
+	spin_lock_init(&np->tx_lock);
+	spin_lock_init(&np->rx_lock);
+
+	skb_queue_head_init(&np->rx_batch);
+	np->rx_target     = RX_DFL_MIN_TARGET;
+	np->rx_min_target = RX_DFL_MIN_TARGET;
+	np->rx_max_target = RX_MAX_TARGET;
+
+	init_timer(&np->rx_refill_timer);
+	np->rx_refill_timer.data = (unsigned long)netdev;
+	np->rx_refill_timer.function = rx_refill_timeout;
+
+	/* Initialise {tx,rx}_skbs as a free chain containing every entry. */
+	for (i = 0; i <= NET_TX_RING_SIZE; i++) {
+		np->tx_skbs[i] = (void *)((unsigned long) i+1);
+		np->grant_tx_ref[i] = GRANT_INVALID_REF;
+	}
+
+	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+		np->rx_skbs[i] = NULL;
+		np->grant_rx_ref[i] = GRANT_INVALID_REF;
+	}
+
+	/* A grant for every tx ring slot */
+	if (gnttab_alloc_grant_references(TX_MAX_TARGET,
+					  &np->gref_tx_head) < 0) {
+		printk(KERN_ALERT "#### netfront can't alloc tx grant refs\n");
+		err = -ENOMEM;
+		goto exit;
+	}
+	/* A grant for every rx ring slot */
+	if (gnttab_alloc_grant_references(RX_MAX_TARGET,
+					  &np->gref_rx_head) < 0) {
+		printk(KERN_ALERT "#### netfront can't alloc rx grant refs\n");
+		err = -ENOMEM;
+		goto exit_free_tx;
+	}
+
+	netdev->open            = network_open;
+	netdev->hard_start_xmit = network_start_xmit;
+	netdev->stop            = network_close;
+	netdev->get_stats       = network_get_stats;
+	netdev->poll            = netif_poll;
+	netdev->set_multicast_list = network_set_multicast_list;
+	netdev->uninit          = netif_uninit;
+	netdev->change_mtu	= xennet_change_mtu;
+	netdev->weight          = 64;
+	netdev->features        = NETIF_F_IP_CSUM;
+
+	SET_ETHTOOL_OPS(netdev, &network_ethtool_ops);
+	SET_MODULE_OWNER(netdev);
+	SET_NETDEV_DEV(netdev, &dev->dev);
+
+	np->netdev = netdev;
+	return netdev;
+
+ exit_free_tx:
+	gnttab_free_grant_references(np->gref_tx_head);
+ exit:
+	free_netdev(netdev);
+	return ERR_PTR(err);
+}
+
+/*
+ * We use this notifier to send out a fake ARP reply to reset switches and
+ * router ARP caches when an IP interface is brought up on a VIF.
+ */
+static int
+inetdev_notify(struct notifier_block *this, unsigned long event, void *ptr)
+{
+	struct in_ifaddr  *ifa = (struct in_ifaddr *)ptr;
+	struct net_device *dev = ifa->ifa_dev->dev;
+
+	/* UP event and is it one of our devices? */
+	if (event == NETDEV_UP && dev->open == network_open)
+		(void)send_fake_arp(dev);
+
+	return NOTIFY_DONE;
+}
+
+
+/* ** Close down ** */
+
+
+/**
+ * Handle the change of state of the backend to Closing.  We must delete our
+ * device-layer structures now, to ensure that writes are flushed through to
+ * the backend.  Once is this done, we can switch to Closed in
+ * acknowledgement.
+ */
+static void netfront_closing(struct xenbus_device *dev)
+{
+	struct netfront_info *info = dev->dev.driver_data;
+
+	DPRINTK("%s\n", dev->nodename);
+
+	close_netdev(info);
+	xenbus_frontend_closed(dev);
+}
+
+
+static int __devexit netfront_remove(struct xenbus_device *dev)
+{
+	struct netfront_info *info = dev->dev.driver_data;
+
+	DPRINTK("%s\n", dev->nodename);
+
+	netif_disconnect_backend(info);
+	free_netdev(info->netdev);
+
+	return 0;
+}
+
+
+static int open_netdev(struct netfront_info *info)
+{
+	int err;
+	
+	err = register_netdev(info->netdev);
+	if (err) {
+		printk(KERN_WARNING "%s: register_netdev err=%d\n",
+		       __FUNCTION__, err);
+		return err;
+	}
+
+	err = xennet_sysfs_addif(info->netdev);
+	if (err) {
+		unregister_netdev(info->netdev);
+		printk(KERN_WARNING "%s: add sysfs failed err=%d\n",
+		       __FUNCTION__, err);
+		return err;
+	}
+
+	return 0;
+}
+
+static void close_netdev(struct netfront_info *info)
+{
+	del_timer_sync(&info->rx_refill_timer);
+
+	xennet_sysfs_delif(info->netdev);
+	unregister_netdev(info->netdev);
+}
+
+
+static void netif_disconnect_backend(struct netfront_info *info)
+{
+	/* Stop old i/f to prevent errors whilst we rebuild the state. */
+	spin_lock_irq(&info->tx_lock);
+	spin_lock(&info->rx_lock);
+	netif_carrier_off(info->netdev);
+	spin_unlock(&info->rx_lock);
+	spin_unlock_irq(&info->tx_lock);
+
+	if (info->irq)
+		unbind_from_irqhandler(info->irq, info->netdev);
+	info->evtchn = info->irq = 0;
+
+	end_access(info->tx_ring_ref, info->tx.sring);
+	end_access(info->rx_ring_ref, info->rx.sring);
+	info->tx_ring_ref = GRANT_INVALID_REF;
+	info->rx_ring_ref = GRANT_INVALID_REF;
+	info->tx.sring = NULL;
+	info->rx.sring = NULL;
+}
+
+
+static void end_access(int ref, void *page)
+{
+	if (ref != GRANT_INVALID_REF)
+		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
+}
+
+
+/* ** Driver registration ** */
+
+
+static struct xenbus_device_id netfront_ids[] = {
+	{ "vif" },
+	{ "" }
+};
+
+
+static struct xenbus_driver netfront = {
+	.name = "vif",
+	.owner = THIS_MODULE,
+	.ids = netfront_ids,
+	.probe = netfront_probe,
+	.remove = __devexit_p(netfront_remove),
+	.resume = netfront_resume,
+	.otherend_changed = backend_changed,
+};
+
+
+static struct notifier_block notifier_inetdev = {
+	.notifier_call  = inetdev_notify,
+};
+
+static int __init netif_init(void)
+{
+	if (!is_running_on_xen())
+		return -ENODEV;
+
+#ifdef CONFIG_XEN
+	if (MODPARM_rx_flip && MODPARM_rx_copy) {
+		WPRINTK("Cannot specify both rx_copy and rx_flip.\n");
+		return -EINVAL;
+	}
+
+	if (!MODPARM_rx_flip && !MODPARM_rx_copy)
+		MODPARM_rx_flip = 1; /* Default is to flip. */
+#endif
+
+	if (is_initial_xendomain())
+		return 0;
+
+	IPRINTK("Initialising virtual ethernet driver.\n");
+
+	(void)register_inetaddr_notifier(&notifier_inetdev);
+
+	return xenbus_register_frontend(&netfront);
+}
+module_init(netif_init);
+
+
+static void __exit netif_exit(void)
+{
+	if (is_initial_xendomain())
+		return;
+
+	unregister_inetaddr_notifier(&notifier_inetdev);
+
+	return xenbus_unregister_driver(&netfront);
+}
+module_exit(netif_exit);
+
+MODULE_LICENSE("Dual BSD/GPL");
===================================================================
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -2,6 +2,8 @@
 #define _XEN_EVENTS_H
 
 #include <linux/irq.h>
+#include <xen/interface/event_channel.h>
+#include <asm/xen/hypercall.h>
 
 int bind_evtchn_to_irqhandler(unsigned int evtchn,
 			      irqreturn_t (*handler)(int, void *),

-- 


^ permalink raw reply	[flat|nested] 45+ messages in thread

end of thread, other threads:[~2007-02-16  4:49 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20070213221729.772002682@goop.org>
     [not found] ` <20070213221829.929261125@goop.org>
2007-02-13 22:39   ` [patch 06/21] Xen-paravirt: remove ctor for pgd cache Zachary Amsden
     [not found] ` <20070213221830.466651996@goop.org>
2007-02-13 22:45   ` [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes Zachary Amsden
2007-02-13 22:49     ` Jeremy Fitzhardinge
2007-02-13 22:54       ` Zachary Amsden
2007-02-13 23:13         ` Jeremy Fitzhardinge
2007-02-14  5:38     ` [Xen-devel] " Rusty Russell
     [not found] ` <20070213221830.542511707@goop.org>
2007-02-13 22:53   ` [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options Dan Hecht
2007-02-13 23:29     ` Jeremy Fitzhardinge
2007-02-13 23:58       ` [Xen-devel] " Zachary Amsden
2007-02-13 23:58       ` Dan Hecht
     [not found] ` <20070213221830.238235953@goop.org>
2007-02-14  1:06   ` [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions Zachary Amsden
2007-02-14  1:16     ` Jeremy Fitzhardinge
2007-02-14  1:18       ` Zachary Amsden
2007-02-14  1:37         ` Jeremy Fitzhardinge
2007-02-14  1:43           ` Zachary Amsden
2007-02-14  1:44             ` Jeremy Fitzhardinge
2007-02-14  5:51     ` Rusty Russell
2007-02-14 19:36     ` Christoph Hellwig
     [not found] ` <20070213221829.845132535@goop.org>
2007-02-14  1:23   ` [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot Dan Hecht
2007-02-14  1:36     ` Jeremy Fitzhardinge
2007-02-14  2:34       ` Dan Hecht
2007-02-14  8:43         ` Gerd Hoffmann
2007-02-14  8:37       ` [Xen-devel] " Jan Beulich
2007-02-14  9:15         ` Andi Kleen
     [not found] ` <20070213221829.513618819@goop.org>
2007-02-14  9:24   ` [patch 02/21] Xen-paravirt: Handle a zero-sized VT console Gerd Hoffmann
     [not found] ` <20070213221830.707197267@goop.org>
2007-02-13 23:54   ` [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen Andi Kleen
2007-02-14  0:39     ` Jeremy Fitzhardinge
2007-02-14  8:56       ` [Xen-devel] " Jan Beulich
2007-02-14 18:53     ` Jeremy Fitzhardinge
2007-02-14 20:10       ` Eric W. Biederman
2007-02-14 20:41         ` Jeremy Fitzhardinge
2007-02-14 21:06           ` Eric W. Biederman
2007-02-15  0:13             ` Jeremy Fitzhardinge
2007-02-15  1:39               ` Eric W. Biederman
2007-02-15  1:52                 ` Jeremy Fitzhardinge
2007-02-15  2:18                   ` Eric W. Biederman
2007-02-15  2:23                     ` Jeremy Fitzhardinge
2007-02-15  2:41                       ` Eric W. Biederman
2007-02-14 20:33   ` Eric W. Biederman
2007-02-14 20:42     ` Jeremy Fitzhardinge
     [not found] ` <20070213221831.150207238@goop.org>
2007-02-14 20:40   ` [patch 21/21] Xen-paravirt: Add the Xen virtual network device driver Eric W. Biederman
     [not found] ` <20070213221830.619562494@goop.org>
2007-02-14 20:45   ` [patch 15/21] Xen-paravirt: Add Xen interface header files Eric W. Biederman
2007-02-15  0:10     ` Jeremy Fitzhardinge
2007-02-15 17:32       ` Christoph Hellwig
2007-02-16  2:24 [patch 00/21] Xen-paravirt: Xen guest implementation for paravirt_ops interface Jeremy Fitzhardinge
2007-02-16  2:25 ` [patch 21/21] Xen-paravirt: Add the Xen virtual network device driver Jeremy Fitzhardinge

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).