Re: [Xen-devel] [patch 03/44] usermodehelper: split setup from execution

Re: [Xen-devel] [patch 03/44] usermodehelper: split setup from execution

[Rusty Russell]

On Mon, 2007-07-16 at 16:15 -0700, Jeremy Fitzhardinge wrote:
> plain text document attachment (usermodehelper-split-init.patch)
> Rather than having hundreds of variations of call_usermodehelper for
> various pieces of usermode state which could be set up, split the
> info allocation and initialization from the actual process execution.
> 
> This means the general pattern becomes:
>  info = call_usermodehelper_setup(path, argv, envp); /* basic state */
>  call_usermodehelper_<SET EXTRA STATE>(info, stuff...);	/* extra state */
>  call_usermodehelper_exec(info, wait);	/* run process and free info */

The patch seems fine, but the names are awkward.  They've always been
awkward (it's *userspace* helper, not *usermode* helper), but this just
shines a bright light on them.

So how about:

	call_usermodehelper_setup -> create_userspace_helper
	call_usermodehelper_<SET_EXTRA_STATE> -> userspace_helper_...
	call_usermodehelper_exec -> run_userspace_helper

I can do that as a separate patch if you prefer (but it'd be nice to
have it in the same merge window so the interface only churns once).

Rusty.

Re: [Xen-devel] [patch 03/44] usermodehelper: split setup from execution

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> The patch seems fine, but the names are awkward.  They've always been
> awkward (it's *userspace* helper, not *usermode* helper), but this just
> shines a bright light on them.
>
> So how about:
>
> 	call_usermodehelper_setup -> create_userspace_helper
> 	call_usermodehelper_<SET_EXTRA_STATE> -> userspace_helper_...
> 	call_usermodehelper_exec -> run_userspace_helper
>
> I can do that as a separate patch if you prefer (but it'd be nice to
> have it in the same merge window so the interface only churns once).

I don't have any particular objection, but I think it would be nicer if
they had a common prefix so that they're obviously related, and you can
easily infer the lifetime of the info structure.

    J

Re: [Xen-devel] [patch 17/44] Add nosegneg capability to the vsyscall page notes

[Rusty Russell]

On Mon, 2007-07-16 at 16:15 -0700, Jeremy Fitzhardinge wrote:
> plain text document attachment (xen-vsyscall-note.patch)
> 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.

Hmm, this is still unconditional?  Not that it causes any measurable
slowdown when enabled, but ISTR discussing making this dynamic...

Rusty.

Re: [Xen-devel] [patch 17/44] Add nosegneg capability to the vsyscall page notes

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> On Mon, 2007-07-16 at 16:15 -0700, Jeremy Fitzhardinge wrote:
>   
>> plain text document attachment (xen-vsyscall-note.patch)
>> 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.
>>     
>
> Hmm, this is still unconditional?  Not that it causes any measurable
> slowdown when enabled, but ISTR discussing making this dynamic...

Played with it for a bit, but it's fairly fiddly.  Didn't seem like it
was worth the complexity.

    J

Re: [patch 37/44] xen: add virtual network device driver

[Jeff Garzik]

Jeremy Fitzhardinge wrote:
> 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: Jeremy Fitzhardinge <jeremy@xensource.com>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> Cc: Ian Pratt <ian.pratt@xensource.com>
> Cc: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
> Cc: Jeff Garzik <jeff@garzik.org>
> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
> Cc: netdev@vger.kernel.org

Seems fairly reasonable.  ACK, presuming Xen dependencies are also merged.

	Jeff

Re: [patch 37/44] xen: add virtual network device driver

[Stephen Hemminger]

> +struct netfront_info {
> +	struct list_head list;
> +	struct net_device *netdev;
> +
> +	struct net_device_stats stats;

There is now a net_device_stats element inside net_device on
2.6.21 or later.

> +
> +	struct xen_netif_tx_front_ring tx;
> +	struct xen_netif_rx_front_ring rx;
> +
> +	spinlock_t   tx_lock;
> +	spinlock_t   rx_lock;

It might be a performance advantage to reorder/align these
structure elements to put transmit hot elements together, and
put tx and rx on different cache lines?

> +	unsigned int evtchn;
> +
> +	/* 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. Free tx_skb entries
> +	 * are linked from tx_skb_freelist through skb_entry.link.
> +	 *
> +	 *  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.
> +	 */
> +	union skb_entry {
> +		struct sk_buff *skb;
> +		unsigned link;
> +	} tx_skbs[NET_TX_RING_SIZE];
> +	grant_ref_t gref_tx_head;
> +	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> +	unsigned tx_skb_freelist;
> +
> +	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> +	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;
> +
> +	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];
> +};

Re: [patch 37/44] xen: add virtual network device driver

[Jeremy Fitzhardinge]

Stephen Hemminger wrote:
>> +struct netfront_info {
>> +	struct list_head list;
>> +	struct net_device *netdev;
>> +
>> +	struct net_device_stats stats;
>>     
>
> There is now a net_device_stats element inside net_device on
> 2.6.21 or later.
>   

Ah, OK.  Should I just do a s/stats/netdev->stats/?  Is there a generic
get_stats routine as well?

>> +
>> +	struct xen_netif_tx_front_ring tx;
>> +	struct xen_netif_rx_front_ring rx;
>> +
>> +	spinlock_t   tx_lock;
>> +	spinlock_t   rx_lock;
>>     
>
> It might be a performance advantage to reorder/align these
> structure elements to put transmit hot elements together, and
> put tx and rx on different cache lines?
>   

Oh, right.  I'd been meaning to look at that layout more closely.

Thanks,
    J

Re: [patch 37/44] xen: add virtual network device driver

[Rusty Russell]

On Tue, 2007-07-17 at 07:28 -0700, Jeremy Fitzhardinge wrote:
> Stephen Hemminger wrote:
> >> +struct netfront_info {
> >> +	struct list_head list;
> >> +	struct net_device *netdev;
> >> +
> >> +	struct net_device_stats stats;
> >>     
> >
> > There is now a net_device_stats element inside net_device on
> > 2.6.21 or later.
> >   
> 
> Ah, OK.  Should I just do a s/stats/netdev->stats/?  Is there a generic
> get_stats routine as well?

The default function points to the internal stats...

Cheers,
Rusty.

Re: [patch 37/44] xen: add virtual network device driver

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> The default function points to the internal stats...
>   

Right you are.

    J

Re: [Xen-devel] [patch 30/44] xen: Add support for preemption

[tgh]

hi
I am using xen,and I am curious about whether Xen support the preempt
scheduler for the VMs or not
could the VM be prempted by xen to scheduler another VM?

Thanks in advance


Jeremy Fitzhardinge 写道:
> Add Xen support for preemption.  This is mostly a cleanup of existing
> preempt_enable/disable calls, or just comments to explain the current
> usage.
>
> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
>
> ---
>  arch/i386/xen/Kconfig      |    2 
>  arch/i386/xen/enlighten.c  |   98 ++++++++++++++++++++++++++------------------
>  arch/i386/xen/mmu.c        |    5 +-
>  arch/i386/xen/multicalls.c |   11 ++--
>  arch/i386/xen/time.c       |   22 +++++++--
>  5 files changed, 86 insertions(+), 52 deletions(-)
>
> ===================================================================
> --- a/arch/i386/xen/Kconfig
> +++ b/arch/i386/xen/Kconfig
> @@ -4,7 +4,7 @@
>  
>  config XEN
>  	bool "Enable support for Xen hypervisor"
> -	depends on PARAVIRT && X86_CMPXCHG && X86_TSC && !(PREEMPT || NEED_MULTIPLE_NODES)
> +	depends on PARAVIRT && X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
>  	help
>  	  This is the Linux Xen port.  Enabling this will allow the
>  	  kernel to boot in a paravirtualized environment under the
> ===================================================================
> --- a/arch/i386/xen/enlighten.c
> +++ b/arch/i386/xen/enlighten.c
> @@ -15,6 +15,7 @@
>  #include <linux/init.h>
>  #include <linux/smp.h>
>  #include <linux/preempt.h>
> +#include <linux/hardirq.h>
>  #include <linux/percpu.h>
>  #include <linux/delay.h>
>  #include <linux/start_kernel.h>
> @@ -108,11 +109,10 @@ static unsigned long xen_save_fl(void)
>  	struct vcpu_info *vcpu;
>  	unsigned long flags;
>  
> -	preempt_disable();
>  	vcpu = x86_read_percpu(xen_vcpu);
> +
>  	/* flag has opposite sense of mask */
>  	flags = !vcpu->evtchn_upcall_mask;
> -	preempt_enable();
>  
>  	/* convert to IF type flag
>  	   -0 -> 0x00000000
> @@ -125,51 +125,56 @@ static void xen_restore_fl(unsigned long
>  {
>  	struct vcpu_info *vcpu;
>  
> -	preempt_disable();
> -
>  	/* convert from IF type flag */
>  	flags = !(flags & X86_EFLAGS_IF);
> +
> +	/* There's a one instruction preempt window here.  We need to
> +	   make sure we're don't switch CPUs between getting the vcpu
> +	   pointer and updating the mask. */
> +	preempt_disable();
>  	vcpu = x86_read_percpu(xen_vcpu);
>  	vcpu->evtchn_upcall_mask = flags;
> +	preempt_enable_no_resched();
> +
> +	/* Doesn't matter if we get preempted here, because any
> +	   pending event will get dealt with anyway. */
>  
>  	if (flags == 0) {
> -		/* Unmask then check (avoid races).  We're only protecting
> -		   against updates by this CPU, so there's no need for
> -		   anything stronger. */
> -		barrier();
> -
> +		preempt_check_resched();
> +		barrier(); /* unmask then check (avoid races) */
>  		if (unlikely(vcpu->evtchn_upcall_pending))
>  			force_evtchn_callback();
> -		preempt_enable();
> -	} else
> -		preempt_enable_no_resched();
> +	}
>  }
>  
>  static void xen_irq_disable(void)
>  {
> +	/* There's a one instruction preempt window here.  We need to
> +	   make sure we're don't switch CPUs between getting the vcpu
> +	   pointer and updating the mask. */
> +	preempt_disable();
> +	x86_read_percpu(xen_vcpu)->evtchn_upcall_mask = 1;
> +	preempt_enable_no_resched();
> +}
> +
> +static void xen_irq_enable(void)
> +{
>  	struct vcpu_info *vcpu;
> -	preempt_disable();
> -	vcpu = x86_read_percpu(xen_vcpu);
> -	vcpu->evtchn_upcall_mask = 1;
> -	preempt_enable_no_resched();
> -}
> -
> -static void xen_irq_enable(void)
> -{
> -	struct vcpu_info *vcpu;
> -
> +
> +	/* There's a one instruction preempt window here.  We need to
> +	   make sure we're don't switch CPUs between getting the vcpu
> +	   pointer and updating the mask. */
>  	preempt_disable();
>  	vcpu = x86_read_percpu(xen_vcpu);
>  	vcpu->evtchn_upcall_mask = 0;
> -
> -	/* Unmask then check (avoid races).  We're only protecting
> -	   against updates by this CPU, so there's no need for
> -	   anything stronger. */
> -	barrier();
> -
> +	preempt_enable_no_resched();
> +
> +	/* Doesn't matter if we get preempted here, because any
> +	   pending event will get dealt with anyway. */
> +
> +	barrier(); /* unmask then check (avoid races) */
>  	if (unlikely(vcpu->evtchn_upcall_pending))
>  		force_evtchn_callback();
> -	preempt_enable();
>  }
>  
>  static void xen_safe_halt(void)
> @@ -189,6 +194,8 @@ static void xen_halt(void)
>  
>  static void xen_set_lazy_mode(enum paravirt_lazy_mode mode)
>  {
> +	BUG_ON(preemptible());
> +
>  	switch (mode) {
>  	case PARAVIRT_LAZY_NONE:
>  		BUG_ON(x86_read_percpu(xen_lazy_mode) == PARAVIRT_LAZY_NONE);
> @@ -293,9 +300,13 @@ static void xen_write_ldt_entry(struct d
>  	xmaddr_t mach_lp = virt_to_machine(lp);
>  	u64 entry = (u64)high << 32 | low;
>  
> +	preempt_disable();
> +
>  	xen_mc_flush();
>  	if (HYPERVISOR_update_descriptor(mach_lp.maddr, entry))
>  		BUG();
> +
> +	preempt_enable();
>  }
>  
>  static int cvt_gate_to_trap(int vector, u32 low, u32 high,
> @@ -328,11 +339,13 @@ static void xen_write_idt_entry(struct d
>  static void xen_write_idt_entry(struct desc_struct *dt, int entrynum,
>  				u32 low, u32 high)
>  {
> -
> -	int cpu = smp_processor_id();
>  	unsigned long p = (unsigned long)&dt[entrynum];
> -	unsigned long start = per_cpu(idt_desc, cpu).address;
> -	unsigned long end = start + per_cpu(idt_desc, cpu).size + 1;
> +	unsigned long start, end;
> +
> +	preempt_disable();
> +
> +	start = __get_cpu_var(idt_desc).address;
> +	end = start + __get_cpu_var(idt_desc).size + 1;
>  
>  	xen_mc_flush();
>  
> @@ -347,6 +360,8 @@ static void xen_write_idt_entry(struct d
>  			if (HYPERVISOR_set_trap_table(info))
>  				BUG();
>  	}
> +
> +	preempt_enable();
>  }
>  
>  static void xen_convert_trap_info(const struct Xgt_desc_struct *desc,
> @@ -368,11 +383,9 @@ static void xen_convert_trap_info(const 
>  
>  void xen_copy_trap_info(struct trap_info *traps)
>  {
> -	const struct Xgt_desc_struct *desc = &get_cpu_var(idt_desc);
> +	const struct Xgt_desc_struct *desc = &__get_cpu_var(idt_desc);
>  
>  	xen_convert_trap_info(desc, traps);
> -
> -	put_cpu_var(idt_desc);
>  }
>  
>  /* Load a new IDT into Xen.  In principle this can be per-CPU, so we
> @@ -382,11 +395,10 @@ static void xen_load_idt(const struct Xg
>  {
>  	static DEFINE_SPINLOCK(lock);
>  	static struct trap_info traps[257];
> -	int cpu = smp_processor_id();
> -
> -	per_cpu(idt_desc, cpu) = *desc;
>  
>  	spin_lock(&lock);
> +
> +	__get_cpu_var(idt_desc) = *desc;
>  
>  	xen_convert_trap_info(desc, traps);
>  
> @@ -402,6 +414,8 @@ static void xen_write_gdt_entry(struct d
>  static void xen_write_gdt_entry(struct desc_struct *dt, int entry,
>  				u32 low, u32 high)
>  {
> +	preempt_disable();
> +
>  	switch ((high >> 8) & 0xff) {
>  	case DESCTYPE_LDT:
>  	case DESCTYPE_TSS:
> @@ -418,10 +432,12 @@ static void xen_write_gdt_entry(struct d
>  	}
>  
>  	}
> +
> +	preempt_enable();
>  }
>  
>  static void xen_load_esp0(struct tss_struct *tss,
> -				   struct thread_struct *thread)
> +			  struct thread_struct *thread)
>  {
>  	struct multicall_space mcs = xen_mc_entry(0);
>  	MULTI_stack_switch(mcs.mc, __KERNEL_DS, thread->esp0);
> @@ -525,6 +541,8 @@ static unsigned long xen_read_cr3(void)
>  
>  static void xen_write_cr3(unsigned long cr3)
>  {
> +	BUG_ON(preemptible());
> +
>  	if (cr3 == x86_read_percpu(xen_cr3)) {
>  		/* just a simple tlb flush */
>  		xen_flush_tlb();
> ===================================================================
> --- a/arch/i386/xen/mmu.c
> +++ b/arch/i386/xen/mmu.c
> @@ -38,6 +38,7 @@
>   *
>   * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
>   */
> +#include <linux/sched.h>
>  #include <linux/highmem.h>
>  #include <linux/bug.h>
>  
> @@ -530,5 +531,7 @@ void xen_exit_mmap(struct mm_struct *mm)
>  	drop_mm_ref(mm);
>  	put_cpu();
>  
> +	spin_lock(&mm->page_table_lock);
>  	xen_pgd_unpin(mm->pgd);
> -}
> +	spin_unlock(&mm->page_table_lock);
> +}
> ===================================================================
> --- a/arch/i386/xen/multicalls.c
> +++ b/arch/i386/xen/multicalls.c
> @@ -20,6 +20,7 @@
>   * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
>   */
>  #include <linux/percpu.h>
> +#include <linux/hardirq.h>
>  
>  #include <asm/xen/hypercall.h>
>  
> @@ -39,9 +40,11 @@ DEFINE_PER_CPU(unsigned long, xen_mc_irq
>  
>  void xen_mc_flush(void)
>  {
> -	struct mc_buffer *b = &get_cpu_var(mc_buffer);
> +	struct mc_buffer *b = &__get_cpu_var(mc_buffer);
>  	int ret = 0;
>  	unsigned long flags;
> +
> +	BUG_ON(preemptible());
>  
>  	/* Disable interrupts in case someone comes in and queues
>  	   something in the middle */
> @@ -60,7 +63,6 @@ void xen_mc_flush(void)
>  	} else
>  		BUG_ON(b->argidx != 0);
>  
> -	put_cpu_var(mc_buffer);
>  	local_irq_restore(flags);
>  
>  	BUG_ON(ret);
> @@ -68,10 +70,11 @@ void xen_mc_flush(void)
>  
>  struct multicall_space __xen_mc_entry(size_t args)
>  {
> -	struct mc_buffer *b = &get_cpu_var(mc_buffer);
> +	struct mc_buffer *b = &__get_cpu_var(mc_buffer);
>  	struct multicall_space ret;
>  	unsigned argspace = (args + sizeof(u64) - 1) / sizeof(u64);
>  
> +	BUG_ON(preemptible());
>  	BUG_ON(argspace > MC_ARGS);
>  
>  	if (b->mcidx == MC_BATCH ||
> @@ -83,7 +86,5 @@ struct multicall_space __xen_mc_entry(si
>  	ret.args = &b->args[b->argidx];
>  	b->argidx += argspace;
>  
> -	put_cpu_var(mc_buffer);
> -
>  	return ret;
>  }
> ===================================================================
> --- a/arch/i386/xen/time.c
> +++ b/arch/i386/xen/time.c
> @@ -88,7 +88,7 @@ static void get_runstate_snapshot(struct
>  	u64 state_time;
>  	struct vcpu_runstate_info *state;
>  
> -	preempt_disable();
> +	BUG_ON(preemptible());
>  
>  	state = &__get_cpu_var(runstate);
>  
> @@ -103,8 +103,6 @@ static void get_runstate_snapshot(struct
>  		*res = *state;
>  		barrier();
>  	} while (get64(&state->state_entry_time) != state_time);
> -
> -	preempt_enable();
>  }
>  
>  static void setup_runstate_info(int cpu)
> @@ -179,8 +177,18 @@ unsigned long long xen_sched_clock(void)
>  unsigned long long xen_sched_clock(void)
>  {
>  	struct vcpu_runstate_info state;
> -	cycle_t now = xen_clocksource_read();
> +	cycle_t now;
> +	u64 ret;
>  	s64 offset;
> +
> +	/*
> +	 * Ideally sched_clock should be called on a per-cpu basis
> +	 * anyway, so preempt should already be disabled, but that's
> +	 * not current practice at the moment.
> +	 */
> +	preempt_disable();
> +
> +	now = xen_clocksource_read();
>  
>  	get_runstate_snapshot(&state);
>  
> @@ -190,9 +198,13 @@ unsigned long long xen_sched_clock(void)
>  	if (offset < 0)
>  		offset = 0;
>  
> -	return state.time[RUNSTATE_blocked] +
> +	ret = state.time[RUNSTATE_blocked] +
>  		state.time[RUNSTATE_running] +
>  		offset;
> +
> +	preempt_enable();
> +
> +	return ret;
>  }
>  
>  
>
>   

Re: [Xen-devel] [patch 30/44] xen: Add support for preemption

[Jeremy Fitzhardinge]

tgh wrote:
> hi
> I am using xen,and I am curious about whether Xen support the preempt
> scheduler for the VMs or not
> could the VM be prempted by xen to scheduler another VM?
>   

Yes, that's the normal mode of operation. The hypervisor will timeslice
multiple vcpus onto a single vcpu.

This patch doesn't relate to that; it's whether a Xen Linux guest's
kernel can be preempted to reschedule processes while running under Xen.
The normal xen-unstable or vendor Xen kernels don't support this, but
the mainline kernel with paravirt_ops/xen support does.

J

Re: [Xen-devel] [patch 30/44] xen: Add support for preemption

[tgh]

Thank for your reply
and I still have several questions
> Yes, that's the normal mode of operation. The hypervisor will timeslice
> multiple vcpus onto a single vcpu.
>   
that is ,the VM could be preempted by xen,and could xen hypervisor also
be preempted to reschedule other vm or xen kernel thread?and are there
the counterpart abstractions in xen for kernel thread in linux?

> This patch doesn't relate to that; it's whether a Xen Linux guest's
> kernel can be preempted to reschedule processes while running under Xen.
>   
that is ,the patch makes the guest's kernel, rather than xen, be able to
be preempted ,is it right?

Thanks in advance
> The normal xen-unstable or vendor Xen kernels don't support this, but
> the mainline kernel with paravirt_ops/xen support does.
>
> J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>   

Re: [Xen-devel] [patch 30/44] xen: Add support for preemption

[Jeremy Fitzhardinge]

tgh wrote:
> Thank for your reply
> and I still have several questions
>   
>> Yes, that's the normal mode of operation. The hypervisor will timeslice
>> multiple vcpus onto a single vcpu.
>>   
>>     
> that is ,the VM could be preempted by xen,and could xen hypervisor also
> be preempted to reschedule other vm or xen kernel thread?and are there
> the counterpart abstractions in xen for kernel thread in linux?
>   

Yes, a vcpu in Xen is the same as a task in the kernel. In the same way
the kernel multiplexes multiple tasks onto your cpu(s), Xen multiplexes
multiple vcpus onto your cpu(s). This isn't directly visible to the
guest kernel, in the same way that user processes can't generally
observe timeslicing.

>> This patch doesn't relate to that; it's whether a Xen Linux guest's
>> kernel can be preempted to reschedule processes while running under Xen.
>>   
>>     
> that is ,the patch makes the guest's kernel, rather than xen, be able to
> be preempted ,is it right?
>   

Yes. Previous to that change, kernel preemption was disabled when
compiling Xen support in.

J

Re: [Xen-devel] [patch 30/44] xen: Add support for preemption

[tgh]

Thank you for your reply
and what about the kernel thread in the xen hypervisor,are there some
instance of kernel threads running in the hypervisor?
I am not sure ,but somewhere I read that there is no kernel thread in
the xen hypervisor ,is it true or what about it?

Thanks in advance


Jeremy Fitzhardinge 写道:
> tgh wrote:
>   
>> Thank for your reply
>> and I still have several questions
>>   
>>     
>>> Yes, that's the normal mode of operation. The hypervisor will timeslice
>>> multiple vcpus onto a single vcpu.
>>>   
>>>     
>>>       
>> that is ,the VM could be preempted by xen,and could xen hypervisor also
>> be preempted to reschedule other vm or xen kernel thread?and are there
>> the counterpart abstractions in xen for kernel thread in linux?
>>   
>>     
>
> Yes, a vcpu in Xen is the same as a task in the kernel. In the same way
> the kernel multiplexes multiple tasks onto your cpu(s), Xen multiplexes
> multiple vcpus onto your cpu(s). This isn't directly visible to the
> guest kernel, in the same way that user processes can't generally
> observe timeslicing.
>
>   
>>> This patch doesn't relate to that; it's whether a Xen Linux guest's
>>> kernel can be preempted to reschedule processes while running under Xen.
>>>   
>>>     
>>>       
>> that is ,the patch makes the guest's kernel, rather than xen, be able to
>> be preempted ,is it right?
>>   
>>     
>
> Yes. Previous to that change, kernel preemption was disabled when
> compiling Xen support in.
>
> J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>   

Re: [Xen-devel] [patch 30/44] xen: Add support for preemption

[Jeremy Fitzhardinge]

tgh wrote:
> Thank you for your reply
> and what about the kernel thread in the xen hypervisor,are there some
> instance of kernel threads running in the hypervisor?
> I am not sure ,but somewhere I read that there is no kernel thread in
> the xen hypervisor ,is it true or what about it?
>   

No, there are no linux kernel threads in the hypervisor. The only
thread-like thing Xen has is a virtual CPU, and they're always guest
domain vcpus.

J