RE: [Xen-ia64-devel] machine ITM = nearest guest ITM vs. full guesttime virtualization

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> > I think you misunderstand the current Xen/ia64 timer
> > implementation.  It is a bit different than Xen/x86
>
> Did you check the vcpu_set_itc()? The current implementation 
> set the guest ITC to machine ITC and adjust guest ITM 
> relatively. How can this works for multiple domain?

The code could be wrong today as it hasn't been tested
with multiple domains.  The way its supposed to work
is that the ITC is owned by the domain.  Xen's only
use for the ITC is to ensure that it gets periodic clock
interrupts for scheduling so, if the domain adjusts ITC,
Xen's "time of next tick" (call this XenITM) must be adjusted.
And at domain switch, Xen may need to adjust ITC (and XenITM)
if either the previous or next domain adjusted ITC.
(Since Linux doesn't do this, the code to handle this
is probably broken or missing.)

> > as ac_timer is not needed for guests.
> What are you mentioning here? I use ac_timer mechanism to 
> fire guest vtimer only. 

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.
 
> > Your example of 16 VMs running each with 4 VPs doesn't
> > result in 64x timer IRQs because a guest can only be
> > delivered a timer tick when it is running and can only
> It is really hard to know how can current approach support 
> multiple VMs. If you only set machine ITM to nearest guest 
> vitm or HV next itm. How can you support domain N vtimer? 

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)
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.
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.

> > change ITM when it is running.  Also, I think SMP
> > OS's generally choose a single processor to handle clock ticks
> > rather than have each processor get interrupted.  Thus
> Will other LP not use ITC timer? Or your xenolinux only use 
> ITC timer in BSP? (But yes only BSP account for clock ticks)

It will work either way.  Only the "XenBSP" gets scheduling
timer ticks, but the guest can configure a BSP for clock ticks
or can get clock ticks for each LP.  In either case, at
most 2x/second clock interrupt will occur (where x is 1024
in the current code).

Dan

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