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

RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot optio

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Mon, 28 Sep 2009 16:22:34 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Mon, 28 Sep 2009 01:23:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <786ff021-ef3e-44a4-879f-7ab6e43270c6@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C6E59A07.15D68%keir.fraser@xxxxxxxxxxxxx> <786ff021-ef3e-44a4-879f-7ab6e43270c6@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco/yQlnn/7zTom9TTSYttpEvykDRgASbNsw
Thread-topic: [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

<Prev in Thread] Current Thread [Next in Thread>