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-ia64-devel

RE: [Xen-ia64-devel] Some things to be considered for ptc.ga emulation

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Some things to be considered for ptc.ga emulation
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Wed, 5 Apr 2006 13:56:05 +0800
Delivery-date: Tue, 04 Apr 2006 22:56:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZYbs3SKr7CnMI0RCCIEHq4K7nbfAAA7LHg
Thread-topic: [Xen-ia64-devel] Some things to be considered for ptc.ga emulation
>From: Tian, Kevin
>4. How long does ptc.ga emulation need to wait?
>       By above IPI style, the best case is that all target vcpus are
>not in
>running state and thus all emulation work can be done within IPI handler
>
>       The worst case is that target vcpu is in running state. In that
>case,
>extra time is added between IPI handler and the point resuming back to
>guest. But that extra time is normally short and tolerable.
>
>       Then the whole emulation can always ensure all other vcpus
>observe
>the effect before resuming back to guest.


Considering VTIdomain, I have below concerns,
If a vcpu receives a IPI, just before do_block( waiting device model
on dom0 to handle IO request), do_block will schedule out this vcpu,
and the schedule in vcpu may use the old tlb mapping.
And the wait maybe long.


Moreover, if this IO request is sent to the vcpu of domain0, which runs
On the same vcpu that send out IPI, because this vcpu is waiting other
Vcpus' response of IPI handling, it can't be scheduled to vcpu of domain0,
Then dead loop happens.

The vcpu that sends IPI should not wait by tight polling, this vcpu should yield
LP and poll.

Thank,
Anthony


>Thanks,
>Kevin
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

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