|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH V1 02/16] xen/ioreq: Make x86's IOREQ feature common
On 22.09.2020 17:05, Oleksandr wrote:
> 2. *arch.hvm.params*: Two functions that use it
> (hvm_alloc_legacy_ioreq_gfn/hvm_free_legacy_ioreq_gfn) either go into
> arch code completely or
> specific macro is used in common code:
>
> #define ioreq_get_params(d, i) ((d)->arch.hvm.params[i])
If Arm has the concept of params, then perhaps. But I didn't think
Arm does ...
> I would prefer macro than moving functions to arch code (which are
> equal and should remain in sync).
Yes, if the rest of the code is identical, I agree it's better to
merely abstract away small pieces like this one.
> 3. *arch.hvm.hvm_io*: We could also use the following:
>
> #define ioreq_get_io_completion(v) ((v)->arch.hvm.hvm_io.io_completion)
> #define ioreq_get_io_req(v) ((v)->arch.hvm.hvm_io.io_req)
>
> This way struct hvm_vcpu_io won't be used in common code as well.
But if Arm needs similar field, why keep them in arch.hvm.hvm_io?
> --- a/xen/common/ioreq.c
> +++ b/xen/common/ioreq.c
> @@ -194,7 +194,7 @@ static bool hvm_wait_for_io(struct hvm_ioreq_vcpu
> *sv, ioreq_t *p)
> bool handle_hvm_io_completion(struct vcpu *v)
> {
> struct domain *d = v->domain;
> - struct hvm_vcpu_io *vio = &v->arch.hvm.hvm_io;
> + ioreq_t io_req = ioreq_get_io_req(v);
> struct hvm_ioreq_server *s;
> struct hvm_ioreq_vcpu *sv;
> enum hvm_io_completion io_completion;
> @@ -209,14 +209,14 @@ bool handle_hvm_io_completion(struct vcpu *v)
> if ( sv && !hvm_wait_for_io(sv, get_ioreq(s, v)) )
> return false;
>
> - vio->io_req.state = hvm_ioreq_needs_completion(&vio->io_req) ?
> + io_req.state = hvm_ioreq_needs_completion(&io_req) ?
> STATE_IORESP_READY : STATE_IOREQ_NONE;
This is unlikely to be correct - you're now updating an on-stack
copy of the ioreq_t instead of what vio points at.
> msix_write_completion(v);
> vcpu_end_shutdown_deferral(v);
>
> - io_completion = vio->io_completion;
> - vio->io_completion = HVMIO_no_completion;
> + io_completion = ioreq_get_io_completion(v);
> + ioreq_get_io_completion(v) = HVMIO_no_completion;
I think it's at least odd to have an lvalue with this kind of a
name. Perhaps want to drop "get" if it's really meant to be used
like this.
> @@ -247,7 +247,7 @@ static gfn_t hvm_alloc_legacy_ioreq_gfn(struct
> hvm_ioreq_server *s)
> for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
> {
> if ( !test_and_clear_bit(i, &d->ioreq_gfn.legacy_mask) )
> - return _gfn(d->arch.hvm.params[i]);
> + return _gfn(ioreq_get_params(d, i));
> }
>
> return INVALID_GFN;
> @@ -279,7 +279,7 @@ static bool hvm_free_legacy_ioreq_gfn(struct
> hvm_ioreq_server *s,
>
> for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
> {
> - if ( gfn_eq(gfn, _gfn(d->arch.hvm.params[i])) )
> + if ( gfn_eq(gfn, _gfn(ioreq_get_params(d, i))) )
> break;
> }
> if ( i > HVM_PARAM_BUFIOREQ_PFN )
And these two are needed by Arm? Shouldn't Arm exclusively use
the new model, via acquire_resource?
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |