From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77C03C433DF for ; Mon, 6 Jul 2020 07:04:14 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 46CDB20724 for ; Mon, 6 Jul 2020 07:04:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BkGYlwL8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46CDB20724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jsLAO-0002ZU-Ar; Mon, 06 Jul 2020 07:03:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jsLAN-0002ZP-FC for xen-devel@lists.xenproject.org; Mon, 06 Jul 2020 07:03:51 +0000 X-Inumbo-ID: d8045e04-bf56-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x432.google.com (unknown [2a00:1450:4864:20::432]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d8045e04-bf56-11ea-b7bb-bc764e2007e4; Mon, 06 Jul 2020 07:03:50 +0000 (UTC) Received: by mail-wr1-x432.google.com with SMTP id z15so28301457wrl.8 for ; Mon, 06 Jul 2020 00:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=SBKsAA7+u0dXdQjfFG41WcLWxsA+fMDFgWXbL5FWNq4=; b=BkGYlwL8QNt/pwe8xZtOFlgec1ug2f/5YqgqifJMTUwvlYk+sLW4sTDOOGatKXN/Cr 1bG9vOYYfCqyjuptcEJBpzWKz6akQIgKF7PhU8/exfRUnGogogitKCCaXbDY0jVAtbqw TvvBwHyF7558yP4dlAeI98Ee+FExtu7wzzpLa/5PZZ0x/wN24yEIKXdTaokYIm0ArxKM ZbU8irq+sXmKhgWVv0hofVHT58ZlCRczC58jlmTF3vzlygD8xW6XvCo/NZbdLW0IoCyP +4YJ2B5dSKGO2SxViGbC7jihkOn13cp1cltq85jcHGTXN3/Dui6oMEyABsVpB7db7qZS FocA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=SBKsAA7+u0dXdQjfFG41WcLWxsA+fMDFgWXbL5FWNq4=; b=K/jSjLSmkdtVfSqDOhXVDnyoCMcRDxvVhewJsLxpPW2Lvs3tsZUtjaNEkQP/+mfYWj xgB9gKGJP5sByJvVUJ+kanc/4b7D5PoGvxPhlQLNhokitsk7x+MPUOCDUOt1/TTeZNT3 s6Ajodxf+3NCTcIVWCzcyrCB7Z8G8HuznlN5a4bLBMjW2UvjuLO05XELiJf2E/9eI1rt cL87K8DQIz0uY+aabyLP0Ax8bYjFGzXjCDLllilQBQMrMkazkxGIIFousv71xB3+Ug/z KVEavoaSzPsnHybLU/gixUcU1YYWIjfNvhQx9GpeTwiYSlLKysCjE1v3rUSbxHY8tiRs bUVQ== X-Gm-Message-State: AOAM533l4T7/l69nyG/ZUhn2BdVwuMq6j6Prof2+4tww14PA+zV3yNQn MktRX6CoH72UWaj9G5W374s= X-Google-Smtp-Source: ABdhPJzOZ4Azv0pyfItyvCQIEo/vELaJ2ixVp+EAeyuIZQb9/x2pzVhR/02lYFbz3YlEDd7iKvtWaw== X-Received: by 2002:adf:e6c8:: with SMTP id y8mr50099349wrm.40.1594019029689; Mon, 06 Jul 2020 00:03:49 -0700 (PDT) Received: from CBGR90WXYV0 ([2a00:23c5:5782:7500:8191:456f:379d:d246]) by smtp.gmail.com with ESMTPSA id u2sm21773367wml.16.2020.07.06.00.03.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 00:03:49 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Jan Beulich'" , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= References: <20200701090210.GN735@Air-de-Roger> In-Reply-To: Subject: RE: vPT rework (and timer mode) Date: Mon, 6 Jul 2020 08:03:50 +0100 Message-ID: <007a01d65363$9ab7c1d0$d0274570$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG+XT3UL7mtyhdM6X8x294LjZ1FmQGlQU2IApzoD8SpB/prwA== Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 03 July 2020 16:03 > To: Jan Beulich ; Roger Pau Monn=C3=A9 = > Cc: xen-devel@lists.xenproject.org; Wei Liu ; Paul Durrant = > Subject: Re: vPT rework (and timer mode) >=20 > On 03/07/2020 15:50, Jan Beulich wrote: > > On 01.07.2020 11:02, Roger Pau Monn=C3=A9 wrote: > >> It's my understanding that the purpose of pt_update_irq and > >> pt_intr_post is to attempt to implement the "delay for missed = ticks" > >> mode, where Xen will accumulate timer interrupts if they cannot be > >> injected. As shown by the patch above, this is all broken when the > >> timer is added to a vCPU (pt->vcpu) different than the actual = target > >> vCPU where the interrupt gets delivered (note this can also be a = list > >> of vCPUs if routed from the IO-APIC using Fixed mode). > >> > >> I'm at lost at how to fix this so that virtual timers work properly > >> and we also keep the "delay for missed ticks" mode without doing a > >> massive rework and somehow keeping track of where injected = interrupts > >> originated, which seems an overly complicated solution. > >> > >> My proposal hence would be to completely remove the timer_mode, and > >> just treat virtual timer interrupts as other interrupts, ie: they = will > >> be injected from the callback (pt_timer_fn) and the vCPU(s) would = be > >> kicked. Whether interrupts would get lost (ie: injected when a > >> previous one is still pending) depends on the contention on the > >> system. I'm not aware of any current OS that uses timer interrupts = as > >> a way to track time. I think current OSes know the differences = between > >> a timer counter and an event timer, and will use them = appropriately. > > Fundamentally - why not, the more that this promises to be a > > simplification. The question we need to answer up front is whether > > we're happy to possibly break old OSes (presumably ones no-one > > ought to be using anymore these days, due to their support life > > cycles long having ended). >=20 > The various timer modes were all compatibility, and IIRC, mostly for > Windows XP and older which told time by counting the number of timer > interrupts. >=20 > Paul - you might remember better than me? I think it is only quite recently that Windows has started favouring = enlightened time sources rather than counting ticks but an admin may = still turn all the viridian enlightenments off so just dropping ticks = will probably still cause time to drift backwards. Paul >=20 > Its possibly worth noting that issues in this are cause triple faults = in > OVMF (it seems to enable interrupts in its timer handler), and breaks > in-guest kexec (because our timer-targetting logic doesn't work in a = way > remotely close to real hardware when the kexec kernel is booting on a > non-zero vCPU). >=20 > ~Andrew