[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 01/12] x86/rtc: drop code related to strict mode


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 3 May 2021 11:28:40 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NspLC+R+2PU6t7UpGfybhUhxS/7Lh2pavD59GqGib4U=; b=g/IADqZo1IBZSScnjWg3/FncI6RoDSTA76DJ4zFaih6lI609EVIvyadm7LEfARPsXhU3q1ll2L7Uf70PCOdKWrhcFsi/P2cWcNHvSUh2jhHQ9JsdZtqvcHrWDlEUNufe/op9Dg5P+m43FZ+DobL8xziD44f+JjwOtRIzXV1HidZMkGB0r+a88sFN0gaAX1EgQNXtZ3kuOWIY3Y97kG9LBHU6zkUUl+DVhvP972U39UwU1NKuTitITjBVelyVTwTLe77Ml2n1gKhp9rESFRNOnGBLoRJJQ1vMjl2eYpP7U2SgK0QCpBlXWcWx9Unm/b4DO/oySMbC82o+RYJCdKmaBQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DuaWpL0iSEv70wi3RbmsuTh1KHsC1e/2eJti0nxqZLMk0wJSYJa0jduMM2hmQlSP0KkA+090sNXXaYNCc5t748iixUpIffUWwmfYlyB3wBaEGzqg3upQZlf+U/uRkqWKShHkD3e1T45SOJpdQU9ZEdDGxF+dU0BzIUKqFTALMRE23w2wXhjpjdf6qrfzv5oj/vvHOo/H0CIjawMhlfSeIVe6VbO+U96GjL98HFBPPx06dS6/93Bm6K0z4MYC/es5kMuvFC8REhI8yYi/dFzWT4AUKx/Wz6EPzjBKUEJxoI1l/GaOu/6x7lSfC6bgYwr9gVlA/PK3/FvwDrOWu2x8sw==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 03 May 2021 09:29:12 +0000
  • Ironport-hdrordr: A9a23:uho5oKhxtIbXjb6jFFMRaJXZWXBQXwh13DAbvn1ZSRFFG/Gwv9 yynfgdyB//gCsQXnZlotybJKycWxrnmKJdy4N5B9efdSPhv3alK5wn0Jv6z1TbaknD38N+9Y MlSahxD9XsEUN35PyR3CCUG8stqePpzImGnuHbpk0CcShPS4VNqzh0ERyaFEoefngiObMcGI CH7sRK4xqMEE5nDfiTPXUOU+jdq9CjrvuPDSIuPBI79BKIyQqh9b+SKXOl9y0DWDBCy6pKyx mmryXF4MyY0s2T+1vn+EL4q79Xn9bgzdUrPr3wtuElbg/CpyztSIBoW7iptC04rue1+D8R4a XxiiZlBetfwTf8eXy0vAvM1mDboUkTwk6n83C0qz/CptH0Xz0zAcYpv/MmTjLpr3AOkfs59Y Aj5RP/i7NnSSnusQ642v3zEzZtrUawqWpKq59ps1VvFbEwRZUUkZYS5ypuYfE9NRO/0q8LOs 90AvrR4f5HGGnqFUzxjy1UzNugUm9bJGb+fmEy/sic0z1hlHtk1UcvxMsGgnca9J4mIqM0n9 j5Dg==
  • Ironport-sdr: 3s1/vaJtYC7YHP9js9sRHnafOMfC/88T35deNbb6toy7WiBnURkXrYaitIJw3ZT9c9ZYcRqk4a //dk40FWYT3pHtNmYhPRhIS0EHqg0yR4mVIPgibl4aWSxsAvk3HNurvXqil6yDwxOn2J5aLcKx k1XwWjNK4eL2aBu5yq+e+oZVFqSIrJGDRa/2cibtnFU0x6Uk+Sp8TDxKWVuO2T1MwvoTNybPrE tYtnjUTE/wEozs4fOCoR7gN/QQk/SyvtJSuqgx8mEJ7kQ4RIgGPpjgoNjq0Q9D5hEcUuNStXMx Zpo=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 29, 2021 at 04:53:07PM +0200, Jan Beulich wrote:
> On 20.04.2021 16:07, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/rtc.c
> > +++ b/xen/arch/x86/hvm/rtc.c
> > @@ -46,15 +46,6 @@
> >  #define epoch_year     1900
> >  #define get_year(x)    (x + epoch_year)
> >  
> > -enum rtc_mode {
> > -   rtc_mode_no_ack,
> > -   rtc_mode_strict
> > -};
> > -
> > -/* This must be in sync with how hvmloader sets the ACPI WAET flags. */
> > -#define mode_is(d, m) ((void)(d), rtc_mode_##m == rtc_mode_no_ack)
> > -#define rtc_mode_is(s, m) mode_is(vrtc_domain(s), m)
> 
> Leaving aside my concerns about this removal, I think some form of
> reference to hvmloader and its respective behavior should remain
> here, presumably in form of a (replacement) comment.

What about adding a comment in rtc_pf_callback:

/*
 * The current RTC implementation will inject an interrupt regardless
 * of whether REG_C has been read since the last interrupt was
 * injected. This is why the ACPI WAET 'RTC good' flag must be
 * unconditionally set by hvmloader.
 */

> > @@ -337,8 +336,7 @@ int pt_update_irq(struct vcpu *v)
> >      {
> >          if ( pt->pending_intr_nr )
> >          {
> > -            /* RTC code takes care of disabling the timer itself. */
> > -            if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) &&
> > +            if ( pt_irq_masked(pt) &&
> >                   /* Level interrupts should be asserted even if masked. */
> >                   !pt->level )
> >              {
> 
> I'm struggling to relate this to any other part of the patch. In
> particular I can't find the case where a periodic timer would be
> registered with RTC_IRQ and a NULL private pointer. The only use
> I can find is with a non-NULL pointer, which would mean the "else"
> path is always taken at present for the RTC case (which you now
> change).

Right, the else case was always taken because as the comment noted RTC
would take care of disabling itself (by calling destroy_periodic_time
from the callback when using strict_mode). When no_ack mode was
implemented this wasn't taken into account AFAICT, and thus the RTC
was never removed from the list even when masked.

I think with no_ack mode the RTC shouldn't have this specific handling
in pt_update_irq, as it should behave like any other virtual timer.
I could try to split this as a separate bugfix, but then I would have
to teach pt_update_irq to differentiate between strict_mode and no_ack
mode.

Would you be fine if the following is added to the commit message
instead:

"Note that the special handling of the RTC timer done in pt_update_irq
is wrong for the no_ack mode, as the RTC timer callback won't disable
the timer anymore when it detects the guest is not reading REG_C. As
such remove the code as part of the removal of strict_mode, and don't
special case the RTC timer anymore in pt_update_irq."

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.