[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 |