This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Fri, 17 Aug 2007 21:12:28 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 17 Aug 2007 13:12:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070816153415.GH16779@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070816124939.GA16779@xxxxxxxxxx> <C2EA077C.14489%keir@xxxxxxxxxxxxx> <20070816153415.GH16779@xxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Aug 16, 2007 at 04:34:15PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 16, 2007 at 01:54:04PM +0100, Keir Fraser wrote:
> > On 16/8/07 13:49, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
> > 
> > >> Are these patches intended to be applied now, or are they RFC?
> > > 
> > > They could be applied now, but was expecting people might have some 
> > > feedback
> > > /recommendations for changes - Christian normally has lots of good 
> > > comments
> > > for QEMU related stuff. So if I have to do another revision of the patches
> > > I'm fine with it.
> > 
> > My own feeling is that the xenfb merge is very sensible, but I don't see
> > much of a win from merging xenconsoled, and the downside is that you then
> > need a qemu-dm instance for every PV guest. I think that requiring qemu-dm
> > for more 'featureful' PV guests -- framebuffer, USB, etc -- is well and
> > good, but someone who is running more minimal domU configurations --
> > console, net, block -- isn't going to want or welcome the rather unnecessary
> > per-domU overhead of qemu-dm.
> Yep, I can see that would be useful for some folks working in constrained
> environments. Of course they probably don't want the XenD overhead either,
> but that's a can of worms I won't get into right now ;-)
> Thinking about this, I think I can easily re-work the last two patches so
> that xenconsoled will continue to process the guest consoles, if-and-only-if
> the guest doesn't have a QEMU instance already doing it. That would give us
> choice between both deployment scenarios per-guest.

I've got this working ok - since both xenconsoled and qemu-dm are already
reading the /local/domain/<id>/console/ path in xenstore, I simply added
an extra field 'use-device-model' which can be 1 or 0. If XenD sees that
a PV domain has a device model then it sets it to 1, causing xenconsoled
to ignore that guest. I'll post patches to this effect over the weekend

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Xen-devel mailing list