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] machine ITM = nearest guest ITM vs. full guesttime

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] machine ITM = nearest guest ITM vs. full guesttime virtualization
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Mon, 2 May 2005 08:43:33 +0800
Cc: ipf-xen <ipf-xen@xxxxxxxxx>
Delivery-date: Mon, 02 May 2005 00:43:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: AcVNYTbiS1g8dJcOT9aDwf6uWGSJAwAnrY6QAA5pBSAAEa0J4AAKTeQA
Thread-topic: [Xen-ia64-devel] machine ITM = nearest guest ITM vs. full guesttime virtualization
Hi, dan:
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> 
> Yes, that's the difference.  I use ac_timer only for
> scheduling (ITC==XenITM).  I don't even need to use it
> there but it is convenient for interfacing to the Xen
> scheduling code.
Yes it can work, but we are deviating from X86 XEN more. Any strategy in
deviation from X86? I think this deviation is not necessary.
> 
> 
> Only one domain can be running on any one processor at
> a time.  So if Xen changes ITC and XenITM (and cr.itm)
> at domain switch time, it all works.
> 
>> Suppose when domain N is switched out when vITCn < vITMn and
>> is switched back at vITCn >vITM. What will you do? Inject
>> immediately? I saw problems here except you know this guest
>> is waiting for vITM interrupt.
> 
> I think maybe we are misunderstanding each other because
> VT works differently than the current Xen/ia64 implementation
> for interrupts.  VT calls it "injection" and I call it
> "delivery".  I thought these might be identical (or similar)
injection and delivery are same. VT injection only changes guest
context.
Control will still be in VMM.
> but I think they are more different than I thought:  From
> what I understand, when VT injects an interrupt, control
> is immediately transferred to the guest, regardless of what
> the VMM is doing at the time (unless vpsr/vitr disallows it).
> When Xen/ia64 delivers an interruption, control is only
> transferred to the guest at the rfi at the end of ia64_leave_kernel.
Yes, it is same.
> If there is an interrupt (timer or external) and the vpsr/vitr
> allows it, the guest resumes in the IVT.  If there is no
> interrupt or the vpsr/vitr doesn't allow it, the guest
> resumes at iip (where it left off when Xen was entered).
> 
> So, yes, when switching from domainA to domainB, if a significant
> amount of time has transpired since domainB ran, it's highly
> likely that the first instruction that will be executed by
> domainB will be in the IVT at the interrupt vector to handle
> a clock tick.
The problem is how you know domain B transpired a significant
amount of time without extra data structure? I mean HV needs to track
last guest ITC and ITM to know there is condition for timer IRQ to fire.
If you would like to track the last guest ITC, the design will be much
like same. Maybe you can give more comments after you saw the code.
> 
> 
> Dan

Eddie

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