From mboxrd@z Thu Jan 1 00:00:00 1970 From: tupeng212 Subject: Re: Big Bug:Time in VM goes slower; foud Solution but demand Judgement! A Interesting Story! Date: Fri, 10 Aug 2012 23:17:59 +0800 Message-ID: <2012081023124696835343@gmail.com> References: <201208070018394210381@gmail.com>, <50224B7402000078000937DA@nat28.tlf.novell.com> Reply-To: tupeng212 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4979082272455034970==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============4979082272455034970== Content-Type: multipart/alternative; boundary="----=_001_NextPart462848748572_=----" This is a multi-part message in MIME format. ------=_001_NextPart462848748572_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBKYW4gQmV1bGljaDoNClRoYW5rcyBmb3IgcmVwbHkhIFlvdSBhcmUgYSB2ZXJ5IGNsZXZl ciBtYW4sIHlvdSBoYXZlIHNlbnNlZCBzb21lIHRoaW5nIGltbWVkaWF0ZWx5IGFzIEkgZm91bmQg bGF0ZWx5LiBQbGVhc2UgZm9yZ2l2ZSBteSBzbyBsYXRlbHkgcmVwbHkhDQoNCjEgd2h5IEpWTSBz ZXQgdGhlIHNhbWUgcmF0ZSBkb3duIHNvIGZyZXF1ZW50bHkgPw0KdGhlIGZpcnN0IGFjaGlldmVt ZW50IEkgd2lsbCBzaG93IGlzIEkgZm91bmQgdGhlIGFjdGlvbiBpbiBKVk0gYW5kIHRoZSByZWFz b24gYnkgZGVidWdnaW5nIGRpc2Fzc2VtYmx5IGNvZGUuDQppdCBzZWVtcyB0byBtZSBsaWtlIHRo aXMgaW4gSlZNOg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAxIHdo YXQgaGFwcGVuZWQgaW4gSlZNID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K d2hpbGUgKGxvb3ApLy9vciBhIGZyZXF1ZW50IGNhbGwNCnsNCnRpbWVCZWdpblBlcmlvZCgpIC0t PiBOdFNldFRpbWVyUmVzb2x1dGlvbigxKGVuYmxlKSkNCnJjID0gV2FpdEZvck11bHRpcGxlT2Jq ZWN0cyg1LCAweDIyMjIyMjIsIDAsIDEpOyAvL3RoZSBsYXN0IHBhcmFtZXRlciBkZW1hbmRzIDFt cyB0aW1lciByZXNvbHV0aW9uDQppZiAocmMgPSBUSU1FT1VUKXsNCmJyZWFrOw0KfQ0KZWxzZXsN CmNhbGwgMHg0NDQ0NDQ0NDsNCn0NCnRpbWVFbmRQZXJpb2QoKSAtLT4gTnRTZXRUaW1lclJlc29s dXRpb24oMChkaXNhYmxlKSkNCn0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCnNvIGl0cyBiZWhhdmlvciBpcyB0b3RhbGx5IGxlZ2FsLCBmb3IgaXQgZGVtYW5k cyBoaWdoZXIgdGltZXIgcmVzb2x1dGlvbiAoaGVyZSAxbXMpLCBzbyBpdCBjYWxscyBOdFNldFRp bWVyUmVzb2x1dGlvbiB0byBpbXByb3ZlIHRoZSByZXNvbHV0aW9uLiANCml0IGlzIG5vdCBhcyBJ IGd1ZXNzZWQgInVuYWNjdXJhdGUiDQoNCkkgYWxzbyB3cm90ZSBhIHRlc3RlciBiZWxvdywgd2hp Y2ggY29uZmlybXMgbXkgc3VwcG9zZS4gaWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIGl0ICwgeW91 IGNhbiBidWlsZCBpdCBieSBNUydzIGNvbXBpbGVyLCBhbmQgYWZ0ZXIgcnVubmluZyB0aGUgdGVz dGVyIGluIFZNIGFib3V0IDEgbWludXRlcywgVk0ncyB0aW1lIHdpbGwgc2xvdy4NCj09PT09PT09 PT09PT09PT09PT09PT09PT09PSAyIGEgdGVzdCB3aGljaCB3aWxsIGxlYWQgdG8gdHJpZ2dlciBz bG93aW5nIFZNJ3MgaW5uZXIgdGltZT09PT09PT09DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNs dWRlIDx3aW5kb3dzLmg+DQp0eXBlZGVmIGludCAoX19zdGRjYWxsICpOVFNFVFRJTUVSKShJTiBV TE9ORyBSZXF1ZXN0ZWRSZXNvbHV0aW9uLCBJTiBCT09MRUFOIFNldCwgT1VUIFBVTE9ORyBBY3R1 YWxSZXNvbHV0aW9uICk7DQp0eXBlZGVmIGludCAoX19zdGRjYWxsICpOVFFVRVJZVElNRVIpKE9V VCBQVUxPTkcgICBNaW5pbXVtUmVzb2x1dGlvbiwgT1VUIFBVTE9ORyBNYXhpbXVtUmVzb2x1dGlv biwgT1VUIFBVTE9ORyBDdXJyZW50UmVzb2x1dGlvbiApOw0KaW50IG1haW4oKQ0Kew0KRFdPUkQg bWluX3JlcyA9IDAsIG1heF9yZXMgPSAwLCBjdXJfcmVzID0gMCwgcmV0ID0gMDsNCkhNT0RVTEUg IGhkbGwgPSBOVUxMOw0KaGRsbCA9IEdldE1vZHVsZUhhbmRsZSgibnRkbGwuZGxsIik7DQpOVFNF VFRJTUVSIEFkZHJOdFNldFRpbWVyID0gMDsNCk5UUVVFUllUSU1FUiBBZGRyTnRRdWV5VGltZXIg PSAwOw0KQWRkck50U2V0VGltZXIgPSAoTlRTRVRUSU1FUikgR2V0UHJvY0FkZHJlc3MoaGRsbCwg Ik50U2V0VGltZXJSZXNvbHV0aW9uIik7DQpBZGRyTnRRdWV5VGltZXIgPSAoTlRRVUVSWVRJTUVS KUdldFByb2NBZGRyZXNzKGhkbGwsICJOdFF1ZXJ5VGltZXJSZXNvbHV0aW9uIik7DQoNCndoaWxl ICgxKQ0Kew0KcmV0ID0gQWRkck50UXVleVRpbWVyKCZtaW5fcmVzLCAmbWF4X3JlcywgJmN1cl9y ZXMpOw0KcHJpbnRmKCJtaW5fcmVzID0gJWQsIG1heF9yZXMgPSAlZCwgY3VyX3JlcyA9ICVkXG4i LG1pbl9yZXMsIG1heF9yZXMsIGN1cl9yZXMpOw0KU2xlZXAoMTApOw0KcmV0ID0gQWRkck50U2V0 VGltZXIoMTAwMDAsIDEsICZjdXJfcmVzKTsNClNsZWVwKDEwKTsNCnJldCA9IEFkZHJOdFNldFRp bWVyKDEwMDAwLCAwLCAmY3VyX3Jlcyk7DQpTbGVlcCgxMCk7DQp9DQpyZXR1cm4gMDsNCn0NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KMiBCdWcgaW4geGVuDQpKVk0g aXMgT0ssIHNvIGxlZnQgdGhlIGJ1ZyB0byB4ZW4sIEkgaGF2ZSBmb3VuZCBib3RoIHRoZSByZWFz b24gYW5kIHNvbHV0aW9uLiBBcyBKYW4gbWVudGlvbmVkIGF2b2lkaW5nIGNhbGwgY3JlYXRlX3Bl cmlvZGljX3RpbWUsIGl0IGdvdCBtdWNoIGJldHRlci4gc28gSSBtb2RpZmllZCBpdCBsaWtlIHRo aXMsIGlmIHRoZSBwdCB0aW1lciBpcyBjcmVhdGVkIGJlZm9yZSwgc2V0dGluZyBSZWdBIGRvd24g aXMganVzdCBjaGFuZ2luZyB0aGUgcGVyaW9kIHZhbHVlLCBzbyBJIGRvIG5vdGhpbmcgZXhjZXB0 IGp1c3Qgc2V0dGluZyBwZXJpb2QgdG8gcHQncyBmaWVsZC4gaXQgaXMgT0shDQoNCkkgdGhvdWdo dCBwdC0+c2NoZWR1bGVkIGlzIHJlc3BvbnNpYmxlIGZvciBBY2N1cmFjeSBvZiBwdF9wcm9jZXNz X21pc3NlZF90aWNrcywgc28gd2Ugc2hvdWxkIG5vdCBpbnRlcmZlcmUgaXQgYXQgYW55IG91dGVy IGludmFkaW5nIG9yIGludGVycnVwdGlvbiwgc28gSSBsZXQgY3JlYXRlX3BlcmlvZGljX3RpbWUg Y2hhbmdlZCBldmVyeXRoaW5nIGJ1dCByZXNlcnZlZCBvbmx5IG9uZSBmaWxlZCBwdC0+c2NoZWR1 bGVkIGFzIHNldHRlZCBiZWZvcmUsIEkgYW0gdmVyeSBoYXBweSB0byBmaW5kIHRoZSBidWcgZGlz YXBwZWFyLiBBZnRlciBJIHJlY2hlY2tlZCB5b3VyIG1haWwgSSBmb3VuZCB5b3UgYXJlIHJlYWxs eSBhIHZlcnkgc21hcnQgbWFuLCB5b3UgaGF2ZSBwcmVkaWN0ZWQgc29tZXRoaW5nIQ0KDQpEaWQg eW91IGZ1cnRoZXIgY2hlY2sgd2hldGhlciB0aGUgYWRqdXN0bWVudHMgZG9uZSB0byB0aGUNCnNj aGVkdWxlZCB0aW1lIGluIGNyZWF0ZV9wZXJpb2RpY190aW1lKCkgYXJlIHJlc3BvbnNpYmxlIGZv ciB0aGlzDQpjb25jbHVzaW9uIG9mIHRoZSBKVk0gKGNvdWxkIGJlIGVmZmVjdGl2ZWx5IGRvdWJs aW5nIHRoZSBmaXJzdA0KaW50ZXJ2YWwgaWYgSFZNX1BBUkFNX1ZQVF9BTElHTiBpcyBzZXQsIGFu ZCB3aXRoIHRoZSBoaWdoIHJhdGUNCm9mIHJlLXNldHMgdGhpcyBjb3VsZCBjZXJ0YWlubHkgaGF2 ZSBhIG1vcmUgdmlzaWJsZSBlZmZlY3QgdGhhbg0KaW50ZW5kZWQpPw0KDQpBZnRlciBJIHRyYWNr ZWQgcHQtPnNjaGVkdWxlZCwgbW9yZSBhbmQgbW9yZSB0cnV0aCBzdXJmYWNlZC4gSSB3aWxsIHNo b3cgeW91IHRoZSBSVEMncyBzcG90dGluZyBhcyBJIG9ic2VydmVkLg0Kbm9ybWFsIHNwb3QgaXMg bGlrZSB0aGlzOg0KMCAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgMyAgICAgICAgICAgICAgIDQgICAgICAgICAgICAgICA1DQouICAgICAgICAgICAgICAgLiAg ICAgICAgICAgICAgIC4gICAgICAgICAgICAgICAuICAgICAgICAgICAgICAgLiAgICAgICAgICAg ICAgIC4gICAgICAobm9ybWFsIHNwb3QpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwocHQtPnNjaGVkdWxlZCBhdCAyKQ0KDQp3aGVuIGNyZWF0ZV9wZXJpb2RpY190aW1lIGludGVy ZmVyZSBwdC0+c2NoZWR1bGUgYXQgTk9XDQowICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAzICAgICAgICAgICAgICAgNCAgICAgICAgICAgICAgIDUNCi4gICAg ICAgICAgICAgICAuICAgICAgICAgICAgICAgLiAgICAgICAgICAgICAgIC4gICAgICAgICAgICAg ICAuICAgICAgICAgICAgICAgLiAgICAgIA0KICAgICAgICAgICAgICAgICAgICB8KE5PVykgICAg ICAgICAgICAgICAgICAgICAgfCAobmV3IHB0LT5zY2hlZHVsZWQgaXMgbW92ZWQgdG8gMyBhZnRl ciBBTElHTikNCg0Kc28gaXQgcmVhbCBzcG90IGlzIGxpa2UgdGhpczoNCi4gICAgICAgICAgICAg ICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4gICAgICAgICAgICAgICAuICAgICAg ICAgICAgICAgLiAgICAgICANCjAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgIDMgICAgICAgICAgICAgICA0ICAgICAgICAgICAgICAgNQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8KGhlcmUgd2UgbWlzc2VkIG9uZSBzcG90IGF0IDIpDQoNCnRo ZSBvcmlnaW5hbCBwdC0+c2NoZWR1bGVkIGlzIGF0IDIgYmVmb3JlIGNyZWF0ZV9wZXJpb2RpY190 aW1lIHdpbGwgYmUgZXhlY3V0ZWQsIGJ1dCBhZnRlciBpdCwgcHQtPnNjaGVkdWxlZCBpcyBtb3Zl ZCB0byAzLCBzbyBtaXNzZWQgb25lIHNwb3QgdG8gR3Vlc3RXaW4uDQoNCg0KMyB3aG8gaXMgd3Jv bmc/DQpJIGRvdWJ0IGFsaWduX3RpbWVyIHdvcnRoIHN1c3BlY3RlZDoNCnNfdGltZV90IGFsaWdu X3RpbWVyKHNfdGltZV90IGZpcnN0dGljaywgdWludDY0X3QgcGVyaW9kKQ0Kew0KICAgIGlmICgg IXBlcmlvZCApDQogICAgICAgIHJldHVybiBmaXJzdHRpY2s7DQoNCiAgICByZXR1cm4gZmlyc3R0 aWNrICsgKHBlcmlvZCAtIDEpIC0gKChmaXJzdHRpY2sgLSAxKSAlIHBlcmlvZCk7IC8vaW4geGVu NC54DQogICAgcmV0dXJuIGZpcnN0dGljayAgLSAoKGZpcnN0dGljayAtIDEpICUgcGVyaW9kKTsv L2l0IHNob3VsZCBiZSBhbGlnbmVkIGxpa2UgdGhpcy4NCn0NCg0KSSBoYXZlIGFsc28gZm91bmQg YW5vdGhlciB1cGRhdGluZyBSVEMncyBSZWdBIGluIHRvb2xzXGlvZW11LXFlbXUteGVuXGh3XE1D YzE0NjgxOHJ0Yy5jOiANCg0KICAgIGlmIChwZXJpb2RfY29kZSAhPSAwICYmIChzLT5jbW9zX2Rh dGFbUlRDX1JFR19CXSAmIFJFR19CX1BJRSkpIHsNCiNlbmRpZg0KICAgICAgICBpZiAocGVyaW9k X2NvZGUgPD0gMikNCiAgICAgICAgICAgIHBlcmlvZF9jb2RlICs9IDc7DQogICAgICAgIC8qIHBl cmlvZCBpbiAzMiBLaHogY3ljbGVzICovDQogICAgICAgIHBlcmlvZCA9IDEgPDwgKHBlcmlvZF9j b2RlIC0gMSk7DQojaWZkZWYgSVJRX0NPQUxFU0NFX0hBQ0sNCiAgICAgICAgaWYocGVyaW9kICE9 IHMtPnBlcmlvZCkNCiAgICAgICAgICAgIHMtPmlycV9jb2FsZXNjZWQgPSAocy0+aXJxX2NvYWxl c2NlZCAqIHMtPnBlcmlvZCkgLyBwZXJpb2Q7DQogICAgICAgIHMtPnBlcmlvZCA9IHBlcmlvZDsN CiNlbmRpZg0KICAgICAgICAvKiBjb21wdXRlIDMyIGtoeiBjbG9jayAqLw0KICAgICAgICBjdXJf Y2xvY2sgPSBtdWxkaXY2NChjdXJyZW50X3RpbWUsIDMyNzY4LCB0aWNrc19wZXJfc2VjKTsgLy9o ZXJlIEkgZG9uJ3QgbWFrZSBzZW5zZSBpdCAuLi4uLi4NCiAgICAgICAgbmV4dF9pcnFfY2xvY2sg PSAoY3VyX2Nsb2NrICYgfihwZXJpb2QgLSAxKSkgKyBwZXJpb2Q7DQogICAgICAgIHMtPm5leHRf cGVyaW9kaWNfdGltZSA9IG11bGRpdjY0KG5leHRfaXJxX2Nsb2NrLCB0aWNrc19wZXJfc2VjLCAz Mjc2OCkgKyAxOw0KICAgICAgICBxZW11X21vZF90aW1lcihzLT5wZXJpb2RpY190aW1lciwgcy0+ bmV4dF9wZXJpb2RpY190aW1lKTsNCg0KDQoNCkkgZG9uJ3Qga25vdyB3aGF0IGhhcHBlbmVkIGlu IHJlYWwgUlRDLCB0aGUgbW9zdCBwb3B1bGFyIFJUQyBjaGlwIGlzIE1DMTQ2ODE4LCBJIGhhdmUg Y2hlY2tlZCBpdHMgZGF0YXNoZWV0IGJ1dCBmb3VuZCBub3RoaW5nIEkgd2FudC4gV2hhdCBJIHdh bnQgdG8ga25vdyBpcyBXaGVuIGEgcmVhbCBvdXRlciAweDcxIGNvbWUgZG93biB0byBzZXQgUlRD J3MgUmVnQSwgd2hvIGRvZXMgaXQgY2hhbmdlIG9yIHNwb3QgdGhlIG5leHQgcGVyaW9kaWMgaW50 ZXJydXB0IHRpbWUgPyBJbiBteSBjYXNlLCB0aGUgcGVyaW9kIGRvZXNuJ3QgY2hhbmdlLCBpdCBt aXNzZXMgb25lIHNwb3QsIGV2ZW4gaWYgdGhlIHBlcmlvZCBjaGFuZ2VzIGhvdyB3aWxsIGl0IHNw b3QgdGhlIG5leHQgc2NoZWR1bGVkIHRpbWU/DQpJIG5lZWQgdGhlIG1hbiB3aG8ga25vd3MgdGhl IGRldGFpbHMgZGVlcGx5IGNvbmNlcm5pbmcgd2hlbiB1cGRhdGluZyBhIHJlYWwgUlRDJ3MgcmVn QSwgaG93IHdpbGwgaXQgdGFrZSBpdCBpbnRvIGVmZmVjdCwgYW5kIG1ha2UgdGhlIHRyYW5zaXRp b24gc21vb3RobHkgaW4gYSByZWFsIFJUQy4NCg0KSSBoYXZlIGJlZW4gdmVyeSBhbnhpb3VzIGlu IGFub3RoZXIgYXNwZWN0LCBpbiBvdXIgdmlydHVhbCBlbnZpcm9ubWVudCwgYXQgY3JlYXRlX3Bl cmlvZGljX3RpbWUsIE5PVygpIG1heSBiZSBmYXIgbW9yZSBsYXRlciB0aGFuIHB0LT5zY2hlZHVs ZWQgc2V0dGVkIGJlZm9yZSwgYXQgdGhpcyBwb2ludCwgdGhlIG5ldyBwdC0+c2NoZWR1bGVkIG1h eSBiZSBmYXIgbW9yZSBiZWhpbmQgdGhlIG9uZSBhZnRlciBleGVjdXRpbmcgY3JlYXRlX3Blcmlv ZGljX3RpbWUuIFNvIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIGJvdGggd2hpY2ggc2hvdWxkIGJlIHRy ZWF0ZWQgYnkgcHRfcHJvY2Vzc19taXNzZWRfdGlja3MgdG8gdGhlIGZvcm1lciBwdC0+c2NoZWR1 bGVkJ3MgcGVyaW9kIGlzIG5vdyBhbGwgdGhyb3duIGF3YXkgYXMgbm90aGluZyBtaXNzZWQuIFNv IEkgdGhpbmsgaG93IHRvIGhhbmRsZSB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBib3RoIHB0LT5zY2hl ZHVsZWQgd29ydGggY29uc2lkZXJhdGlvbiBpbiBjcmVhdGVfcGVyaW9kaWNfdGltZS4NCg0KVGhh bmtzIQ0KDQoNCg0KDQp0dXBlbmcyMTINCg0KRnJvbTogSmFuIEJldWxpY2gNCkRhdGU6IDIwMTIt MDgtMDggMTc6MjANClRvOiB0dXBlbmcyMTINCkNDOiB4ZW4tZGV2ZWwNClN1YmplY3Q6IFJlOiBb WGVuLWRldmVsXSBCaWcgQnVnOlRpbWUgaW4gVk0gcnVubmluZyBvbiB4ZW4gZ29lcyBzbG93ZXIN Cj4+PiBPbiAwNy4wOC4xMiBhdCAxNzo0NCwgdHVwZW5nMjEyIDx0dXBlbmcyMTJAZ21haWwuY29t PiB3cm90ZToNCj4gMiBYZW4NCj4gdm14X3ZtZXhpdF9oYW5kbGVyICAtLT4gLi4uLi4uLi4uIC0t PiBoYW5kbGVfcnRjX2lvICAtLT4gcnRjX2lvcG9ydF93cml0ZSAgLS0+IA0KPiBydGNfdGltZXJf dXBkYXRlIC0tPiBzZXQgUlRDJ3MgUkVHX0EgdG8gYSBoaWdoIHJhdGUtLT4gY3JlYXRlX3Blcmlv ZGljX3RpbWUoZGlzYWJsZSANCj4gdGhlIGZvcm1lciB0aW1lciwgYW5kIGluaXQgYSBuZXcgb25l KQ0KPiBXaW43IGlzIGluc3RhbGxlZCBpbiB0aGUgdm0uIFRoaXMgY2FsbGluZyBwYXRoIGlzIGV4 ZWN1dGVkIHNvIGZyZXF1ZW50IHRoYXQgDQo+IG1heSBjb21lIGRvd24gdG8gc2V0IHRoZSBSVEMn cyBSRUdfQSBodW5kcmVkcyBvZiB0aW1lcyBldmVyeSBzZWNvbmQgYnV0IHdpdGggDQo+IHRoZSBz YW1lIHJhdGUoOTc2LjU2MnVzKDEwMjRIWikpLCBpdCBpcyBzbyBhYm5vcm1hbCB0byBtZSB0byBz ZWUgc3VjaCANCj4gYmVoYXZpb3IuDQoNCl9JZl8gdGhlIHByb2JsZW0gaXMgbWVyZWx5IHdpdGgg dGhlIGhpZ2ggcmF0ZSBvZiBjYWxscyB0bw0KY3JlYXRlX3BlcmlvZGljX3RpbWUoKSwgSSB0aGlu ayB0aGlzIGNvdWxkIGJlIHRha2VuIGNhcmUgb2YgYnkNCmF2b2lkaW5nIHRoZSBjYWxsIChhbmQg cGVyaGFwcyB0aGUgY2FsbCB0byBydGNfdGltZXJfdXBkYXRlKCkgaW4NCnRoZSBmaXJzdCBwbGFj ZSkgYnkgY2hlY2tpbmcgd2hldGhlciBhbnl0aGluZyBhY3R1YWxseSBjaGFuZ2VzDQpkdWUgdG8g dGhlIGN1cnJlbnQgd3JpdGUuIEkgZG9uJ3QgdGhpbmssIGhvd2V2ZXIsIHRoYXQgdGhpcyB3b3Vs ZA0KaGVscCBtdWNoLCBhcyB0aGUgaGlnaCByYXRlIG9mIHBvcnQgYWNjZXNzZXMgKGFuZCBoZW5j ZSB0cmFwcw0KaW50byB0aGUgaHlwZXJ2aXNvcikgd291bGQgcmVtYWluLiBJdCBtaWdodCwgbmV2 ZXJ0aGVsZXNzLCBnZXQNCnlvdXIgaW1tZWRpYXRlIHByb2JsZW0gb2YgdGhlIHRpbWUgc2xvd2lu ZyBkb3duIHRha2VuIGNhcmUgb2YNCmlmIHRoYXQgaXMgY2F1c2VkIGluc2lkZSBYZW4gKGJ1dCB0 aGUgY2F1c2UgaGVyZSBtYXkgYXMgd2VsbCBiZSBpbg0KdGhlIFdpbmRvd3Mga2VybmVsKS4NCg0K PiAzIE9TDQo+IEkgaGF2ZSB0cmllZCB0byBmaW5kIHdoeSB0aGUgd2luNyBzZXR0ZWQgUlRDJ3Mg cmVnQSBzbyBmcmVxdWVudGx5LiBmaW5hbGx5IA0KPiBnb3QgdGhlIHJlc3VsdCwgYWxsIHRoYXQg Y29tZXMgZnJvbSBhIGZ1bmN0aW9uOiBOdFNldFRpbWVyUmVzb2x1dGlvbiAtLT4gDQo+IDB4NzAs MHg3MQ0KPiB3aGVuIEkgYXR0YWNoZWQgd2luZGJnIGludG8gdGhlIGd1ZXN0IE9TLCBJIGFsc28g Zm91bmQgdGhlIHNvdXJjZSwgdGhleSBhcmUgDQo+IGFsbCBjYWxsZWQgZnJvbSBhIHVwcGVyIHN5 c3RlbSBjYWxsIHRoYXQgY29tZXMgZnJvbSBKVk0oSmF2YSBWaXJ0dWFsIA0KPiBNYWNoaW5lKS4N Cg0KR2V0dGluZyBXaW5kb3dzIHRvIGJlIGEgbGl0dGxlIHNtYXJ0ZXIgYW5kIGF2b2lkIHRoZSBw b3J0IEkvTyB3aGVuDQpkb2luZyByZWR1bmRhbnQgd3JpdGVzIHdvdWxkIG9mIGNvdXJzZSBiZSBl dmVuIGJldHRlciwgYnV0IGlzDQpjbGVhcmx5IGEgZGlmZmljdWx0IHRvIGFjaGlldmUgZ29hbC4N Cg0KPiA0IEpWTQ0KPiBJIGRvbid0IGtub3cgd2h5IEpWTSBjYWxscyBOdFNldFRpbWVyUmVzb2x1 dGlvbiB0byBzZXQgdGhlIHNhbWUgUlRDJ3MgcmF0ZSANCj4gZG93biAoOTc2LjU2MnVzKDEwMjRI WikpIHNvIGZyZXF1ZW50bHkuIA0KPiBCdXQgZm91bmQgc29tZXRoaW5nIHVzZWZ1bCwgaW4gdGhl IGphdmEgc291cmNlIGNvZGUsIEkgZm91bmQgbWFueSBwYWxhY2VzIA0KPiB3cml0dGVuIHdpdGgg dGltZS5zY2hlZHVsZUF0Rml4ZWRSYXRlKCksIEluZm9ybWF0aW9ucyBmcm9tIEludGVybmV0IHRv bGQgbWUgDQo+IHRoaXMgZnVuY3Rpb24gc2NoZWR1bGVBdEZpeGVkUmF0ZSBkZW1hbmRzIGEgaGln aGVyIHRpbWUgcmVzb2x1dGlvbi4gc28gSSANCj4gZ3Vlc3MgdGhlIHdob2xlIHByb2Nlc3MgbWF5 IGJlIHRoaXM6IA0KPiBqYXZhIHdhbnRzIGEgaGlnaGVyIHRpbWUgcmVzb2x1dGlvbiB0aW1lciwg c28gaXQgY2hhbmdlcyB0aGUgUlRDJ3MgcmF0ZSBmcm9tIA0KPiAxNS42MjVtcyg2NEhaKSB0byA5 NzYuNTYydXMoMTAyNEhaKSwgYWZ0ZXIgdGhhdCwgaXQgcmVjb25maXJtcyB3aGV0aGVyIHRoZSAN Cj4gdGltZSBpcyBhY2N1cmF0ZSBhcyBleHBlY3RlZCwgYnV0IGl0J3Mgc29ycnkgdG8gZ2V0IHNv bWUgbm90aWNlIGl0ICdzIG5vdCANCj4gYWNjdXJhdGUgZWl0aGVyLiBzbyBpdCBzZXRzICB0aGUg UlRDJ3MgcmF0ZSBmcm9tIDE1LjYyNW1zKDY0SFopIHRvIA0KPiA5NzYuNTYydXMoMTAyNEhaKSBh Z2FpbiBhbmQgYWdhaW4uLi4sIGF0IGxhc3QsIHJlc3VsdHMgaW4gYSBzbG93IHN5c3RlbSB0aW1l ciANCj4gaW4gdm0uDQoNCk5vdyB0aGF0J3MgcmVhbGx5IHRoZSBmdW5kYW1lbnRhbCB0aGluZyB0 byBmaW5kIG91dCAtIHdoYXQgbWFrZXMgaXQNCnRoaW5rIHRoZSBjbG9jayBpc24ndCBhY2N1cmF0 ZT8gSXMgdGhpcyBhbiBhcnRpZmFjdCBvZiBzY2hlZHVsaW5nIChhcw0KdGhlIHNjaGVkdWxlciB0 aWNrIGNlcnRhaW5seSBpcyBzZXZlcmFsIG1pbGxpc2Vjb25kcywgd2hlcmVhcw0KImFjY3VyYXRl IiBoZXJlIGFwcGVhcnMgdG8gcmVxdWlyZSBiZWxvdyAxbXMgZ3JhbnVsYXJpdHkpLCBwZXJoYXBz DQphcyBhIHJlc3VsdCBvZiB0aGUgYm94IGJlaW5nIG92ZXJsb2FkZWQgKGkuZS4gdGhlIFZNIG5v dCBiZWluZyBhYmxlDQp0byBnZXQgc2NoZWR1bGVkIHF1aWNrbHkgZW5vdWdoIHdoZW4gdGhlIHRp bWVyIGV4cGlyZXMpPyBGb3IgdGhhdCwNCmRpZCB5b3UgdHJ5IGxvd2VyaW5nIHRoZSBzY2hlZHVs ZXIgdGltZSBzbGljZSBhbmQvb3IgaXRzIHJhdGUgbGltaXQNCihwb3NzaWJsZSB2aWEgY29tbWFu ZCBsaW5lIG9wdGlvbik/IE9mIGNvdXJzZSBkb2luZyBzbyBtYXkgaGF2ZQ0Kb3RoZXIgdW5kZXNp cmFibGUgc2lkZSBlZmZlY3RzLCBidXQgaXQgd291bGQgYmUgd29ydGggYSB0cnkuDQoNCkRpZCB5 b3UgZnVydGhlciBjaGVjayB3aGV0aGVyIHRoZSBhZGp1c3RtZW50cyBkb25lIHRvIHRoZQ0Kc2No ZWR1bGVkIHRpbWUgaW4gY3JlYXRlX3BlcmlvZGljX3RpbWUoKSBhcmUgcmVzcG9uc2libGUgZm9y IHRoaXMNCmNvbmNsdXNpb24gb2YgdGhlIEpWTSAoY291bGQgYmUgZWZmZWN0aXZlbHkgZG91Ymxp bmcgdGhlIGZpcnN0DQppbnRlcnZhbCBpZiBIVk1fUEFSQU1fVlBUX0FMSUdOIGlzIHNldCwgYW5k IHdpdGggdGhlIGhpZ2ggcmF0ZQ0Kb2YgcmUtc2V0cyB0aGlzIGNvdWxkIGNlcnRhaW5seSBoYXZl IGEgbW9yZSB2aXNpYmxlIGVmZmVjdCB0aGFuDQppbnRlbmRlZCk/DQoNCkphbg== ------=_001_NextPart462848748572_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Jan Beulich:
Thanks for reply! You are a very clever ma= n, you=20 have sensed some thing immediately as I found lately. Please forgive = my so=20 lately reply!
 
