From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH V3] xen: Fix BUFIOREQ evtchn init for a stubdom. Date: Mon, 02 Jul 2012 20:37:51 +0100 Message-ID: References: <4FF1E1F1020000780008D29B@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FF1E1F1020000780008D29B@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Anthony PERARD Cc: Xen Devel , Keir Fraser , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 02/07/2012 17:01, "Jan Beulich" wrote: >>>> On 02.07.12 at 17:58, "Jan Beulich" wrote: >>> @@ -3775,19 +3790,16 @@ long do_hvm_op(unsigned long op, >>> XEN_GUEST_HANDLE(void) arg) >>> rc = 0; >>> domain_pause(d); /* safe to change per-vcpu xen_port */ >>> iorp = &d->arch.hvm_domain.ioreq; >>> + if (d->vcpu[0]) >>> + hvm_replace_event_channel(d->vcpu[0], a.value, >>> + >>> (int*)&d->vcpu[0]->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] >>> ); >> >> Did I overlook this in v2? You clearly need to handle the error >> case here (it is being handled, albeit - but that's not your patch's >> fault - only in a rudimentary way, inside the loop). > > Probably it'll be easiest if I - or Keir if he's faster - add this while > committing, to save you from posting another version. I'm travelling so please just go ahead, Jan. K. > Jan >