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

Re: [PATCH v3 05/11] x86/vioapic: switch to use the EOI callback mechanism


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 7 Apr 2021 18:46:57 +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=IQISxLn7cl+Xpu0aBwzT99DyZWyjhTJ0C1evcy3bkkc=; b=eHJwwrrAKFkS/dYR3Nq1S+wJKm2X5vDFJbYMh9ycAUhNhdMnS0n5ETp+BrW288CmoCORp+gejBLqAu4lgr424MpEp47svzYA4wzZ/GJZZP9V0HjgkPOwydIWQg8EpDSCo89a2QGGTT3nkwMS8jEE2y80DwWVHi/T8CaMwuaj4//S88YhY9KaRGQH/S7W66IzeYqU3c/6ET1o6BwODPSYJmzZXesZe7JC7SAfqOgSwymPMmYuXtPZE8Iu+bxE5bVKRYmACvQdkgU2x270nsxZCEX/E0v6/biRA7Cs3UdNp2ex154aCkpbiTicJ4WTeMDw6XFbSc+5DDnnn43svWw37w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TeuADc7OF0XvVGxKF0fkQQ+YgllDAcGmJwIrcY2nAMhN6PE3/1Cj4NhcNAmaMdOEa7Rsrw6ROxhL/cJnN3bhg4foTivdB9onH/nr5kHi6sJTrw7fII+5hRNY0ZSMh/2LpnWyNBmwELUkWYU5MFHQxsAhGF2WD9N7N73Eb37BHNA9y6pLXWfOLB+plpfEpv8TIRq4idHHmhnLcx5QiUlSRVNumR/pBFwMSsy0dn9qvcHEZ72m+39OTuva0rzLfOLq3l81YD+XhnV3sGejkrBryLKho9Q1rrEbLfo8ZyUzECt/UJhjLfvRiwWAzyVWDU7EVtTsEhVOoEIMpJ7lFaTz4w==
  • 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: Wed, 07 Apr 2021 16:47:15 +0000
  • Ironport-hdrordr: A9a23:lDWbQ6pswUNWNvzk/YACWFoaV5v5L9V00zAX/kB9WHVpW+SFis Gjm+ka3xfoiDAXHEotg8yEJbPoex7h3LR+iLNwAZ6JWg76tGy0aLxz9IeK+UyFJwTS1M54kZ 1hfa93FcHqATFB5/rSzQGkH78br+Wv37uvgY7loUtFaSFPR+Ve4xxiCgCde3cGITVuIZYiDp KT6o5milObCBcqR/+2DHUEQOTPzuej/P7bSCULGgI97022hS6ogYSQLzGjwhwcXzlTqI1Sk1 TtrgqR3MSemsD+8DDw/Sv575NamNzuo+EzefCku4wuBRjHziqtbIRlcbWesD4yu/HH0idXrP D85y0OEu42x3TNfnykgRaF4Xie7B8er0XM5HXdoXz/rdf3TDg3YvAx+75xQ1/ixGcL+PRfuZ g7uF6xht5sIj7r2BnZ3ZzuUSpnk0KlyEBS6tI7vjhkfqY1LINKoZd3xjIyLL4wWBjUxaoAC+ dUAMTV9J9tACmnRkGchGVpzdC2N05DZyuucwwHssyR5TBcgGp0+Use3NAehXcN7vsGOuF529 g=
  • Ironport-sdr: WuFP++YhHZrjqPuBny0ZM7r0gtMY9caWhH16cab2eKwVUHAu5ZarjotoZj9uRyPWUvCJJZf95Z bD5gJxWHOHGuhMW2NUoodQ/g2vtuKOunI0exg43zDGe4WAClZHVYE/1ogfzReZ+WNRw0Q8/Crn Gw//pzOlxWMumFpKd2O/P6jxMnL1hk4edRNoDqPM/LE0DgoriryMWfZPxzEBzoYM87T2iSlk4F mi8e/dR244RQnl7l0kgrmYGvlwjcc1obxM5wuv+NedJgli9V/hWSapWX3WALEB7pAy7smc63cS 2kk=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Apr 07, 2021 at 05:19:06PM +0200, Jan Beulich wrote:
