WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 15 Apr 2010 09:13:06 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 15 Apr 2010 01:14:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BC6C707.4080709@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrccV74GaC9GZ9lTbWk9MTZP2+EwQAAhsPF
Thread-topic: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets
User-agent: Microsoft-Entourage/12.24.0.100205
On 15/04/2010 08:57, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

>> What revision did you test? I put in some fixes as c/s 21173.
> 
> My highest c/s was 21167.
> c/s 21173 is hanging, too (sorry for the delay, but I had to remove my cpupool
> stuff due to the scheduler changes for credit2).

Ah yes, just done a test myself (clearly my dom0 setup is not doing
microcode updates) and I've now fixed it as c/s 21176. Thanks!

> Is a call of sync_vcpu_execstate() fro a tasklet really allowed? I don't
> think the ASSERTs in __sync_lazy_execstate() are all fulfilled in this case.

Better hope so or e.g.,
acpi_enter_sleep
->continue_hypercall_on_cpu(enter_state_helper)
->enter_state
->freeze_domains
->domain_pause
->vcpu_sleep_sync
->sync_vcpu_execstate
Also wouldn't work.

There is only one ASSERT in __sync_lazy_execstate, and it's safe for this
case. Bear in mind that our softirqs always run in the context of whatever
domain happens to be running on that cpu currently -- they don't have their
own proper vcpu context.

By the by, your original attempt at synchronisation (spin on return value in
regs changing) was risky as it could be unbounded time before the vcpu
registers get copied out of the original cpu's stack. Especially during
early dom0 boot, when the system is very idle.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>