|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 4/9] ioreq-server: create basic ioreq server abstraction.
>>> On 01.05.14 at 14:08, <paul.durrant@xxxxxxxxxx> wrote:
> Collect together data structures concerning device emulation together into
> a new struct hvm_ioreq_server.
>
> Code that deals with the shared and buffered ioreq pages is extracted from
> functions such as hvm_domain_initialise, hvm_vcpu_initialise and do_hvm_op
> and consolidated into a set of hvm_ioreq_server manipulation functions. The
> lock in the hvm_ioreq_page served two different purposes and has been
> replaced by separate locks in the hvm_ioreq_server structure.
>
> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> bool_t hvm_io_pending(struct vcpu *v)
> {
> - ioreq_t *p = get_ioreq(v);
> + struct hvm_ioreq_server *s = v->domain->arch.hvm_domain.ioreq_server;
> + ioreq_t *p;
>
> - if ( !p )
> + if ( !s )
> return 0;
>
> + p = get_ioreq(s, v);
> return p->state != STATE_IOREQ_NONE;
I don't think you need the variable "p" here anymore.
> @@ -426,14 +431,6 @@ void hvm_do_resume(struct vcpu *v)
> }
> }
>
> -static void hvm_init_ioreq_page(
> - struct domain *d, struct hvm_ioreq_page *iorp)
> -{
> - memset(iorp, 0, sizeof(*iorp));
> - spin_lock_init(&iorp->lock);
> - domain_pause(d);
So where is this ...
> @@ -513,22 +507,15 @@ static int hvm_map_ioreq_page(
> if ( (rc = prepare_ring_for_helper(d, gmfn, &page, &va)) )
> return rc;
>
> - spin_lock(&iorp->lock);
> -
> if ( (iorp->va != NULL) || d->is_dying )
> {
> destroy_ring_for_helper(&va, page);
> - spin_unlock(&iorp->lock);
> return -EINVAL;
> }
>
> iorp->va = va;
> iorp->page = page;
>
> - spin_unlock(&iorp->lock);
> -
> - domain_unpause(d);
... and this going? Or is the pausing no longer needed for a non-
obvious reason?
> +static int hvm_set_ioreq_pfn(struct domain *d, bool_t buf,
> + unsigned long pfn)
> +{
> + struct hvm_ioreq_server *s = d->arch.hvm_domain.ioreq_server;
> + int rc;
> +
> + spin_lock(&s->lock);
> +
> + rc = hvm_map_ioreq_page(s, buf, pfn);
> + if ( rc )
> + goto fail;
> +
> + if (!buf) {
Coding style. I'm afraid this isn't the first time I have to make such a
remark on this series. Please check style before submitting.
> + struct hvm_ioreq_vcpu *sv;
> +
> + list_for_each_entry ( sv,
> + &s->ioreq_vcpu_list,
> + list_entry )
> + hvm_update_ioreq_evtchn(s, sv);
> + }
> +
> + spin_unlock(&s->lock);
> + return 0;
> +
> + fail:
> + spin_unlock(&s->lock);
> + return rc;
> +}
If the function isn't going to change significantly in subsequent
patches, there's no real point here in having the "fail" label and
separate error exit path.
> +static int hvm_replace_event_channel(struct vcpu *v, domid_t remote_domid,
> + evtchn_port_t *p_port)
> +{
> + evtchn_port_t old_port, new_port;
> +
> + new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
> + if ( new_port < 0 )
> + return new_port;
I'm pretty sure I commented on this too in a previous version:
evtchn_port_t is an unsigned type, hence checking it to be negative
is pointless.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |