> 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
|
Home