RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> if administrator doesn't 
> like to suffer performance loss in emulation way,  he can 
> migrate the guest back

OK, that makes sense.

> system administrator can get the tsc emulation 
> knowledge from Xen's system log

Getting information from the log is probably not a good
longterm solution though.  I think there needs
to be a management/tools mechanism to query if
a migrated/restored domain has transitioned
from tsc-native to tsc-emulated or vice versa.

Thanks,
Dan

> -----Original Message-----
> From: Zhang, Xiantao [mailto:xiantao.zhang@xxxxxxxxx]
> Sent: Monday, September 28, 2009 2:23 AM
> To: Dan Magenheimer; Keir Fraser; Xen-Devel (E-mail)
> Subject: RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen
> boot option with per-domain (hypervisor part)
> 
> 
> Dan Magenheimer wrote:
> > Sorry I should have explained my logic for those changes
> > in the original posting.
> > 
> > The scaling is a strange corner case where a domain
> > can invisibly change from native-tsc to virtual-tsc.
> > I started to add a domctl so that the current state
> > could be probed, but decided that the scaling is
> > really a policy decision that is best made at
> > config time and best retained in the VM information
> > carried along with a save file (or live migration).
> > Allowing rdtsc to change dynamically according to
> > whether a save/restore/migration happened to occur
> > and whether the restored VM happened to land on
> > a machine with a different clock rate seems like
> > it could get very confusing.  The domain adminstrator
> > either assumes correctness (the default) or turns
> > off emulation to get better performance and deals
> > with ALL the consequences.  So IMHO removing the
> > scaling simplifies an already complex-to-explain
> > issue. 
> Hi, Dan
>   I didn't see the necessity to remove the scaling logic.  
> This logic just allows the domain can run  in different 
> TSC-freq platforms without strange timing behaviors.  If the 
> domain is migrated between tow machines with different TSC 
> rate, system administrator can get the tsc emulation 
> knowledge from Xen's system log, and if administrator doesn't 
> like to suffer performance loss in emulation way,  he can 
> migrate the guest back.  Besides, I don't think this logic 
> conflicts with your boot-stage option.IMO,  if the boot-stage 
> option is set to use emulation, the scaling policy can be 
> switched off, but if the option is not specified, I think the 
> default scaling policy should be adopted in migration case.  
> Xiantao
> 
> > 
> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >> Sent: Sunday, September 27, 2009 3:39 PM
> >> To: Dan Magenheimer; Xen-Devel (E-mail)
> >> Subject: Re: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native
> >> xen boot option with per-domain (hypervisor part)
> >> 
> >> 
> >> On 27/09/2009 20:22, "Dan Magenheimer"
> >> <dan.magenheimer@xxxxxxxxxx> wrote:
> >> 
> >>> (I'm still struggling against the coils of python on
> >>> the tools part of this patch, so thought I'd post the
> >>> hypervisor side separately first.)
> >>> 
> >>> Switches rdtsc emulation from boot option to per-domain
> >>> and enables it by default.  Also removes hvm tsc scaling
> >>> as it is no longer necessary.
> >> 
> >> The hvm tsc scaling will still be useful in the case that
> >> trap-&-emulate was originally disabled for an hvm domain. So I'd
> >> keep it, and 
> >> also keep the
> >> flag called d->arch.vtsc rather than flipping it and renaming
> >> it, and the
> >> patch will end up about 20 lines long.
> >> 
> >> I'll rework this patch myself and check it in at the same
> >> time as the tools
> >> patch, when you have that ready.
> >> 
> >>  -- Keir
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> >> 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
>

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