1 why JVM set the same rate down so frequently ?
the first achievement I will show is I found the action in JVM and th= e=20 reason by debugging disassembly code.
it seems to me like this in JVM:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 what happened in JVM= =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
while (loop)//or a frequent call
{
timeBeginPeriod() --> NtSetTimerResolution(1(enble))
rc =3D WaitForMultipleObjects(5, 0x2222222, 0,&= nbsp;1); //the last parameter demands 1ms ti= mer resolution
if (rc =3D TIMEOUT){
break;
}
else{
call 0x44444444;
}
timeEndPeriod() --> NtSetTimerResolution(0(disable))
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
so its behavior is totally legal, for it demands higher timer resolut= ion=20 (here 1ms), so it calls NtSetTimerResolution to improve the=20 resolution. 
it is not as I guessed "unaccurate"
I also wrote a tester below, which confirms my suppose. if you are=20 interested in it , you can build it by MS's compiler, and after running th= e=20 tester in VM about 1 minutes, VM's time will slow.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 2 a test which will lead to trigger slowing=20 VM's inner time=3D=3D=3D=3D=3D=3D=3D=3D
#include <stdio.h>
#include <windows.h>
typedef int (__stdcall *NTSETTIMER)(IN ULONG = ;RequestedResolution, IN BOOLEAN Set, OUT PULONG&= nbsp;ActualResolution );
typedef int (__stdcall *NTQUERYTIMER)(OUT PULONG&= nbsp;  MinimumResolution, OUT PULONG MaximumResol= ution, OUT PULONG CurrentResolution );
int main()
{
DWORD min_res =3D 0, max_res =3D 0,&n= bsp;cur_res =3D 0, ret =3D 0;
HMODULE  hdll =3D NULL;
hdll =3D GetModuleHandle("ntdll.dll");
NTSETTIMER AddrNtSetTimer =3D 0;
NTQUERYTIMER AddrNtQueyTimer =3D 0;
AddrNtSetTimer =3D (NTSETTIMER) GetProcAddress(hdll,=  "NtSetTimerResolution");
AddrNtQueyTimer =3D (NTQUERYTIMER)GetProcAddress(hdll,&nb= sp;"NtQueryTimerResolution");
 
while (1)
{
ret =3D AddrNtQueyTimer(&min_res, &max_res= , &cur_res);
printf("min_res =3D %d, max_res =3D %d,&= nbsp;cur_res =3D %d\n",min_res, max_res, cur_res);
Sleep(10);
ret =3D AddrNtSetTimer(10000, 1, &cur_res= );
Sleep(10);
ret =3D AddrNtSetTimer(10000, 0, &cur_res= );
Sleep(10);
}
return 0;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
2 Bug in xen
JVM is OK, so left the bug to xen, I have found both the reason and=20 solution. As Jan mentioned avoiding call create_periodic_time, it got much= =20 better. so I modified it like this, if the pt timer is created b= efore,=20 setting RegA down is just changing the period value, so I do nothing excep= t just=20 setting period to pt's field. it is OK!
I thought pt->scheduled is responsible for Accuracy of pt_process_misse= d_ticks,=20 so we should not interfere it at any outer invading or interruption, so I = let=20 create_periodic_time changed everything but reserved only one=20 filed pt->scheduled as setted before, I am very happy to find the = bug=20 disappear. After I rechecked your mail I found you are really a very smart= man,=20 you have predicted something!
 
Did you further check whether the adjus= tments done to the
scheduled time in create_periodic_time() are = ;responsible for this
conclusion of the JVM (could be effecti= vely doubling the first
interval if HVM_PARAM_VPT_ALIGN is set, and&= nbsp;with the high rate
of re-sets this could certainly have a&= nbsp;more visible effect than
intended)?
 
After I tracked pt->scheduled, more and more truth surfaced. I wil= l show=20 you the RTC's spotting as I observed.
normal spot is like this:
0           &n= bsp;  =20 1            &= nbsp;  2         &n= bsp;    =20 3            &= nbsp;=20  4           &= nbsp;   5
.           =20    .          =  =20    .          =  =20    .         =20      .        =  =20      .      (normal=20 spot)
           &nb= sp;            = ;       =20 |(pt->scheduled at 2)
 
when create_periodic_time interfere pt->schedule at NOW
0           &n= bsp;  =20 1            &= nbsp;  2         &n= bsp;    =20 3            &= nbsp;=20  4           &= nbsp;  =20 5
.           =20    .          =  =20    .          =  =20    .       =20     =20   .           =  =20   .      
           &nb= sp;       =20 |(NOW)           &n= bsp;        =20  | (new pt->scheduled is moved to 3 after ALIGN)
 
so it real spot is like this:
.           =20    .         &= nbsp;     =20             &n= bsp;  .       =20     =20   .           =  =20   .       
0           &n= bsp;  =20 1            &= nbsp;  2         &n= bsp;    =20 3            &= nbsp;=20  4           &= nbsp;  =20 5
           &nb= sp;            = ;        |(here=20 we missed one spot at 2)
 
the original pt->scheduled is at 2 before create_periodic_time wil= l be=20 executed, but after it, pt->scheduled is moved to 3, so missed one spot= to=20 GuestWin.
 
 
3 who is wrong?
I doubt align_timer worth suspected:
s_time_t align_timer(s_time_t firsttick, uint64_t = ;period)
{
    if ( !period )
        return firsttick= ;
 
    return firsttick + (period&nbs= p;- 1) - ((firsttick - 1) % period);=20 //in xen4.x
   =20 return firsttick  - ((firsttick - 1) %&= nbsp;period);//it=20 should be aligned like this.
}
 
I have also found another updating RTC's RegA in=20 tools\ioemu-qemu-xen\hw\MCc146818rtc.c:
 
    if (period_code !=3D 0 &a= mp;& (s->cmos_data[RTC_REG_B] & REG_B_PIE)) = ;{
#endif
        if (period_code&= nbsp;<=3D 2)
           &nb= sp;period_code +=3D 7;
        /* period i= n 32 Khz cycles */
        period =3D = 1 << (period_code - 1);
#ifdef IRQ_COALESCE_HACK
        if(period !=3D&n= bsp;s->period)
           &nb= sp;s->irq_coalesced =3D (s->irq_coalesced * s-&g= t;period) / period;
        s->period =3D=  period;
#endif
        /* compute = 32 khz clock */
        cur_clock =3D&nb= sp;muldiv64(current_time, 32768, ticks_per_sec);=20 //here I don't make sense it ......
        next_irq_clock = =3D (cur_clock & ~(period - 1)) + p= eriod;
        s->next_periodic_t= ime =3D muldiv64(next_irq_clock, ticks_per_sec, 32768)=  + 1;
        qemu_mod_timer(s->= periodic_timer, s->next_periodic_time);
 
 
 
I don't know what happened in real RTC, the most popular RTC chip is MC146818, I have c= hecked its=20 datasheet but found nothing I want. What I want to know is When a real out= er=20 0x71 come down to set RTC's RegA, who does it change or spot the next periodic interrupt time ? In my case, the= period=20 doesn't change, it misses one spot, even if the period changes how will it= spot=20 the next scheduled time?
I= need the=20 man who knows the details deeply concerning when updating a real RTC's reg= A, how=20 will it take it into effect, and make the transition smoothly in= a=20 real RTC.
 
I= have been=20 very anxious in another aspect, in our virtual environment, at=20 create_periodic_time, NOW() may be far more later than pt->schedul= ed=20 setted before, at this point, the new pt->scheduled may be far mor= e=20 behind the one after executing create_periodic_time. So the interval=20 between both which should be treated by pt_process_missed_ticks to th= e=20 former pt->scheduled's period is now all thrown away as nothing mi= ssed.=20 So I think how to handle the interval between both pt->schedu= led=20 worth consideration in=20 create_periodic_time.
 <= /DIV>
Thanks!=
 <= /DIV>
tupeng212
 
Date: 2012-08-08 17:20
To: tupeng212<= /DIV>
CC: xen-devel
Subject: Re: [Xen-devel] Big Bug:Time in VM running on xe= n goes=20 slower
>>> On 07.08.12 at 17:44, tupeng212=  <tupeng212@gmail.com> wrote:
> 2 Xen
> vmx_vmexit_handler  --> ......... --= > handle_rtc_io  --> rtc_ioport_write  = ;--> 
> rtc_timer_update --> set RTC's REG_A=  to a high rate--> create_periodic_time(disabl= e 
> the former timer, and init a = new one)
> Win7 is installed in the vm. = This calling path is executed so frequent&nb= sp;that 
> may come down to set the RTC'= s REG_A hundreds of times every second = but with 
> the same rate(976.562us(1024HZ)), it is=  so abnormal to me to see such 
> behavior.
 
_If_ the problem is merely with the&nbs= p;high rate of calls to
create_periodic_time(), I think this could b= e taken care of by
avoiding the call (and perhaps the call=  to rtc_timer_update() in
the first place) by checking whether an= ything actually changes
due to the current write. I don't = think, however, that this would
help much, as the high rate of por= t accesses (and hence traps
into the hypervisor) would remain. It m= ight, nevertheless, get
your immediate problem of the time slow= ing down taken care of
if that is caused inside Xen (but = the cause here may as well be in
the Windows kernel).
 
> 3 OS
> I have tried to find why the&= nbsp;win7 setted RTC's regA so frequently. f= inally 
> got the result, all that comes&nbs= p;from a function: NtSetTimerResolution --> 
> 0x70,0x71
> when I attached windbg into the&nb= sp;guest OS, I also found the source, t= hey are 
> all called from a upper system&nbs= p;call that comes from JVM(Java Virtual 
> Machine).
 
Getting Windows to be a little smarter&= nbsp;and avoid the port I/O when
doing redundant writes would of course = be even better, but is
clearly a difficult to achieve goal.
 
> 4 JVM
> I don't know why JVM calls Nt= SetTimerResolution to set the same RTC's rat= e 
> down (976.562us(1024HZ)) so frequently. = ;
> But found something useful, in the=  java source code, I found many palaces=  
> written with time.scheduleAtFixedRate(), Inf= ormations from Internet told me 
> this function scheduleAtFixedRate demands&nb= sp;a higher time resolution. so I 
> guess the whole process may be&nbs= p;this: 
> java wants a higher time resolutio= n timer, so it changes the RTC's rate&n= bsp;from 
> 15.625ms(64HZ) to 976.562us(1024HZ), after&n= bsp;that, it reconfirms whether the 
> time is accurate as expected, but&= nbsp;it's sorry to get some notice it '= s not 
> accurate either. so it sets  = the RTC's rate from 15.625ms(64HZ) to 
> 976.562us(1024HZ) again and again..., a= t last, results in a slow system timer&= nbsp;
> in vm.
 
Now that's really the fundamental thing = ;to find out - what makes it
think the clock isn't accurate? Is this=  an artifact of scheduling (as
the scheduler tick certainly is several = ;milliseconds, whereas
"accurate" here appears to require below&nbs= p;1ms granularity), perhaps
as a result of the box being overl= oaded (i.e. the VM not being able
to get scheduled quickly enough when th= e timer expires)? For that,
did you try lowering the scheduler time=  slice and/or its rate limit
(possible via command line option)? Of = course doing so may have
other undesirable side effects, but it = would be worth a try.
 
Did you further check whether the adjus= tments done to the
scheduled time in create_periodic_time() are = ;responsible for this
conclusion of the JVM (could be effecti= vely doubling the first
interval if HVM_PARAM_VPT_ALIGN is set, and&= nbsp;with the high rate
of re-sets this could certainly have a&= nbsp;more visible effect than
intended)?
 
Jan
 
------=_001_NextPart462848748572_=------ --===============4979082272455034970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4979082272455034970==--