> On 31.03.2021 12:32, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vioapic.c
> > +++ b/xen/arch/x86/hvm/vioapic.c
> > @@ -621,7 +624,43 @@ static int ioapic_load(struct domain *d, 
> > hvm_domain_context_t *h)
> >           d->arch.hvm.nr_vioapics != 1 )
> >          return -EOPNOTSUPP;
> >  
> > -    return hvm_load_entry(IOAPIC, h, &s->domU);
> > +    rc = hvm_load_entry(IOAPIC, h, &s->domU);
> > +    if ( rc )
> > +        return rc;
> > +
> > +    for ( i = 0; i < ARRAY_SIZE(s->domU.redirtbl); i++ )
> > +    {
> > +        const union vioapic_redir_entry *ent = &s->domU.redirtbl[i];
> > +        unsigned int vector = ent->fields.vector;
> > +        unsigned int delivery_mode = ent->fields.delivery_mode;
> > +        struct vcpu *v;
> > +
> > +        /*
> > +         * Add a callback for each possible vector injected by a 
> > redirection
> > +         * entry.
> > +         */
> > +        if ( vector < 16 || !ent->fields.remote_irr ||
> > +             (delivery_mode != dest_LowestPrio && delivery_mode != 
> > dest_Fixed) )
> > +            continue;
> > +
> > +        for_each_vcpu ( d, v )
> > +        {
> > +            struct vlapic *vlapic = vcpu_vlapic(v);
> > +
> > +            /*
> > +             * NB: if the vlapic registers were restored before the 
> > vio-apic
> > +             * ones we could test whether the vector is set in the vlapic 
> > IRR
> > +             * or ISR registers before unconditionally setting the 
> > callback.
> > +             * This is harmless as eoi_callback is capable of dealing with
> > +             * spurious callbacks.
> > +             */
> > +            if ( vlapic_match_dest(vlapic, NULL, 0, ent->fields.dest_id,
> > +                                   ent->fields.dest_mode) )
> > +                vlapic_set_callback(vlapic, vector, eoi_callback, NULL);
> 
> eoi_callback()'s behavior is only one of the aspects to consider here.
> The other is vlapic_set_callback()'s complaining if it finds a
> callback already set. What guarantees that a mistakenly set callback
> here won't get in conflict with some future use of the same vector by
> the guest?

Such conflict would only manifest as a warning message, but won't
cause any malfunction, as the later callback would override the
current one.

This model I'm proposing doesn't support lapic vector sharing with
different devices that require EOI callbacks, I think we already
discussed this on a previous series and agreed it was fine.

> And btw - like in the earlier patch you could again pass d instead of
> NULL here, avoiding the need to establish it from current in the
> callback.

On the new version the vlapic callback gets passed a vcpu parameter,
as I will drop the prepatches to remove passing a domain parameter to
vioapic_update_EOI.

> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -192,7 +192,13 @@ void vlapic_set_irq_callback(struct vlapic *vlapic, 
> > uint8_t vec, uint8_t trig,
> >  
> >      if ( hvm_funcs.update_eoi_exit_bitmap )
> >          alternative_vcall(hvm_funcs.update_eoi_exit_bitmap, target, vec,
> > -                          trig || callback);
> > +                          /*
> > +                           * NB: need to explicitly convert to boolean to 
> > avoid
> > +                           * truncation wrongly result in false begin 
> > reported
> > +                           * for example when the pointer sits on a page
> > +                           * boundary.
> > +                           */
> > +                          !!callback);
> 
> I've had quite a bit of difficulty with the comment. Once I realized
> that you likely mean "being" instead of "begin" it got a bit better.
> I'd like to suggest also s/result/resulting/, a comma after "reported",
> and maybe then s/being reported/getting passed/.
> 
> As to explicitly converting to bool, wouldn't a cast to bool do? That's
> more explicitly an "explicit conversion" than using !!.

I've always used !! in the past for such cases because it's shorter, I
can explicitly cast if you prefer that instead.

Thanks, Roger.



 


Rackspace

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