From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UownX-0007mB-7c for qemu-devel@nongnu.org; Tue, 18 Jun 2013 10:22:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UownR-0002p5-Nt for qemu-devel@nongnu.org; Tue, 18 Jun 2013 10:22:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UownR-0002ox-Bh for qemu-devel@nongnu.org; Tue, 18 Jun 2013 10:22:09 -0400 Date: Tue, 18 Jun 2013 17:22:52 +0300 From: "Michael S. Tsirkin" Message-ID: <20130618142252.GB11222@redhat.com> References: <1371554221-5762-1-git-send-email-paul.durrant@citrix.com> <51C054A6.70308@redhat.com> <20130618125158.GA23792@redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0049B46@LONPEX01CL01.citrite.net> <20130618130143.GA29113@redhat.com> <51C05D1A.9050208@redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0049C11@LONPEX01CL01.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0049C11@LONPEX01CL01.citrite.net> Subject: Re: [Qemu-devel] [PATCH 0/2] Remove hardcoded xen-platform device initialization (v4) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Durrant Cc: Laszlo Ersek , "qemu-devel@nongnu.org" On Tue, Jun 18, 2013 at 01:15:57PM +0000, Paul Durrant wrote: > > -----Original Message----- > > From: Laszlo Ersek [mailto:lersek@redhat.com] > > Sent: 18 June 2013 14:14 > > To: Michael S. Tsirkin > > Cc: Paul Durrant; qemu-devel@nongnu.org > > Subject: Re: [Qemu-devel] [PATCH 0/2] Remove hardcoded xen-platform > > device initialization (v4) > > > > On 06/18/13 15:01, Michael S. Tsirkin wrote: > > > On Tue, Jun 18, 2013 at 12:57:54PM +0000, Paul Durrant wrote: > > >>> -----Original Message----- > > >>> From: Michael S. Tsirkin [mailto:mst@redhat.com] > > >>> Sent: 18 June 2013 13:52 > > >>> To: Laszlo Ersek > > >>> Cc: Paul Durrant; qemu-devel@nongnu.org > > >>> Subject: Re: [Qemu-devel] [PATCH 0/2] Remove hardcoded xen- > > platform > > >>> device initialization (v4) > > >>> > > >>> On Tue, Jun 18, 2013 at 02:37:58PM +0200, Laszlo Ersek wrote: > > >>>> Hi Paul, > > >>>> > > >>>> (xen-devel snipped) > > >>>> > > >>>> On 06/18/13 13:16, Paul Durrant wrote: > > >>>>> Because of concerns over backwards compatibility and a suggestion > > that > > >>>>> xenfv should be retired in favour of using the pc machine type I have > > re- > > >>>>> worked my original patch into 2 patches: > > >>>>> > > >>>>> [PATCH 1/2] Allow use of pc machine type (accel=xen) for Xen HVM > > >>>>> [PATCH 2/2] Move hardcoded initialization of xen-platform device. > > >>>>> > > >>>>> Application of both these patches allows alternative pc machine types > > to > > >>> be > > >>>>> used with the accel=xen option, but preserves the hardcoded > > creation of > > >>>>> the xen-platform device only for machine type xenfv. > > >>>>> > > >>>>> v3: > > >>>>> - Add test for xen_enabled() that went missing in v2 > > >>>>> > > >>>>> v4: > > >>>>> - Remove erroneous whitespace hunk > > >>>>> - Replace hw_error() with fprintf()+exit(1) > > >>>>> - Add braces to single-line if > > >>>> > > >>>> can you please offer an opinion in the > > >>>> > > >>>> [PATCH 1/2] pvpanic: initialization cleanup > > >>>> http://thread.gmane.org/gmane.comp.emulators.qemu/216940 > > >>>> > > >>>> thread? > > >>>> > > >>>> >From where I stand (which is "quite afar" :)) this series of yours seems > > >>>> somewhat related to my doubt there. > > >>>> > > >>>> Thanks! > > >>>> Laszlo > > >>> > > >>> OK will make it skip fwcfg as we did earlier. > > >>> Thanks for the review. > > >>> > > >> > > >> Yes, I think the assert(fw_cfg) would be problematic in the xen case > > where, up until my patch, machine types was necessarily xenfv. > > >> > > >> Paul > > > > > > Do you guys actually need the pvpanic device? > > > How do you know which port to use without fwcfg? > > > > Xen domains don't know the port and don't use the pvpanic device, but > > qemu starts at least. In other words, the pvpanic device is created, but > > unreachable. Maybe the has_pvpanic logic should depend on (or extended > > with) !xen_enabled(). > > > > That seems entirely reasonable to me. > > Paul We can just skip creating the device if there's no fw cfg.