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

Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.



On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
>> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
>> parameter. This patch changes the ownership of the buifioreq event channel to
>> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
>>
>> This fix the initialization of QEMU inside the stubdomain.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>
> This fixes stub domains for me, thanks.
>
> The user of this field (hvm_buffered_io_send) takes iorp->lock so we
> probably want to put the update inside that too, just like for the
> non-buffered case?

Will do.

> It would be nice to extract the alloc&replace functionality into a
> helper.

I tried but it does not work well.
xen_port is an it (non-buffer case) and params[bufioreq...] is an
uint64_t. Both should be argument of the helper, as a pointer to be
pass to xchg().

The prototype of the not working helper:
static int hvm_replace_event_channel(struct vcpu *v, uint64_t
remote_domid, int *port)

So unless there is another way to create this helper, there won't be any.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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