|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH V1 11/16] xen/ioreq: Introduce hvm_domain_has_ioreq_server()
> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 16 September 2020 09:05
> To: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>; Paul Durrant <paul@xxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Oleksandr Tyshchenko
> <oleksandr_tyshchenko@xxxxxxxx>; Stefano
> Stabellini <sstabellini@xxxxxxxxxx>; Julien Grall <julien@xxxxxxx>; Volodymyr
> Babchuk
> <Volodymyr_Babchuk@xxxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Wei
> Liu <wl@xxxxxxx>; Roger
> Pau Monné <roger.pau@xxxxxxxxxx>; Julien Grall <julien.grall@xxxxxxx>
> Subject: Re: [PATCH V1 11/16] xen/ioreq: Introduce
> hvm_domain_has_ioreq_server()
>
> On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> >
> > This patch introduces a helper the main purpose of which is to check
> > if a domain is using IOREQ server(s).
> >
> > On Arm the benefit is to avoid calling handle_hvm_io_completion()
> > (which implies iterating over all possible IOREQ servers anyway)
> > on every return in leave_hypervisor_to_guest() if there is no active
> > servers for the particular domain.
> >
Is this really worth it? The limit on the number of ioreq serves is small...
just 8. I doubt you'd be able measure the difference.
> > This involves adding an extra per-domain variable to store the count
> > of servers in use.
>
> Since only Arm needs the variable (and the helper), perhaps both should
> be Arm-specific (which looks to be possible without overly much hassle)?
>
> > --- a/xen/common/ioreq.c
> > +++ b/xen/common/ioreq.c
> > @@ -38,9 +38,15 @@ static void set_ioreq_server(struct domain *d, unsigned
> > int id,
> > struct hvm_ioreq_server *s)
> > {
> > ASSERT(id < MAX_NR_IOREQ_SERVERS);
> > - ASSERT(!s || !d->arch.hvm.ioreq_server.server[id]);
> > + ASSERT((!s && d->arch.hvm.ioreq_server.server[id]) ||
> > + (s && !d->arch.hvm.ioreq_server.server[id]));
>
> For one, this can be had with less redundancy (and imo even improved
> clarity, but I guess this latter aspect my depend on personal
> preferences):
>
> ASSERT(d->arch.hvm.ioreq_server.server[id] ? !s : !!s);
>
> But then I wonder whether the original intention wasn't rather such
> that replacing NULL by NULL is permissible. Paul?
>
Yikes, that's a long time ago.. but I can't see why the check for !s would be
there unless it was indeed intended to allow replacing NULL with NULL.
Paul
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |